Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2025-10035 (Fortra GoAnywhere MFT Deserialization of Untrusted…
Threats, Abuse & Incident Response

Is CVE-2025-10035 (Fortra GoAnywhere MFT Deserialization of Untrusted Data) being exploited in the wild?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2025-10035 to its Known Exploited Vulnerabilities catalogue on 29 September 2025, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Fortra GoAnywhere MFT contains a deserialization of untrusted data vulnerability allows an actor with a validly forged license response signature to deserialize an arbitrary actor-controlled object, possibly leading to command injection.

What this means for exploitation status

This is not a theoretical issue. CISA’s KEV listing means defenders should treat the vulnerability as actively exploited, then verify whether any GoAnywhere MFT instance is present in the environment, internet-facing, or reachable by a trusted partner path. For fast triage and response patterns around exploited flaws, see the Zero-Day and Exploited Vulnerabilities Guide.

Because the flaw is in managed file transfer software, exposure is often concentrated in a small number of high-value gateways. That makes it easy to miss in a broad asset inventory and hard to ignore once identified, especially if the product is used for regulated transfers, partner onboarding, or batch integrations.

Why deserialization bugs become execution paths

deserialization of untrusted data is dangerous because the application may reconstruct attacker-influenced objects before normal validation or authorization logic can stop them. In a product like GoAnywhere MFT, that can turn a trust-boundary failure into code execution or command injection if the crafted input reaches the vulnerable processing path.

From a defender’s point of view, the key question is not only whether the service is patched, but whether it was exposed long enough for an attacker to have interacted with it. If the service accepted externally reachable requests before remediation, treat the vulnerability as a potential intrusion path, not just a software defect.

For a deeper technical reference on this class of flaw, use the Insecure Deserialisation Guide.

How to verify exposure and what to do next

Start with a simple exposure check: identify every GoAnywhere MFT deployment, confirm whether it is internet-facing or reachable from untrusted networks, and compare that inventory against the vendor advisory and the CISA KEV catalogue for authoritative remediation details. If you have multiple environments, do not assume the same patch state or configuration applies everywhere.

If patching is delayed, reduce exposure immediately by restricting access to the management and application interfaces, removing unnecessary public reachability, and increasing logging on authentication, configuration, and command-execution events. After remediation, review the system for signs of pre-patch compromise, including unusual user creation, suspicious jobs, unexpected child processes, and outbound connections that do not match normal file-transfer activity.

Where exploitation may have exposed credentials or session material, rotate the affected secrets and review any service accounts or integrations that depended on the vulnerable instance. For a practical response lens on exploited vulnerabilities, consult the NIST National Vulnerability Database and the CISA Known Exploited Vulnerabilities Catalog.

Risk and Threat Considerations

Exploited MFT flaws are attractive because they sit on a trusted path between the organisation and external counterparties. Once abused, they can provide direct access to data flows, internal hosts, or credentials tied to downstream automation, which raises both breach and ransomware risk.

Failure mechanism: An attacker reaches a vulnerable GoAnywhere MFT instance and abuses the deserialization path before or instead of normal validation, turning trusted file-transfer infrastructure into an execution foothold.

Impact: The compromised service can be used for command execution, lateral movement, data theft, or follow-on ransomware activity, especially where the platform has broad partner connectivity or privileged integration credentials.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementActively exploited flaws require rapid identification, prioritization and remediation.
Recommendation — Prioritise and remediate KEV-listed exposures on an emergency timeline.
NIST SP 800-53 Rev 5SI-2 — Flaw RemediationThe question is about an exploited vulnerability and response to it.
IR-4 — Incident HandlingActive exploitation requires containment and compromise assessment, not patching alone.
Recommendation — Patch or mitigate the vulnerable GoAnywhere MFT instance immediately. Treat the exposed service as an incident candidate and investigate for compromise.
OWASP ASVSV4 — API and Web Service SecurityThe flaw sits in a network-exposed service that processes untrusted input.
Recommendation — Harden service interfaces that accept untrusted input and validate trust boundaries.
MITRE ATT&CKT1190 — Exploit Public-Facing ApplicationThe vulnerability is a public-facing application exploitation path when exposed externally.
Recommendation — Hunt for exploitation of the exposed GoAnywhere MFT application path.

Practitioner Guidance

What to verify: Confirm whether GoAnywhere MFT exists anywhere in production, DR, or partner-facing zones, and whether any instance was reachable from the internet or a less trusted network segment before remediation.

Decision rule: If the system handled external transfers and was exposed during the vulnerable window, treat the event as a potential compromise investigation, not a routine patching exercise, and prioritize log review and containment before broad functional testing.

What to measure: Track time-to-identify, time-to-contain, and time-to-remediate for exposed managed file transfer systems, because these platforms often carry outsized blast radius relative to their footprint.

Practitioner takeaway: When a KEV-listed MFT flaw is present, the important decision is not whether exploitation is possible, it is how quickly you can prove exposure, contain the service, and determine whether trust in adjacent integrations has been lost.

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