We use cookies to ensure you get the best experience on our website.Read moreRead moreGot it

close
  • Products
    • Products
      • Snyk Code (SAST)
        Secure your code as it’s written
      • Snyk Open Source (SCA)
        Avoid vulnerable dependencies
      • Snyk Container
        Keep your base images secure
      • Snyk Infrastructure as Code
        Develop secure cloud infrastructure
      • Snyk Cloud
        Keep your cloud environment secure
    • Solutions
      • Application security
        Build secure, stay secure
      • Software supply chain security
        Mitigate supply chain risk
      • Cloud security
        Build and operate securely
    • Platform
      • What is Snyk?
        Developer-first security in action
      • Developer security platform
        Modern security in a single platform
      • Security intelligence
        Comprehensive vulnerability data
      • License compliance management
        Manage open source usage
      • Snyk Learn
        Self-service security education
  • Resources
    • Using Snyk
      • Documentation
      • Vulnerability intelligence
      • Product training
      • Support & services
      • Support portal & FAQ’s
      • User hub
    • learn & connect
      • Blog
      • Community
      • Events & webinars
      • DevSecOps hub
      • Developer & security resources
    • Listen to the Cloud Security Podcast, powered by Snyk
  • Company
    • About Snyk
    • Customers
    • Partners
    • Newsroom
    • Snyk Impact
    • Contact us
    • Jobs at Snyk We are hiring
  • Pricing
Log inBook a demoSign up
All articles
  • Application Security
  • Cloud Native Security
  • DevSecOps
  • Engineering
  • Partners
  • Snyk Team
  • Show more
    • Vulnerabilities
    • Product
    • Ecosystems
Application SecurityEngineeringOpen SourceProductVulnerabilities

Log4j 2.16 High Severity Vulnerability (CVE-2021-45105) Discovered

Jason Lane, Benji Catabi-KalmanDecember 18, 2021

Overnight, it was disclosed by Apache that Log4j version 2.16 is also vulnerable by way of a Denial of Service attack with the impact being a full application crash, the severity for this is classified as High (7.5). Snyk is currently not aware of any fully-fledged PoCs or exploits in circulation. CVE-2021-45105 has been issued, and a new fixed version (2.17.1) has been published by Apache which we recommend upgrading to.

Snyk’s Research team is staying on top of this dynamic Log4j situation and will continue to provide vulnerability details the moment we know about them. 

Should I move up to the new version?

It’s always important to eliminate vulnerabilities in your applications, but since there have been a few in the Log4j library, we should put this one into perspective. This is a Denial of Service vulnerability rather than an arbitrary code execution like the previous two, so the potential risk is less severe. The most important observation here is the exploitability. The previous two vulnerabilities were very clearly exploitable with mature and functional exploit examples that proved this. While there is potential for this new Denial of Service vulnerability to be exploited, it’s unclear how easy or common this could be at the time of writing with the current available data. 

In summary, if you can and have time to remediate this vulnerability, you should move up to version 2.17.1, but making sure all your Log4j versions are at a minimum 2.16.0 is more important to mitigate the arbitrary code execution risk, before moving all to 2.17.1. If you still have services that are yet to be upgraded, then it makes sense to jump straight up to the latest 2.17.1 version to fix all the Log4j issues that have been disclosed recently.

Why are there so many Log4j vulnerabilities all of a sudden?

For those wondering why there are so many rapid disclosures and corresponding releases in this library, it’s important to understand the full context of what is happening, and why it makes sense that new upgrades have been, and might still be, released.

  1. Increased community exposure – the initial disclosure of the critical Remote Code Execution in Log4j has pulled in the community at large onto this project. As such, many bugs that might have been overlooked previously are now coming to light thanks to the efforts of the Java open source community. This community exposure has been spilling over into other similar projects as well, sometimes to mixed results, as the haste to help disclose potential vulnerabilities gets ahead of community consensus.
  1. Rushed initial security fix – while the exact events leading up to the disclosure of CVE-2021-44228 are still being understood, it would appear that the normally maintained responsible disclosure window was not strictly adhered to, as details of this vulnerability were leaked to the public before a full fix was ready. The Apache team had to release a fix for the vulnerability as quickly as possible. This led to additional vectors and issues being identified, resulting in the subsequent releases.  
  1. Backward compatibility – Log4j is a core component of the Java ecosystem. There is a need for any new version to maintain backward compatibility with previous versions to avoid unnecessary breakage, potentially leaving users unable to upgrade to the new and safe version. Unfortunately, this necessary and cautious approach means the core functionality can’t be altered whole-scale. Therefore, additional attack vectors or workarounds undiscovered at the time of fix publication may exist and could be exposed as the community continues to review the threat landscape.

What can I do to make this easier going forward?

Considering the above context, it’s likely we will see additional vulnerabilities and corresponding version releases in the near future. It’s important for users of Log4j (and other open source packages) to be prepared for this eventuality. Here are some best practices to improve your AppSec program to make these zero-day events easier to manage:

  • Scan code daily to find the latest vulnerabilities in managed and even unmanaged code
  • Create an SBOM to keep track of your software supply chain
  • Set up automated CI/CD DevOps Pipelines with integrated application security
  • Where possible, practice good open source hygiene by updating to more recent releases of packages. This way, any urgent security fixes are more easily upgraded to and will cause less churn to the compatibility of your project

Be sure to follow us on LinkedIn, Twitter, or Facebook to stay on top of all the latest Log4Shell and other critical vulnerability news.

Discuss this blog on Discord

Join the DevSecOps Community on Discord to discuss this topic and more with other security-focused practitioners.

GO TO DISCORD
Footer Wave Top
Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment
Develop Fast.
Stay Secure.
Snyk|Open Source Security Platform
Sign up for freeBook a demo

Product

  • Developers & DevOps
  • Vulnerability database
  • API status
  • Pricing
  • IDE plugins
  • What is Snyk?

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Code snippets
  • Japanese site
  • Audit services
  • Web stories

Company

  • About
  • Snyk Impact
  • Customers
  • Jobs at Snyk
  • Snyk for government
  • Legal terms
  • Privacy
  • Press kit
  • Events
  • Security and trust
  • Do not sell my personal information

Connect

  • Book a demo
  • Contact us
  • Support
  • Report a new vuln

Security

  • JavaScript Security
  • Container Security
  • Kubernetes Security
  • Application Security
  • Open Source Security
  • Cloud Security
  • Secure SDLC
  • Cloud Native Security
  • Secure coding
  • Python Code Examples
  • JavaScript Code Examples
  • Code Checker
  • Python Code Checker
  • JavaScript Code Checker
Snyk|Open Source Security Platform

Snyk is a developer security platform. Integrating directly into development tools, workflows, and automation pipelines, Snyk makes it easy for teams to find, prioritize, and fix security vulnerabilities in code, dependencies, containers, and infrastructure as code. Supported by industry-leading application and security intelligence, Snyk puts security expertise in any developer's toolkit.

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Code snippets
  • Japanese site
  • Audit services
  • Web stories

Track our development

© 2023 Snyk Limited
Registered in England and Wales
Company number: 09677925
Registered address: Highlands House, Basingstoke Road, Spencers Wood, Reading, Berkshire, RG7 1NT.
Footer Wave Bottom