Brother
Professional
- Messages
- 2,590
- Reaction score
- 500
- Points
- 83
The vulnerability fixed 2 years ago is still relevant for 38% of applications.
Recently, security researchers from Veracode found that about 38% of applications using the Apache Log4j library run on versions that are susceptible to a variety of security vulnerabilities, including the critical Log4Shell ( CVE-2021-44228 ) of the maximum severity (CVSS 10 points). Despite the availability of patches for more than two years, many organizations continue to use vulnerable versions.
Log4Shell is a remote code execution (RCE) vulnerability that allows full control of systems from Log4j 2.0-beta9 to 2.15.0. This issue was detected as an actively exploited zero-day on December 10, 2021. Its broad impact, ease of use, and serious security implications have aroused increased interest among attackers.
Despite numerous warnings and an active awareness campaign, a significant number of organizations continued to use vulnerable versions even after the release of patches.
Analyzing data from August 15 to November 15, Veracode researchers found that about 38% of applications still use insecure versions of Log4j. The study included 3,866 organizations with 38,278 applications that depend on Log4j versions 1.1 through 3.0.0-alpha1.
Of these, 2.8% use Log4J variants from 2.0-beta9 to 2.15.0 that are directly vulnerable to Log4Shell. Another 3.8% use Log4j 2.17.0, which, while not affected by Log4Shell, is vulnerable to CVE-2021-44832. At the same time, 32% use the Log4j 1.2.x version, which ended support in August 2015 and is vulnerable to several serious vulnerabilities published before 2022.
In addition, the study found that 79% of developers never update third-party libraries after their initial inclusion in the code to avoid breaking functionality, even though 65% of open source updates contain minor changes and fixes.
Veracode notes that Log4Shell was not the "wake-up call" that many in the security industry were hoping for. Log4j is still a source of risk in about one in three cases and can be one of the many ways attackers can compromise a target.
All companies that use Log4j or similar libraries are encouraged to scan their environment, identify the open source library versions in use, and then develop a plan to "painlessly" upgrade all of them to secure versions.
Recently, security researchers from Veracode found that about 38% of applications using the Apache Log4j library run on versions that are susceptible to a variety of security vulnerabilities, including the critical Log4Shell ( CVE-2021-44228 ) of the maximum severity (CVSS 10 points). Despite the availability of patches for more than two years, many organizations continue to use vulnerable versions.
Log4Shell is a remote code execution (RCE) vulnerability that allows full control of systems from Log4j 2.0-beta9 to 2.15.0. This issue was detected as an actively exploited zero-day on December 10, 2021. Its broad impact, ease of use, and serious security implications have aroused increased interest among attackers.
Despite numerous warnings and an active awareness campaign, a significant number of organizations continued to use vulnerable versions even after the release of patches.
Analyzing data from August 15 to November 15, Veracode researchers found that about 38% of applications still use insecure versions of Log4j. The study included 3,866 organizations with 38,278 applications that depend on Log4j versions 1.1 through 3.0.0-alpha1.
Of these, 2.8% use Log4J variants from 2.0-beta9 to 2.15.0 that are directly vulnerable to Log4Shell. Another 3.8% use Log4j 2.17.0, which, while not affected by Log4Shell, is vulnerable to CVE-2021-44832. At the same time, 32% use the Log4j 1.2.x version, which ended support in August 2015 and is vulnerable to several serious vulnerabilities published before 2022.
In addition, the study found that 79% of developers never update third-party libraries after their initial inclusion in the code to avoid breaking functionality, even though 65% of open source updates contain minor changes and fixes.
Veracode notes that Log4Shell was not the "wake-up call" that many in the security industry were hoping for. Log4j is still a source of risk in about one in three cases and can be one of the many ways attackers can compromise a target.
All companies that use Log4j or similar libraries are encouraged to scan their environment, identify the open source library versions in use, and then develop a plan to "painlessly" upgrade all of them to secure versions.
