FastJson Zero-Day RCE Under Active Exploitation — Patch or Mitigate Now

What Happened

Threat actors are actively exploiting a zero-day remote code execution vulnerability in FastJson, the widely-used open-source Java JSON parsing library originally developed by Alibaba. Confirmed attacks are targeting US-based organizations, and the exploitation requires no user interaction and no elevated privileges — an unauthenticated attacker who can reach a vulnerable endpoint can execute arbitrary code on the host.

This is not a theoretical proof-of-concept. Active in-the-wild exploitation has been confirmed, placing this firmly in the category of zero-days that demand immediate triage, not scheduled patching.

Why It Matters

FastJson is embedded in an enormous surface area of enterprise Java applications. It ships as a transitive dependency in dozens of popular frameworks and internal tooling, meaning teams frequently run it without knowing. Its history of critical deserialization-based RCEs — several with CVSS scores of 9.8 — has made it a perennial attacker target, and this new zero-day follows that same pattern.

The combination of unauthenticated access + no interaction required + RCE is the worst-case trifecta. Any internet-facing Java service that accepts JSON input and processes it through FastJson is potentially a target. Internal services behind VPNs are a lower-risk tier but not exempt if lateral movement is in play.

US firms are the confirmed initial target set, but exploits for widely-deployed open-source libraries rarely stay geographically contained.

What to Do

Immediate (next 2 hours):

1. Inventory FastJson usage. Grep your codebases and dependency trees: grep -r "fastjson" pom.xml build.gradle *.lock. Include transitive deps — run mvn dependency:tree | grep fastjson or the Gradle equivalent.
2. Check your WAF/edge logs. Look for anomalous POST payloads to JSON-consuming endpoints, particularly those containing @type keys, which is the classic FastJson gadget chain trigger.
3. Isolate or firewall exposed services running confirmed FastJson versions while you assess the patch/replace path.

Short-term (this week):

1. Upgrade or replace. Check the FastJson GitHub releases for an emergency patch. If no patched version is available yet, evaluate migrating to Jackson or Gson — both are drop-in-compatible for most use cases and do not share this vulnerability class.
2. Enable safeMode if you must stay on FastJson temporarily. FastJson's ParserConfig.getGlobalInstance().setSafeMode(true) blocks @type deserialization and closes the primary exploit surface, at the cost of disabling polymorphic type handling.
3. Deploy a WAF rule blocking or alerting on JSON payloads containing @type, $ref, or known FastJson gadget strings at the edge.

Ongoing:

• Add FastJson to your SCA (software composition analysis) block-list for new services until a vetted patched version ships.
• Review your incident response runbook for Java deserialization attacks — this class of vulnerability typically enables full server compromise, not just data exfiltration.

Track updates at BleepingComputer and the FastJson GitHub advisory page for CVE assignment and patch availability.