Tina: Broken Access Control: arbitrary bucket-key write/delete in `next-tinacms-s3` (and sibling production media adapters)

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

Tina is a headless content management system. Prior to next-tinacms-s3 23.0.4, next-tinacms-dos 23.0.4, next-tinacms-azure 14.0.4, and next-tinacms-cloudinary 26.0.4, the first-party production media adapters pass attacker-controlled object keys to storage SDK upload and delete operations without enforcing the operator's configured mediaRoot. In packages/next-tinacms-s3/src/handlers.ts, createMediaHandler accepts req.query.key for a signed PutObject URL and the DELETE path uses req.query.media as the DeleteObjectCommand key. The same missing key-boundary check exists in packages/next-tinacms-dos/src/handlers.ts, packages/next-tinacms-azure/src/handlers.ts, and packages/next-tinacms-cloudinary/src/handlers.ts. An authenticated CMS editor can therefore create or delete objects anywhere the deployment's storage credential can reach, including other tenants' or non-media objects. These issues are fixed in next-tinacms-s3 23.0.4, next-tinacms-dos 23.0.4, next-tinacms-azure 14.0.4, and next-tinacms-cloudinary 26.0.4.

Source published

19 Aug 2026 21:30:51 UTC

Source modified

21 Aug 2026 16:48:12 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 5.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

Tina is a headless content management system. Prior to next-tinacms-s3 23.0.4, next-tinacms-dos 23.0.4, next-tinacms-azure 14.0.4, and next-tinacms-cloudinary 26.0.4, the first-party production media adapters pass attacker-controlled object keys to storage SDK upload and delete operations without enforcing the operator's configured mediaRoot. In packages/next-tinacms-s3/src/handlers.ts, createMediaHandler accepts req.query.key for a signed PutObject URL and the DELETE path uses req.query.media as the DeleteObjectCommand key. The same missing key-boundary check exists in packages/next-tinacms-dos/src/handlers.ts, packages/next-tinacms-azure/src/handlers.ts, and packages/next-tinacms-cloudinary/src/handlers.ts. An authenticated CMS editor can therefore create or delete objects anywhere the deployment's storage credential can reach, including other tenants' or non-media objects. These issues are fixed in next-tinacms-s3 23.0.4, next-tinacms-dos 23.0.4, next-tinacms-azure 14.0.4, and next-tinacms-cloudinary 26.0.4.

Source published

Aug 19, 2026, 9:30:51 PM (timezone not stated)

Source modified

Aug 21, 2026, 4:48:12 PM (timezone not stated)

Observed here

7 Nov 2026 13:26:13 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 5.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

Tina is a headless content management system. Prior to next-tinacms-s3 23.0.4, next-tinacms-dos 23.0.4, next-tinacms-azure 14.0.4, and next-tinacms-cloudinary 26.0.4, the first-party production media adapters pass attacker-controlled object keys to storage SDK upload and delete operations without enforcing the operator's configured mediaRoot. In packages/next-tinacms-s3/src/handlers.ts, createMediaHandler accepts req.query.key for a signed PutObject URL and the DELETE path uses req.query.media as the DeleteObjectCommand key. The same missing key-boundary check exists in packages/next-tinacms-dos/src/handlers.ts, packages/next-tinacms-azure/src/handlers.ts, and packages/next-tinacms-cloudinary/src/handlers.ts. An authenticated CMS editor can therefore create or delete objects anywhere the deployment's storage credential can reach, including other tenants' or non-media objects. These issues are fixed in next-tinacms-s3 23.0.4, next-tinacms-dos 23.0.4, next-tinacms-azure 14.0.4, and next-tinacms-cloudinary 26.0.4.

Source published

19 Aug 2026 22:16:40 UTC

Source modified

26 Oct 2026 10:10:00 UTC

Observed here

27 Oct 2026 15:15:33 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 5.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

## Summary The production media handler shipped by `next-tinacms-s3` (`createMediaHandler` in `packages/next-tinacms-s3/src/handlers.ts`) accepts an attacker-chosen `?key=` query parameter and returns an AWS-signed `PutObject` URL whose `Key` is that value, with no check that the key falls under the operator's configured `mediaRoot`. The same handler's `DELETE` branch reads `objectKey = (req.query.media as string[])[1]` and dispatches a `DeleteObjectCommand` for that exact key, again unbounded by `mediaRoot`. Any caller that passes the operator-supplied `authorized()` predicate — i.e. any logged-in CMS editor in a typical TinaCloud / self-hosted deployment — therefore has write and delete authority over the *entire* S3 bucket the IAM key can reach, even though the package documents `mediaRoot` as the place where editors are scoped. The same shape is present in `next-tinacms-dos`, `next-tinacms-azure`, and `next-tinacms-cloudinary`, so a single design mistake spans every first-party production media backend. * Project: TinaCMS — first-party production media adapters (consumed by self-hosted Next.js sites and TinaCloud-backed deployments). * Source reviewed: `tinacms/tinacms` @ `main` (`b56dad4`). * Deployed artefact validated: `[email protected]` handler logic, exercised against `@aws-sdk/[email protected]` via `[email protected]` (the AWS SDK signs the URL identically whether the bucket is real or mocked). * Affected file(s): * `packages/next-tinacms-s3/src/handlers.ts:67-90` — `GET ?key=` returns presigned `PutObjectCommand` URL with attacker-chosen `Key`. * `packages/next-tinacms-s3/src/handlers.ts:199-223` — `DELETE` reads `[, objectKey] = media` and issues `DeleteObjectCommand` against attacker-chosen `Key`. * `packages/next-tinacms-dos/src/handlers.ts:79-152` and `:249-278` — same write/delete pattern, plus a server-side upload that builds the key with `path.join(mediaRoot, prefix + filename)` over attacker-controlled `directory` and `filename`. * `packages/next-tinacms-azure/src/handlers.ts:44-95` — `uploadMedia` writes `path.join(directory, filename)` with both fields attacker-controlled (no `mediaRoot` configured at all); `deleteAsset` deletes any blob in the container. * `packages/next-tinacms-cloudinary/src/handlers.ts:193-204` — `cloudinary.uploader.destroy(public_id)` over attacker-chosen `public_id`. * CWE: CWE-639 — Authorization Bypass Through User-Controlled Key. Adjacent: CWE-284 (Improper Access Control), CWE-862 (Missing Authorization on the per-key authority check). * OWASP 2021: **A01:2021 — Broken Access Control** (the operator's intended `mediaRoot` boundary is enforced only on listing, not on writes or deletes). Secondary: A04:2021 — Insecure Design (every adapter independently re-implements the same broken pattern). ## Vulnerable code `packages/next-tinacms-s3/src/handlers.ts:39-98`: ```ts export const createMediaHandler = (config: S3Config, options?: S3Options) => { const client = new S3Client(config.config); const bucket = config.bucket; let mediaRoot = config.mediaRoot || ''; // (1) if (mediaRoot) { /* normalise to "media/" form */ } return async (req: NextApiRequest, res: NextApiResponse) => { const isAuthorized = await config.authorized(req, res); if (!isAuthorized) { res.status(401).json({ message: 'sorry this user is unauthorized' }); return; } switch (req.method) { case 'GET': if (req.query.key) { const expiresIn: number = (req.query.expiresIn && Number(req.query.expiresIn)) || 3600; // (2) const s3_key = req.query.key ? Array.isArray(req.query.key) ? req.query.key[0] : req.query.key : null; if (!s3_key) return res.status(400).json({ message: 'key is required' }); if (await keyExists(client, bucket, s3_key)) { return res.status(400).json({ message: 'key already exists' }); // (3) } const signedUrl = await getUploadUrl(bucket, s3_key, expiresIn, client); // (4) return res.json({ signedUrl, src: cdnUrl + s3_key }); } return listMedia(req, res, client, bucket, mediaRoot, cdnUrl); // (5) case 'DELETE': return deleteAsset(req, res, client, bucket); // (6) ``` `packages/next-tinacms-s3/src/handlers.ts:199-223`: ```ts async function deleteAsset(req, res, client, bucket) { const { media } = req.query; const [, objectKey] = media as string[]; // (7) const params: DeleteObjectCommandInput = { Bucket: bucket, Key: objectKey }; const command = new DeleteObjectCommand(params); ... } ``` At **(1)** the operator configures `mediaRoot` (e.g. `"media/"`), and the package's `README` documents this as the directory the IAM key is scoped to. At **(4)** the handler signs a `PutObjectCommand` with `Key: s3_key` taken verbatim from `req.query.key`. Nothing between (1) and (4) verifies that `s3_key` starts with `mediaRoot`, so any path the IAM key can reach is fair game. The only filter is the `keyExists` check at **(3)**, which prevents *overwrite* of an existing object but not creation of arbitrary new ones (and not overwrite of objects the IAM key cannot `HeadObject`). At **(2)** the validity window of the produced URL is also attacker-controlled, capped only by AWS SigV4's 7-day hard limit. At **(5)** the *list* path **does** prefix-join `mediaRoot` (`Prefix: mediaRoot ? path.join(mediaRoot, prefix) : prefix`), demonstrating that the boundary was understood to exist — it just isn't enforced on writes. At **(6)** + **(7)** delete extracts the second URL segment into `objectKey` with no prefix check, so `DELETE /api/s3/media/x/anything-in-the-bucket` is a valid arbitrary-key delete primitive. For contrast, the same package's `listMedia` (line 139) does write `Prefix: mediaRoot ? path.join(mediaRoot, prefix) : prefix`, and `stripMediaRoot` (line 100) exists explicitly to peel `mediaRoot` off keys returned to the client — so the codebase models `mediaRoot` as a security boundary on the read side. The write and delete sides simply forgot to apply it. The same misalignment is duplicated in three sibling packages: * `packages/next-tinacms-dos/src/handlers.ts:115-125` — upload builds `Key: mediaRoot ? path.join(mediaRoot, prefix + filename) : prefix + filename` over attacker-controlled `prefix` (from `req.body.directory`) and `filename` (from `multer`'s `file.originalname`); `path.join` collapses `..` segments, so a `directory` of `../..` plus a chosen `filename` lands at any key in the bucket. Lines 249-278 reproduce the S3 delete-by-second-segment pattern. * `packages/next-tinacms-azure/src/handlers.ts:44-95` — `uploadMedia` writes a blob at `path.join(directory, filename)` with both values straight out of `formData`. `next-tinacms-azure` has no `mediaRoot` config at all (`AzureBlobStorageConfig` in `src/types.ts`), so the entire container is writable / deletable by any authorized user. * `packages/next-tinacms-cloudinary/src/handlers.ts:193-204` — `deleteAsset` calls `cloudinary.uploader.destroy(public_id)` over the attacker-chosen second segment, deleting any asset in the cloud. The same handler's `listMedia` (line 110) interpolates `mediaListOptions.directory` directly into a Cloudinary search-expression DSL string (`folder="${directory}"`), giving an authorized user full search-expression injection — out of scope for this finding but worth a separate report. ## Reproduction (validated locally) Environment: Node 22, `@aws-sdk/[email protected]`, `@aws-sdk/[email protected]`, `[email protected]`. The harness vendors `createMediaHandler` byte-for-byte from `packages/next-tinacms-s3/src/handlers.ts` and runs it against a mocked `S3Client`. The AWS SDK signs the URL identically whether the bucket exists — the resulting URL is the same one a real S3 deployment would hand back to the editor's browser, so it would PUT against a real bucket without further help. PoC layout under `/Users/admin/joplin_research/tinacms-s3-poc/`: ``` package.json (deps only) handler-vendored.mjs (verbatim copy of createMediaHandler, types stripped) poc.mjs (four exhibits exercising the handler) ``` Handler is configured the way the package's `README` documents: ```js const handler = createMediaHandler({ config: { region: 'us-east-1', credentials: { accessKeyId: '…', secretAccessKey: '…' } }, bucket: 'editor-media-bucket', mediaRoot: 'media', // editors are "scoped to media/" authorized: async () => true, // typical wiring: TinaCloud verified user }); ``` Run: ```bash $ cd /Users/admin/tinacms-s3-poc && node poc.mjs --- Exhibit A: presigned PUT URL for arbitrary bucket key --- HTTP status : 200 signedUrl : https://editor-media-bucket.s3.us-east-1.amazonaws.com/index.html?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=AKIAFA... src : https://editor-media-bucket.s3.us-east-1.amazonaws.com/index.html signed Key : /index.html RESULT : BYPASS (signed URL writes outside media/) --- Exhibit B: cross-tenant overwrite via attacker-chosen key --- signed Key : /tenant-victim/posts/announcement.mdx RESULT : BYPASS (cross-tenant write primitive granted) --- Exhibit C: arbitrary-key DELETE via [...media] route --- HTTP status : 200 S3 Bucket : editor-media-bucket S3 Key : tenant-victim/posts/announcement.mdx RESULT : BYPASS (arbitrary-key DELETE granted) --- Exhibit D: attacker-controlled ?expiresIn --- X-Amz-Expires: 604800 sec RESULT : BYPASS (URL valid far longer than the 1h default) ``` Verification, in detail: 1. **Exhibit A** — `GET /api/s3/media?key=index.html`. `mediaRoot=media/` is configured but never consulted on the write path. The handler hands back a SigV4 URL whose path is `/index.html`. PUT'ing any body to that URL would create the bucket-root object `index.html` against the operator's IAM credentials. For a deployment that fronts the bucket with CloudFront / S3-website hosting, this is a one-shot site-defacement primitive (and, for any CSP that trusts the bucket, a one-shot stored-XSS primitive against the published site). 2. **Exhibit B** — same primitive, attacker-chosen key `tenant-victim/posts/announcement.mdx`. In the multi-tenant TinaCloud / TinaCMS Cloud deployment shape (one bucket shared across tenants, each tenant assigned a `mediaRoot/<tenant>/` prefix), a Tenant A editor receives a presigned PUT URL for any Tenant B key. Cross-tenant content tampering with no further bug needed. 3. **Exhibit C** — `DELETE /api/s3/media/anything-here-is-ignored/tenant-victim%2Fposts%2Fannouncement.mdx`. The handler reads the catch-all as `req.query.media = ['anything-here-is-ignored', 'tenant-victim/posts/announcement.mdx']`, destructures to `objectKey = media[1]`, dispatches `DeleteObjectCommand({ Bucket: 'editor-media-bucket', Key: 'tenant-victim/posts/announcement.mdx' })`. The mock confirms the captured command's `Key` is the attacker-supplied string. Real S3 will honour the same call. (The mock-captured call confirms the *handler's* behaviour; the real S3 call requires only `s3:DeleteObject` on the bucket, which the package's `README` instructs operators to grant.) 4. **Exhibit D** — `?expiresIn=604800` (7 days, the SigV4 ceiling). The handler accepts it, the resulting `X-Amz-Expires=604800`. Combined with Exhibit A, an attacker who briefly compromises a CMS session (e.g. via a stolen idle browser session or the dev-server CSRF write described in finding 06) can mint a long-lived offline write primitive — usable for a week with no further interaction with the CMS. The four exhibits together: cross-mediaRoot write, cross-tenant write, arbitrary-key delete, and long-lived signed-URL minting. ## Impact * **Cross-tenant / cross-mediaRoot write.** In any deployment where the bucket holds anything other than this one editor's `mediaRoot` (multi-tenant TinaCloud, shared corporate bucket, bucket-backed static site), an authorized editor obtains write authority over every key the IAM credential can reach. Concretely: defacement of a static site fronted by the bucket; cross-tenant content tampering; replacement of `*.html`, `*.js`, `*.json` assets that downstream consumers trust. (Exhibits A, B; `handlers.ts:67-90`.) * **Stored XSS via uploaded HTML.** S3 returns objects with the `Content-Type` the upload supplies. The presigned `PutObjectCommand` URL carries no `Content-Type` constraint — the attacker's `PUT` chooses it. An editor can therefore write an HTML / SVG / JS payload to the bucket-root, and any CDN or origin that serves bucket objects directly to an authenticated SaaS surface inherits stored XSS in that origin. * **Arbitrary-key delete (data destruction).** Through `[...media]` the handler treats the second URL segment as a free-form object key. An editor can wipe any object the IAM key can `s3:DeleteObject`, including non-media artefacts like deployment manifests, backups, or other tenants' files. (Exhibit C; `handlers.ts:199-223`.) * **Bucket-policy implications.** The `README` (lines 38-90) tells operators to grant the IAM key `s3:PutObject`, `s3:PutObjectAcl`, `s3:DeleteObject`, and `s3:ListBucket` on the *whole* bucket. The README implies the application code constrains the editor's actions to `mediaRoot`. Because the application code does not, every operator who follows the README has — without realising — granted every CMS editor full write/delete on the whole bucket. * **Long-lived offline write primitive.** `expiresIn` is attacker-controlled and not capped by the handler. A single GET request mints a URL valid for up to 7 days (AWS SigV4 ceiling). An attacker who briefly compromises a CMS session can stash one such URL and continue writing arbitrary objects long after the session is revoked. (Exhibit D.) * **Same-shape exposure on every other first-party media adapter.** `next-tinacms-dos` (DigitalOcean Spaces, S3-compatible), `next-tinacms-azure` (Blob Storage), and `next-tinacms-cloudinary` (Cloudinary) all duplicate the broken pattern. Azure has *no* mediaRoot config at all, so the boundary that `next-tinacms-s3` advertises but doesn't enforce isn't even nominally present in `next-tinacms-azure`.

Source published

19 Aug 2026 21:56:30 UTC

Source modified

21 Aug 2026 18:45:12 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

Publisher rating · MODERATE