Log4j Remote Code Execution (RCE) Flow in FilteredObjectInputStream (no CVE & Patch yet)

A critical zero-day Remote Code Execution (RCE) vulnerability has been disclosed recently which affecting Apache Log4j, arising from a bypass of the FilteredObjectInputStream (FOIS) deserialization allowlist.  The vulnerability affects log4j-api versions 2.11.0 through 2.26.1 and log4j-core versions 2.8.0 through 2.26.1. Whilst the vulnerability has not yet been exploited in the wild, the Proof-of-Concept (PoC) availability and historic, widespread exploitation suggests that malicious actors may quickly weaponize the flaw.  Affected system owners are strongly recommended to follow the recommendations below to reduce potential risks, and monitor for the official fix for patching asap.

Vulnerability

• Log4j Remote Code Execution (RCE) Flaw in FilteredObjectInputStream  (no CVE assigned or Patch available)
  • Exploitation requires that a target application expose an unauthenticated, FOIS-based serialized-LogEvent receiver (e.g. Log4j’s socket server/appender bridge) reachable over TCP, plus a usable deserialization gadget (e.g. Commons Collections) on the application’s classpath – at that point, a single crafted serialized message can achieve unfiltered remote code execution with no attacker class required on the victim.

Severity Level

• Critical

Affected Versions

• log4j-api versions 2.11.0 through 2.26.1
• log4j-core versions 2.8.0 through 2.26.1

The flaw is platform-independent and has been reproduced across tested JDK versions (confirmed on JDK 17).  It is recommended to treat all Log4j deployments that use the socket-based serialized LogEvent receiver as at risk until Apache publishes official version guidance.

Recommendation

At this moment, the Apache Logging Services project has not released an official patch, advisory, or workaround specifically addressing this FilteredObjectInputStream bypass.  Until an advisory or fix becomes available, please take the following recommended actions:

• Apply the JVM serial filter to block the exploited class: set -Djdk.serialFilter=’!java.rmi.MarshalledObject’ (or the equivalent jdk.serialFilter security property) on any JVM running a Log4j socket-based LogEvent receiver.
• Identify and inventory any application using Log4j’s SocketAppender/SocketServer, or other components that accept serialized LogEvent objects over the network.
• Restrict network access to any FOIS-based serialized-LogEvent receiver to trusted hosts only via firewall/network segmentation; do not expose these ports to the internet.
• Where feasible, migrate serialized-event transport to a non-serialization format (JSON or RFC 5424 syslog) over authenticated TLS, eliminating the vulnerable code path entirely.
• Audit application classpaths for known deserialization gadget libraries (e.g. Commons Collections) and remove or upgrade where not required.
• Enable logging/monitoring on any exposed LogEvent receiver for anomalous or oversized serialized payloads, and alert on unexpected process spawns from Java processes hosting Log4j.
• Monitor Apache’s public issue tracker (GitHub issue #4255) and the Log4j2 release notes for an official fix, and prioritise patch deployment once available.

Reference:

• GitHub – dinosn/log4j-4255
• Release notes :: Apache Log4j

Published on: 27 August 2026