CVE-2026-63506 in auth
Summary
by MITRE • 09/16/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Tina headless content management system, specifically within its authentication modules prior to versions 1.1.4 for the core auth package and 15.0.1 for the Azure integration, suffers from a critical insecure direct object reference vulnerability that allows for tenant isolation bypasses. The root cause lies in how the isAuthorized function processes incoming requests by accepting a clientID parameter directly controlled by the attacker rather than enforcing it against the server-side configuration of the self-hosted site or the specific TinaCloud application intended to serve the victim. This design flaw means that during the authentication handshake, the system does not validate whether the provided client identifier matches the expected tenant context associated with the current session or endpoint. Instead, it proceeds to delegate validation to isUserAuthorized using this attacker-supplied identifier, effectively allowing an external entity to dictate which application's credentials are being validated against the TinaCloud backend infrastructure.
This architectural flaw enables a sophisticated cross-tenant authentication bypass where any individual possessing a valid TinaCloud account can manipulate the authorization flow for other tenants. By submitting their own app ID along with a legitimate bearer token from their own TinaCloud application, an attacker tricks the victim's endpoint into accepting that external token as valid for the victim's context. The vulnerability is present in two primary code paths: packages/@tinacms/auth/src/index.ts and packages/next-tinacms-azure/src/auth.ts. In both instances, the lack of strict binding between the request origin or configured tenant ID and the clientID used for token validation creates a window for exploitation that does not require any prior access to the victim's account or any form of user interaction such as clicking malicious links.
The operational impact of this vulnerability is severe, granting attackers full administrative control over the victim's content management environment without authentication credentials belonging to the victim. Once the attacker successfully bypasses the authorization check using their own valid token and manipulated client ID, they are treated as an authenticated user within the victim's tenant boundary. This permits unrestricted access to media assets including listing existing files, reading sensitive documents, uploading new malicious content, or deleting critical data. Furthermore, when the TinaCloudBackendAuthProvider is utilized in conjunction with this flaw, the attacker gains full GraphQL API privileges over the victim's content model. This includes read, create, update, and delete operations on all structured content managed by the system, effectively compromising the integrity, confidentiality, and availability of the entire CMS deployment.
From a classification perspective, this vulnerability aligns closely with CWE-284 Improper Access Control, specifically involving insecure direct object references where user input is used to access resources without sufficient verification of authorization rights relative to the current context. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, as it involves the misuse of legitimate credentials from one account to gain unauthorized access in another environment due to flawed session or tenant management logic. The attack vector is classified under remote code execution principles because it allows an unauthenticated actor to execute actions on behalf of a victim through API manipulation rather than traditional software exploitation techniques like buffer overflows.
Mitigation strategies must prioritize immediate patching to the specified fixed versions, which enforce strict validation that the client ID used for token verification matches the expected configuration for the specific tenant or site instance. In addition to upgrading dependencies, organizations should implement defense-in-depth measures such as validating the origin of requests against a whitelist of allowed domains and ensuring that authentication middleware strictly binds session tokens to their originating application context rather than accepting dynamic identifiers from request payloads. Monitoring logs for unusual patterns in token validation failures or unexpected tenant switches can also aid in detecting attempted exploitation before full compromise occurs, although prevention through proper input validation and secure configuration remains the primary defense against this class of identity management flaws.