BlackTree Security · Infrastructure · Automation · AI

GoAnywhere MFT’s ‘Secure Folder’ Had a Hidden Exit

A managed file-transfer service is supposed to be unusually clear about who can reach which files. Fortra has disclosed a flaw in GoAnywhere MFT that breaks that expectation for a specific class of authenticated user: someone allowed to use both Secure Folders and Secure Mail could step outside their assigned home directory and read other files on the server.

The issue is CVE-2026-15913, a high-severity path traversal vulnerability in the /attachRemoteFiles endpoint. Fortra’s advisory was first published and last updated on 9 September 2026, with no time provided. It says the flaw affects GoAnywhere MFT versions before 7.10.2 and directs customers to upgrade to 7.10.2 or later. The vendor gives it a CVSS 3.1 score of 7.7.

The permission combination is the story

This is not an unauthenticated route into every GoAnywhere installation. Fortra says the attacker must already be a Web User with both Secure Folders and Secure Mail permissions. A reader skimming only the product name and severity score could miss that precondition. A defender who dismisses the bug because it needs an account could miss the opposite problem: file-transfer services often grant external partners and customers precisely this kind of web access.

Path traversal means the application does not keep a file request inside the directory it promised to confine the user to. In this case, a specially formed request to the affected endpoint can escape the user’s sandboxed home directory and reach files that account should not be able to read. The advisory describes arbitrary file read. It does not describe file modification or remote code execution, and the available vendor notice does not claim either.

That distinction matters operationally. The immediate question is not simply whether the MFT server is reachable from the internet. It is which active Web Users have the two required permissions, whether those accounts are held by outside organisations, and what sensitive material the GoAnywhere process can read beyond their assigned folders. A customer portal with many partner accounts may have a different exposure profile from a tightly limited internal deployment.

What administrators should check now

First, establish the installed GoAnywhere MFT version and plan the upgrade to 7.10.2 or later. Fortra identifies that release as the vendor fix. Until the change is complete, review accounts with both Secure Folders and Secure Mail permissions and remove either permission where an account does not need it. This is a risk-reduction step, not a substitute for the patch.

Next, inspect the files accessible to the application and the trust boundaries around them. An MFT server should not have broad read access to secrets, backups or unrelated application data merely because it needs to send and receive particular files. A review of least-privilege filesystem access will not prove that no attacker used this flaw, but it can limit what a successful file-read attempt could expose.

Finally, preserve and review relevant web-access and application logs for unusual use of the affected endpoint, especially by Web Users holding the required permission combination. Do not treat the absence of a public exploit report as evidence that an individual installation was not accessed. Equally, do not label every unusual file request an exploit without checking the underlying event. Fortra’s public advisory does not report confirmed malicious exploitation or provide a victim count.

The managed-service exception

Fortra adds an important exception: controls in its GoAnywhere MFT as a Service environment protect those customers from this vulnerability. That statement applies to the vendor’s managed service, not automatically to self-managed deployments or other hosting arrangements. Customers should confirm which service and version they actually run before applying the exception.

The uncomfortable lesson is familiar but easy to overlook. A folder boundary inside a file-transfer product is a security boundary, not just an organisational convenience. When that boundary can be crossed by a legitimate account, the exposure depends as much on account permissions and server-side file access as it does on whether the endpoint is publicly visible.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *