CVE-2026-93363: Improper Access Control in Payload CMS Storage Upload Route

Payload CMS is an open-source, headless content management system and application framework built with TypeScript and Node.js. It provides extensible file management capabilities through dedicated upload collections and pluggable cloud storage adapters, such as @payloadcms/storage-vercel-blob and @payloadcms/storage-r2. To reduce server bandwidth overhead when handling large media assets, Payload supports client-side direct uploads, where the browser requests a pre-signed upload URL or client token from the CMS and transmits file bytes directly to the cloud storage provider.

In Payload CMS versions 3.25.0 prior to 3.90.0 and 4.0.0-canary.0 prior to 4.0.0-canary.34, the server-side endpoint responsible for issuing these client upload credentials (/upload-instructions) fails to enforce collection-level authorization properly. Tracked as CVE-2026-93363 (and GHSA-mc8m-rr6c-r5qr), this vulnerability is classified under CWE-862 (Missing Authorization).

The flaw stems from two independent implementation defects in packages/payload/src/uploads/endpoints/uploadInstructions.ts. First, the authorization routine was conditionally gated behind a boolean check that skipped permission evaluation whenever a custom storage adapter was configured. Second, the HTTP endpoint handler passed the unsanitized client JSON body into the internal instruction generator via object spreading, allowing callers to supply internal API flags such as overrideAccess: true.

As a result, any low-privileged authenticated user can request valid upload instructions and pre-signed tokens for restricted upload collections. The user can then upload unauthorized files directly into the underlying cloud storage bucket without possessing create or update privileges on the target collection.

The root cause of CVE-2026-93363 resides in how Payload CMS processes requests to the /upload-instructions endpoint within packages/payload/src/uploads/endpoints/uploadInstructions.ts. In Payload's architecture, internal Local API operations accept an overrideAccess boolean parameter. When overrideAccess is set to true (the default for internal server-to-server calls), Payload bypasses access control functions; when invoked via HTTP REST or GraphQL endpoints, overrideAccess is supposed to be enforced as false so that collection-level permissions are evaluated against the requesting user session (req.user).

The first defect is a conditional authorization bypass triggered by the presence of a third-party storage adapter. When a collection is configured to use a storage plugin that supports client uploads (such as @payloadcms/storage-vercel-blob), the collection registers an uploadInstructions handler object. In getUploadInstructions, the access control check was written with the condition if (!uploadInstructions && !overrideAccess). Because uploadInstructions is defined and truthy when a storage adapter is active, !uploadInstructions evaluates to false. Consequently, the entire permission validation block is skipped, and execution immediately delegates token generation to uploadInstructions.generate().

The second defect is a mass assignment / internal parameter injection flaw in uploadInstructionsEndpoint. The endpoint handler parsed the incoming HTTP request JSON body into the upload variable and passed it directly into getUploadInstructions({ ...upload, req }) using the JavaScript spread operator (...).

Because the getUploadInstructions function signature accepts overrideAccess as a property of its first argument object (defaulting to false only if undefined), spreading the raw client JSON object allowed an attacker to include "overrideAccess": true in the HTTP request body. This explicitly overwrote the default overrideAccess = false parameter, disabling access control checks even for standard staged uploads that did not use a custom storage adapter.

Examining the vulnerable implementation in packages/payload/src/uploads/endpoints/uploadInstructions.ts prior to commit 47abe9bb5c444330dbfaa9a5bc2033337932270b illustrates how both defects interact within the same file.

// VULNERABLE CODE: packages/payload/src/uploads/endpoints/uploadInstructions.ts
export async function getUploadInstructions({
  overrideAccess = false,
  req,
  ...upload
}: UploadInstructionsArgs): Promise<Response> {
  const uploadInstructions = req.payload.collections[upload.collectionSlug]?.config.upload?.adapter
 
  // Defect 1: If an adapter is present (uploadInstructions is truthy),
  // this entire authorization block is skipped.
  if (!uploadInstructions && !overrideAccess) {
    if (!req.user) {
      throw new Forbidden(req.t)
    }
 
    const collectionPermissions = (await getAccessResults({ req })).collections?.[
      upload.collectionSlug
    ]
 
    if (!collectionPermissions?.create && !collectionPermissions?.update) {
      throw new Forbidden(req.t)
    }
  }
 
  return uploadInstructions
    ? uploadInstructions.generate({ ...upload, overrideAccess, req })
    : generateStagedUploadInstructions({ ...upload, req })
}
 
export const uploadInstructionsEndpoint: Endpoint = {
  handler: async (req) => {
    const upload = (await req.json!()) as UploadInstructionsRequest
    if (!upload) {
      throw new APIError('Invalid upload instructions request', 400)
    }
 
    // Defect 2: Object spread (...upload) allows client JSON to inject overrideAccess: true
    return Response.json(await getUploadInstructions({ ...upload, req }))
  },
  method: 'post',
  path: '/upload-instructions',
}

In commit 47abe9bb5c444330dbfaa9a5bc2033337932270b, the maintainers resolved the vulnerability through three structural changes. First, they created a dedicated authorization helper function, assertClientUploadAccess, in packages/payload/src/uploads/assertClientUploadAccess.ts. Rather than computing global access results across all collections via getAccessResults, this helper directly evaluates the target collection's create and update access control functions using executeAccess:

// PATCHED HELPER: packages/payload/src/uploads/assertClientUploadAccess.ts
export const assertClientUploadAccess = async ({
  collectionSlug,
  req,
}: {
  collectionSlug: string
  req: PayloadRequest
}): Promise<void> => {
  if (!req.user) {
    throw new Forbidden(req.t)
  }
 
  const collectionConfig = req.payload.collections[collectionSlug]?.config
 
  if (!collectionConfig) {
    throw new Forbidden(req.t)
  }
 
  // Evaluate collection-level create access first
  const canCreate = await executeAccess(
    { slug: collectionSlug, disableErrors: true, req },
    collectionConfig.access.create,
  )
 
  if (canCreate) {
    return
  }
 
  // Fall back to evaluating update access if create is denied
  const canUpdate = await executeAccess(
    { slug: collectionSlug, disableErrors: true, req },
    collectionConfig.access.update,
  )
 
  if (!canUpdate) {
    throw new Forbidden(req.t)
  }
}

Second, getUploadInstructions was updated to call assertClientUploadAccess unconditionally whenever overrideAccess is false, prior to invoking either custom storage adapter handlers or staged upload handlers. Third, uploadInstructionsEndpoint was refactored to explicitly pick only the expected properties from the client payload, preventing parameter injection:

// PATCHED ENDPOINT: packages/payload/src/uploads/endpoints/uploadInstructions.ts
export async function getUploadInstructions({
  overrideAccess = false,
  req,
  ...upload
}: UploadInstructionsArgs): Promise<Response> {
  // Fix 1: Unconditionally enforce access checks regardless of storage adapter presence
  if (!overrideAccess) {
    await assertClientUploadAccess({ collectionSlug: upload.collectionSlug, req })
  }
 
  const uploadInstructions = req.payload.collections[upload.collectionSlug]?.config.upload?.adapter
  return uploadInstructions
    ? uploadInstructions.generate({ ...upload, overrideAccess, req })
    : generateStagedUploadInstructions({ ...upload, req })
}
 
export const uploadInstructionsEndpoint: Endpoint = {
  handler: async (req) => {
    const upload = (await req.json!()) as UploadInstructionsRequest
    if (!upload) {
      throw new APIError('Invalid upload instructions request', 400)
    }
 
    // Fix 2: Explicit property mapping prevents client injection of overrideAccess
    return Response.json(
      await getUploadInstructions({
        collectionSlug: upload.collectionSlug,
        docPrefix: upload.docPrefix,
        filename: upload.filename,
        filesize: upload.filesize,
        mimeType: upload.mimeType,
        req,
      }),
    )
  },
  method: 'post',
  path: '/upload-instructions',
}

> [!NOTE] > Fix Completeness Assessment: In addition to patching /upload-instructions, commit 47abe9bb5c444330dbfaa9a5bc2033337932270b also audited and updated multipart upload handlers in other storage adapters (such as @payloadcms/storage-r2) to invoke assertClientUploadAccess({ collectionSlug, req }). This ensures consistent access enforcement across both single-request signed URLs and multipart upload initiation endpoints.

Exploiting CVE-2026-93363 requires network access to the Payload CMS HTTP API and normally requires a valid authentication session (PR:L) for a low-privileged user account (such as a standard registered user or viewer role) that lacks create and update permissions on a target upload collection. However, if an attacker exploits the overrideAccess: true parameter injection vector, the !req.user check inside the vulnerable conditional block is also bypassed.

To execute the attack against an application using @payloadcms/storage-vercel-blob or a similar client-upload configuration, the attacker first identifies the slug of an upload-enabled collection (for example, media or restricted-documents). The attacker then sends a crafted POST request to the /api/upload-instructions endpoint.

POST /api/upload-instructions HTTP/1.1
Host: target.example.com
Authorization: JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json
 
{
  "collectionSlug": "restricted-documents",
  "filename": "unauthorized-asset.pdf",
  "filesize": 204800,
  "mimeType": "application/pdf",
  "overrideAccess": true
}

When the vulnerable server receives this request, uploadInstructionsEndpoint spreads the JSON properties into getUploadInstructions. Because uploadInstructions is defined on the restricted-documents collection (and overrideAccess is injected as true), the server skips all role and permission checks.

The server subsequently invokes the storage adapter's generate function, which communicates with the cloud provider (or signs a token locally using BLOB_READ_WRITE_TOKEN) and returns the upload instructions and signed token in the HTTP response. The attacker uses the returned credentials to upload the file payload directly to the Vercel Blob store or configured cloud bucket.

The primary security impact of CVE-2026-93363 is a partial loss of integrity (I:L in CVSS v3.1, VI:L in CVSS v4.0) on the affected system's storage layer. Attackers cannot read existing sensitive files (C:N) or directly delete existing database records (A:N) through this vector alone, resulting in a CVSS v3.1 base score of 4.3 (Medium) and a CVSS v4.0 base score of 5.3 (Medium).

By bypassing collection-level access controls on upload routes, an unauthorized user can persist arbitrary files inside the application's configured cloud storage bucket (such as Vercel Blob or Cloudflare R2). Depending on how the downstream application serves or processes files from the storage bucket, this enables several secondary risks:

• Storage Quota and Financial Exhaustion: Attackers can repeatedly request upload tokens for large files and push data directly to the cloud storage provider, driving up bandwidth and storage costs.
• Hosting of Unauthorized Content: If the cloud bucket is configured for public read access, attackers can abuse the trusted domain of the organization's blob storage to host phishing pages, malware payloads, or unapproved media.
• Asset Overwrite / Prefix Collision: If the storage adapter configuration does not enforce unique randomized prefixes or allows predictable docPrefix values, an attacker could overwrite existing objects in the blob store.

According to FIRST EPSS telemetry, CVE-2026-93363 currently holds an EPSS score of 0.00177 (0.18%), placing it in the 7.28th percentile. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no active in-the-wild exploitation campaigns have been recorded.

To remediate CVE-2026-93363, operators must upgrade payload and all installed @payloadcms/storage-* packages (including @payloadcms/storage-vercel-blob and @payloadcms/storage-r2) to a patched release. The vulnerability is fixed in Payload 3.90.0 for the 3.x release line and Payload 4.0.0-canary.34 for the 4.x canary line.

# Using pnpm
pnpm update payload @payloadcms/storage-vercel-blob
 
# Using npm
npm update payload @payloadcms/storage-vercel-blob

For environments where an immediate version upgrade is not feasible, developers can implement two workarounds to mitigate the exposure. First, if using @payloadcms/storage-vercel-blob with clientUploads enabled, explicitly define an access callback inside the clientUploads configuration object to enforce user role checks inside the adapter itself:

import { vercelBlobStorage } from '@payloadcms/storage-vercel-blob'
 
vercelBlobStorage({
  collections: {
    media: true,
  },
  clientUploads: {
    // Explicitly enforce authorization at the adapter level
    access: ({ collectionSlug, req }) => {
      return Boolean(req.user && req.user.roles?.includes('admin'))
    },
  },
  token: process.env.BLOB_READ_WRITE_TOKEN,
})

Second, deploy Web Application Firewall (WAF) or reverse proxy rules at the ingress layer to inspect POST requests targeting /api/upload-instructions. Any request body containing the JSON key overrideAccess should be blocked immediately, as legitimate client upload requests never include internal Local API control flags.