GoAnywhere MFT CVE-2025-10035: critical RCE and Medusa

CVE-2025-10035 is a critical GoAnywhere MFT deserialization vulnerability rated CVSS 10.0. It enables command injection through the administration console’s License Servlet. Fortra released fixes in September 2025, while subsequent investigations by the vendor and Microsoft confirmed earlier exploitation at multiple organisations, including activity associated with Storm-1175 and deployment of Medusa ransomware.

Recommendation: upgrade to GoAnywhere MFT 7.6.3 or 7.8.4, or a later supported release, immediately remove the Admin Console from the public Internet and search logs for SignedObject.getObject. Any system reachable before the fix warrants incident analysis and credential rotation.

Confirmed CVE-2025-10035 facts

Attribute	Value
Product	Fortra GoAnywhere MFT
Component	Admin Console License Servlet
CVSS	10.0 — critical
Vulnerable versions	releases before 7.8.4; fixed sustain line 7.6.3
Fixed releases	7.6.3 and 7.8.4
Weakness	untrusted deserialization / command injection
Key exposure	Internet-facing administration console
Exploitation	confirmed from at least 11 September 2025 by Fortra and Microsoft
Public PoC analysis	yes — watchTowr Labs

Fortra states that it opened an investigation on 11 September after a suspicious-activity report, created a hotfix on 12 September and posted full 7.6.3 and 7.8.4 releases on 15 September. The public advisory followed on 18 September.

Technical cause: trusting SignedObject

The vulnerable path processes a licensing response. GoAnywhere accepted an encrypted bundle carrying a serialized Java object. An outer validation layer restricted the type to java.security.SignedObject, which superficially looks like a security control. The danger appeared when reading the inner object.

SignedObject.getObject() deserializes the stored content. If an application performs that operation before effectively establishing trust in the signature and permitted inner classes, a controlled object may trigger a gadget chain. watchTowr’s public analysis showed how access to the licensing path and weaknesses in the surrounding authentication flow reached that sink.

A signed wrapper is not sufficient protection when:

a token required by the endpoint can be obtained without authentication;
keys or the protection format can be recovered from the product;
verification does not precede dangerous deserialization;
the classpath contains usable gadget classes;
the administration console is exposed to the Internet.

Public PoC and safe validation

watchTowr published “Is This Bad? This Feels Bad”, documenting technical reconstruction and proof-of-concept research. Do not test those details in production. Deserialization can immediately execute a command with application privileges.

A safe validation process is:

verify the active version and hotfix level in the portal and installation files;
establish historical Admin Console exposure, including load balancers and temporary rules;
preserve goanywhere.log, Admin Audit Logs, proxy logs and EDR data;
search exception traces for SignedObject.getObject;
reproduce testing only on an isolated copy without customer credentials or data;
externally confirm that the administration interface is unreachable after remediation.

PoC execution is unnecessary to justify patching. A vulnerable version combined with a public console is already sufficient evidence of severe risk.

Exploitation and ransomware

Microsoft Defender observed exploitation across multiple organisations on 11 September 2025, with tactics aligned to Storm-1175. After initial access, actors deployed remote-access tooling, moved through environments and, in one reported case, successfully deployed Medusa ransomware.

This does not mean every intrusion ended with Medusa or that only one actor possessed the exploit. Public technical detail and maximum severity make replication likely. The key defensive fact is that exploitation preceded the full public warning.

Remediation and attack-surface reduction

Fortra identifies 7.6.3 and 7.8.4 as fixed releases. Install the latest supported version from the customer portal and confirm every cluster node restarted successfully. Fortra-managed MFTaaS was updated by the vendor, but customers should still review tenant accounts, integrations and transfers.

The Admin Console should never be Internet-facing. Route access through a private network or MFA-protected VPN, dedicated administration workstations and an address allowlist. Separate public transfer endpoints from management at the routing and firewall layers.

Also:

assign separate service identities to each partner and workflow;
restrict MFT access to shares, databases and secrets;
disable unused protocols and connectors;
control egress and child-process execution;
export audit data off-host so an attacker cannot easily erase it;
practise restoring configuration from a trusted backup.

Hunting and indicators

The most distinctive artefact described by Fortra is an exception containing SignedObject.getObject in the License Servlet stack. It is not a complete indicator—successful exploitation may produce different or limited logs.

Review:

requests to licensing paths and LicenseResponseServlet from unusual addresses;
new administrators, keys and partner-configuration changes;
Java child processes, command interpreters and remote-access tools;
staging archives and files created outside scheduled transfers;
new RDP, SSH and SMB activity from the MFT server;
services, scheduled tasks and other persistence;
bulk file reads or off-hours transfers;
attempts to clear logs or disable endpoint protection.

If deserialization or an unauthorised process is evident, isolate the system, preserve evidence and consider a full rebuild. Rotate partner credentials, SSH keys, certificates, database passwords and domain identities available to workflows.

Attack surface: separate administration from transfer

Fortra ties the at-risk condition to deployments where the Admin Console was exposed to the public Internet. That is an important architectural distinction: public SFTP, FTPS, AS2 or other business transfer endpoints do not need to publish the administration listener and route. Load balancers and reverse proxies sometimes expose both unintentionally.

Inventory every node, virtual address, port, proxy path, WAF rule, partner tunnel, disaster-recovery node and test image. Review historical configuration from at least the beginning of the vendor’s stated activity window, not only the state after September remediation. Firewall change records, infrastructure as code, DNS/certificate history and archived scans can establish when the console was reachable.

Collect the release from the portal, distribution files and active process on each node. A cluster can appear updated while one backend was never restarted. A DR image or restore automation may also retain a vulnerable branch. For managed service, confirm the provider/customer boundary but still assess your tenant’s accounts, workflows and transfers.

Safe exposure validation sends no encrypted package or Java object. Confirm whether an untrusted source can reach the administration endpoint at TCP, TLS and HTTP layers, record the response and compare it with the approved design. Do not bypass authentication. If a public path exists, remove it before deeper review.

Triage: vulnerable, exposed or compromised?

Divide instances into four groups:

Fixed release and console never public. Confirm every node and routing layer, then retest management controls.
Vulnerable release with a demonstrably private console. Patch urgently and verify that partner networks, VPN users and lower-trust segments could not reach it.
Vulnerable release with historical public console, no known indicator. Preserve logs, begin hunting, restrict access, update and prepare credential rotation.
Stack trace, unauthorised process, account, remote tool or lateral movement. Isolate and treat as a complete incident rather than patch management.

SignedObject.getObject raises confidence but its absence does not prove safety. Logs might have rotated, been disabled or changed, and successful execution need not leave the identical exception. Assess completeness across goanywhere.log, Admin Audit Logs, proxy/WAF, EDR and network telemetry. A visibility gap during exposure should increase caution.

For group four, stop automated transfers in a controlled way so evidence is not overwritten and modified files are not distributed. Where necessary, move approved partners to a clean, limited contingency channel. This belongs in the data-breach response plan, because an MFT platform has access to both sensitive data and external organisations.

Build a timeline and useful indicators

Start with requests to the Admin Console and licensing paths. Join source, X-Forwarded-For, timestamp, session identifier, HTTP status and responding backend. Then examine application events and exceptions in the same window. Normalise time zones and clocks across the load balancer, application and EDR before correlation.

On the host, focus on relationships between the Java process, child processes, new files and egress. Do not key detections to one shell name. Monitor unusual process trees, execution from temporary locations, archive creation, new administration tools, services and scheduled jobs. Maintain a baseline of child processes legitimately used by MFT integrations.

The data layer answers another question: what may have been read or changed? Correlate workflow logs, transfer queues, sizes, partner identities, technical accounts, source/destination and time. Look for bulk reads without an approved job, replay of old files, destination changes and new partner keys.

Lateral movement from an MFT server can appear in AD, RDP, SSH, SMB, databases and hypervisors. Review source sign-ins from the instance even when the identity is not a GoAnywhere administrator. Where the host had broad domain rights, include an Active Directory security assessment.

Harden MFT after the patch

Give the administration console a private route: management segment, allowlist, VPN or ZTNA with phishing-resistant MFA and a dedicated device. Do not publish it on the same virtual host as transfer services. Zero Trust controls evaluate principal, device, context and operation rather than only an IP address.

Separate administrator roles by function. A partner manager does not need global configuration, credential and audit control. Activate high-impact permission temporarily with reason and approval under privileged access management. Keep emergency identities outside routine SSO and alert on every use.

Each workflow should have a distinct identity with minimum rights to its share, bucket or database. Do not use one domain account for multiple partners. Restrict egress to known partners, update repositories and internal services. Prevent direct domain, backup or hypervisor administration from the transfer server.

Export Admin Audit, workflow and system logs off-host with tamper protection. File Integrity Monitoring should cover application libraries, configuration, keys and task scripts. Configuration backups need encryption, tested restoration and availability independent of a potentially compromised identity tenant.

Verify remediation and retest without exploitation

After installation, confirm the release on every node, Java process start time and file integrity against the vendor package. Record this state as evidence. Verify the load balancer sends no traffic to an old backend and that DR and staging also received the fix.

From an external network, prove the Admin Console is unreachable. From the management segment, test a dedicated administrator, MFA, roles, a low-risk configuration change and its complete audit trail. An agreed alert should correlate an unusual panel-access attempt across proxy and SIEM logs.

Do not replay public deserialisation mechanics in production. If technical confirmation is required, use an isolated lab with vulnerable and fixed releases and no customer keys, partners or data. The retest criterion is rejection of the former input class or inability to reach the sink using a harmless marker, without command execution.

Where compromise is suspected, an update is not sufficient closure. Require a clean rebuild or justified integrity analysis, rotation of every reachable credential, transfer and partner review, persistence checks, restoration from trusted backup and functioning detections. Include cloud dependencies and edge exposure in a renewed AWS, Azure and GCP penetration test.

CVE-2025-10035 decision tree

Does every node run 7.6.3, 7.8.4 or a later supported fix? If no or uncertain, preserve logs and update. If yes, confirm the active process and DR state.
Was the Admin Console ever public? If yes or history is incomplete, begin hunting. If no, document routing and log evidence.
Is SignedObject.getObject present, or a licensing request from an unusual source? Escalate triage if yes. If no, still review processes, accounts and transfers.
Did Java spawn an unusual process or did the host begin lateral movement? Isolate and perform full IR if yes. If no, assess EDR and log continuity.
Did workflows expose secrets, databases or shares? Rotate and review their use in risk order.
Was encryption, remote tooling or data staging detected? Invoke the ransomware response plan and notify data or partner owners under the incident procedure.

Why MFT needs a dedicated threat model

GoAnywhere automates exchange between organisations and internal systems. One server often holds trust across multiple zones, so compromise can enable both data theft and lateral movement. Segmentation should prevent direct domain administration, and the service identity must be limited to each specific transfer.

Regular infrastructure penetration testing should confirm that public MFT services do not expose the management plane or internal resources. A ransomware incident-response plan must include stopping automated transfers without destroying evidence.