Log4Shell – 2.17.x Vulnerable Again? Demystifying CVE-2021-44228

log4j log4shell new vulnerability cve-2021-44228

So another version of a potential RCE has lightened up the web including some controversy around the disclosure and what’s a vulnerability.

Some Timeline of the Log4j

Below is a timeline of the discovery of Log4Shell and its effects:

  • July 2014 – Log4j v2 was released
  • Aug 5 2015 – Log4j 2 1.4 was released in response to the previous vulnerabiltiies
  • November 26 2021: MITRE assigns the CVE identifier CVE-2021-44228
  • November 29 2021: An issue, LOG4J2-3198, is created to fix the vulnerability
  • November 30 2021: The commit fixing the vulnerability is pushed to the Log4j codebase
  • December 09 2021: On December 9, 2021, a zero-day vulnerability involving arbitrary code execution in Log4j 2 was published by the Alibaba Cloud Security Team and given the descriptor “Log4Shell”.
  • December 10 2021: LunaSec publishes an analysis and detailed advisory of the vulnerability
  • December 10 2021: Mass scanning and exploitation attempts of the vulnerability are recorded (see: Greynoise analysis)
  • December 15 2021: CVE-2021-45046 update
  • December 18 2021: CVE-2021-45105 additional CVE with DDoS
  • December 28 2021: CVE-2021-44832 gets released with the newer version 2.17.1 and 2.12.4 following briefly after


First of all let’s put some context, this vulnerability is not easy to exploit as the original CVE-2021-44228 has kicked off the whole internet’s hornet nest (for good reason)

This vulnerability was original disclosed by Yaniv Nizry a researcher of Checkmarx,

This early disclosure did of course cause a storm as it was released on the web before the team of apache could act on it and publish a resolution…nonetheless CVE was assigned quickly and resolution (2.17.1) was released promptly

The post/disclosure flared up and caused several security researchers to animatedly comment (to say the least).

Immediately after a clarification came from Yaniv that the vulnerability was triggered in an arbitrary mode (not always triggered) and under specific circumstances

With the following comments and a few others that spent quite a lot of time verifying 2.17.0 solidity like  234.

The vulnerability

CVE-2021-44832, with 6.6 CVSS score, concerns non-default scenarios of Log4j versions from 2.0-beta7 up to and including 2.17.0.

following some time another researcher (Aaditya Purani) discovered an alternative way to get a much more malicious version of the RCE:

The controversy was sparked mostly by CVE assignment and the immediate request as there are a lot of applications using config files where you can specify the JNDI address to fetch the JDBC data source as discussed here:


Should you panic and update the whole system? Our suggestion is to assess whether the vulnerability really can affect you with testing (some tooling below). Nonetheless, the 2.17.0/1 remains the most secure and you should consider a path to resolution as per the matrix above or at least perform an assessment if the vulnerability is exploitable, prioritizing the one that are visible from external networks.

“This is why research and reporting of vulnerabilities done by the community is a boon to open source. But It can quickly become a bane if not done responsibly.”

The topic of open source maintenance and disclosure remains hot with the following quotes

“One of the biggest takeaways from the events surrounding Log4j is that it is humanly impossible for maintainers of open source projects to cover each and every attack vector while fixing known vulnerabilities.”

“Irresponsible disclosures stand to undermine the work of open source projects, as well as their maintainers and this issue will only grow bigger if not addressed.”

Early disclosure can expose organizations to vulnerabilities and attacks as clearly happened with the public disclosure on the 9th of December Log4Shell PoC exploit leak following a firm hit by a $5 million ransom demand, following a successful Log4Shell attack after the PoC exploit leaked.

Latest List of vulnerable vendors:

The Log4j library is frequently used in software and the links below provide a non-exhaustive list of vulnerable products:

Our deepest support goes to them and all the vendor e-mail that has gone around 🙂

We have instead been silent and helping organizations where they can and if they need more they can ask later (karma anyone )

Some good elements and flow have gone out to test for vulnerability

You can refer to the original existing report here and our overall vulnerability page updated with the latest data here


Some good news and attention from National Cyber Security Centre on cyber security impact. You can see the full post here

The challenges organisations face are, therefore:

  • asset inventory and application composition
  • where are deployed and how they get affected
  • prioritizing the ones that are internet-facing
  • monitor and threat model as well as real-world assessment (test and check if you see an answer back)

No Change to the advice:

users should upgrade according to their version of Java.

  • Java 8 or later: v.2.17.1, available on Maven Central
  • Java 7: v.2.12.4
  • Java 6: v.2.3.2
  • Older releases: confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java.

Mitigation and testing

We are maintaining a mindmap of resolution ourselves to track all the variation and remediation but most importantly how to tackle Vulnerability at scale

check the latest version of the vulnerable vendors

Mitigation and Update for Log4Shell

Scanners Available:

Scan & Remediation

Just scan:

Read More

For more information look at log4shell summary page with details on the flow and the original post on the vulnerability

Other References


CISA Github:

Apache Vuln page:

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

Critical Alert: Discover the implications of the Lace Tempest CVE-2023-47246 vulnerability in SysAid software, exploited by the notorious ransomware group TA505 also known as cl0p. Learn path traversal flaw, Microsoft’s insights, and urgent patching advice. Stay informed on the latest in cybersecurity with Phoenix Security’s insights and solutions for mitigating this high-impact ransomware threat. Focus on your vulnerability management program and application security program
Francesco Cipollone

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.

x Logo: ShieldPRO
This Site Is Protected By