~/f4n6 $ grep -r "Hackers target US firms in FastJson RCE zero-day attacks" ./investigations/ --include="*.md"

Hackers target US firms in FastJson RCE zero-day attacks

Jeff Davies 28 Jul 2026 6 min read

1. Executive summary

A critical unauthenticated remote code execution vulnerability (CVE-2026-16723, CVSS 9.0) in Alibaba's FastJson 1.x library is being actively exploited in the wild against organisations across financial services, healthcare, computing, and retail. The flaw resides in the library's type-resolution logic, which performs attacker-controlled resource lookups before enforcing AutoType restrictions, enabling code execution on the most common Spring Boot fat-JAR deployment model without requiring user interaction, elevated privileges, or third-party gadget chains. No patch exists and FastJson 1.x is no longer actively maintained, meaning the only effective remediation is migrating to fastjson2 or enabling SafeMode. EMEA financial services firms with supply-chain dependencies on Chinese enterprise software or Alibaba-platform-based projects should treat this as a high-priority exposure.

2. Regulatory framing

Article Trigger (the fact in this item) Practical impact
DORA Art. 24: digital operational resilience testing — general requirements No patch exists for CVE-2026-16723 and the vulnerable component (FastJson 1.x) is end-of-life; standard patch-based remediation is unavailable, requiring compensating controls (SafeMode enablement or migration to fastjson2) that must be validated through testing. Firms must test that SafeMode or fastjson2 migration does not break application functionality and confirm the compensating control actually neutralises the exploit chain.
DORA Art. 28: ICT third-party risk — general principles FastJson is an unmaintained open-source dependency widely embedded in third-party Chinese enterprise software and Alibaba-platform projects, creating a supply-chain exposure that the firm cannot remediate by patching the upstream library directly. Firms must identify which third-party software suppliers ship FastJson 1.x in their stacks and contractually require migration or mitigation; this is a third-party risk issue, not just an internal patching task.

3. Technical analysis & attack chain

CVE-2026-16723 — CVSS 9.0 (Alibaba-assigned). Affects FastJson versions 1.2.68 through 1.2.83. Versions 1.2.60 and earlier are not affected. The fastjson2 library is not affected (it uses an allowlist-first model for polymorphic deserialization and does not rely on the @JSONType annotation as a trust signal).

Attack chain (confirmed from source material)

  1. Target selection. Attackers send a malicious JSON request to a Spring Boot application that deserialises input using a vulnerable FastJson 1.x version (1.2.68–1.2.83). No authentication is required. Imperva reports attacks are almost entirely targeting US-based organisations, with a few in Singapore and Canada; expansion globally is expected.
  2. Type-resolution abuse. The malicious JSON payload abuses @type processing. The vulnerability exists because FastJson's type-resolution logic performs attacker-controlled resource lookups before enforcing AutoType restrictions. This ordering flaw creates a window in which malicious classes can be loaded and executed without AutoType enabled.
  3. Payload delivery. Attackers embed malicious payloads within Object or Map fields. Alibaba has confirmed that specifying a target class during deserialization does not mitigate the vulnerability — attackers bypass this by nesting payloads in generic field types.
  4. Code execution. Malicious classes are loaded and executed in the context of the Java process. No third-party gadget chains are required. The only deployment prerequisite is that the target runs as a Spring Boot executable fat-JAR (launched via java -jar xxx.jar). Non-fat-JAR deployments are not affected.
  5. Post-exploitation. Code executes with the privileges of the Java process. The sources do not describe specific post-exploitation behaviour, persistence mechanisms, C2 infrastructure, or lateral movement.

Attribution: No named threat actor is identified in the source material. The vulnerability was discovered by FearsOff, an offensive security company, which published a technical write-up. Attack activity was observed by ThreatBook and confirmed by Imperva. No MITRE ATT&CK actor profile is available for any entity referenced in this item; attribution to any specific threat group is unconfirmed.

Confidence caveat: The technical mechanism (type-resolution ordering, @type abuse, fat-JAR requirement, SafeMode as mitigation) is corroborated across BleepingComputer, SecurityWeek, The Hacker News, and Alibaba's own advisory. The claim that FastJson 1.x will not receive a patch is attributed to Imperva and is single-sourced; verify with Alibaba's official support channels before treating end-of-life status as definitive for procurement decisions.

4. Mitigation & containment

P1 — Within 24 hours

  • Identify exposure. Inventory all Java applications (internal and third-party-supplied) for FastJson 1.x dependency usage. Check for versions 1.2.68–1.2.83 specifically. Look in dependency trees (mvn dependency:tree, gradle dependencies) and inside fat-JARs (jar tf app.jar | grep fastjson). Prioritise Spring Boot fat-JAR deployments.
  • Enable SafeMode. For any application using an affected FastJson version, immediately enable SafeMode (ParserConfig.getGlobalInstance().setSafeMode(true)). This is the primary compensating control pending migration. Test application functionality after enablement — SafeMode disables AutoType entirely, which may break legitimate polymorphic deserialization.
  • Block external input to vulnerable endpoints. If SafeMode cannot be enabled without breaking functionality, place WAF rules in front of exposed Spring Boot endpoints to block JSON payloads containing @type fields. This is a containment measure, not a complete fix — attackers may obfuscate @type references.

P2 — Within 72 hours

  • Engage third-party suppliers. Identify which vendors in your software supply chain ship FastJson 1.x. Contractually require them to confirm whether their products are affected and to provide a remediation timeline (migration to fastjson2 or SafeMode enablement). This is a DORA Art. 28 obligation.
  • Restrict network exposure. Ensure Spring Boot applications running as fat-JARs are not directly internet-facing. Place them behind reverse proxies with strict request filtering. If an affected application must be internet-facing, implement aggressive WAF rules blocking @type in JSON bodies and monitor for evasion attempts.

P3 — Within 7 days

  • Migrate to fastjson2. Plan and execute migration from FastJson 1.x to fastjson2 for internally maintained applications. fastjson2 uses an allowlist-first model for polymorphic deserialization and does not rely on @JSONType as a trust signal, eliminating this class of vulnerability.
  • Validate compensating controls. Test that SafeMode or fastjson2 migration does not break application functionality. Confirm the control neutralises the exploit chain using the FearsOff technical writeup as a test reference.
  • Deprioritise non-affected deployments. FastJson versions 1.2.60 and earlier, non-fat-JAR deployments, and fastjson2 are not affected. Document these exclusions to focus remediation resources.

5. Indicators of compromise

No atomic indicators of compromise (IPs, domains, hashes, URLs, file paths) are present in the source material.

Behavioural indicators

Behaviour Where to observe Confidence
Inbound HTTP requests containing JSON payloads with @type fields targeting Spring Boot endpoints WAF logs, application ingress logs, reverse proxy logs High — consistent with confirmed attack mechanism
Unexpected class loading or resource lookups in Java process during JSON deserialisation JVM monitoring, EDR process telemetry, application runtime logs Medium — derived from vulnerability mechanism, not directly observed in source
Outbound network connections from Java process following inbound JSON request Network firewall logs, EDR network telemetry Low — plausible post-exploitation behaviour, not described in sources

6. Detection

Insufficient indicators to author detection rules.

The source material describes the vulnerability mechanism and attack pattern but does not contain specific malicious artefacts (file hashes, hard-coded strings, command-line arguments, mutex names, scheduled task names, C2 domains, or payload content) that would enable a functional YARA or Sigma rule. A rule grepping for @type in JSON bodies would generate excessive false positives from legitimate FastJson usage and is not recommended as a standalone detection.

Recommended detection approach: Deploy WAF rules to alert on inbound JSON payloads containing @type fields directed at Spring Boot endpoints using FastJson 1.x. Correlate with JVM process telemetry for unexpected class loading or outbound network connections following such requests. Tune based on your application baseline.

7. Sources

  • BleepingComputer — "Hackers target US firms in FastJson RCE zero-day attacks" — https://www.bleepingcomputer.com/news/security/hackers-target-us-firms-in-fastjson-rce-zero-day-attacks/ — 2026-07-27
  • SecurityWeek — "Unpatched Fastjson Vulnerability Exploited in Attacks" — https://www.securityweek.com/unpatched-fastjson-vulnerability-exploited-in-attacks/ — 2026-07
  • The Hacker News — "Fastjson 1.x RCE Vulnerability Targeted in Attacks With No Patched Available" — https://thehackernews.com/2026/07/fastjson-1x-rce-vulnerability-targeted.html — 2026-07
  • GitHub Security Advisories — "Jaspersoft Reports: Java Deserialization Vulnerability Leads to Remote Code Execution (RCE)" — https://github.com/advisories/GHSA-9wxq-mwqw-8hhg — (contextual reference; not directly related to CVE-2026-16723)

8. Adverse Trace position

This is a critical unpatched RCE vulnerability in a widely deployed Java library with confirmed active exploitation. The CVSS 9.0 rating is justified: unauthenticated, no user interaction, no elevated privileges, and exploitable under default configurations on the most common Spring Boot deployment model. The absence of a patch and the end-of-life status of FastJson 1.x elevate this from a standard patch-management issue to an architecture-level remediation problem requiring migration or compensating controls. EMEA financial services clients should prioritise discovery of FastJson 1.x in their application stacks and third-party supply chains — the library's prevalence in Chinese enterprise software means exposure may be hidden inside supplier products. We will monitor for expansion of targeting beyond the US/Singapore/Canada footprint, for any reversal of Alibaba's maintenance posture on FastJson 1.x, and for emergence of IOCs or actor attribution from ThreatBook or Imperva follow-up reporting.


Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.

Post this to LinkedIn
Formatting is converted automatically — headings, bullets, a link back & hashtags. Paste straight in.
J
Jeff Davies