Log4J (CVE-2021-44228) was considered as low severity vulnerability
See original GitHub issueI have scanned a vulnerable log4j repo just for testing and found that CVE-2021-44228
is considered as low severity.
Repository used for scanning: https://github.com/christophetd/log4shell-vulnerable-app
Attaching the screenshot for reference:
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:7 (3 by maintainers)
Top Results From Across the Web
Apache Log4j Security Vulnerabilities
Severity is now Critical The original severity of this CVE was rated as Moderate; since this CVE was published security experts found ...
Read more >CVE-2021-44228 vulnerability in Apache Log4j library
The remote code execution vulnerability CVE-2021-44228 was found in the Apache Log4j library, a part of the Apache Logging Project.
Read more >Exploiting, Mitigating, and Detecting CVE-2021-44228: Log4j ...
The CVE-2021-44228 is a CRITICAL vulnerability that allows attackers to execute arbitrary code on a machine. Updating log4j to 2.16.0.
Read more >Have you patched Apache Log4j vulnerability CVE-2021 ...
CVE-2021-4104 has a severity of 8.1 (high) on the CVSS v3 scale and is classified as CWE-502 vulnerable to deserialization of untrusted data....
Read more >Simulating and Preventing CVE-2021-44228 Apache Log4j ...
In this blog, the CVE-2021-44228 Apache Log4j vulnerability, Log4j exploit ... its severity is lower than Log4Shell (CVE-2021-44228).
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks @prabhu! This worked after I deleted db files and cached again.
But I also did
--cache
and--sync
before deleting the files as well, but maybe somehow the files were not really replaced. I think it might be a bug in vdb. I tried understanding the code but I wasn’t able to figure out.Thanks, @kakumanivrn, for raising this issue. This is fixed with 2.1.4
Perhaps a bug or the format of OSV schema had changed recently; severity is now appearing in the root instead of under the affected array in the OSV feed. https://github.com/AppThreat/vulnerability-db/commit/a45fc845257b963f079130d504debae3ea7282ec