CVE-2026-73613

This CVE exposes a structural gap in filebrowser's defense model: cache eviction logic was apparently never integrated into the permission boundary system, making it a permanent escape hatch that bypasses the same-file security controls applied to every other operation. The vulnerability isn't technically sophisticated — it's a straightforward TOCTOU race with a symlink swap — but its significance lies in where it lives. The TUS upload cache eviction path calls raw `os.Remove` directly, outside the ScopedFs wrapper that normally enforces user boundaries. That this code path exists at all suggests either an oversight during development or a deliberate architectural trade-off that was never flagged as a security-relevant decision. What's striking is the permission scope: a user with only Create permission can trigger arbitrary deletion. The principle of least privilege would suggest Create should never imply or enable Delete, yet here the cache eviction mechanism treats the triggering user as a passthrough and acts on whatever path materialized during the race window. This means the permission model isn't truly enforced end-to-end — it's enforced at certain checkpoints, but not at the point of actual damage. The deeper concern is what this reveals about trust architecture. Developers chose to use ScopedFs because they assumed it was a comprehensive boundary, not a recommended-but-optional layer. This vulnerability proves that assumption wrong, and the blast radius extends to every assumption downstream of it. When one code path breaks the permission wrapper contract, it retroactively invalidates trust in every other path that was built on top of that guarantee. The EPSG score of 0.00364 seems low for a path-confusion attack requiring only Create access. Analysts should consider whether the TTL window adequately raises difficulty, or whether the low score reflects underweighting of access-control bypasses in scoring models that can't reason about permission model integrity as a first-class asset. What to check: review other auxiliary code paths — thumbnail generation, temp file handling, any background workers — for similar patterns where raw OS calls bypass ScopedFs wrappers. The TUS feature was likely integrated as a third-party library with its own lifecycle management, and that boundary between "our code" and "integrated code" created a zone where no single person's mental model of the threat model fully covered. That pattern almost certainly exists elsewhere in the codebase.

Reviewed through automated stages and approved by a human before publication.