CVE-2026-32101
Authorization Bypass in StudioCMS S3 Storage Manager Allows File Manipulation
Publication date: 2026-03-11
Last updated on: 2026-03-17
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| studiocms | studiocms | to 0.3.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "This vulnerability in StudioCMS affects the S3 storage manager's authorization checks. The function isAuthorized() is asynchronous and returns a Promise, but it was called without using await in the POST and PUT handlers. Because a Promise object is always truthy in JavaScript, the negation check (!isAuthorized(type)) always evaluates to false, effectively bypassing the authorization check."}, {'type': 'paragraph', 'content': 'As a result, any authenticated user with the lowest visitor role can perform privileged actions such as uploading, deleting, renaming, and listing all files in the S3 bucket, which should normally be restricted to users with editor-level permissions or higher.'}] [1]
How can this vulnerability impact me? :
This vulnerability allows unauthorized users with minimal privileges to fully manage the S3 storage bucket. They can list all files, upload new files, delete existing files, and rename files.
- Unauthorized deletion of critical files leading to data loss.
- Exposure of sensitive content by listing files and generating presigned URLs.
- Potential injection of malicious payloads by uploading or renaming files, compromising data integrity.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by testing whether users with the lowest visitor role can perform privileged actions such as uploading, deleting, renaming, or listing files in the S3 bucket, which should normally be restricted.'}, {'type': 'paragraph', 'content': 'For example, you can attempt to list files in the S3 bucket using an authenticated visitor account and check if you receive a 200 OK response instead of a 401 Unauthorized.'}, {'type': 'paragraph', 'content': 'Specific commands depend on your environment, but a typical approach is to use HTTP requests to the POST and PUT endpoints of the StudioCMS S3 storage manager to test actions like file upload, deletion, or listing.'}, {'type': 'paragraph', 'content': 'Example using curl to test listing files (replace URL and authentication as appropriate):'}, {'type': 'list_item', 'content': 'curl -X POST -H "Authorization: Bearer <visitor_token>" -d \'{"action":"list"}\' https://your-studiocms-instance/api/s3-storage'}, {'type': 'paragraph', 'content': 'If this returns a 200 OK with file listings, the authorization bypass is present.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation is to upgrade the @studiocms/s3-storage package to version 0.3.1 or later, where the vulnerability is fixed.
The fix involves adding the missing await keyword to the asynchronous isAuthorized() calls in both the POST and PUT handlers to ensure proper authorization checks.
If upgrading is not immediately possible, as a temporary workaround, restrict access to the affected endpoints to trusted users only or disable S3 storage management features until the fix can be applied.