ForumsExploitsZero-Day RCE in FastJson: Active Exploitation and Detection Tips

Zero-Day RCE in FastJson: Active Exploitation and Detection Tips

DevSecOps_Lin 7/27/2026 USER

Hey everyone,

Just saw the latest report regarding active exploitation of a zero-day vulnerability in the FastJson library. It appears US firms are being specifically targeted in these campaigns. What makes this particularly dangerous is that the vulnerability allows for Remote Code Execution (RCE) without requiring user interaction or elevated privileges on the target system.

For those unfamiliar, FastJson is a popular Java library for JSON processing. The root cause of many of these issues, including this zero-day, is typically the "AutoType" feature. When enabled, it allows the attacker to specify a Java class in the JSON payload using the @type field. The library then deserializes the object, executing arbitrary code contained in the referenced class's constructor or setters.

Since official patches might be delayed for this zero-day, defensive coding and WAF configurations are critical. We've started blocking requests containing @type outside of specific whitelisted contexts.

I wrote a quick Python snippet to analyze our raw access logs for potential FastJson exploit attempts. This looks for the tell-tale AutoType signature:

import re

def scan_for_fast(log_file_path):
    # Regex to find @type usage which is common in FastJson exploits
    fast_pattern = re.compile(r'"@type"\s*:\s*"')
    
    with open(log_file_path, 'r') as f:
        for line in f:
            if fast_pattern.search(line):
                print(f"Suspicious entry found: {line.strip()}")
                
# scan_for_fast('access.log')


Is anyone else seeing specific indicators of compromise (IOCs) related to this? Or are you seeing mostly scanning activity? Also, for those stuck on FastJson, have you had success with the `SafeMode` configuration or is a full library migration to Jackson/Gson the only reliable path right now?
MA
MasterSlacker7/27/2026

We noticed a similar spike in traffic yesterday. I'm using this simple KQL query in Sentinel to hunt for suspicious JSON payloads hitting our endpoints:

HttpEvent
| where Body contains "@type"
| project TimeGenerated, SrcIp, Body
| summarize count() by SrcIp, bin(TimeGenerated, 1h)


It's noisy if your app actually uses complex JSON, but once we filtered out internal IPs, we found several scanning attempts originating from TOR nodes.
SU
Support7/27/2026

Honestly, the best mitigation is to deprecate FastJson entirely if you can. We migrated our core services to Jackson last year after the previous round of CVEs. The AutoType feature in FastJson is just too risky to leave enabled in production environments. If migration isn't an option right now, make sure you enable SafeMode immediately.

PE
Pentest_Sarah7/27/2026

I tested a proof-of-concept for this in my lab environment. It's shockingly simple—no auth required, just send the malicious JSON object. The payload executes immediately. If you haven't blocked outbound traffic from your app servers, you're at high risk of reverse shells or C2 beaconing.

PH
PhishFighter_Amy7/28/2026

Validating the suggestions above, network-level detection is crucial if endpoint checks fail. If you use Suricata or Snort, this rule helps catch the JNDI callback attempts often associated with these exploits:

text alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"Possible FastJson Exploit"; content:"@type"; http_client_body; pcre:"/jndi:(ldap|rmi|dns):/i"; classtype:attempted-admin;)

Keep in mind that obfuscation might bypass simple string matching, so monitoring for outbound JNDI connections is also smart.

Verified Access Required

To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.

Request Access

Thread Stats

Created7/27/2026
Last Active7/28/2026
Replies4
Views183