Security & Threat Intelligence · 27.08.2026, 00:47 UTC
A Reported Log4j RCE Is More Complicated Than It Looks
| Schweregrad | info |
|---|---|
| Kategorie | Security & Threat Intelligence |
| Quelle | Sonatype ↗ |
| Veröffentlicht | 27.08.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
TL;DR A recently circulated Log4j finding demonstrates a reproducible bypass of a defense-in-depth deserialization control involving FilteredObjectInputStream. Sonatype does not currently consider this a clear-cut Log4j vulnerability. Apache explicitly warns that deserializing untrusted data is unsafe and treats these filters as hardening measures rather than complete security boundaries. Exploitation requires uncommon, legacy-style application behavior: an application must deserialize Java-serialized Log4j events from an untrusted source, an attacker must reach that path, and a usable gadget must already exist on the JVM. The finding was produced by an AI agent and reached public view before maintainers, researchers, and defenders had fully established its reachability, prerequisites, trust boundaries, or real-world impact. That makes the disclosure process part of the security story, not just the technical finding. A reported Log4j remote code execution (RCE) issue began circulating after details of FilteredObjectInputStream bypass appeared publicly and were later removed. The underlying behavior appears to be real. The "new critical Log4j RCE" framing is much less clear. Current analysis shows that the bypass exists in a legacy Java deserialization path that Log4j does not treat as a security boundary. Reaching it requires applications to accept and deserialize serialized Log4j events from potentially untrusted sources, behavior that is uncommon in modern deployments and explicitly discouraged by Apache. Sonatype published sonatype-2026-006746 as an …