# Shared storage path overwrite

Writes to shared upload or metadata paths not bound to the caller's identity or tenant

_Area: Web access control and IDOR. Seen in 2 disclosed reports; one confirmed bounty: $400; latest 2023-06-22. Updated 2026-10-23._

## How it works
A write operation (upload, import, file-drop, metadata update) targets a storage location that is shared across users or tenants, and the code keys that location only by a name, secret, or filename rather than by the caller's ownership. The assumption that breaks: that the path or key uniquely identifies the caller's own object. When two parties can compute or supply the same key, the second writer silently replaces the first writer's data. The same flaw appears when a config attribute store is "locked" but an alternate code path writes to it anyway, so document content overrides settings the platform intended to control [E1](https://bugbountylibrary.com/r/h1%3A1098793.md).

## Where to show up
- Import/export or archive-restore code that writes into a global uploads directory keyed by secret+filename [E3](https://bugbountylibrary.com/r/h1%3A534794.md)
- File-drop or multi-writer stores that return the whole metadata blob to every participant and accept client-supplied metadata wholesale [E2](https://bugbountylibrary.com/r/h1%3A1914115.md)
- Framework "locked" attributes with alternate writers (counters, substitutions, includes) that bypass the lock check [E1](https://bugbountylibrary.com/r/h1%3A1098793.md)
- Any consumer that File.read's or serves a path derived from user-controlled attributes [E1](https://bugbountylibrary.com/r/h1%3A1098793.md)

## How to review
Check the invariant: every write must be bound to the caller's identity/tenant, and an existing object owned by someone else must not be overwritable. Trace the key used for the write path; confirm it includes an owner or tenant component the caller cannot forge. For locked-attribute systems, enumerate every code path that writes to the attribute store and confirm each honors the lock. For shared metadata, confirm the server validates that a client only appends or edits its own entry.

## Variants seen
- Attribute-lock bypass via counter directive, leading to arbitrary file read/write [E1](https://bugbountylibrary.com/r/h1%3A1098793.md)
- Shared E2EE metadata overwrite making another user's upload undecodable [E2](https://bugbountylibrary.com/r/h1%3A1914115.md)
- Project import overwriting another user's upload by known secret+filename [E3](https://bugbountylibrary.com/r/h1%3A534794.md)

## Impact and severity
Led to arbitrary file read/write [E1](https://bugbountylibrary.com/r/h1%3A1098793.md), permanent data loss of encrypted uploads [E2](https://bugbountylibrary.com/r/h1%3A1914115.md), and backdoored served binaries [E3](https://bugbountylibrary.com/r/h1%3A534794.md). Severity rises when the overwritten object is later served or executed, and when the attacker only needs a guessable secret or filename.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A1098793.md
- E2: https://bugbountylibrary.com/r/h1%3A1914115.md
- E3: https://bugbountylibrary.com/r/h1%3A534794.md