This CVE exposes a privilege boundary collapse in TinaCMS's media storage adapters (S3, DOS, Azure, Cloudinary). The API design treats storage SDK operations as transparent passthrough rather than a security-critical interface. When createMediaHandler accepts req.query.key and passes it directly to PutObjectCommand or DeleteObjectCommand, it's operating at the infrastructure layer with no concept of CMS mediaRoot boundaries. The mediaRoot configuration existed in the application layer but was never enforced at the point where credentials were actually exercised.
The identical flaw across all four adapters signals an architectural assumption baked into the design: developers were expected to trust authenticated CMS editors completely, treating the CMS layer as a UI wrapper around storage operations. But CMS editors aren't infrastructure operators—they shouldn't have write access to arbitrary object keys within a bucket. The vulnerability emerged because the API design didn't distinguish between 'editing content within the CMS scope' and 'manipulating storage objects with infrastructure credentials.'
The fix enforces mediaRoot at the handler level, but examine the actual implementation. Is the handler validating that the requested key starts with mediaRoot using string prefix matching (bypassable with path traversal like ../), or is it a hard namespace boundary? If mediaRoot itself is operator-configurable to values like / or s3://bucket/, the patch is cosmetic. The patch may also leave historical exposure intact—if credentials were exercised during the vulnerable window, existing objects may already be compromised or poisoned.
For operators: audit whether mediaRoot is hardcoded or configurable in your deployment, assume storage credentials used by these adapters may have been exercised beyond intended scope, and treat this as a supply-chain staging platform (the write oracle enables CDN cache poisoning, signed URL abuse, or Lambda trigger manipulation). Check your dependency trees for older adapter versions that may never receive the patch, and rotate storage credentials if there's any indication of historical abuse.