Snyk detects the Log4j "Log4Shell" family of vulnerabilities by scanning your project's dependency tree — including deeply nested transitive dependencies — and matching resolved versions against its vulnerability database. Log4Shell (CVE-2021-44228) was the case that made this capability famous, because the vulnerable log4j-core was so often pulled in indirectly that teams had no idea they were exposed. This walks how a software composition analysis tool like Snyk handles it, what the fix path looks like, and where the free tier limits bite.
Why Log4Shell was a dependency-tree problem
CVE-2021-44228 affected Apache Log4j versions from 2.0-beta9 through 2.14.1, allowing remote code execution through JNDI lookups in logged strings. The reason it caused such chaos was reach: Log4j is a transitive dependency of an enormous number of Java libraries and frameworks, so applications that never listed Log4j in their own build file were still shipping the vulnerable code.
A manifest read misses this entirely. You have to resolve the full graph to see that some framework three levels down brings in log4j-core-2.13.3. That is precisely what an SCA tool does — and where its value over grep lies.
What Snyk reports for Log4j
When Snyk scans a Java project, it walks the resolved Maven or Gradle dependency graph and reports each vulnerable Log4j instance with the CVE, severity, the introducing path, and a recommended upgrade. For Log4Shell it will typically point you at a safe version. A command-line scan looks like:
# Authenticate, then test the resolved project
snyk auth
snyk test --all-projects
The output names the vulnerable package, shows the chain that introduced it (for example your-app > some-framework > log4j-core), and recommends the minimum fixed version. Snyk can also open a fix pull request through its SCM integration that bumps the dependency for you.
The fix is not a single version bump
This is where Log4j teaches a lasting lesson, and where any tool's "upgrade to X" advice needs a human read. The Log4Shell remediation took several releases:
- 2.15.0 partially mitigated CVE-2021-44228 but left CVE-2021-45046 open.
- 2.16.0 fixed that but introduced a denial-of-service flaw, CVE-2021-45105.
- 2.17.0 fixed the DoS but left a JDBC-appender RCE (CVE-2021-44832) open.
- 2.17.1 was the version that fully remediated the family for Java 8+.
Teams that reflexively took the first suggested bump ended up upgrading three or four times. The takeaway: read the advisory, confirm the recommended version closes the whole family, and prefer the version labeled the complete fix. When the introducing dependency pins an old Log4j, you may need to override it in your build rather than waiting for the upstream project to update:
<!-- Maven: force a safe Log4j across the whole tree -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.17.1</version>
</dependency>
</dependencies>
</dependencyManagement>
Know the free tier limits
Snyk's free plan is genuinely useful for individuals but capped by "tests," where a test is one scan of one manifest. The free tier includes a monthly allotment of open-source tests (public repository scans do not count against it), and paid Team plans, priced per developer per month, remove the caps. A team with many repositories and frequent pull requests can exhaust the free allotment quickly once scanning is wired into CI, which is the usual trigger for upgrading. Verify current numbers on Snyk's own pricing page before you budget, since plan details change.
Where other tools fit
Snyk is a strong option, and for a Log4j-style transitive-dependency hunt any capable SCA scanner should resolve the full graph and match against a maintained advisory feed. If you are weighing options, the practical differentiators are database freshness, how cleanly fix PRs are generated, per-scan versus per-developer pricing, and whether the tool surfaces the full introducing path. An SCA tool such as Safeguard can flag a transitive Log4j exposure the same way, and our Snyk comparison lays out the tradeoffs honestly. The right answer depends on your stack and how scan pricing maps to your repo count.
FAQ
Can Snyk detect Log4Shell in transitive dependencies?
Yes. Snyk resolves the full dependency graph and reports vulnerable Log4j instances even when they are pulled in indirectly by another library, showing the chain that introduced them.
What Log4j version fully fixes Log4Shell?
For Java 8 and later, version 2.17.1 fully remediates the Log4Shell family (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832). Earlier interim releases each left a related flaw open.
Is Snyk free for scanning Log4j?
Snyk's free tier includes a monthly allotment of open-source tests and does not count public repository scans. Teams with many repos and CI-integrated scanning often exceed the free caps and move to a paid per-developer plan.
How do I fix Log4j when a dependency pins an old version?
Override the version in your build using Maven dependencyManagement or a Gradle resolution strategy to force a safe Log4j across the whole tree, rather than waiting for the upstream library to update.