CVE-2025-10035 is a Java deserialization vulnerability in GoAnywhere MFT's licensing servlet. The bug lives in the code path that processes license response data from external clients — a classic trust boundary crossing point where untrusted input enters the system and gets deserialized without sufficient safeguards. The CVE explicitly states this can lead to command injection, meaning the classpath available to GoAnywhere includes deserialization gadgets capable of invoking Runtime.exec() or ProcessBuilder.
Here is what matters for defenders: the CVE describes a signature requirement on the license response, but this is not a strong security control. Licensing implementations overwhelmingly use symmetric HMAC schemes where the signing key is embedded in the client binary. Attackers routinely recover these keys through reverse-engineering rather than through cryptographic attacks. More critically, signature verification code is notorious for implementation flaws — timing oracle leaks, short-circuit evaluation bugs, and algorithm confusion attacks (requesting 'none' or downgrading to MD5) that bypass validation entirely without touching the key. You should assume a skilled attacker can craft a signed payload regardless of what the documentation claims.
The EPSS score of 0.99614 signals that automated exploitation is effectively certain. Attackers are already weaponizing this — they do not need to confirm command injection works in your specific environment before using the deserialization primitive. Even if your classpath lacks the full RCE chain, the trigger itself is valuable for persistence, lateral movement, or as a stepping stone. Do not wait for full impact confirmation.
Immediate actions: (1) Confirm GoAnywhere MFT version and apply the vendor patch immediately — this is not a vulnerability to schedule for a maintenance window. (2) Review whether your instance exposes the licensing servlet to external networks; if possible, restrict it to administrative networks or localhost. (3) Audit your Java classpath for dangerous deserialization gadgets (Commons Collections versions before 3.2.2 or 4.x before 4.1, Spring Beans or Spring Core below 3.2.18/4.3.30) — if these exist alongside the vulnerable code path, the attack surface is real. (4) Enable comprehensive request logging on the licensing endpoint to detect exploitation attempts; deserialization failures often leave diagnostic artifacts in logs even when exploitation appears to fail.