The fix only ships upstream
Projects patch their current line. If a vendor certified 2.11, or your platform still compiles for Java 7, there is no release with the fix for you.
Early access · Maven · Log4j 2.x today
Give it a CVE and the old version you run. Backport Anything finds the upstream fix, ports it onto your release, and proves it: a test that reproduces the vulnerability fails before the patch and passes after, and the library's own tests still pass.
$ cve-backport patch --project log4j2 \
--cve CVE-2021-44228 \
--purl pkg:maven/org.apache.logging.log4j/log4j-core \
--ref rel/2.11.2
rel/2.11.2
patched
c77b3cb393patch.diff run.json advisory.json
16 min · $1.64
Projects patch their current line. If a vendor certified 2.11, or your platform still compiles for Java 7, there is no release with the fix for you.
Someone has to find the right commit, untangle conflicts against years of drift, and port the helpers the fix depends on that your version never had.
Reviewers and auditors want to see the exploit fail. A security patch nobody has demonstrated is a guess.
Each job runs the same five stages in a sandboxed build, and stops early when there is nothing to patch.
Look the CVE up in OSV, GHSA and NVD and place your version in the affected ranges. Not affected, or no upstream fix exists? You get that answer before anything is cloned or built.
Resolve the CVE to the upstream fix commit: advisory links first, then the issue key in the history, then a search of the commits between the last vulnerable release and the fixed one.
Diff your release against the fix for the files it touches, and list the helpers the fix relies on that don't exist in your version.
Cherry-pick the fix. On conflict, the agent resolves each hunk, drops changes that aren't part of the fix, and backports minimal versions of missing helpers.
Run the targeted tests (failures go back to the agent, up to five attempts), write a reproducer that must fail on your release and pass on the patched one, then run the full test suite of every module it touched.
Every backport in the eval set is compared with the real upstream fix. The agent never sees that answer; scoring runs separately.
| CVE | Library | Backported to |
|---|---|---|
| CVE-2021-44228 Log4Shell | log4j-core | 2.14.1 2.11.2 2.10.0 |
| CVE-2021-45046 | log4j-core | 2.15.0 2.13.3 |
| CVE-2021-45105 | log4j-core, log4j-1.2-api | 2.16.0 2.13.3 2.10.0 |
| CVE-2021-44832 | log4j-core | 2.17.0 2.14.1 |
| CVE-2021-44228 | log4j-core | 2.0-beta8 correctly not affected |
| CVE-2021-4104 | log4j 1.x | 1.2.17 correctly no upstream fix |
The one partial match, CVE-2021-45105 on 2.10.0, leaves out a file that doesn't exist at that release and an interface method Java 7 can't compile; the backport puts the equivalent on the base class instead.
patch.diffA patch that applies to your tag, about the size of upstream's fix, ready for your own build and review.
It fails on the unpatched release because of the vulnerability (a JNDI lookup, a runaway recursion) and passes once the patch is in.
run.jsonEvery tool call, test run, attempt and token, with secrets redacted, so a reviewer can follow exactly what happened.
Not affected or no upstream fix, with the reason, when that is the answer. No patch is invented to fill the gap.
The hosted service runs jobs for your organization from a web app, a CLI or CI.
--download it from the CLIMaven libraries: Log4j 2.x patches, and triage for Log4j 1.x. Packages are named by purl, so other libraries and ecosystems fit the same jobs; each new library gets a build recipe and eval cases before it's offered.