Unpatched Fast 1.x RCE (CVE-2026-16723): Active Exploitation in the Wild
Just caught the report from ThreatBook and Imperva regarding active exploitation of a critical RCE vulnerability in Fast 1.x, tracked as CVE-2026-16723. The situation is pretty tense because Alibaba has not released a patch for this yet.
The flaw affects Spring Boot applications utilizing the library. Attackers can send a malicious JSON request to trigger deserialization, leading to unauthenticated code execution with the privileges of the Java process. With a CVSS score of 9.0, this is a critical risk for anyone running legacy stacks.
Since a patch isn't available, mitigation relies heavily on WAFs and input filtering. The exploit chain often relies on the @type keyword to specify malicious classes. I've thrown together a basic ModSecurity rule to block this specific pattern at the edge:
apache
SecRule REQUEST_BODY "@rx @type"
"id:1001,phase:2,deny,status:403,msg:'Potential Fast Autotype Attack',logdata:'Matched Data: %{MATCHED_VAR} within %{MATCHED_VAR_NAME}'"
If you are hunting for compromises, check your application logs for deserialization exceptions or suspicious JAR loading attempts:
grep -i "autotype\|fast" /var/log/tomcat/catalina.out | grep -i "error\|exception"
Long-term, we need to migrate to Fast 2.x or Jackson, but that takes significant testing.
Is anyone else seeing specific IOCs related to this in their environment yet? For those stuck on 1.x, are you relying on WAFs or attempting to patch the library manually?
We saw a massive spike in probes this morning. The @type regex works for basic scanning, but be careful—attackers are obfuscating the payload with unicode escapes to bypass simple string matching. Make sure your WAF normalizes the request body before inspection. We've also started monitoring for unusual child processes spawning from the Java user.
If you can't update the library immediately, check if you can enable SafeMode in your Fast configuration. It effectively denies auto-type resolution. You can enforce it programmatically:
ParserConfig.getGlobalInstance().setSafeMode(true);
It's a Band-Aid, but it stops the autotype deserialization vector immediately.
This is exactly why I push teams to use Jackson by default. We migrated off Fast 1.x last year. For anyone doing incident response right now, look for outbound reverse shell connections (e.g., netcat or bash) originating from your application servers.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access