# GHSA-q9m2-fhv9-3jcf: `potato-annotation` has a Project-Boundary Bypass

> Attackers can bypass project boundary checks to access or modify files outside the intended directory due to flawed string-prefix validation.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not stated
- **Attackable:** Not stated
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 8 May 2026

## What is GHSA-q9m2-fhv9-3jcf?

GHSA-q9m2-fhv9-3jcf is a path traversal vulnerability in potato-annotation, published on 8 May 2026. 

### Official description

## Summary
`validate_path_security` uses string-prefix containment (`startswith`) for boundary checks. This allows paths that are **outside** the intended project directory but share its prefix string (e.g., `/tmp/potato_proj_demo_evil/...` vs `/tmp/potato_proj_demo`) to be accepted.

## Details
### Affected source location (root cause)
**File:** `potato/server_utils/config_module.py`

**Snippet (lines 370–373):**
```python
real_path = os.path.realpath(normalized_path)
real_base = os.path.realpath(base_dir)
if not real_path.startswith(real_base):
    raise ConfigSecurityError(...)
```

**Snippet (lines 384–389):**
```python
real_path = os.path.realpath(normalized_path)
check_dir = project_dir if project_dir else base_dir
real_check_dir = os.path.realpath(check_dir)
if not real_path.startswith(real_check_dir):
    raise ConfigSecurityError(...)
```

`startswith()` is string-based, so `/tmp/potato_proj_demo_evil/...` passes when checked against `/tmp/potato_proj_demo`.

### Confirmed affected call sites
**File:** `potato/server_utils/config_module.py`

1) `validate_file_paths` task_dir branch (line 2113)
```python
validated_task_dir = validate_path_security(task_dir, project_dir)
```

2) `validate_file_paths` data_files branch (line 2151)
```python
validated_path = validate_path_security(file_path, base_dir, project_dir)
```

3) `validate_training_config` training.data_file branch (line 2286)
```python
validated_path = validate_path_security(data_file, base_dir, project_dir)
```

## PoC
```python
from potato.server_utils.config_module import validate_path_security

base = '/tmp/potato_proj_demo'
vuln = '/tmp/potato_proj_demo_evil/file.txt'

try:
    print('inside=', validate_path_security('/tmp/potato_proj_demo/file.txt', base, base))
except Exception as e:
    print('inside_error=', type(e).__name__, e)

try:
    validate_path_security('/tmp/other_demo/file.txt', base, base)
except Exception as e:
    print('baseline=', type(e).__name__, e)

print('trigger=', validate_path_security(vuln, base, base))
```

## Impact
- Can allow unauthorized sibling-prefix file access outside intended project boundary.
- Can affect read paths (`data_files`, `training.data_file`, `base_css`, `header_logo`) and output/path placement depending on configuration.

## Which versions are affected by GHSA-q9m2-fhv9-3jcf?

2 open source packages ship an affected version, including potato-annotation.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `potato-annotation` | PyPI | From 2.0.0 | 2.4.5 |
| `potato-annotation` | PyPI | From 2.0.0 | 2.4.5 |

## How do I fix GHSA-q9m2-fhv9-3jcf?

Upgrade potato-annotation to 2.4.5 or later.

## Is GHSA-q9m2-fhv9-3jcf being exploited?

There is no known exploitation of GHSA-q9m2-fhv9-3jcf in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-q9m2-fhv9-3jcf and fix it if it is affected.

What it is: GHSA-q9m2-fhv9-3jcf is a path traversal vulnerability in potato-annotation, published on 8 May 2026. 
Exploitation: There is no known exploitation of GHSA-q9m2-fhv9-3jcf in the wild and no public exploit code.

Affected packages and fixed versions:
- potato-annotation (PyPI): affected from 2.0.0; fixed in 2.4.5
- potato-annotation (PyPI): affected from 2.0.0; fixed in 2.4.5

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-q9m2-fhv9-3jcf/ (Markdown: https://insights.sbomify.com/GHSA-q9m2-fhv9-3jcf/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-q9m2-fhv9-3jcf

---
From sbomify Insights: https://insights.sbomify.com/GHSA-q9m2-fhv9-3jcf/
Summaries are generated and may contain mistakes; the official description above is the record.