Payload Plugins
Monthly
Any authenticated user of a Payload CMS instance running @jhb.software/payload-cloudinary-plugin (0.3.0 through 0.3.x, fixed in 0.4.0) can obtain a cryptographically valid Cloudinary HMAC-SHA1 upload signature for parameters of their choosing, because the client-upload signing endpoint POST /api/cloudinary-generate-signature forwards attacker-controlled 'paramsToSign' straight to cloudinary.utils.api_sign_request() with no key allowlist, folder policy, or timestamp check. With that signature plus the intentionally client-visible Cloudinary API key, an attacker can overwrite existing assets, flip upload visibility with type=private, register notification_url callbacks to attacker-chosen hosts, force cache invalidation, and write files outside the intended upload folder. The issue is only reachable when the plugin's clientUploads option is enabled, and no public exploit code or active-exploitation reporting was present in the supplied intelligence.
Any authenticated user of a Payload CMS instance running @jhb.software/payload-cloudinary-plugin (0.3.0 through 0.3.x, fixed in 0.4.0) can obtain a cryptographically valid Cloudinary HMAC-SHA1 upload signature for parameters of their choosing, because the client-upload signing endpoint POST /api/cloudinary-generate-signature forwards attacker-controlled 'paramsToSign' straight to cloudinary.utils.api_sign_request() with no key allowlist, folder policy, or timestamp check. With that signature plus the intentionally client-visible Cloudinary API key, an attacker can overwrite existing assets, flip upload visibility with type=private, register notification_url callbacks to attacker-chosen hosts, force cache invalidation, and write files outside the intended upload folder. The issue is only reachable when the plugin's clientUploads option is enabled, and no public exploit code or active-exploitation reporting was present in the supplied intelligence.