Active Exploitation of Fast 1.x (CVE-2026-16723): WAF Rules and IOCs?
Has anyone else seen the alerts regarding CVE-2026-16723? ThreatBook and Imperva are reporting that attackers are actively exploiting a critical unauthenticated RCE in Fast 1.x, Alibaba's JSON library for Java.
The vulnerability impacts Spring Boot applications utilizing this library. An attacker can send a crafted malicious JSON request to execute code without authentication, carrying the full privileges of the Java process. With a CVSS score of 9.0 and no official patch available yet, this is a nightmare scenario for legacy Java environments.
Since we can't patch immediately, we are focusing on detection and limiting the attack surface. We are particularly worried about lateral movement if the Java process is running as a service account with excessive permissions. We've disabled the AutoType feature where possible, but that's not a silver bullet for all versions.
We are currently hunting for IOCs in the logs. Here is a basic query we are using to look for potential Fast autotype probes in our web logs:
// KQL query to detect potential Fast autotype exploitation attempts
WebEvent
| where RequestMethod == "POST" and ContentType == "application/"
| where Body has "@type"
| where Body has "fast" or Body has "net.sf."
| project TimeGenerated, SourceIP, URL, Body
| take 100
We are also deploying a ModSecurity rule to drop requests containing specific class mappings typically used in these exploit chains. How is everyone else handling this? Are you blocking Fast traffic at the network edge, or have you found a successful configuration workaround?
We're seeing similar probes. The problem with relying on WAF signatures for Fast is that the payloads are highly obfuscateable. Attackers can easily bypass regex for @type by using Unicode encoding or mixed-case variations if your parser isn't strict.
We've shifted focus to EDR telemetry. Since this is an RCE, we are alerting on any unexpected child processes spawned by the Java application user (e.g., cmd.exe, /bin/sh, or powershell). It's noisy, but it catches the execution phase regardless of the payload delivery method.
If you're stuck on 1.x, you might try implementing a 'safe mode' by setting AutoTypeSupport to false and explicitly listing the allowed classes in the deny or accept lists in the ParserConfig. It's a config change rather than a full code upgrade.
However, if you can, the best stopgap is to put the application behind a strict API Gateway that validates the JSON schema against an expected structure. If the request body contains fields that shouldn't be there (like malicious class definitions), drop it before it hits the backend.
Just a heads up: check your dependencies for transitive usage. A lot of developers think they aren't using Fast, but legacy libraries like older versions of RocketMQ or Elasticsearch clients sometimes bundle it in.
We ran a SBOM scan and found it lurking in three internal tools we forgot existed. You can use this simple grep command to find potential usage in your codebase:
grep -r "fast" --include="*.java" --include="*.xml" --include="*.pom" /path/to/source
Quinn's config advice is solid for defense, but you need visibility too. Since payloads are easily obfuscated, regex often fails. I recommend setting up an anomaly detection rule for high-entropy JSON bodies in your SIEM. For Splunk users, this search helps identify potential obfuscated FastJSON payloads:
splunk index=web sourcetype=access_combined uri_path="*." | eval body_entropy=entropy(body)
| where body_entropy > 6.5
| stats count by src_ip, uri_path
Excellent point on transitive dependencies, Tom. To quickly hunt down vulnerable instances on your Linux servers, you can use this find command to locate the JARs directly on the filesystem:
find / -name 'fast-*.jar' 2>/dev/null
If you find version 1.x, consider temporarily restricting ingress to non-essential endpoints at the perimeter until you can validate Quinn's config changes. RASP agents are also highly effective here, as they can intercept the malicious deserialization calls regardless of payload encoding.
Building on Hannah's discovery tip: finding the JARs is just step one. To quickly verify if your instances fall within the vulnerable 1.x range without analyzing the whole dependency tree, you can extract the version from the manifest directly on the server:
find / -name "fast*.jar" -exec sh -c 'echo "File: $1"; unzip -p "$1" META-INF/MANIFEST.MF | grep Implementation-Version' _ {} \;
This granular visibility helps you prioritize patching for those hidden transitive dependencies Tom mentioned.
Since signatures are unreliable, I’d suggest shifting focus to behavioral analysis. If you’re using Elastic Security, this EQL rule catches the post-exploitation phase—specifically the Java parent process spawning shells—which bypasses any payload obfuscation:
eql process where host.os.type == "linux" and process.parent.name == "java" and process.name in ("bash", "sh", "nc", "curl", "wget")
Also, verify if a migration to Fast 2.x is viable; it addresses the root cause and isn't affected by 1.x flaws.
To complement the WAF and config strategies, runtime visibility is crucial since Fast bypasses standard logging. If you're incident handling, consider using Arthas to trace the deserialization activity directly on the compromised or suspected host. You can monitor the checkAutoType method to see exactly which classes are being requested during the parsing attempts:
watch com.alibaba.fast.parser.ParserConfig checkAutoType '{params[0], returnObj}' -x 2
This helps identify the specific gadget chain being targeted even if the JSON payload is obfuscated.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access