CVE-2026-63506

Executive Summary

CVE-2026-63506 is an authorization bypass (CWE-639) in the Tina headless CMS authentication libraries @tinacms/auth (prior to 1.1.4) and next-tinacms-azure (prior to 15.0.1). The isAuthorized function accepts a request-controlled clientID and instructs isUserAuthorized to validate the presented bearer token against the attacker-selected TinaCloud application rather than the self-hosted site's own configured application, allowing any party holding a legitimate TinaCloud account to have their token treated as verified against a victim deployment. The impact is severe (CVSS 3.1 base 8.8, High confidentiality/integrity/availability): successful exploitation yields media listing, reading, upload and deletion, and — when TinaCloudBackendAuthProvider is in use — full GraphQL read, create, update and delete operations on the victim's content, with no victim account and no victim interaction.

Technical Analysis

Tina is a headless content management system that separates content storage from the presentation layer. In self-hosted deployments, the Next.js application embeds Tina's authentication middleware to gate access to content operations and media handling. TinaCloud provides the identity layer: applications are registered on TinaCloud and identified by a clientID, and users authenticate to obtain bearer tokens that TinaCloud validates against a specific application.

The defect is a classic authorization bypass through a user-controlled key (CWE-639). The trust decision relies on two inputs — a bearer token and a clientID — but only the token is cryptographically bound to an identity that the attacker cannot forge. The clientID is not bound to the server's own configuration; it is read from the request. The NVD description states plainly that "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."

Consequently the validation routine performs a correct cryptographic check against the wrong object. An attacker who possesses any valid TinaCloud account can register (or reuse) an application that they legitimately control, obtain a valid bearer token for it, and then submit that token together with their own clientID to a victim endpoint. isUserAuthorized asks TinaCloud whether the token is valid for the attacker's app; TinaCloud truthfully answers yes; the victim's isAuthorized therefore returns true. The tenant boundary — the implicit assumption that a token valid for App A conveys no authority over App B — is never enforced.

The vulnerable logic is reported to reside in packages/@tinacms/auth/src/index.ts and packages/next-tinacms-azure/src/auth.ts. Two consumer paths are named in the description:

• TinaCloudBackendAuthProvider — the backend authentication provider used to authorize GraphQL content operations. Because it consumes the same flawed isAuthorized verdict, a forged cross-tenant token grants read, create, update and delete access to the victim's content.
• Affected media authorized callbacks — the media handlers in next-tinacms-azure that gate blob/asset operations, granting media listing, download, upload and deletion.

Two properties make this unusually dangerous. First, the precondition is trivial: any TinaCloud account, including a self-registered free-tier account, satisfies the "attacker has a valid token" requirement. Second, the exploit is a well-formed, correctly authenticated request from the server's perspective — there is no malformed payload, no injection character, and no signature failure to alert on. The only anomaly is the identity of the claiming application relative to the deployment being accessed, a relationship the application never checks.

Insufficient technical detail is available in the supplied data to specify exact parameter names, header names, or request paths beyond clientID, isAuthorized, isUserAuthorized, TinaCloudBackendAuthProvider, and the two source files named. Analysts should treat any further implementation specifics as unverified until the fixing commits are reviewed.

Exploitation Scenarios

No public proof-of-concept, Nuclei template, or exploit code was available at the time of writing. The attack chain below is inferred strictly from the vulnerability class and the NVD description; no implementation detail beyond the named symbols is asserted.

1. Reconnaissance / target identification. The attacker identifies Internet-facing Next.js deployments running Tina in a self-hosted configuration. Fingerprinting is passive: responses and static assets referencing Tina, TinaCloud, or the @tinacms package namespace, admin routes, and GraphQL endpoints exposed by the application. Where next-tinacms-azure media endpoints are reachable (for example an Azure-backed media handler), they form an additional target surface.

2. Attacker-controlled prerequisite setup. The attacker registers or reuses an ordinary TinaCloud account and an application they legitimately own, obtaining that application's clientID and a valid bearer token for it. This step is entirely legitimate on the attacker's side and leaves no trace in the victim's environment.

3. Triggering the flawed trust decision. The attacker sends an authenticated request to a victim endpoint that invokes isAuthorized. The request carries the attacker's own bearer token and the attacker's own clientID. Because isAuthorized uses the request-supplied clientID rather than the deployment's configured application, isUserAuthorized validates the token against the attacker's TinaCloud app, receives a positive answer, and the request is admitted across the tenant boundary. No victim account, credential, or interaction is required (UI:N).

4. Post-exploitation impact. With authorization established, the attacker exercises the two named consumer paths:

   • Via TinaCloudBackendAuthProvider: GraphQL read, create, update and delete operations over the victim's content (integrity and availability impact).
   • Via affected media authorized callbacks: listing, reading, uploading and deleting media assets (content poisoning, exfiltration, destructive tampering). Because the session is a legitimate application session, attacker actions are indistinguishable from legitimate CMS operations in application logs unless application-identity attribution is captured.

Impact Assessment

The CVSS 3.1 base score is 8.8 (High) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

• AV:N / AC:L — exploitable over the network with no special conditions. The only real precondition is a TinaCloud account, which is not a meaningful barrier.
• PR:L — the attacker must hold low-privileged credentials: their own TinaCloud token. This is what caps the score below 9.0, despite the severity of the outcome.
• UI:N — no victim interaction whatsoever; the victim need not click, approve, or even be logged in.
• S:U — the scoring assumes the vulnerable component's authority scope; in practice the business consequence crosses a tenant boundary, which is precisely the security property violated.
• C:H / I:H / A:H — read access to all content and media, write/create/delete on content and media, and destructive availability impact through deletion.

Blast radius. Every self-hosted Tina deployment below the fixed versions that exposes the affected auth path is potentially affected. Multi-tenant hosting providers running Tina on behalf of multiple customers face the worst exposure: a single valid TinaCloud account can be turned against any number of victim tenants sequentially. Content management systems typically sit upstream of published websites, CDN origins, and build pipelines, so successful content tampering can propagate to public-facing properties. Media write access additionally enables hosting of attacker-supplied files (possible malware distribution or stored-content attacks) and destruction of irreplaceable assets.

Business impact. Integrity compromise of published content is a reputational and potentially regulatory concern (defacement, misinformation, SEO poisoning). Deletion of content or media can be an availability and recovery-cost event. In regulated environments, cross-tenant access to content may constitute a reportable data-access incident depending on what the CMS stores.

Detection Guidance

Because the exploit is a well-formed authenticated request, detection should focus on attribution and behavioral anomalies rather than payload signatures. The highest-value signals are: a request's claimed application identity differing from the deployment's configured application, previously unseen clientID values, and authenticated content mutations from sources with no prior legitimate session history.

Sigma Rule

title: Tina CMS Cross-Tenant Authorization Bypass Attempt (CVE-2026-63506)
id: 3f9a1c2e-7b64-4d1a-9c11-tina63506sig
status: experimental
description: Detects authenticated Tina/Next.js requests that carry a clientID not matching the deployment's configured TinaCloud application, indicative of CWE-639 authorization bypass through user-controlled key (CVE-2026-63506).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-63506
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1190
  - attack.initial_access
  - cve.2026-63506
logsource:
  category: web
  product: nextjs
detection:
  selection_auth_path:
    request_uri|contains:
      - '/api/tina'
      - '/api/graphql'
      - '/media'
      - '/admin'
  selection_clientid_mismatch:
    query_string|contains: 'clientID='
    client_id_matches_configured: 'false'
  condition: selection_auth_path and selection_clientid_mismatch
fields:
  - client_ip
  - request_uri
  - query_string
  - client_id
  - user_agent
falsepositives:
  - Multi-tenant deployments where tenants legitimately supply their own TinaCloud clientID (tune the allowlist of expected clientID values)
level: high

Note: field names such as client_id_matches_configured are placeholders for whatever attribution field your logging pipeline can derive; the rule's intent is the mismatch between claimed and configured application identity, which is the exploitable condition. Rename to match your schema.

YARA Rule

rule CVE_2026_63506_Tina_CrossTenant_AuthBypass
{
    meta:
        description = "Detects Tina auth code/config artifacts referencing the CVE-2026-63506 vulnerable pattern"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-63506"
        date = "2026-01-01"
        cve = "CVE-2026-63506"

    strings:
        $a1 = "isAuthorized" ascii wide
        $a2 = "isUserAuthorized" ascii wide
        $a3 = "TinaCloudBackendAuthProvider" ascii wide
        $a4 = "@tinacms/auth" ascii wide
        $a5 = "next-tinacms-azure" ascii wide

    condition:
        uint16(0) == 0x5A4D or true
        and (
            (2 of ($a1, $a2, $a3))
            or (1 of ($a4, $a5) and 1 of ($a1, $a2, $a3))
        )
}

Note: this is an artifact/inventory rule (identifying vulnerable code or packages in a filesystem or build artifact), not a behavioral indicator. It will match legitimate deployments — pair it with a version check to distinguish vulnerable from fixed releases.

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-63506 Tina CMS possible cross-tenant clientID authorization bypass"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/api/graphql"; http.header; content:"Authorization|3a 20|Bearer"; http.client_body; content:"clientID"; nocase; threshold:type both, track by_src, count 5, seconds 60; reference:cve,2026-63506; classtype:attempted-user; sid:9063506; rev:1;)

Note: clientID appearing in a GraphQL-adjacent POST body is only a weak signal — many legitimate tenants include their own clientID. Deploy this rule in alert/log mode for baselining, then tune by correlating the clientID value against the deployment's configured application. classtype and thresholds should be adjusted to your environment.

Elastic Detection

sequence by source.ip, host.name with maxspan=5m
  [ network where network.protocol == "http" and
      http.request.method == "POST" and
      (http.request.body.content : "clientID" or url.query : "clientID") ]
  [ network where network.protocol == "http" and
      http.request.method in ("POST", "PUT", "DELETE") and
      (url.path : "*graphql*" or url.path : "*media*" or url.path : "*tina*") ]

Note: this EQL sequence flags a client-ID-bearing request immediately followed by an authenticated content or media mutation from the same source — a behavioral approximation of the exploit. It assumes HTTP body and URL fields are captured in your ingestion pipeline; if not, substitute event.original or your proxy log fields. Tune out legitimate same-tenant traffic.

Splunk SPL Query

index=web_logs (uri="*graphql*" OR uri="*tina*" OR uri="*media*" OR uri="*admin*")
| rex field=uri "(?<clientID>clientID=[^&\s]+)"
| eval has_bearer=if(match(headers, "(?i)authorization:\s*bearer"), 1, 0)
| eval app_mismatch=if(isnotnull(clientID) AND clientID!=expected_client_id, 1, 0)
| where has_bearer=1 AND (app_mismatch=1 OR isnull(known_client_id))
| stats count min(_time) as first_seen max(_time) as last_seen values(uri) as targets values(clientID) as claimed_app_ids by src_ip
| where count >= 3
| sort -count

Note: expected_client_id and known_client_id are illustrative lookups — the detection logic is "authenticated request whose claimed application ID is unknown or does not match the deployment's configured application." Build the population of known client IDs from a baseline period before enabling alerting.

Wazuh OSSEC Rule

<group name="web,tina,cve-2026-63506">
  <rule id="100635" level="10">
    <if_sid>31100,31101,31103</if_sid>
    <field name="url">graphql|tina|media|admin</field>
    <field name="id">clientID=</field>
    <description>CVE-2026-63506: Possible Tina CMS cross-tenant clientID authorization bypass via web request</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve_2026_63506,</group>
  </rule>
</group>

Note: this depends on Wazuh web-access-log decoding populating url/id fields and on your decoder exposing the clientID token; adjust <if_sid> to match your actual web-log decoder SIDs. This is correlation-only and should be tuned against baselined legitimate tenant IDs.

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The NVD description states the vulnerability is fixed in @tinacms/auth 1.1.4 and next-tinacms-azure 15.0.1, but no vendor advisory, commit, or OSV package record appears in the supplied data. Verify these versions against the vendor's own release channel before treating them as authoritative. Do not rely on CISA KEV (not listed) or an EPSS value (not scored) for prioritization; use the 8.8 CVSS base and your own exposure analysis.

1) Immediate mitigations (until patched):

• Enforce at the edge (reverse proxy / WAF / middleware) that the clientID presented on authenticated requests must equal the deployment's configured TinaCloud application ID. Because the flaw is precisely that the server trusts the request-supplied value, rejecting mismatches recreates the missing tenant binding. This is the single highest-leverage control.
• If the application has a fixed single-tenant clientID, strip or ignore any client-supplied clientID parameter entirely at the proxy.
• Where next-tinacms-azure media endpoints are not required to be publicly reachable, restrict them by network ACL or authentication-at-proxy.
• Add alerting (see Detection Guidance) on authenticated content/media mutations whose claimed application ID is unknown to the deployment, and on deletions of media or content, to catch exploitation attempts while unpatched.

2) Patch / upgrade steps:

• Upgrade @tinacms/auth to 1.1.4 or later and next-tinacms-azure to 15.0.1 or later across all deployments and build artifacts.
• Update lockfiles and rebuild; confirm transitive resolutions so no cached vulnerable copy remains in the dependency tree.
• After upgrading, re-run the detection queries above in monitoring mode and confirm the claimed-vs-configured application mismatch no longer occurs from legitimate traffic.
• Audit the deployment inventory for other Tina packages or integrations that consume isAuthorized; the description names only two packages, but the flawed function is the shared dependency.

3) Long-term hardening:

• Treat any server-side authorization decision that depends on a client-supplied identifier as a design smell (CWE-639). Enforce app-identity binding server-side and derive the tenant from authenticated token claims, never from request input.
• Adopt automated dependency scanning and SBOM tracking for CMS dependencies so that this class of issue is surfaced at build time.
• Maintain least-privilege replication/credential scoping for CMS backends (Git provider or blob storage), so that a bypass yields limited, recoverable damage.
• Ensure content and media are backed up with tested restore procedures; exploit enables destructive deletion, and recovery is the ultimate control.
• Since no public exploit exists yet, treat the window as an opportunity: patch and harden now, before weaponization raises the urgency.

References

1. NVD — CVE-2026-63506: https://nvd.nist.gov/vuln/detail/CVE-2026-63506
2. CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
3. MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
4. Tina CMS project site and package registry listings for @tinacms/auth and next-tinacms-azure (verify the fixing versions 1.1.4 and 15.0.1 directly): https://www.tina.io/ and https://www.npmjs.com/package/@tinacms/auth
5. CVSS v3.1 Specification (base score 8.8, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H): https://www.first.org/cvss/v3.1/specification-document

Threat actor / exploitation status: No CISA KEV listing, no public proof-of-concept, no Nuclei template, and no in-the-wild exploitation evidence was present in the supplied data at the time of writing. EPSS has not yet scored this CVE — do not cite an EPSS value. The exploit is low-complexity and requires only a self-registered TinaCloud account, so weaponization should be anticipated; treat patch and the clientID-binding edge control as time-sensitive.