Path traversal in a managed file transfer platform
Enterprise software
A managed file transfer product moved contracts, records and financial documents between large organisations. We were asked to test whether the download path could be made to serve a file the caller had no claim to.
Web & API penetration test, File transfer platform, severity CRITICAL, reported 2024
At a glance
- Challenge. A download endpoint accepted a caller-supplied file reference and returned the bytes without checking it resolved inside the caller's own space.
- Approach. We treated the download path as untrusted input and, with two accounts, adjusted a reference to point outside its intended root.
- Result. Path resolution was pinned to a per-tenant root and ownership enforced on the resolved file, then the download surface was retested.
- Impact. A tenant could read other tenants' documents and the server configuration holding credentials, and from there anything the platform had ever handled.
- Classification. CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), OWASP Top 10 (2021): A01 Broken Access Control. Component: File download endpoint.
The challenge
The download endpoint accepted a file reference from the client and returned the bytes. It confirmed the caller held a session. It did not confirm that the reference resolved to a file inside the caller’s own space, and it did not constrain where the reference was allowed to point.
A path supplied by a caller is an instruction, not a fact. When the receiving side treats it as a fact, the boundary that is supposed to separate one tenant’s files from another’s, and application data from the server’s own configuration, stops being a boundary and becomes a naming convention. Certification against a compliance checklist does not close this gap, because the checklist asks whether access control exists, not whether it is applied to the object actually being served.
On a platform whose entire purpose is to hold other people’s sensitive documents, a reference that can be pointed outside its intended directory reaches the configuration that holds credentials, and from there everything the platform has ever handled.
Our approach
We treated the download path as untrusted input and asked what it could be made to resolve to, rather than what the interface intended it to resolve to. Two accounts under our control provided a clean before and after: a reference issued to one, replayed and adjusted from the other.
Around that we checked the surface that shares the same assumption:
- Whether the reference was resolved against a fixed root or trusted as an absolute location
- Whether tenant ownership was enforced on the resolved file, not on the request
- Whether secrets recovered from configuration unlocked anything beyond the file store
- Whether the token that verified identity was signed with a key strong enough to resist offline guessing
Delivered with the exact references used and the resulting responses, so each finding could be reproduced against a test tenant without taking our word for it.
From finding to fix
- Mapped the file-download surface
- Pointed a request outside its intended root
- Reached configuration and other tenants' files
- Pinned resolution to one root, retested
The outcome
Path resolution was pinned to a per-tenant root and ownership was enforced on the resolved object rather than on the presence of a session, so a reference can no longer escape the space it was issued in. Token signing was moved to a managed key of adequate strength, closing the second path to impersonation.
We retested the download surface and the authentication path after the fix. Reported as CRITICAL in 2024. Retest included in the engagement.
Check your own system
- Resolve every caller-supplied path against a fixed root and reject any reference that escapes it.
- Enforce tenant ownership on the resolved file, not on the presence of a valid session.
- Keep application file stores separate from server configuration and secrets, so one boundary failure does not reach both.
- Sign identity tokens with a key strong enough to resist offline guessing, and review what a recovered secret would grant.
Read more case studies, see Web Application Penetration Testing, or tell us about your system on the contact page.