Every security team has the same reflex when a critical CVE drops: check for a patch, schedule the maintenance window, move on. That reflex just failed. A remote code execution bug in Fastjson 1.x, Alibaba’s widely embedded JSON library for Java, is being actively exploited right now, and there is no fix coming. Not a slow fix. Not a fix scheduled for next quarter. No fix, period. If your cybersecurity program only knows how to react to patches, this is the week that plan runs out of road.

That gap sits next to two other stories that, together, tell you where the next twelve months of extortion campaigns are headed: Cl0p affiliates chaining unauthenticated bugs in enterprise PLM software most security teams have never heard of, and a ransomware-as-a-service operation that now runs like a SaaS company, complete with a portal for payload builds and affiliate payouts. None of these are exotic. All three are exploitable today, against real production systems, with defenses that have nothing to do with waiting on a vendor.

The Bug Alibaba Isn’t Fixing

Fastjson has a long, ugly history of deserialization vulnerabilities, and 1.x has been effectively retired in favor of the 2.x line for years. That’s the problem. Researchers at ThreatBook and Imperva are now watching active exploitation of a new flaw, tracked as CVE-2026-16723 and carrying a 9.0 severity score from Alibaba itself, that lets an attacker send a malicious JSON payload to an affected Spring Boot application and execute code with no authentication at all. The code runs with whatever privileges the Java process has, which in a lot of shops is more than it should.

Here’s the part that should bother you more than the CVSS number: 1.x isn’t getting a fix. It’s out of active support, and Alibaba’s attention is on the newer branch. So every organization still running an application built years ago on top of Fastjson 1.x, and there are a lot of them, is stuck with a live, actively exploited RCE and nothing to install. Vulnerability management programs built entirely around “patch within 30 days” have no answer for that sentence. You either replace the dependency, isolate the application, or accept the risk and hope your other layers of security hardening hold.

Your PLM Platform Was Never Supposed to Face the Internet

Meanwhile, Cl0p affiliates, the crew also tracked as FIN11, Lace Tempest, and a handful of other aliases, are running a fresh extortion campaign against PTC Windchill and FlexPLM deployments that are sitting exposed to the internet. The attack chain is straightforward once you see it: a pre-authentication information disclosure bug in the FlexPLM WSDL endpoint gets combined with a server-side flaw in the Windchill login servlet, and the result is unauthenticated remote code execution against product lifecycle management software.

Most security teams don’t think about PLM systems the way they think about a customer-facing web app. Windchill and FlexPLM manage product designs, engineering documents, bills of materials, sometimes defense and manufacturing IP that’s genuinely sensitive. They’re internal tools by design, which is exactly why they end up misconfigured: someone needed remote access for a vendor, or a branch office, and a firewall rule got opened and never revisited. Cl0p has built an entire business model around finding software categories like this, ones that are valuable enough to extort over and boring enough that nobody’s watching the exposure.

Why “Internal” Software Keeps Showing Up in Extortion Campaigns

This isn’t a one-off. Cl0p made its name hitting MOVEit, then GoAnywhere, then a string of managed file transfer tools, always picking software that organizations assumed was tucked safely behind the perimeter. PLM platforms are the next logical target: high-value data, low visibility, and administrators who often don’t know the vendor’s default install exposes a login servlet to the open internet at all. If you run any enterprise platform that handles design files, financial records, or HR data and you haven’t personally verified what ports it exposes externally, that’s this week’s homework.

Ransomware Now Ships With a Product Roadmap

The third piece is DevMan, a ransomware-as-a-service operation that Swiss firm PRODAFT is tracking under the name Funky Mantis. What’s notable isn’t the ransomware itself, it’s the infrastructure behind it: a centrally administered web portal where affiliates build payloads, track victim status, and manage payouts, all from one dashboard. Ransomware crews have been trending this direction for a while, but DevMan is a clean example of just how commoditized the business has become. This isn’t a lone operator with a Tor site anymore. It’s a platform with a finance module.

Why does that matter for a story about unpatched Java libraries and exposed PLM servers? Because RaaS platforms are demand-side infrastructure. The easier it is for an affiliate to spin up a campaign, the more of them go looking for exactly the kind of entry points Fastjson and Windchill represent: soft, exposed, unauthenticated. Professionalized ransomware operations don’t discover novel bugs, they scale exploitation of the ones already public. Every unpatched or unpatchable system sitting on the internet is now a target for a much larger, better-organized pool of affiliates than it was two years ago.

When Patching Isn’t an Option, Here’s What Actually Works

Waiting for a vendor fix is not a strategy when there isn’t one coming. Defense in depth exists precisely for this situation. If you’re running Fastjson 1.x, an exposed PLM deployment, or any other software category where the patch pipeline has run dry, here’s where to focus:

1. Inventory before you panic. Find every application using Fastjson 1.x (check dependency manifests, not just what’s deployed) and every internet-facing PLM, ERP, or file-transfer system. You can’t defend what you haven’t mapped.
2. Cut off external exposure first. If a system doesn’t need to be internet-facing, put it behind a VPN or internal-only firewall rule today. This is the single highest-leverage move available and it costs nothing.
3. Add virtual patching at the edge. A web application firewall or reverse proxy rule that blocks the known malicious JSON structures or the specific WSDL/login servlet request patterns buys you real protection while you plan a longer-term fix.
4. Tighten brute-force and threat detection on anything you can’t isolate. Rate-limit authentication endpoints, alert on anomalous JSON deserialization attempts, and watch for the kind of outbound connections that follow successful RCE.
5. Plan the migration, don’t just mitigate. Upgrading off Fastjson 1.x, or replacing an exposed legacy PLM front end, is the only way to actually close this instead of managing it indefinitely.
6. Rehearse incident response for exactly this scenario. Unauthenticated RCE against unpatchable software should have a documented containment and isolation runbook, not an improvised one written during the breach.

None of this requires a specific vendor tool. It requires someone deciding that “no patch available” ends the conversation about risk acceptance, not the conversation about defense.

Frequently Asked Questions

Why doesn’t Alibaba just patch Fastjson 1.x?

The 1.x branch is effectively end of life; Alibaba’s development effort has moved to Fastjson 2.x. Vendors routinely stop backporting fixes to deprecated major versions, even when those versions remain widely deployed, which leaves organizations that haven’t migrated exposed indefinitely.

How do I know if my Windchill or FlexPLM instance is exposed?

Check whether the WSDL endpoints or login servlet are reachable from the public internet using an external scan or asset inventory tool, and confirm with your PTC vendor contact whether your deployment includes the specific components named in the current advisories.

Is virtual patching a real substitute for a software fix?

It’s a mitigation, not a cure. A WAF rule or firewall restriction can block known exploit patterns and buy time, but it won’t close the underlying flaw. Treat it as a bridge toward migration or replacement, not a permanent answer.

Sources

• Fastjson 1.x RCE Vulnerability Targeted in Attacks With No Patched Available
• Cl0p Affiliates Target Internet-Exposed PTC Windchill and FlexPLM with Unauthenticated RCE
• DevMan RaaS Portal Centralizes Payload Builds, Victim Management, and Affiliate Payouts