TinaCMS: dev-server CORS bypass allows arbitrary file write; production S3/Azure/Cloudinary media adapters allow cross-tenant write and delete
Two TinaCMS advisories landed together: the local dev server's CORS check only blocks the browser from reading the response, not from processing the state-changing request, so a malicious webpage can write arbitrary files into a running `tinacms dev` server's media root with no interaction beyond a page visit (CVE-2026-63123). Separately, the first-party production media handlers for S3, DigitalOcean Spaces, Azure Blob, and Cloudinary trust a caller-supplied key/path with no check that it falls under the configured `mediaRoot`, so any authorized CMS editor can mint presigned PUT URLs or issue deletes against any object the IAM credential can reach, including other tenants' content in shared-bucket deployments (CVE-2026-59992). Patch `@tinacms/cli` to ≥2.5.2 and the media adapter packages (`next-tinacms-s3`/`next-tinacms-dos` ≥23.0.4, `next-tinacms-azure` ≥14.0.4, `next-tinacms-cloudinary` ≥26.0.4); multi-tenant Tina deployments on a shared bucket should treat this as urgent, since the package's own README recommends bucket-wide IAM grants that this bug turns into a cross-tenant write primitive.