Is CVE-2022-47986 (IBM Aspera Faspex Code Execution) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2022-47986 to its Known Exploited Vulnerabilities catalogue on 21 February 2023, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. IBM Aspera Faspex could allow a remote attacker to execute code on the system, caused by a YAML deserialization flaw.

How to verify active exploitation for CVE-2022-47986

The practical question is not whether the flaw is serious, but whether your environment is exposed to a version or deployment pattern that could still be reachable by an attacker. For an actively exploited CVE, the first task is to confirm whether the vulnerable IBM Aspera Faspex instance exists anywhere in your estate, including internet-facing, partner-accessible, and forgotten test systems. Use the vendor advisory and the CISA KEV catalogue for authoritative version and remediation details, rather than relying on secondary summaries.

When a CVE reaches KEV status, treat it as an exploitation problem, not just a patching ticket. That means checking whether the asset is present, whether compensating controls exist, and whether any adjacent systems can reach it over the paths an attacker would actually use. A vulnerable service hidden behind a VPN is still relevant if an authenticated user, contractor, or exposed integration can reach it.

For a broader response pattern, the Zero-Day and Exploited Vulnerabilities Guide is the most direct internal starting point because it covers KEV triage, emergency mitigation, and post-patch hunting for exploited flaws.

Why YAML deserialization flaws become exploitation-ready

This CVE is a code execution issue rooted in unsafe deserialization. That matters because deserialization bugs often turn untrusted input into executable object graphs, which can convert a single request into arbitrary code execution if the application accepts attacker-controlled data in the wrong place. In practice, the exposure is not just the application feature itself, but the trust boundary around how it parses and reconstructs incoming data.

Once an attacker can influence that parsing path, the likely outcomes are remote command execution, implant placement, and follow-on access to application credentials, configuration material, or adjacent internal services. That is why deserialization flaws are routinely treated as high-impact even when the initial access path looks narrow. For readers who want the mechanics of this failure mode, Insecure Deserialisation Guide provides the underlying attack pattern and defensive filters that matter here.

If you need to understand how exploitability and operational urgency fit together, the CISA KEV listing is the strongest public signal that this is not a theoretical weakness. The more important decision is whether the system is still reachable, whether logging is sufficient to see misuse, and whether the application has already been exposed long enough for an attacker to test it.

What defenders should do when patching is delayed

If patching cannot happen immediately, the priority is to reduce reachable surface area and preserve evidence. Restrict access to the application, disable or isolate the vulnerable service if business operations allow it, and verify whether any front-end proxy, WAF, or network control is actually blocking the input path that triggers deserialization. If the system must remain online, document the exception as time-bound and owner-approved.

Because this is a code execution class issue, compensating controls should be judged on whether they truly break the exploit path, not whether they merely make exploitation harder. A generic perimeter rule is weaker than a control that prevents the vulnerable endpoint from receiving attacker-controlled payloads at all. For teams that want a structured remediation workflow, the Vulnerability Management Guide is useful for prioritisation, exception handling, and verification after remediation.

For supporting external references, the CISA Known Exploited Vulnerabilities Catalog confirms the exploitation status, and the CVE Program remains the canonical place to identify the record and track the vulnerability identifier consistently across tools and advisories.

Risk and Threat Considerations

Actively exploited remote code execution flaws are attractive because they collapse initial access and execution into one step. If the vulnerable IBM Aspera Faspex instance is exposed, an attacker can move from curiosity to control quickly, then use that foothold to stage persistence, steal credentials, or pivot into internal systems. The ransomware relevance in KEV is especially important because it indicates the flaw has value in real intrusion chains, not just proof-of-concept testing.

Failure mechanism: The application accepts attacker-controlled input, deserializes it unsafely, and allows crafted data to trigger code execution in the server process.

Impact: Successful exploitation can lead to full application compromise, data exposure, lateral movement, and deployment of secondary payloads, including ransomware.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs require rapid discovery, prioritization, and remediation.
Recommendation — Prioritise, contain, and remediate KEV-listed flaws on a continuous schedule.
NIST CSF 2.0	PR.PS-04 — Platform resilience and exploit mitigation	Exploitation of a server-side flaw requires hardening and mitigations around the vulnerable service.
	DE.CM-08 — Vulnerability scans are performed	Confirmed exploitation should trigger exposure checks and verification of vulnerable assets.
Recommendation — Reduce exploitability by hardening exposed services and validating compensating controls. Continuously scan for the vulnerable product and verify where it is still reachable.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	A KEV-listed vulnerability requires timely remediation and exception tracking.
	SI-4 — System Monitoring	Active exploitation makes monitoring and post-compromise detection material.
Recommendation — Remediate the flaw quickly and document any delay as a controlled exception. Increase monitoring for exploit attempts, suspicious execution, and follow-on activity.

Practitioner Guidance

What to verify: Confirm whether any Faspex instance exists in production, DR, partner, or legacy environments, then verify whether it is internet reachable, reachable from less-trusted networks, or exposed through shared authentication paths.

Decision rule: If you cannot prove the vulnerable instance is absent, treat it as exposed until you can verify version, exposure, and mitigation status from authoritative vendor guidance and CISA KEV.

What to measure: Track time to identify the asset, time to contain exposure, and time to complete remediation or a documented compensating control, because exploit windows matter more than theoretical severity for KEV-listed flaws.

Practitioner takeaway: For KEV-listed code execution flaws, the right question is not whether the weakness exists in the abstract, but whether any reachable instance still gives an attacker a live execution path.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org