Insecure deserialization isn't a Java problem. Ask Ruby's YAML.load.

Insecure deserialization has a reputation as a Java problem: ObjectInputStream, gadget chains, the stuff of Log4j-adjacent nightmares. That reputation is misleading, and CVE-2022-47986 is a clean reminder why. It’s a pre-authentication remote code execution flaw in IBM Aspera Faspex, CVSS 9.8, and the root cause is a single call to Ruby’s YAML.load on data an unauthenticated attacker controls. Same trap, different language. Every serialization format that can instantiate objects, YAML in Ruby, pickle in Python, ObjectInputStream in Java, has the same footgun, and deserializing untrusted input is dangerous in all of them.

What the bug is

Aspera Faspex is IBM’s high-speed file-exchange application, and the vulnerable code is in its Ruby on Rails backend. Assetnote, which disclosed it, traced the flaw to an obsolete API endpoint, /package_relay/relay_package, reachable without authentication, where a user-controlled parameter (external_emails) flows into YAML.load (CWE-502). In Ruby, YAML.load on attacker-controlled input can instantiate arbitrary objects and trigger code execution, the same way unsafe deserialization does elsewhere. The result is unauthenticated RCE. IBM fixed it by removing the obsolete endpoint in Faspex 4.4.2 Patch Level 2; everything at 4.4.2 PL1 and earlier is vulnerable. CISA added it to the Known Exploited Vulnerabilities catalog on February 21, 2023, with the ransomware flag, and Assetnote reported thousands of exposed instances.

The cross-language lesson

The fix in Ruby mirrors the fix everywhere else, which is the point worth internalizing for anyone who writes code: never deserialize untrusted input with an API that can construct arbitrary objects. The safe pattern exists in every ecosystem:

• Ruby: use YAML.safe_load (or Psych.safe_load) with an explicit allowlist of permitted classes, not YAML.load. The unsafe call has been a known hazard for years.
• Python: never pickle.loads untrusted data; use a data-only format like JSON, and yaml.safe_load, not yaml.load.
• Java/.NET: avoid native object deserialization of untrusted input; use allowlist-based, data-only parsers.

The common thread: prefer formats and APIs that parse data into plain values, not ones that reconstruct live objects, and when you must, default-deny with an allowlist of safe types. Faspex’s bug was an YAML.load where a safe_load belonged, sitting on an unauthenticated endpoint that should have been removed long before. Both of those are review-catchable. If your codebase has deserialization sinks, grep for the unsafe variants in every language you use, not just the one you think of as risky.

The ransomware angle: following file transfer onto Linux

The exploitation pattern matters too. At least two ransomware operations adopted CVE-2022-47986, including Buhti and IceFire. IceFire is notable because this bug was part of its expansion onto Linux: a group previously focused on Windows used the Faspex flaw to hit enterprise Linux systems. That fits a broader trend, ransomware crews increasingly targeting Linux and the appliance-style enterprise software that runs on it, and file-transfer applications are a favored entry because they’re internet-facing, hold valuable data, and have a track record of pre-auth RCE bugs. The Cl0p MOVEit and GoAnywhere campaigns made the category famous; Faspex shows the same logic applied by other crews. If you run any internet-facing managed file-transfer product, assume it’s on a target list and patch it like a perimeter device.

What to do

• Patch Faspex to 4.4.2 PL2 or later. The fix removes the vulnerable endpoint. Given a pre-auth, ransomware-exploited RCE, this is emergency-grade if you somehow still run an older build.
• Get the file-transfer interface off the open internet where the workflow allows, or tightly restrict access. Most MFT compromises route through internet-exposed instances.
• Assume compromise on long-exposed, unpatched instances. Exploitation has been active since early 2023. Hunt for web shells, the Ruby/Rails process spawning unexpected children, and the ransomware payloads (IceFire, Buhti).
• For developers: audit deserialization across every language in your stack. Replace unsafe deserialization calls with safe, allowlist-based parsing, and treat any deserialization of request-derived data as a critical-severity finding in review, regardless of the language.

The reframe is for anyone who’s mentally filed deserialization risk under “Java.” It’s a property of how a format turns bytes back into objects, and it shows up in Ruby, Python, PHP, and .NET just as readily. CVE-2022-47986 is the Ruby instance: one unsafe YAML.load on an unauthenticated endpoint, escalated by ransomware crews onto enterprise Linux. Patch Faspex, keep your file-transfer software off the open internet, and in your own code, make safe deserialization the default in every language you ship. We track these file-transfer and deserialization entries closely, because they keep proving that the same class of bug recurs across the whole stack.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NVD CVE-2022-47986 — 2023-02
• IBM X-Force: CVE-2022-47986 — 2023-02
• Help Net Security: Ransomware gangs are exploiting IBM Aspera Faspex RCE flaw — 2023-03-30
• Qualys ThreatPROTECT: IBM Aspera Faspex RCE (CVE-2022-47986) — 2023-02-24