CVE-2025-10035: Goanywhere Managed File Transfer Deserialization of Untrusted Data (CVSS 10.0 CRITICAL)

TL;DR and CVE Summary

What This Vulnerability Actually Is

A deserialization vulnerability in the License Servlet of Fortra's GoAnywhere MFT allows an actor with a validly forged license response signature to deserialize an arbitrary actor-controlled object, possibly leading to command injection.

The CVSS 3.1 vector decomposes as follows: Network attack vector. low complexity. no privileges required. no user interaction. SCOPE CHANGED. high confidentiality impact. high integrity impact. high availability impact. The primary weakness classification is CWE-77 (Deserialization of Untrusted Data). An attacker submits a serialized data blob that the application deserializes without validating the contained object types. The deserialization process instantiates attacker-controlled classes and may invoke side-effect methods that lead to arbitrary code execution.

For investigators and defenders the practical translation of the CVSS vector matters. Network attack vectors mean the exposure surface is reachable from outside the affected host. Local vectors mean the attacker needs prior local access. Adjacent network vectors mean network-adjacent access (same VLAN or subnet) is required. The privileges-required field tells the defender whether an authenticated foothold is needed; no-privileges-required vulnerabilities can be exploited by unauthenticated traffic which expands the attack surface meaningfully. The user-interaction field is the other major control lever: vulnerabilities requiring user interaction typically depend on phishing or drive-by delivery paths that additional email and web-filtering controls can mitigate. Scope-changed vulnerabilities are the class defenders should treat as highest priority because exploitation crosses a security boundary the affected component was supposed to enforce; a compromised authentication scope often means credential extraction against the entire tenant and lateral movement into related systems.

How an Attacker Would Exploit This

Attacker identifies a deserialization sink (Java RMI, .NET BinaryFormatter, PHP unserialize, Python pickle, Ruby YAML). Crafts a payload using a known gadget chain (ysoserial for Java, ysoserial.net for .NET, PHPGGC for PHP) that produces code execution on deserialization. Submits the payload and confirms execution via callback. The Java vector typically targets enterprise application servers; the .NET vector targets ASP.NET applications; the PHP vector targets WordPress and other PHP CMS deployments.

This explanation is provided for defensive context. Sherlock Forensics does not publish weaponized proof-of-concept code. The exploitation path explanation is what defenders need to design detection rules and understand the attack surface; the precise weaponized payload belongs in vendor-coordinated disclosure and security research channels not in public-facing forensic analysis content. Where public exploit code does exist in the inventories below, defenders can review it through the linked sources for completeness.

The reconnaissance phase that typically precedes exploitation is worth understanding separately. Attackers scanning for the affected component typically fingerprint the version banner over standard protocols (HTTP for web-tier vulnerabilities, SSH and Telnet for management-plane vulnerabilities, service-specific banners for application-tier vulnerabilities). Modern attacker tooling (Shodan queries, Censys scans, mass port scanning with Zmap or Masscan) inventories every reachable instance of the affected component before targeting any specific host. For defenders the reconnaissance phase is the first opportunity for detection: unusual scanning against the exposed component surface and version-fingerprint probes leaves logging traces on the network perimeter and in the affected application access logs. Detecting reconnaissance early buys the defender the window needed to patch or apply compensating controls before the mass-exploitation phase begins.

Public Exploit Availability

ExploitDB: No public exploit code identified in the ExploitDB catalog as of the publication date of this article.

GitHub proof-of-concept repositories: 3 top-starred repositories reference this CVE:

• rxerium/CVE-2025-10035 (19 stars, last updated 2026-07-13). Detection for CVE-2025-10035
• ThemeHackers/CVE-2025-10035 (1 stars, last updated 2025-09-26). A deserialization vulnerability in the License Servlet of Fortra's GoAnywhere MFT allows an actor with a validly forged license response signature to deserialize an arbitrary actor-controlled object,
• sentinel-aidefense/CVE-2025-10035 (0 stars, last updated 2026-07-13). CVE-2025-10035 Research writeup

Metasploit Framework: No exploit or auxiliary module identified in the Rapid7 metasploit-framework repository as of the publication date of this article.

Nuclei templates: No detection template identified in the ProjectDiscovery nuclei-templates repository as of the publication date of this article.

The exploit-availability inventory above represents a snapshot at the publication date of this article. Public exploit availability changes over time. New ExploitDB entries and new GitHub PoC repositories and new Metasploit modules and new Nuclei templates may appear in the weeks after disclosure. Defenders should re-check the inventory periodically through the cited sources to stay current.

Forensic Detection Angle

For a forensic investigator or incident responder approaching a system suspected of exploitation by CVE-2025-10035 the detection workflow begins with the affected component access logs. For network-attack-vector vulnerabilities the relevant logs are web server access logs and application logs that capture the inbound request and the application response. For local-attack-vector vulnerabilities the relevant logs are system event logs (Windows Security and Windows Application and Sysmon when present; Linux auth.log and journald) and process execution evidence (Windows ShimCache and AmCache; Linux audit framework).

The detection pattern for Deserialization of Untrusted Data vulnerabilities typically shows in log artifacts as anomalous input and anomalous response correlation. The Sigma signature in the next section provides a starting detection logic; investigators should tune the signature to the specific affected component and the local log infrastructure. For organizations running endpoint detection and response (EDR) tooling the equivalent rule definitions in the EDR-specific query language (Microsoft Defender for Endpoint advanced hunting, CrowdStrike Falcon, SentinelOne, Sophos) cover the same logic and integrate into the existing security operations workflow.

Log retention is the practical constraint that most investigations run into after the fact. Web server access logs at default settings often retain only 30 to 90 days of history. Application logs vary widely; some retain days, others retain years. Windows Security event logs are size-bounded and can roll over within hours on busy systems. Linux systemd-journald retention is size-bounded and configuration-dependent. For any investigation the acquisition timing matters: preserve the relevant logs immediately upon suspicion because normal operation continues to roll the retention window forward. The Sherlock Forensics methodology treats log acquisition as an early-triage priority in every incident response engagement and documents the artifact retention window as part of the acquisition record. For organizations building incident response capacity the operational discipline is to extend retention on critical log sources beyond default settings and to include log destination inventory as part of the standard IR playbook so the acquisition team knows where every relevant log lives before an incident begins.

Detection Signature

The following Sigma rule covers the Deserialization of Untrusted Data pattern as it commonly appears in web server logs. Adapt the logsource and the field names to your specific stack. For non-web-application vulnerabilities the same logic translates to the corresponding application-tier log shape.

title: Java Deserialization Attack Indicators
id: cve-2025-10035-sigma-rule
status: experimental
description: Detects Java deserialization gadget chain signatures in application traffic.
references:
  - https://cwe.mitre.org/data/definitions/502.html
logsource:
  product: webserver
  category: webserver
detection:
  selection_payload:
    cs-uri-query|base64offset|contains:
      - "ysoserial"
      - "CommonsCollections"
      - "rO0AB"
  condition: selection_payload
falsepositives:
  - Legitimate serialized object exchange
level: high

The signature is starting logic. Production deployment requires tuning to reduce false positives against the specific application context. The signature is most effective when combined with other detection layers (network signature, application-specific WAF rules, EDR behavior rules).

Mitigation and Patch Guidance

The vendor remediation path for CVE-2025-10035 is published in the vendor advisory linked in the references section. Apply the vendor patch through the normal change management process. For organizations that cannot apply the patch within the standard SLA the compensating controls depend on the CVSS vector: for network-vector vulnerabilities the compensating controls include access restriction at the perimeter and WAF signatures and network segmentation; for local-vector vulnerabilities the compensating controls include privilege restriction and binary allowlisting.

After patch deployment the verification step confirms the affected version has been replaced with the fixed version. The verification command varies by component: package manager queries (rpm -qa and dpkg -l on Linux; Get-Package on Windows) confirm OS-package versions; application-specific version checks (Get-Module and Get-Item Version for Windows applications; npm ls and pip show for language ecosystems) confirm application-tier versions. For network-exposed services a direct probe of the version banner can confirm the patched version is in production. Document the verification result as part of the remediation record.

Post-patch monitoring matters as much as the patch itself. The Sigma signature provided above should be deployed even after the patch is applied because exploitation attempts continue against systems regardless of patched state. Failed exploitation attempts in the post-patch log stream are themselves intelligence about the threat landscape facing the affected component. Sherlock Forensics engagements routinely include post-remediation monitoring as part of the broader incident response and prevention scope.

References and Further Reading

• NIST National Vulnerability Database entry for CVE-2025-10035
• Vendor advisory
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-10035
• CISA Known Exploited Vulnerabilities Catalog

For Canadian organizations operating under PIPEDA or provincial-equivalent privacy frameworks an incident that involves exploitation of CVE-2025-10035 may carry breach notification obligations depending on the data exposure. The Sherlock PIPEDA Section 4.7 Compliance Deep Dive covers the notification framework. For incident response engagement support on this CVE class the Sherlock services page documents the methodology Sherlock applies to investigations involving the affected component class.