CVE-2026-72921

This vulnerability in SeaweedFS exposes a design assumption gap that should concern every organization running multi-tenant storage: the authorization layer conflated string-scoped tokens with path-scoped access control, and tenant isolation failed at the implementation level, not just at the edges. The issue comes down to how token scopes were matched against requested paths. The code used a simple string prefix check—a token scoped to `/tenant1` would authorize access to `/tenant1-old`, `/tenant1234`, and any path beginning with those characters. There was no delimiter awareness, no segment boundary enforcement. The code wasn't checking if `/tenant1234` was a sibling namespace; it was checking if the path string started with the scope string. This isn't a subtle edge case. It's a fundamental mismatch between what the authorization model promised (tenant isolation) and what the code enforced (character sequence matching). The detail that should keep analysts awake at night is the write access vector. Read-only leakage in multi-tenant storage is a known and documented risk category. But the ability to corrupt or overwrite data in a sibling tenant's namespace transforms this from information disclosure into a data integrity issue. An attacker with a legitimately issued `/tenant1` token could silently modify `/tenant1234`'s data with no indication anything was wrong from the victim's perspective—and critically, without any audit trail if the system wasn't logging cross-tenant authorization decisions. The CVSS 8.1 rating warrants scrutiny. It captures network-exploitability, high-privilege-required, no-user-interaction characteristics accurately. But it structurally understates organizational exposure: every tenant issued a scoped token was simultaneously creating an exploitable write vector to every sibling path sharing that prefix. That's not one vulnerability exploited once—it's an access vector that scaled with the number of tenants and the creativity of their naming conventions. The 4.24 fix addresses the symptom, but the underlying problem is that the authorization layer exposed no friction against naive string matching. Path-segment-aware authorization requires deliberate semantic reasoning about what the authorization model actually means. The gap between 'scope to /tenant1' and 'check if path starts with /tenant1' is exactly the kind of assumption gap that emerges when authorization intent isn't formalized as machine-checkable constraints. Until the authorization model's interface specifies delimiter-aware matching as a contractual requirement rather than a security fix, future contributors will face the same cognitive gap. Defenders should audit their current token scopes immediately, checking for ambiguity in numeric or suffix-based tenant naming that could create sibling-bounding paths. Implement delimiter-aware path matching as a defensive layer regardless of patch status. And critically, verify that access logging exists at the authorization boundary—without it, cross-tenant writes leave no forensic footprint, and exploitation becomes indistinguishable from application bugs or user error.

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