Vulnerability-Lookup

GHSA-8MQ9-5FW2-5RM4

Vulnerability from github – Published: 2026-08-19 21:56 – Updated: 2026-08-21 18:31

Summary

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

Details

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: next-tinacms-s3@21.0.3 handler logic, exercised against @aws-sdk/client-s3@3.665.x via aws-sdk-client-mock@4.1.0 (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:

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:

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/client-s3@3.665.0, @aws-sdk/s3-request-presigner@3.665.0, aws-sdk-client-mock@4.1.0. 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:

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:

$ 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:

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).
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.
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.)
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.

Severity

5.4 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "next-tinacms-s3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "23.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next-tinacms-dos"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "23.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next-tinacms-azure"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next-tinacms-cloudinary"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59992"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-19T21:56:30Z",
    "nvd_published_at": "2026-08-19T22:16:40Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe 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\u0027s configured `mediaRoot`. The same handler\u0027s `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 \u2014 i.e. any logged-in CMS editor in a typical TinaCloud / self-hosted deployment \u2014 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.\n\n* Project: TinaCMS \u2014 first-party production media adapters (consumed by self-hosted Next.js sites and TinaCloud-backed deployments).\n* Source reviewed: `tinacms/tinacms` @ `main` (`b56dad4`).\n* Deployed artefact validated: `next-tinacms-s3@21.0.3` handler logic, exercised against `@aws-sdk/client-s3@3.665.x` via `aws-sdk-client-mock@4.1.0` (the AWS SDK signs the URL identically whether the bucket is real or mocked).\n* Affected file(s):\n  * `packages/next-tinacms-s3/src/handlers.ts:67-90` \u2014 `GET ?key=` returns presigned `PutObjectCommand` URL with attacker-chosen `Key`.\n  * `packages/next-tinacms-s3/src/handlers.ts:199-223` \u2014 `DELETE` reads `[, objectKey] = media` and issues `DeleteObjectCommand` against attacker-chosen `Key`.\n  * `packages/next-tinacms-dos/src/handlers.ts:79-152` and `:249-278` \u2014 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`.\n  * `packages/next-tinacms-azure/src/handlers.ts:44-95` \u2014 `uploadMedia` writes `path.join(directory, filename)` with both fields attacker-controlled (no `mediaRoot` configured at all); `deleteAsset` deletes any blob in the container.\n  * `packages/next-tinacms-cloudinary/src/handlers.ts:193-204` \u2014 `cloudinary.uploader.destroy(public_id)` over attacker-chosen `public_id`.\n* CWE: CWE-639 \u2014 Authorization Bypass Through User-Controlled Key. Adjacent: CWE-284 (Improper Access Control), CWE-862 (Missing Authorization on the per-key authority check).\n* OWASP 2021: **A01:2021 \u2014 Broken Access Control** (the operator\u0027s intended `mediaRoot` boundary is enforced only on listing, not on writes or deletes). Secondary: A04:2021 \u2014 Insecure Design (every adapter independently re-implements the same broken pattern).\n\n## Vulnerable code\n\n`packages/next-tinacms-s3/src/handlers.ts:39-98`:\n\n```ts\nexport const createMediaHandler = (config: S3Config, options?: S3Options) =\u003e {\n  const client = new S3Client(config.config);\n  const bucket = config.bucket;\n  let mediaRoot = config.mediaRoot || \u0027\u0027;                 // (1)\n  if (mediaRoot) { /* normalise to \"media/\" form */ }\n\n  return async (req: NextApiRequest, res: NextApiResponse) =\u003e {\n    const isAuthorized = await config.authorized(req, res);\n    if (!isAuthorized) {\n      res.status(401).json({ message: \u0027sorry this user is unauthorized\u0027 });\n      return;\n    }\n    switch (req.method) {\n      case \u0027GET\u0027:\n        if (req.query.key) {\n          const expiresIn: number =\n            (req.query.expiresIn \u0026\u0026 Number(req.query.expiresIn)) || 3600; // (2)\n          const s3_key = req.query.key\n            ? Array.isArray(req.query.key) ? req.query.key[0] : req.query.key\n            : null;\n          if (!s3_key) return res.status(400).json({ message: \u0027key is required\u0027 });\n          if (await keyExists(client, bucket, s3_key)) {\n            return res.status(400).json({ message: \u0027key already exists\u0027 }); // (3)\n          }\n          const signedUrl = await getUploadUrl(bucket, s3_key, expiresIn, client); // (4)\n          return res.json({ signedUrl, src: cdnUrl + s3_key });\n        }\n        return listMedia(req, res, client, bucket, mediaRoot, cdnUrl);     // (5)\n      case \u0027DELETE\u0027:\n        return deleteAsset(req, res, client, bucket);                      // (6)\n```\n\n`packages/next-tinacms-s3/src/handlers.ts:199-223`:\n\n```ts\nasync function deleteAsset(req, res, client, bucket) {\n  const { media } = req.query;\n  const [, objectKey] = media as string[];                                  // (7)\n  const params: DeleteObjectCommandInput = { Bucket: bucket, Key: objectKey };\n  const command = new DeleteObjectCommand(params);\n  ...\n}\n```\n\nAt **(1)** the operator configures `mediaRoot` (e.g. `\"media/\"`), and the package\u0027s `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\u0027s 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 \u2014 it just isn\u0027t 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.\n\nFor contrast, the same package\u0027s `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 \u2014 so the codebase models `mediaRoot` as a security boundary on the read side. The write and delete sides simply forgot to apply it.\n\nThe same misalignment is duplicated in three sibling packages:\n\n* `packages/next-tinacms-dos/src/handlers.ts:115-125` \u2014 upload builds `Key: mediaRoot ? path.join(mediaRoot, prefix + filename) : prefix + filename` over attacker-controlled `prefix` (from `req.body.directory`) and `filename` (from `multer`\u0027s `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.\n* `packages/next-tinacms-azure/src/handlers.ts:44-95` \u2014 `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.\n* `packages/next-tinacms-cloudinary/src/handlers.ts:193-204` \u2014 `deleteAsset` calls `cloudinary.uploader.destroy(public_id)` over the attacker-chosen second segment, deleting any asset in the cloud. The same handler\u0027s `listMedia` (line 110) interpolates `mediaListOptions.directory` directly into a Cloudinary search-expression DSL string (`folder=\"${directory}\"`), giving an authorized user full search-expression injection \u2014 out of scope for this finding but worth a separate report.\n\n## Reproduction (validated locally)\n\nEnvironment: Node 22, `@aws-sdk/client-s3@3.665.0`, `@aws-sdk/s3-request-presigner@3.665.0`, `aws-sdk-client-mock@4.1.0`. 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 \u2014 the resulting URL is the same one a real S3 deployment would hand back to the editor\u0027s browser, so it would PUT against a real bucket without further help.\n\nPoC layout under `/Users/admin/joplin_research/tinacms-s3-poc/`:\n\n```\npackage.json            (deps only)\nhandler-vendored.mjs    (verbatim copy of createMediaHandler, types stripped)\npoc.mjs                 (four exhibits exercising the handler)\n```\n\nHandler is configured the way the package\u0027s `README` documents:\n\n```js\nconst handler = createMediaHandler({\n  config: { region: \u0027us-east-1\u0027, credentials: { accessKeyId: \u0027\u2026\u0027, secretAccessKey: \u0027\u2026\u0027 } },\n  bucket: \u0027editor-media-bucket\u0027,\n  mediaRoot: \u0027media\u0027,                 // editors are \"scoped to media/\"\n  authorized: async () =\u003e true,       // typical wiring: TinaCloud verified user\n});\n```\n\nRun:\n\n```bash\n$ cd /Users/admin/tinacms-s3-poc \u0026\u0026 node poc.mjs\n--- Exhibit A: presigned PUT URL for arbitrary bucket key ---\n  HTTP status : 200\n  signedUrl   : https://editor-media-bucket.s3.us-east-1.amazonaws.com/index.html?X-Amz-Algorithm=AWS4-HMAC-SHA256\u0026X-Amz-Content-Sha256=UNSIGNED-PAYLOAD\u0026X-Amz-Credential=AKIAFA...\n  src         : https://editor-media-bucket.s3.us-east-1.amazonaws.com/index.html\n  signed Key  : /index.html\n  RESULT      : BYPASS  (signed URL writes outside media/)\n\n--- Exhibit B: cross-tenant overwrite via attacker-chosen key ---\n  signed Key  : /tenant-victim/posts/announcement.mdx\n  RESULT      : BYPASS  (cross-tenant write primitive granted)\n\n--- Exhibit C: arbitrary-key DELETE via [...media] route ---\n  HTTP status : 200\n  S3 Bucket   : editor-media-bucket\n  S3 Key      : tenant-victim/posts/announcement.mdx\n  RESULT      : BYPASS  (arbitrary-key DELETE granted)\n\n--- Exhibit D: attacker-controlled ?expiresIn ---\n  X-Amz-Expires: 604800 sec\n  RESULT       : BYPASS  (URL valid far longer than the 1h default)\n```\n\nVerification, in detail:\n\n1. **Exhibit A** \u2014 `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\u0027ing any body to that URL would create the bucket-root object `index.html` against the operator\u0027s 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).\n\n2. **Exhibit B** \u2014 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/\u003ctenant\u003e/` prefix), a Tenant A editor receives a presigned PUT URL for any Tenant B key. Cross-tenant content tampering with no further bug needed.\n\n3. **Exhibit C** \u2014 `DELETE /api/s3/media/anything-here-is-ignored/tenant-victim%2Fposts%2Fannouncement.mdx`. The handler reads the catch-all as `req.query.media = [\u0027anything-here-is-ignored\u0027, \u0027tenant-victim/posts/announcement.mdx\u0027]`, destructures to `objectKey = media[1]`, dispatches `DeleteObjectCommand({ Bucket: \u0027editor-media-bucket\u0027, Key: \u0027tenant-victim/posts/announcement.mdx\u0027 })`. The mock confirms the captured command\u0027s `Key` is the attacker-supplied string. Real S3 will honour the same call. (The mock-captured call confirms the *handler\u0027s* behaviour; the real S3 call requires only `s3:DeleteObject` on the bucket, which the package\u0027s `README` instructs operators to grant.)\n\n4. **Exhibit D** \u2014 `?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 \u2014 usable for a week with no further interaction with the CMS.\n\nThe four exhibits together: cross-mediaRoot write, cross-tenant write, arbitrary-key delete, and long-lived signed-URL minting.\n\n## Impact\n\n* **Cross-tenant / cross-mediaRoot write.** In any deployment where the bucket holds anything other than this one editor\u0027s `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`.)\n* **Stored XSS via uploaded HTML.** S3 returns objects with the `Content-Type` the upload supplies. The presigned `PutObjectCommand` URL carries no `Content-Type` constraint \u2014 the attacker\u0027s `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.\n* **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\u0027 files. (Exhibit C; `handlers.ts:199-223`.)\n* **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\u0027s actions to `mediaRoot`. Because the application code does not, every operator who follows the README has \u2014 without realising \u2014 granted every CMS editor full write/delete on the whole bucket.\n* **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.)\n* **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\u0027t enforce isn\u0027t even nominally present in `next-tinacms-azure`.",
  "id": "GHSA-8mq9-5fw2-5rm4",
  "modified": "2026-08-21T18:31:05Z",
  "published": "2026-08-19T21:56:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tinacms/tinacms/security/advisories/GHSA-8mq9-5fw2-5rm4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59992"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinacms/tinacms/pull/7088"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinacms/tinacms/commit/d44558e9b4502d4f4fc2c970d22985339fe2b6ce"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tinacms/tinacms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinacms/tinacms/releases/tag/next-tinacms-s3@23.0.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Tina: Broken Access Control: arbitrary bucket-key write/delete in `next-tinacms-s3` (and sibling production media adapters)"
}

CVE-2026-59992 (GCVE-0-2026-59992)

Vulnerability from cvelistv5 – Published: 2026-08-19 21:30 – Updated: 2026-08-21 16:48

Title

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

Summary

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.

Severity

5.4 (Medium)


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

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-08-21 16:47 UTC

CWE

CWE-639 - Authorization Bypass Through User-Controlled Key
CWE-862 - Missing Authorization

Assigner

GitHub_M mitre root

References

4 references

URL	Tags
https://github.com/tinacms/tinacms/security/advis…	x_refsource_CONFIRM
https://github.com/tinacms/tinacms/pull/7088	x_refsource_MISC
https://github.com/tinacms/tinacms/commit/d44558e…	x_refsource_MISC
https://github.com/tinacms/tinacms/releases/tag/n…	x_refsource_MISC

Impacted products

5 products

Vendor	Product	Version
tinacms	tinacms	Affected: < 23.0.4
tinacms	next-tinacms-s3	Affected: < 23.0.4
tinacms	next-tinacms-dos	Affected: < 23.0.4
tinacms	next-tinacms-azure	Affected: < 14.0.4
tinacms	next-tinacms-cloudinary	Affected: < 26.0.4

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-59992",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-21T16:47:38.735308Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-21T16:48:12.641Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/tinacms/tinacms/security/advisories/GHSA-8mq9-5fw2-5rm4"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "tinacms",
          "vendor": "tinacms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 23.0.4"
            }
          ]
        },
        {
          "product": "next-tinacms-s3",
          "vendor": "tinacms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 23.0.4"
            }
          ]
        },
        {
          "product": "next-tinacms-dos",
          "vendor": "tinacms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 23.0.4"
            }
          ]
        },
        {
          "product": "next-tinacms-azure",
          "vendor": "tinacms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 14.0.4"
            }
          ]
        },
        {
          "product": "next-tinacms-cloudinary",
          "vendor": "tinacms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 26.0.4"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s 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\u0027s storage credential can reach, including other tenants\u0027 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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 5.4,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-639",
              "description": "CWE-639: Authorization Bypass Through User-Controlled Key",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-862",
              "description": "CWE-862: Missing Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-19T21:32:09.476Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/tinacms/tinacms/security/advisories/GHSA-8mq9-5fw2-5rm4",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/tinacms/tinacms/security/advisories/GHSA-8mq9-5fw2-5rm4"
        },
        {
          "name": "https://github.com/tinacms/tinacms/pull/7088",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/tinacms/tinacms/pull/7088"
        },
        {
          "name": "https://github.com/tinacms/tinacms/commit/d44558e9b4502d4f4fc2c970d22985339fe2b6ce",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/tinacms/tinacms/commit/d44558e9b4502d4f4fc2c970d22985339fe2b6ce"
        },
        {
          "name": "https://github.com/tinacms/tinacms/releases/tag/next-tinacms-s3@23.0.4",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/tinacms/tinacms/releases/tag/next-tinacms-s3@23.0.4"
        }
      ],
      "source": {
        "advisory": "GHSA-8mq9-5fw2-5rm4",
        "discovery": "UNKNOWN"
      },
      "title": "Tina: Broken Access Control: arbitrary bucket-key write/delete in `next-tinacms-s3` (and sibling production media adapters)"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-59992",
    "datePublished": "2026-08-19T21:30:51.975Z",
    "dateReserved": "2026-07-07T19:41:00.005Z",
    "dateUpdated": "2026-08-21T16:48:12.641Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

GHSA-8MQ9-5FW2-5RM4

Summary

Vulnerable code

Reproduction (validated locally)

Impact

CVE-2026-59992 (GCVE-0-2026-59992)

Tags

Sightings

Nomenclature