CVE-2022-47986

What it actually does

CVE-2022-47986 is an unauthenticated remote code execution vulnerability in IBM Aspera Faspex 4.4.2 Patch Level 1 and earlier. The flaw is caused by unsafe YAML deserialization reachable through an obsolete API endpoint. A remote attacker can send a specially crafted request that causes the Faspex application to deserialize attacker-controlled Ruby objects, resulting in arbitrary command execution with the privileges of the Faspex application process. Because exploitation requires no authentication, no user interaction, and only network access to the service, compromise can lead to full confidentiality, integrity, and availability impact on the Faspex host and potentially adjacent systems.

Why it matters to the business

Successful exploitation can allow attackers to take over an exposed managed file transfer server, steal transferred files, deploy ransomware, create persistence, or use the server as a foothold into the broader network. This vulnerability is in CISA KEV, has been exploited in the wild, is associated with ransomware activity, and has an extremely high EPSS score, so internet-facing Faspex systems should be treated as high-priority emergency remediation targets. Organizations using Faspex for business-critical file exchange may face operational disruption, data exposure, regulatory reporting obligations, and recovery costs if exploited.

How an attack unfolds

An attacker first identifies an internet-accessible IBM Aspera Faspex instance running a vulnerable 4.x version. They then send a crafted HTTP request to the obsolete package relay API endpoint that includes malicious YAML content. The Faspex application parses the YAML unsafely, instantiates attacker-controlled Ruby objects, and executes embedded commands on the server. After gaining code execution, the attacker may run discovery commands, download additional tooling, create web shells or backdoors, access files handled by Faspex, harvest credentials or configuration secrets, move laterally, and in ransomware campaigns encrypt data or stage extortion-related activity. Public exploitation has been observed, including ransomware-related use, so exposed unpatched systems should be investigated for compromise, not only upgraded.

How to fix it

Upgrade IBM Aspera Faspex to a fixed release immediately. IBM removed the vulnerable obsolete API call in Faspex 4.4.2 Patch Level 2, so systems running Faspex 4.4.2 PL1 or earlier should be upgraded to 4.4.2 PL2 or a later supported Faspex release. If immediate upgrade is not possible, restrict network access to Faspex to trusted sources only, place it behind VPN or strong access controls, block access to the vulnerable package relay endpoint at a reverse proxy or WAF, and monitor aggressively for exploitation. Because this vulnerability is actively exploited and ransomware-associated, remediation should include incident-response validation: rotate credentials and secrets stored on or used by the Faspex host if compromise cannot be ruled out, review transferred-file exposure, and rebuild from known-good media where exploitation is confirmed.

How to confirm the fix worked

Confirm the installed IBM Aspera Faspex version is 4.4.2 Patch Level 2 or later, or another vendor-supported fixed release. Verify that the obsolete package relay API endpoint is no longer reachable or no longer processes requests. From external and internal network perspectives, confirm that Faspex is not exposed beyond intended trusted access paths. Review HTTP access logs for requests to the obsolete relay endpoint, especially POST requests containing Ruby YAML object markers. Validate that WAF or reverse-proxy controls block suspicious YAML deserialization payloads if compensating controls are used. On remediated systems, perform authenticated administrative version checks and, where approved, use a safe vulnerability scanner or vendor-recommended check to confirm the instance is no longer vulnerable.

Typical attack path

1. Scan the internet or target address ranges for exposed IBM Aspera Faspex services.
2. Fingerprint the Faspex version or test for the vulnerable obsolete API behavior.
3. Send a crafted unauthenticated request to the obsolete package relay API endpoint containing malicious YAML serialized objects.
4. Trigger unsafe YAML deserialization inside the Faspex application.
5. Execute operating system commands under the Faspex application context.
6. Download and run second-stage payloads such as web shells, reverse shells, credential harvesters, or ransomware tooling.
7. Access transferred files, application configuration, credentials, and local system data.
8. Establish persistence, move laterally, exfiltrate data, or disrupt operations.

How to detect it

To determine whether exploitation already occurred, review Faspex application logs, web server access logs, reverse-proxy logs, WAF events, EDR telemetry, operating system command execution logs, authentication logs, file integrity monitoring, and outbound network telemetry. Focus on unauthenticated POST requests to the obsolete package relay endpoint, especially requests containing Ruby YAML object syntax or deserialization gadget names. Correlate suspicious HTTP requests with child processes spawned by the Faspex/Ruby application, such as shell interpreters, download utilities, scripting engines, archive tools, or encryption-related commands. Investigate unexpected files created under Faspex application directories and web-accessible paths, new or modified startup mechanisms, unauthorized SSH keys, new local users, unusual outbound connections, and large archive or exfiltration activity. Because ransomware use has been reported, also search for ransom notes, mass file modification, suspicious encryption processes, and attacker staging directories. Threat intelligence and detections should include activity related to exploitation of IBM Aspera Faspex remote code execution and ransomware campaigns abusing this flaw.

• /aspera/faspex/package_relay/relay_package
• package_relay/relay_package
• relay_package
• !ruby/object
• --- !ruby/object
• Gem::Installer
• Gem::SpecFetcher
• ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy
• DeprecatedInstanceVariableProxy
• ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.new
• package_file_list
• YAML.load
• POST /aspera/faspex/package_relay/relay_package
• /opt/aspera/faspex
• /opt/aspera/faspex/log
• /opt/aspera/faspex/tmp
• /opt/aspera/faspex/public

What your security team should do

• Treat any internet-facing vulnerable Faspex instance as potentially compromised because the vulnerability is in CISA KEV, has active exploitation, has ransomware association, and has a very high EPSS likelihood.
• Upgrade IBM Aspera Faspex to 4.4.2 Patch Level 2 or later immediately; prioritize systems exposed to the internet or partner networks.
• If upgrade cannot be completed immediately, restrict access to Faspex at firewalls, VPNs, reverse proxies, and WAFs, and block requests to the obsolete package relay endpoint.
• Hunt historical web, application, reverse-proxy, EDR, and system logs for exploit attempts and post-exploitation activity dating back to at least the public disclosure and any available log-retention window.
• Look for signs of arbitrary command execution by the Faspex application account, including unexpected shell, curl, wget, Python, Perl, Ruby, PowerShell, certutil, or encoded command activity.
• Inspect the Faspex host for unauthorized files, web shells, new users, SSH keys, scheduled tasks, cron jobs, services, ransomware notes, suspicious archives, and outbound connections to unknown infrastructure.
• Rotate credentials, API keys, database passwords, transfer credentials, and certificates accessible from the Faspex server if exploitation is suspected or cannot be ruled out.
• Segment managed file transfer infrastructure from internal networks and limit outbound egress to approved destinations.
• Preserve forensic evidence before rebuilding systems where compromise is suspected.
• Report and track remediation according to KEV urgency; the CISA remediation due date was 2023-03-14, so any remaining vulnerable deployment is significantly overdue.