INSIGHTi
Systemic Vulnerabilities in Information
Technology—Log4Shell
Updated December 21, 2021
On December, 9, 2021 a critical vulnerability in software used by mil ions of internet servers was
discovered. Since its discovery both criminals and nation-state actors have reportedly exploited it. It is
unclear how many entities are vulnerable, but it is presumed there are many. This CRS Insight describes
the vulnerability and considerations for federal government response.
Log4Shell
Log4j is an open-source tool the Apache Foundation makes available for logging web server activity. To
do this, Log4J has to access many network services (e.g., network maps and directories). Malicious actors
discovered a way to use the Log4j tool to send the servers commands that in turn gives them control of
the servers. The cybersecurity community has named this vulnerability Log4Shel .
Log4Shel exploits have been observed throughout December. Some actors have used Log4Shel -hijacked
servers to mine for cryptocurrencies and expand botnets.
Apache Foundation software is very useful and freely available, so it is widely used. Hundreds of
software projects maintained by the foundation rely on volunteer developers and are supported by
donations and sponsorships.
Current Responses
The Apache Foundation has released an updated version of Log4j which remediates the vulnerability.
However, deploying this solution is not as straightforward as with other vulnerabilities (i.e., applying the
patch).
1. Deploying the solution is logistical y complex, as Log4j is not part of a single software
platform. Instead it is a part of many different web services. Users wil have to identify
al instances of its use and in some cases recompile software using the patched version.
Congressional Research Service
https://crsreports.congress.gov
IN11824
CRS INSIGHT
Prepared for Members and
Committees of Congress

---

Congressional Research Service
2
2. Vulnerable versions of the software go back nearly a decade, and some instances may be
used in software that is no longer maintained.
3. End users may not be aware that they are vulnerable because they are unaware that the
web services they rely on use this tool. Some may have difficulty enumerating which
servers and applications are vulnerable.
The private sector has taken several steps to minimize the exploitation of Log4Shel . Companies have
produced security alerts to inform their customers and their broader community. Companies have updated
their anti-malware programs to detect potential exploits of the vulnerability. Others have deployed rules to
detect the types of queries that would compromise servers. Some have published mitigation guidance.
The federal government has also moved to mitigate this vulnerability. The Cybersecurity and
Infrastructure Security Agency (CISA) created a new website with guidance on the vulnerability. CISA is
using the Joint Cyber Defense Collaborative (JCDC) to manage the incident. The creation of the JCDC
executed a recommendation from the Cyberspace Solarium Commission and was enacted last year. In
addition to the private sector, CISA is leveraging the Federal Bureau of Investigation and the National
Security Agency in this response.
Per Emergency Directive 22-02, agencies have until December 23 to remediate the vulnerability in their
internet-connected systems. For federal agencies, CISA added Log4Shel to its Known Exploited
Vulnerabilities Catalog, which requires agency action regardless of whether an agency system is operated
by the agency or a third-party (e.g., a cloud service provider).
The White House has not disclosed whether it has activated a Cyber Unified Coordination Group or is
using the National Cyber Incident Response Plan in this response, as it did during the SolarWinds
response.
Options for Congress
This is not the first time the cybersecurity community has had to address this type of systemic
vulnerability in information and communications technology. In 2014, government and private sector
entities coordinated to resolve the Heartbleed bug. In that case too, the critical vulnerability existed in
widely used open-source software. Lessons from that response are being applied to Log4Shel ’s response,
but also highlight opportunities for policy changes.
Policymakers may choose to explore the creation of a specific capability to address systemic
vulnerabilities in the future. The JCDC can support public and private sector actions to address
Log4Shel . But the involvement of the JCDC does not activate new authorities, and remediation wil rely
on entities using their existing authorities and capabilities. Congress may choose to direct a federal
agency to build a capability to assist the open source community in identifying and remediating
vulnerabilities. Dedicated resources may help to al eviate some chal enges that open-source projects face,
such as volunteer developers not being able to commit time to identifying and resolving security issues in
the same way that corporate and proprietary software developers can. Once such capability may be to
authorize an agency to proactively scan the internet to discover potential y vulnerable servers and notify
their owners. CISA has a technical capability to do this, but their authority requires entities to request
scanning. But, some may view this type of activity as unwanted, and it may trigger incident response
teams at unaware organizations—procedures on capability use and limitations wil need to be developed.
Additional y, policymakers may explore opportunities to strengthen public-private partnerships to address
malicious actors exploiting vulnerabilities. The federal government and private companies have
coordinated their actions to disrupt botnet operations in the past. However, the authority to do so is ad-hoc
and entities frequently rely on court orders to empower them to move against malicious infrastructure.
Some in Congress have proposed empowering agencies to take additional actions against malicious

---

Congressional Research Service
3
infrastructure. Policymakers may choose to examine what additional authorities may be granted to federal
agencies seeking to identify the infrastructure malicious actors use, conditions under which agencies may
take action against that infrastructure, what options agencies may pursue (e.g., confiscating servers), and
what protections private entities may have for assisting and partnering with agencies.
Policymakers may seek to create greater transparency in the software supply chain. When users acquire
and deploy software, they may only be familiar with the end product and may be oblivious to the
underlying components used to build that product. Policymakers may choose to enact proposals on
software bil s of materials (SBOMs) which would require software developers to disclose which software
packages went into their final products. This transparency would speed up the discovery of potential y
vulnerable information technology (IT). The federal government has recently required SBOMs for agency
IT.

Author Information

Chris Jaikaran

Analyst in Cybersecurity Policy




Disclaimer
This document was prepared by the Congressional Research Service (CRS). CRS serves as nonpartisan shared staff
to congressional committees and Members of Congress. It operates solely at the behest of and under the direction of
Congress. Information in a CRS Report should not be relied upon for purposes other than public understanding of
information that has been provided by CRS to Members of Congress in connection with CRS’s institutional role.
CRS Reports, as a work of the United States Government, are not subject to copyright protection in the United
States. Any CRS Report may be reproduced and distributed in its entirety without permission from CRS. However,
as a CRS Report may include copyrighted images or material from a third party, you may need to obtain the
permission of the copyright holder if you wish to copy or otherwise use copyrighted material.

IN11824 · VERSION 3 · UPDATED

---