What’s going on?

Okay, buckle up: attackers are exploiting a nasty bug in the FastJson Java library that lets them run code on vulnerable systems. The flaw affects FastJson versions 1.2.68 through 1.2.83 and has been used in real-world attacks, mostly against companies in the United States (with a few hits in Singapore and Canada). Researchers and incident responders have seen the activity across sectors like finance, healthcare, retail, and general business services.

Short, nerdy breakdown: the issue lives in FastJson’s type-resolution logic. It looks up attacker-controlled resources before enforcing type restrictions, which opens a door for remote code execution. The exploit is especially dangerous for apps packaged and run as a Spring Boot fat-jar (the kind you launch with java -jar), because that deployment model makes it trivial for the attacker to get their malicious classes loaded.

  • Affected: FastJson 1.2.68 through 1.2.83.
  • Not affected: FastJson 1.2.60 and earlier, non-fat-JAR deployments, and FastJson 2.x (which uses safer allowlisting).
  • Discovery and research: offensive security teams documented the vulnerability and public analysis explains how @type processing can be abused to load malicious classes without typical gadget chains.

What you should do now

If your app uses a vulnerable FastJson build, don’t wait around like it’s a software-themed picnic. Immediate options:

  • Enable SafeMode in FastJson if that option is available—this can reduce the risk while you plan next steps.
  • Move to a non-impacted build or upgrade to FastJson 2.x when possible; FastJson 1.x is basically legacy at this point and unlikely to get patched.
  • Check whether your services run as a Spring Boot fat-jar. If they do, consider swapping the deployment model or adding runtime controls that block untrusted deserialization.
  • Audit logs and endpoint telemetry for suspicious deserialization activity, especially anomalies involving @type fields or unexpected classloading.

If there’s one thing this reminds us of: deserialization is still a beloved playground for attackers. Treat libraries that parse types from input with suspicion, and prioritize fixes for anything that can be remote code execution-y. In short: patch your processes even if you can’t patch the library immediately—disable risky features, tighten runtime controls, and hunt for signs of compromise.

Yes, it’s annoying. No, it’s not going away by itself. But with a little triage and some sensible changes, you can make your apps a much less fun target for the bad actors. Good luck, and may your classpaths be ever clean.