CVE-2026-59992: Broken Access Control and Path Traversal in Tina CMS Production Media Adapters

CVE-2026-59992 represents a significant authorization bypass vulnerability in Tina CMS, specifically affecting its official production media adapters. These adapters include next-tinacms-s3, next-tinacms-dos, next-tinacms-azure, and next-tinacms-cloudinary. The role of these adapters is to bridge the CMS content editing interface with cloud-based asset storage solutions, enabling direct upload, deletion, and organization of media files.\n\nThe vulnerability is classified under CWE-639 (Authorization Bypass Through User-Controlled Key) and CWE-862 (Missing Authorization). While administrators can set a mediaRoot configuration to restrict editors to a logical directory within the cloud storage, this restriction was only validated during directory listings. Write and delete operations failed to enforce any directory containment boundaries, exposing a logical security bypass.\n\nAn authenticated CMS editor with otherwise restricted directory privileges can exploit this lack of sanitization to perform read, write, or delete actions across any object within the underlying cloud storage bucket or container. The impact is determined by the permissions assigned to the backend IAM user or storage client credential, allowing actions to occur outside the administrative boundaries defined by the CMS configuration.

The root cause of CVE-2026-59992 lies in the asymmetrical implementation of path boundary enforcement across the Tina CMS media adapters. The configuration option mediaRoot is designed to define a hard boundary for media operations, creating an isolated namespace for standard editors. During directory listing operations (listMedia), the adapters correctly restricted visibility to the specified prefix, leading administrators to believe that containment was strictly enforced.\n\nHowever, the API endpoints responsible for mutations—specifically file creation, presigned URL generation, and deletion—accepted arbitrary, user-supplied key and directory parameters from incoming HTTP requests without verification. The backend passed these parameters directly to the underlying SDKs, such as the AWS SDK for S3 or the Azure Storage SDK, bypassing directory limits.\n\nBecause the adapters did not validate that the target file path started with the configured mediaRoot prefix, they allowed directory traversal sequences (such as ../) or absolute path specifications. This failure to sanitize incoming paths allowed authenticated users to access and manipulate any key within the entire cloud bucket or container, effectively escalating their capabilities to the permission levels of the server's cloud credentials.

A review of the vulnerable codebase in the S3 media handler reveals how client-supplied values were handled. In packages/next-tinacms-s3/src/handlers.ts, the upload routine retrieved the object key directly from req.query.key. It then passed this unvalidated key to the S3 client to generate a presigned upload URL, enabling unchecked writes.\n\ntypescript\n// Vulnerable write path in next-tinacms-s3\nconst s3_key = req.query.key\n ? Array.isArray(req.query.key)\n ? req.query.key[0]\n : req.query.key\n : null;\n// This key was passed straight to the S3 PutObject request generator\n\n\nThe corresponding patch introduced a unified validation layer using a helper utility named media-key.ts. This helper implements the resolveKey function, which normalizes the input path and verifies that the resulting string is prefixed by the configured mediaRoot directory boundary.\n\ntypescript\n// Patched write path enforcing mediaRoot containment\nlet s3_key: string;\ntry {\n // Enforce boundary verification using the centralized helper\n s3_key = resolveKey(mediaRoot, rawKey, { decode: false });\n} catch (e) {\n if (e instanceof MediaKeyError) {\n return res.status(400).json({ message: e.message });\n }\n throw e;\n}\n\n\nThe helper utility resolveKey mitigates path traversal by checking for NUL bytes, validating Windows and Unix path separators, and verifying that the final path starts with the designated mediaRoot. It throws a MediaKeyError if any portion of the path resolves to a location outside the containment boundary.

Exploitation of CVE-2026-59992 requires an attacker to possess valid credentials for a Tina CMS editor account. Since the vulnerability is located within the authenticated API handlers, unauthenticated attackers cannot exploit this weakness directly. However, any standard editor role with access to the media library interface is sufficient to trigger the flaw.\n\nTo perform an unauthorized write operation on an AWS S3 backend, the attacker intercepts or constructs an API request directed at the S3 media endpoint (commonly /api/s3/media). By providing a path traversal payload such as ../ in the key parameter, the attacker forces the backend to generate a presigned PutObject URL for a target outside of their authorized directory.\n\nhttp\nGET /api/s3/media?key=../critical-assets/index.html HTTP/1.1\nHost: target-cms-domain.com\nAuthorization: Bearer <authenticated_editor_jwt>\n\n\nThe server returns a signed Amazon S3 URL, which the attacker then uses to write directly to the target storage location. Deletion attacks proceed similarly, where the attacker issues a DELETE request containing traversal sequences in the media parameter to trigger S3's DeleteObjectCommand on files belonging to other tenants or systems.

The security impact of CVE-2026-59992 is significant for multi-tenant deployments or configurations where the underlying storage bucket is shared with other applications. While the vulnerability has a CVSS v3.1 score of 5.4, the actual impact in production environments depends heavily on the level of permissions granted to the storage credentials used by the CMS server.\n\nIf the server's IAM role or API keys possess write and delete permissions across the entire storage bucket (which is a common deployment practice), an attacker can overwrite, modify, or delete critical application assets, database backups, configuration files, or other tenant data stored in the same bucket. This can lead to persistent denial of service, data loss, or secondary client-side attacks like stored cross-site scripting (XSS) if the attacker overwrites served static files.\n\nThe vulnerability does not directly expose read operations on arbitrary keys through the media handlers, restricting the immediate impact to integrity (unauthorized file creation/modification) and availability (unauthorized deletion). However, the ability to generate long-lived presigned URLs (up to seven days via the unchecked expiresIn parameter) provides attackers with persistent offline write access.

To remediate CVE-2026-59992, administrators must upgrade the affected Tina CMS media adapter packages to version 23.0.4 or higher (or version 14.0.4/26.0.4 depending on the specific adapter used). These updates introduce the resolveKey verification function, ensuring that all client-requested operations are strictly confined within the configured mediaRoot directory.\n\nIn addition to upgrading, organizations should implement defense-in-depth measures by configuring the cloud IAM policies to enforce the same directory restrictions at the storage layer. For example, AWS IAM policies should restrict the server's credentials to the specific mediaRoot prefix using policy conditions or resource limits, rather than granting blanket write and delete permissions to the entire bucket.\n\nDetection of exploitation attempts can be achieved by analyzing web server access logs for anomalous directory traversal characters (such as %2e%2e%2f or ..) in the query strings of the media endpoints. Cloud-level audit logs, such as AWS CloudTrail or S3 Server Access Logs, should also be monitored for write and delete events that occur outside the designated media directories, especially those initiated by the CMS server's credentials.