# Leaked Cloudinary API Secret? Rotate It and Check Assets

> Cloudinary API secret exposed on GitHub? Create a new key in the console, remove the old one and audit uploads. Step-by-step guide.

Source: https://leakwatch.net/secrets/cloudinary-api-secret

---

[LeakWatch](/)

[Product](/product)[Live feed](/leaks)[Guides](/secrets)[Blog](/blog)[Free scan](/)

1.  [Home](/)
2.  [Secrets](/secrets)
3.  Cloudinary API Secret

Databases & keys · Secret guide

# Leaked Cloudinary API Secret: what to do in the first hour

Critical severityChecked liveLast verified October 2, 2026 · 4 min read

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](https://console.cloudinary.com/app/settings/api-keys)

## 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:

```text
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](/secrets/google-api-key) guide.

## How Cloudinary secrets get leaked

-   **The `CLOUDINARY_URL` line.** Copied from the console into a `.env` file 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.yaml` carrying the variable in clear text.
-   **Support threads.** The whole `CLOUDINARY_URL` pasted into an issue or a chat when asking for help with an upload error.

## What to do in the first hour

1.  **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.
2.  **Deploy the new pair** to every service that talks to Cloudinary, then confirm uploads and image delivery still work.
3.  **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.
4.  **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.
5.  **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.
6.  **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](/).

7.  **Then clean the repository**: remove the value and rewrite history if you want to. See [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github).

[Not sure what else leaked? Run a free scan.](/)

## Revoke it at Cloudinary

Open the [API Keys page of the Cloudinary Console](https://console.cloudinary.com/app/settings/api-keys), 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.

## Related

-   [Database Connection String](/secrets/database-connection-string)
-   [Google API Key](/secrets/google-api-key)
-   [AWS access key](/secrets/aws-access-key)
-   [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github)
-   [Which vendors leak most this week](/leaks/trends)
-   [All secret guides](/secrets)

[Get alerted next time a secret leaks — create a free account](/)

LeakWatch is not affiliated with Cloudinary.

![Gabriel Diyan, founder of LeakWatch](/brand/Photo-Gabriel-Diyan.webp)

Gabriel Diyan (0xCr0c0)

Cybersecurity student, founder of LeakWatch. I built and run the scanner described here — the detection patterns, the false-positive classifier and the provider validators are mine. [More about who I am](/about).

[GitHub](https://github.com/Leakwatch-Scan) · [X](https://x.com/LeakwatchScan) · [LinkedIn](https://www.linkedin.com/in/gabriel-diyan-80a378375) · [GitHub (personal)](https://github.com/crocogab)

LeakWatch

Secrets leak into public commits every minute. This watches the forges for yours. Built and run by [Gabriel Diyan](/about), a cybersecurity student — [why LeakWatch exists](/about).

Scan

-   [Product](/product)
-   [Live feed](/leaks)
-   [Trends](/leaks/trends)
-   [API docs](/docs)
-   [CI/CD](/docs?tab=ci)

Read

-   [Blog](/blog)
-   [Secret guides](/secrets)
-   [Changelog](/changelog)
-   [About](/about)

Verify

-   [Security](/security)
-   [Privacy](/privacy)
-   [Terms](/terms)
-   [Legal](/legal)
-   [Contact](/contact)
-   [Status](https://status.leakwatch.net)

© 2026 LeakWatch

[GitHub](https://github.com/Leakwatch-Scan)[X](https://x.com/LeakwatchScan)
