TinaCMS EUVD-2026-81019

Requires a valid TinaCloud account (the attacker's own - any account suffices, PR:L) and a self-hosted Tina site that uses the vulnerable isAuthorized flow via TinaCloudBackendAuthProvider or the next-tinacms-azure media 'authorized' callback on versions @tinacms/auth < 1.1.4 or next-tinacms-azure < 15.0.1. The endpoint must be network-reachable and honor a request-supplied clientID. No victim account and no victim/user interaction are needed. Limiting factors: the attacker must hold a legitimate TinaCloud-verifiable token, and post-patch deployments fail closed if the site's own clientID (NEXT_PUBLIC_TINA_CLIENT_ID or an explicitly passed value) cannot be resolved at runtime, returning 401.

Multiple signals point to a genuine, elevated-priority authorization flaw rather than an inflated high-CVSS score. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8) is internally consistent with the description: network-reachable API, low complexity, and only a low-privilege TinaCloud account (the attacker's own) required with no victim interaction. The root cause is a classic CWE-639 IDOR - isAuthorized trusts a request-controlled clientID and validates the bearer token against the attacker-selected TinaCloud app rather than the site's own configured app, so the attacker's legitimately verified status is accepted across the tenant boundary. Impact is broad (media list/read/upload/delete plus full GraphQL read/create/update/delete on victim content). Tempering the urgency: there is no CISA KEV listing, no public exploit code referenced, and no EPSS score provided, so this is 'no public exploit identified at time of analysis' - exploitation is plausible and technically simple but not yet observed or automated in the wild. The C:H/I:H/A:H impact is well-supported; A:H rests on the delete capability, which is defensible though A:L could be argued since it destroys content data rather than crashing the service. Net: prioritize patching for any self-hosted Tina deployment exposed to untrusted TinaCloud accounts, but treat active exploitation as unconfirmed.

An attacker registers any ordinary TinaCloud account and obtains a valid bearer token for their own app. They send an authenticated request to a victim self-hosted Tina endpoint while supplying their own clientID (e.g. via the request query), causing isAuthorized/TinaCloudBackendAuthProvider or the next-tinacms-azure media callback to validate the token against the attacker's app and accept it for the victim tenant. No public exploit code is referenced, but the attack is low-complexity and requires no victim account or interaction.