# Leaked Bitbucket Client Secret? Rotate It Now > Bitbucket OAuth client secret exposed on GitHub? Replace the consumer secret, revoke issued tokens and review repository access. Step-by-step guide. Source: https://leakwatch.net/secrets/bitbucket-client-secret --- [LeakWatch](/) [Product](/product)[Live feed](/leaks)[Guides](/secrets)[Blog](/blog)[Free scan](/) 1. [Home](/) 2. [Secrets](/secrets) 3. Bitbucket Client Secret Code & CI · Secret guide # Leaked Bitbucket Client Secret: what to do in the first hour High severityDetected onlyLast verified October 23, 2026 · 5 min read A Bitbucket client secret is the secret half of an OAuth consumer. An application that uses “Log in with Bitbucket” or that works with repositories through OAuth presents this secret, together with the consumer key, to exchange a code for an access token. Whoever holds the secret can impersonate that application in that exchange and, if they also obtain a user’s authorization, act on repositories that user can reach. Replace the secret first, then check what the application was used for. [Check your GitHub account for leaked secrets — free](/) Provider Bitbucket Severity High Impact Source code and build access Checked live by LeakWatch No ## What a Bitbucket Client Secret looks like A Bitbucket client secret is a long string of lowercase letters, digits, equals signs, dashes and underscores. It has no fixed prefix, so the value alone says little. Masked, the shape is: ```text BITBUCKET_CLIENT_SECRET=… Bitbucket client secret (value hidden) ``` The word `bitbucket` next to the value is what identifies it. A long string in an unrelated file is not reported, and neither is a Bitbucket word without a value of the right length. The consumer key that goes with it is a shorter value and is handled separately. If both appear in the same file, rotate the secret and treat the key as exposed as well, since the two are used together. ## How Bitbucket Client Secrets get leaked - **Application configuration.** A `.env` file or a settings module for an OAuth integration, committed with the secret filled in. - **Copied examples.** A sample file from a tutorial or a previous project, with the real secret left in place. - **Pipeline variables written into files.** A pipeline step that writes the secret into a configuration file and then commits or publishes it. - **Shared scripts.** A script that exchanges tokens for a team and is pasted into a ticket or chat with the secret visible. - **Deployment manifests.** Container or platform configuration that holds the secret in plain text instead of a secret store. ## What to do in the first hour 1. **Replace the secret.** Open the OAuth consumer in your Bitbucket workspace settings, and look for an option to generate a new secret. If the consumer offers one, use it, then update the application with the new value straight away. 2. **Stop the old value working.** If the consumer has no regenerate option, create a new consumer, move the application to its key and secret, and then delete the old consumer. Deleting a consumer also deletes the tokens issued through it, so schedule the switch carefully to avoid an outage for your users. 3. **Deploy the new value** to the secret store or environment, and confirm that the sign-in and token exchange still work. 4. **Review the tokens issued.** Look at which users authorized the application and when. Revoke any authorization you do not recognize, and make sure the application only asks for the scopes it needs. 5. **Check repository activity.** Review the workspace audit log and the activity of repositories the application can reach, for the period since the exposure. Look for pushes, new deploy keys, webhook changes and access grants you did not make. 6. **Review workspace members.** Remove anyone who no longer needs access, and check whether a new member appeared recently. 7. **Clean up the repository.** Remove the secret from the file 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), and use [deep-scan your whole git history](/blog/deep-scan-your-whole-git-history) to find older copies. Not sure what else leaked? [Run a free scan](/). [Not sure what else leaked? Run a free scan.](/) ## Revoke it at Bitbucket Open the OAuth consumers section of your workspace settings, find the consumer that owns the leaked secret, and generate a new secret if the page offers that option. This guide does not describe a regenerate button as certain, because the menu wording can differ between workspaces and over time. If you cannot find one, use the fallback in the first-hour steps: create a replacement consumer, update the application, and delete the exposed consumer. Remember that deleting a consumer ends every token it issued, so the application’s users will have to authorize it again. ## How LeakWatch detects it The rule is called Bitbucket Client Secret. It looks for the word `bitbucket` in a line, allows a short label and a separator such as `=` or `:`, and then expects exactly sixty-four characters from a small set of letters, digits, equals signs, underscores and dashes. The match is not case-sensitive. A value that is shorter or longer, or one with no `bitbucket` word near it, is not reported. The severity is **high**. This type is not checked live: LeakWatch does not send any request to Bitbucket with the value it found, so a finding means a value of the right shape sits next to the word, not that it is still active. 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 Does changing the client secret log out my users? Not by itself, in most setups. Existing access tokens keep working until they expire or are revoked. Deleting the consumer is different, because it removes the tokens issued through it. Is the client secret enough to read my repositories? No, not on its own. An attacker also needs a user to authorize the application, or a token that was already issued. The secret makes it possible to take part in that flow as your application, which is why it still needs replacing. Should I also rotate the consumer key? Only if it appeared in the same leaked file or the same place. The key is less sensitive, but if both values travelled together, rotate the consumer so the pair is no longer usable. ## Related - [GitHub Personal Access Token](/secrets/github-personal-access-token) - [GitLab Personal Access Token](/secrets/gitlab-personal-access-token) - [npm Access Token](/secrets/npm-access-token) - [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 Bitbucket. ![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)