A Cloudinary API secret is the private half of the credentials your server uses to manage your media: uploading, transforming, listing and deleting images and videos. Anyone who holds it together with the API key and cloud name can act on your whole media library, not just read it. The secret is also used to sign upload requests, so a leak undermines every signed-upload rule you rely on.
Check your GitHub account for leaked secrets — free
- Provider
- Cloudinary
- Severity
- Critical
- Impact
- SaaS account access and billing
- Checked live by LeakWatch
- Yes
- Revoke at
- Cloudinary
What a Cloudinary API secret looks like
Cloudinary credentials come in three parts, and they are usually leaked in one line, the CLOUDINARY_URL environment variable:
CLOUDINARY_URL=cloudinary://<api_key>:<api_secret>@<cloud_name>
The cloud name identifies your account and appears in every delivery URL, so it is public. The API key is a numeric identifier. The API secret is a short random string, typically 27 characters, with no distinctive prefix. This is the value to protect and rotate.
One thing it is not: an unsigned upload preset is a separate, deliberately public setting that lets browsers upload without a secret. That is a design choice to review, not a leaked credential. For other credentials that sit behind a media or storage account, see the Google API key guide.
How Cloudinary secrets get leaked
- The
CLOUDINARY_URLline. Copied from the console into a.envfile or a Docker Compose file that was then committed. - Server-side config in a public repo. A
cloudinary.config({ ... api_secret: "..." })call in Node, or the equivalent in Python, Ruby or PHP, with the real value. - Front-end bundles. The secret placed in a browser or mobile app because “uploading needs credentials”; uploads from clients should use signatures generated on your server.
- CI and deploy files. A workflow file, Helm values or
app.yamlcarrying the variable in clear text. - Support threads. The whole
CLOUDINARY_URLpasted into an issue or a chat when asking for help with an upload error.
What to do in the first hour
- Create a new key pair. In the Cloudinary Console open Settings and the API Keys page, and generate a new API key and secret. Save the secret in your secret manager.
- Deploy the new pair to every service that talks to Cloudinary, then confirm uploads and image delivery still work.
- Disable or delete the exposed key on the same page. If the console only lets you regenerate the secret for a given key, do that and confirm the old value is rejected.
- Audit the media library. In the Media Library, sort by upload date and look at what was added or changed since the exposure. Look for assets you did not upload and, as important, for assets that have disappeared. Check the Activity or audit views your plan provides.
- Check what the key could do. Admin API access lets someone list, rename, and delete assets, create presets and change folder structure. Review your upload presets for any that are unsigned or allow unusual formats.
- Review usage and content. Compare storage, transformations and bandwidth against your normal level; abuse often shows up as sudden storage growth from unwanted uploads. If private or authenticated assets were stored, ask whether anyone could have downloaded them with the secret.
Not sure what else leaked? Run a free scan.
- Then clean the repository: remove the value and rewrite history if you want to. See I accidentally pushed an API key to GitHub.
Revoke it at Cloudinary
Open the API Keys page of the Cloudinary Console, generate a replacement, and then disable or delete the key whose secret leaked. If you manage several product environments, make sure you are in the one the leaked credentials belong to; the cloud name in your CLOUDINARY_URL tells you which.
How LeakWatch detects it
The rule is called Cloudinary API Secret. The secret has no prefix, so detection is context-based: LeakWatch looks for a 27-character value of letters, digits, _ and - that appears within about 40 characters after the word “cloudinary”. That keeps false alarms down, but a secret kept far from that word in a file can be missed. This type is checked live: when the cloud name, API key and secret are all found together, LeakWatch can check whether they still work with a read-only ping request. It does not read, upload or delete any media.
LeakWatch can check whether a detected key is still active with a read-only request to Cloudinary. It never reads your data or spends your credits.
FAQ
Is the cloud name in my image URLs a leak?
No. It is public by design. The API secret is what needs protection, and it never appears in delivery URLs.
Can someone delete my whole media library?
With the API key, secret and cloud name, the Admin API allows deleting assets, so yes, that is the main risk. Keep backups of originals elsewhere, and check for missing assets as part of the audit.
Do I have to rotate if I only leaked the secret and not the key?
Yes. The key is not secret, so it is trivially recovered from your own site and configuration. Treat the secret alone as a full leak.