Paths or symlinks ending in a slash escape the sandbox

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

9.0 · CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

EPSS

No dated EPSS signal available.

As published by the source; long descriptions are shortened.

cap-primitives resolves a path inside a sandboxed directory one component at a time and opens the last component with `O_NOFOLLOW`, so that a symlink there cannot lead out of the directory. When the path ended in `/`, the resolver added the slash back to the last component before opening it. With a trailing slash the operating system no longer treats that component as the last one, so `O_NOFOLLOW` does not apply, the symlink is followed, and the resulting file descriptor was returned without further checks. A symlink inside the sandbox that points outside it, such as `escape -> ../outside` or a link to `/`, can therefore be opened as `escape/`. If the symlink's own target ends in `/`, the caller's path does not need a trailing slash at all, so removing trailing slashes from untrusted input is not a workaround. The maintainers' advisory reports reads and writes outside the sandbox through `open`, `open_dir`, `read_dir` and `canonicalize`, and directory creation, removal and renames…

Published by the source

20 Aug 2026, 12:00 UTC

Last modified by the source

11 Nov 2026, 08:45 UTC

Source last checked

12 Nov 2026, 06:15 UTC

1. Revision 1 · created · 12 Nov 2026

   Published from osv record RUSTSEC-2026-0482

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: GHSA-hp8f-xmx4-4qrg

Advisory: Paths or symlinks ending in a slash escape the sandbox
IDs: GHSA-hp8f-xmx4-4qrg
Record: https://patchnext.com/advisories/rustsec-2026-0482 (revision 1, source checked 12 Nov 2026, 06:15 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Critical (CVSS 9.0)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: cap-primitives 4.0.3, 3.4.6. A vendor fix does not mean a deployment is fixed.

## Affected components
- crates.io cap-primitives: affected >= 0.0.0-0, < 3.4.6; >= 4.0.0, < 4.0.3; fixed in 3.4.6, 4.0.3

## Suggested inspection (read-only)
- crates.io cap-primitives: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on cap-primitives.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://osv.dev/vulnerability/RUSTSEC-2026-0482 (OSV record RUSTSEC-2026-0482 lists affected ranges: crates.io cap-primitives >=0.0.0-0 =4.0.0 <4.0.3 (fixed))

Commands are suggestions: review each one before running it.