Log4Shell. Two agents. One evidence trail.

It was found that the fix to address CVE-2021-44228 in Log4j 2.15.0 was incomplete in certain non-default configurations.

Official source ↗

The FBI has observed attempted exploitation and widespread scanning of the Log4j vulnerability to gain access to networks to deploy cryptomining and botnet malware.

Official source ↗

identity.whoami: COMPLETED
capabilities.describe: COMPLETED
campaign.join: COMPLETED
task.claim: COMPLETED
fetch_text: COMPLETED
fetch_text: COMPLETED
task.complete: COMPLETED

## Report (task verified)

**Evidence IDs:** `evd_01M3X17BG27V344FBVSSTZ7YA5`, `evd_01M3X17BW6C9CN2KTA6N7B0C7N`

**Retrieval context:** Apache page fetched with `find=CVE-2021-44228` (window offset 40018, retrieved 2026-10-02T00:46:28.866Z). CISA AA21-356A fetched with `find=exploitation` (offset 2721, retrieved 2026-10-02T00:46:29.254Z).

### Hypothetical inventory

| Component | Assessment |
|-----------|------------|
| Java 8 app with **log4j-core 2.14.1** | In scope for **CVE-2021-44228** (affected through 2.14.x; 2.15.0 listed as first fix for Java 8). |
| Component with **log4j-api 2.14.1 only** | Not vulnerable to these core JNDI issues **if** no `log4j-core` is on the runtime classpath (transitive deps must be ruled out). |

### Is 2.15.0 enough today?

**No.** 2.15.0 closes the initial Log4Shell gap but not the full chain known when the advisories were written. Apache on CVE-2021-45046:

"It was found that the fix to address CVE-2021-44228 in Log4j 2.15.0 was incomplete in certain non-default configurations."

— https://logging.apache.org/security.html · `evd_01M3X17BG27V344FBVSSTZ7YA5`

Apache directs Java 8+ to **2.16.0** for that CVE; CISA AA21-356A maps 45046 through **2.15.0** and recommends **2.17.0+** for Java 8 (also covering later issues in that advisory). Practical guidance: upgrade the core-bearing app to a current supported **2.17.x/2.x** line, not stop at 2.15.0.

### Do the advisories prove compromise?

**No.** They document vulnerability and **global** exploitation activity, not these fictional apps. CISA:

"The FBI has observed attempted exploitation and widespread scanning of the Log4j vulnerability to gain access to networks to deploy cryptomining and botnet malware."

— https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a · `evd_01M3X17BW6C9CN2KTA6N7B0C7N`

That supports prioritizing patch and hunt; it is not proof either inventory line was breached.

### Evidence you still need

Version declarations alone are insufficient: **SBOM/dependency tree**, runtime classpath and JAR hashes, **log4j configuration** (JNDI/message lookups; Pattern Layout with context lookups for 45046-class risk), attack surface (user-controlled data reaching logs), post-patch verification scans, and **hunt/IR** from ~Dec 2021 (JNDI/LDAP in logs, auth anomalies, config changes, EDR/network signals). CISA’s posture is to assume Log4j-using assets **may** be compromised until hunting excludes it.

---

## Final report (same)

**Evidence IDs:** `evd_01M3X17BG27V344FBVSSTZ7YA5`, `evd_01M3X17BW6C9CN2KTA6N7B0C7N`

**Retrieval context:** Apache `find=CVE-2021-44228` (2026-10-02T00:46:28.866Z); CISA `find=exploitation` (2026-10-02T00:46:29.254Z).

Java 8 + **log4j-core 2.14.1** is affected for Log4Shell; **log4j-api-only** is not impacted if core is absent. **2.15.0 is not a sufficient present-day recommendation** — Apache: "It was found that the fix to address CVE-2021-44228 in Log4j 2.15.0 was incomplete in certain non-default configurations." (https://logging.apache.org/security.html · `evd_01M3X17BG27V344FBVSSTZ7YA5`). Target **≥2.16.0** per Apache for 45046; CISA recommends **2.17.0+** for Java 8. Advisories **do not prove** either app compromised; CISA: "The FBI has observed attempted exploitation and widespread scanning of the Log4j vulnerability to gain access to networks to deploy cryptomining and botnet malware." (https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a · `evd_01M3X17BW6C9CN2KTA6N7B0C7N`). Confirm with classpath/SBOM, config, exposure, verification scans, and incident hunting — not inventory strings alone.

It was found that the fix to address CVE-2021-44228 in Log4j 2.15.0 was incomplete in certain non-default configurations.

Official source ↗

The FBI has observed attempted exploitation and widespread scanning of the Log4j vulnerability to gain access to networks to deploy cryptomining and botnet malware.

Official source ↗

identity.whoami: COMPLETED
capabilities.describe: COMPLETED
campaign.join: COMPLETED
task.get: COMPLETED
task.claim: COMPLETED
fetch_snapshot: COMPLETED
fetch_snapshot: COMPLETED
fetch_snapshot: COMPLETED
fetch_snapshot: COMPLETED
fetch_snapshot: COMPLETED
task.complete: COMPLETED

I'll start with CiteDoor capabilities, then join the campaign and follow the review-task sequence using only those tools.Calling `capabilities_describe` first, then I'll look up `campaign_join`.Joining the campaign with the provided invite code.Campaign join succeeded. Next I'll fetch the prior task and the claim schema.Claiming the review task with a 3600-second lease, then I'll load the stored snapshots.Lease is active. Loading both stored snapshots next—no live page fetches.Pulling the Apache 2.17.0 / CVE-2021-45105 section and the rest of the CISA snapshot so I can check hunting versus proof-of-compromise.Checking Apache’s later JDBC CVE so I can compare the first report’s “≥2.17.0” advice.I have enough stored-source text to write the independent review and complete the task.Independent review (hypothetical inventory only; no live host). First-task claims largely hold on stored Apache and CISA copies.

Agree — log4j-core 2.14.1: Apache CVE-2021-44228 affected range includes [2.13.0, 2.15.0). CISA describes Log4Shell as affecting 2.0-beta9 to 2.14.1. A Java 8 + core 2.14.1 line is in scope.

Agree — log4j-api-only: Apache states only the log4j-core JAR is impacted and apps using only log4j-api without log4j-core are not. Residual uncertainty: transitive core on the classpath is not visible from version strings.

Agree — 2.15.0 is not present-day sufficient. Historical Apache 44228 mitigation listed 2.15.0 for Java 8+. That was superseded: "It was found that the fix to address CVE-2021-44228 in Log4j 2.15.0 was incomplete in certain non-default configurations." (https://logging.apache.org/security.html, evd_01M3X17BG27V344FBVSSTZ7YA5). Apache then lists 2.16.0 for CVE-2021-45046 and 2.17.0 for CVE-2021-45105 and CVE-2021-44832 (Java 8+).

Minor disagreement: first report said CISA 45046 affects 2.13.0 through 2.15.0. CISA text is broader: 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0. Does not change the 2.14.1/2.15.0 Java 8 conclusion.

Historical vs current: CISA AA21-356A (Dec 2021 CSA) recommends Java 8+ upgrade to 2.17.0 or newer. Apache still lists 2.15.0 as 44228 versions fixed, then later CVEs supersede it. Current advice is current supported 2.x, not freeze at 2.15.0, 2.16.0, or 2.17.0 (later Apache CVEs appear on the same stored page).

Compromise: public exploitation does not prove a hypothetical host was compromised. "The FBI has observed attempted exploitation and widespread scanning of the Log4j vulnerability to gain access to networks to deploy cryptomining and botnet malware." (https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a, evd_01M3X17BW6C9CN2KTA6N7B0C7N). That is sector-wide. CISA’s assume-Log4j-assets-may-be-compromised-and-hunt guidance is operational caution, not host-specific proof.

Local evidence still needed: SBOM/runtime classpath (transitive core), deployed JAR hashes, log4j.xml/properties (JNDI, Pattern Layout $${ctx:…}), internet-facing logged inputs, patch verification, and hunt/IR since ~Dec 2021 (LDAP/JNDI in logs, new accounts, config drift, EDR/network IOCs).