CVE-2026-125113: xrootd has path traversal in directory listing that allows access to the parent directory via trailing ".." pattern
Summary
A path traversal vulnerability in XRootD allows users to escape the exported directory scope and enumerate the contents of the parent directory by appending /.. (specifically without trailing slash) to an exported path in xrdfs ls or HTTP PROPFIND requests.
This bypass ignores the all.export restriction.
Affected component
src/XrdXrootd/XrdXrootdXeq.cc, and more precisely the functions rpCheck() and Squash() used in doDirlist() (link), as they do not check if the path ends with ".." (without trailing slash). Then the path is passed directly to the filesystem layer.
PoC
Configuration
- Configuration file: conf xrd.port 1094
Exposing only /alice/ oss.localroot /srv/xrootd/data/ all.export /alice/
HTTP xrd.protocol http:1094 libXrdHttp.so
Logs / monitoring all.adminpath /var/spool/xrootd all.pidpath /var/run/xrootd
- Filesystem layout on the server: /srv/xrootd/data/ ├── alice/ ← only exported directory ├── bob/ ← not exported └── secret.txt ← not exported
- Starting the server: xrootd -c /etc/xrootd/xrootd.cfg
Steps to reproduce
Normal behavior (access outside export is denied): bash $ xrdfs root://<xrootd-server> ls / [ERROR] Server responded with an error: [3010] Stating path '/' is disallowed.
Bypass via trailing ..: bash $ xrdfs root://<xrootd-server>ls /alice/.. /alice/../alice /alice/../bob /alice/../secret.txt Also exploitable via HTTP PROPFIND:
bash curl -X PROPFIND 'http://<xrootd-server>:1094/alice/..' \ --path-as-is \ -H "Depth: 1" Returns HTTP 200 with full listing of the parent directory, including unexported entries (bob/, secret.txt).
However, file download via this path traversal is blocked: bash $ xrdcp root://<xrootd-server>/alice/../secret.txt . [0B/0B][100%][==================================================][0B/s] Run: [ERROR] Server responded with an error: [3010] Opening relative path 'alice/../secret.txt' is disallowed. (source)
Impact An attacker can enumerate directories and filenames outside the authorized export scope defined by all.export. In the example above, a server exporting only /alice/ leaks the existence of /bob/ and secret.txt located in the parent directory (oss.localroot).
File download is not possible through this vector, as xrdcp correctly rejects the path with error 3010. The impact seems therefore limited to information disclosure (directory and filename enumeration).
This vulnerability could affect all XRootD deployments regardless of authentication configuration, as it bypasses the export path restriction itself.
Suggested fix
In rpCheck() (src/XrdXrootd/XrdXrootdXeq.cc), change: cpp // Before if (fn[0] == '.' && fn[1] == '.' && fn[2] == '/') return 1;
// After if (fn[0] == '.' && fn[1] == '.' && (fn[2] == '/' || fn[2] == '\0')) return 1;
Other sources
The XRootD project provides a high-performance, fault-tolerant, and secure solution for handling large amounts of data distributed across multiple storage resources. Prior to version 5.9.2, XRootD's rpCheck() function in src/XrdXrootd/XrdXrootdXeq.cc rejects a parent-directory component only when two dots are followed by a slash and does not reject a terminal two-dot component. An unauthenticated attacker can append /.. to an exported path in xrdfs ls or an HTTP PROPFIND request, bypass the all.export directory scope, and cause directory and filename enumeration in the parent directory under oss.localroot. The demonstrated vector does not permit file download or disclose file contents. This issue is fixed in version 5.9.2.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/xrootdto a version that resolves this vulnerability.Fixed in 5.9.2 - Upgrade
Upgrade
XRootDto a version that resolves this vulnerability.Fixed in 5.9.2
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments that export a directory through XRootD are exposed when a requester can use directory-listing operations against that export. The issue affects both xrdfs ls and HTTP PROPFIND requests, and the provided example shows that all.export limited to /alice/ does not prevent listing its parent directory.
What does an attacker need to do to exploit this?
The attacker needs network access to the XRootD service and must submit a directory-listing request for an exported path with /.. appended without a trailing slash. No privileges or user interaction are indicated by the supplied severity vector.
What information can be obtained?
An attacker can enumerate the contents of the parent directory outside the configured exported scope. In the example, this exposes the names of a non-exported bob directory and secret.txt; the data only describes directory enumeration, not reading file contents.
How can I check whether a server is affected?
Test a directory-listing request against an exported path with /.. appended and no trailing slash, using either xrdfs ls or HTTP PROPFIND. If the response lists the parent directory rather than enforcing the all.export boundary, the server is affected.
What should be done to remediate this issue?
Update to the XRootD release containing the referenced fix, v5.9.2. The referenced commit changes the directory-listing path handling in rpCheck() and Squash() used by do_Dirlist().