An IBM Cloud API key lets whoever holds it sign in to IBM Cloud as the user or service ID that created it. From there the holder can list and change resources, read data in the services that user can reach, and create new keys of their own. Most IBM Cloud automation runs on API keys, so a leaked one often gives access to a whole account rather than a single application. Delete the exposed key first, then check what it was used for.
Check your GitHub account for leaked secrets — free
- Provider
- IBM Cloud
- Severity
- High
- Impact
- Cloud infrastructure access
- Checked live by LeakWatch
- No
What an IBM Cloud API Key looks like
An IBM Cloud API key is a long random string with no visible prefix. It is 44 characters drawn from letters, digits, underscores and hyphens:
…XXXX IBM Cloud API key (masked, the full value is 44 characters)
Because the value has no fixed prefix, the string alone says very little. Any 44-character random token would look the same. What identifies it is context: a variable named after IBM Cloud, such as IBMCLOUD_API_KEY, or a configuration key that mentions ibm right before the value. IBM Cloud also has other credentials, such as service credentials for individual services, that are stored differently. If a leaked file contains several of them, handle each one.
How IBM Cloud API keys get leaked
- Environment files. An
IBMCLOUD_API_KEYline in a.envfile or a shell profile that was committed by accident. - Infrastructure as code. Terraform or Ansible variables that hold the key directly, instead of reading it from a secret store at run time.
- Continuous integration. A pipeline definition that sets the key in plain text, or a step that prints its environment.
- Command-line sessions. A terminal capture or a shared history file that shows a login command with the key on it.
- Sample code. A tutorial or a demo that was copied with a real key left in place of the placeholder.
What to do in the first hour
- Find the key’s owner. In IBM Cloud, go to the access management area and look at the API keys list. The owner is the user or service ID that created the key, and that tells you what it could reach.
- Create a replacement first. Create a new key for the same user or service ID and store it in your secret manager. Confirm that your deployments still work before you remove the old key.
- Delete the exposed key. Deleting it is what ends the exposure, and any call with the old value fails from then on. Do not leave it in place while you investigate.
- Review Activity Tracker. IBM Cloud Activity Tracker records management events for the account. Search for actions taken with the exposed key since the exposure. Look for logins from unfamiliar locations, new resources, new keys and changes to access policies.
- Check for new keys and access. An attacker often creates another API key or adds a policy to a user. Review the keys and the access policies of the account, and remove anything you cannot account for.
- Review the service IDs. If the key belonged to a service ID, check the policies attached to it, and make sure only the required services are granted.
- Clean the repository. Remove the value and rewrite history if you want to. See I accidentally pushed an API key to GitHub and Deep scan your whole git history.
Not sure what else leaked? Run a free scan.
Revoke it at IBM Cloud
IBM Cloud API keys are listed in the access management section of your account. Open the API keys page, find the key by its name and creation date, and delete it. The page only shows keys for the account you have selected, so switch to the correct account first. Keys created for service IDs appear under those service IDs rather than under your own user. If the labels differ from this description, look for the API keys list in the access management area, and follow IBM’s documentation for the current steps.
How LeakWatch detects it
The rule is called IBM Cloud API Key. It looks for the word ibm in any letter case, followed within about 20 characters by an assignment sign or a colon, optional quotes and spaces, and then a 44-character value made of letters, digits, underscores and hyphens. The value must be exactly that length and must not run on into more characters. A value of a different length is not reported, and a token with no nearby ibm word is not reported either. The severity is high. This type is not checked live: LeakWatch does not send any request to IBM Cloud with the value it found.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Why is this rated high and not critical?
The rule relies on a nearby word rather than a fixed prefix, so it has to be more cautious about what it reports. The key itself is just as dangerous if it is real. Treat a hit as urgent.
Can I rotate instead of deleting?
Create the replacement first, then delete the old key. Deleting is the step that makes the old value useless, so do not stop at creating a new one.
What if the key belonged to a service ID?
It may run an application, so plan the swap with the owner of that application. Keep the service ID, but give it a new key and check its policies while you are there.