The payload‑cloudinary‑plugin forwards client‑supplied parameters directly to cloudinary.utils.api_sign_request without filtering, freshness validation, or allowed‑list enforcement. An authenticated Payload user can thus request signatures for arbitrary Cloudinary parameters such as overwrite, type, notification_url, invalidate, folder, and public_id. With the resulting HMAC‑SHA1 signature the user can trigger asset replacement, alter upload visibility, redirect callbacks to malicious URLs, invalidate caches, and upload files outside the intended folder. This gives the attacker unauthorized control over Cloudinary operations and effectively bypasses the intended permission boundaries. The weakness is a case of CWE‑347, Insecure Direct Objects Reference, caused by the lack of parameter validation and policy enforcement.

The vulnerability impacts deployments of the Payload Plugins collection, specifically the payload‑cloudinary‑plugin component, from version 0.3.0 through 0.4.0 (inclusive of the pre‑fix 0.4.0). Any installation that has clientUploads enabled and exposes the /api/cloudinary‑generate‑signature endpoint is susceptible.

With a CVSS score of 7.1 the vulnerability is of moderate‑high severity. An EPSS score is not available and the flaw is not listed in CISA KEV, indicating no known widespread exploitation. The likely attack vector involves authenticated users sending POST requests to the exposed endpoint. Once authenticated, an attacker crafts a request specifying arbitrary signing parameters, enabling them to manipulate Cloudinary assets, trigger callbacks, and perform operations that would normally require higher privileges. Because the signing routine runs on the server, the attacker need not possess the Cloudinary account credentials; the generated signature serves as the necessary authorization token.