# Leaked Firebase Server Key? Revoke It and Check Pushes

> Firebase Cloud Messaging server key exposed on GitHub? Retire it, move senders to service accounts and review recent push sends. Step-by-step guide.

Source: https://leakwatch.net/secrets/firebase-cloud-messaging-server-key

---

[LeakWatch](/)

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

1.  [Home](/)
2.  [Secrets](/secrets)
3.  Firebase Cloud Messaging Server Key

Messaging · Secret guide

# Leaked Firebase Cloud Messaging Server Key: what to do in the first hour

High severityDetected onlyLast verified October 23, 2026 · 5 min read

A Firebase Cloud Messaging server key was the credential that let a backend send push notifications to the users of a mobile or web app. Whoever holds it can send a notification to any device registered with that project, with any title and link. That is not access to your database or your users’ accounts, but it is a direct line to every installed copy of your app, and a push that looks like it came from your service is an effective way to send phishing links. Stop the key from working first, then review what was sent.

[Check your GitHub account for leaked secrets — free](/)

Provider

Firebase

Severity

High

Impact

SaaS account access and billing

Checked live by LeakWatch

No

## What a Firebase server key looks like

The legacy server key had a recognizable shape: a fixed `AAAA` prefix, a short identifier, a colon, and a long body of letters, digits, underscores and hyphens. The part after the colon is much longer than the part before it:

```text
AAAA…XXXX:…XXXX   Firebase Cloud Messaging server key (masked)
```

Do not confuse it with other Google keys. A key starting with `AIza` is a web API key, which can be restricted or used for other Google services, and a Firebase service account file is a JSON document with a private key. Each has its own revocation steps. If the leaked value is a web API key, see the [Google API key](/secrets/google-api-key) page instead.

## How Firebase server keys get leaked

-   **Backend configuration.** A push sender in a server, a queue worker or a cron job with the key set as a constant, committed with the rest of the code.
-   **Mobile build settings.** A key copied into a configuration file or a build script that was published to a public repository.
-   **Tutorials and samples.** A copied sample that calls the send endpoint with a real key left in place.
-   **Environment files.** A `.env` file or a CI variable export printed into logs during a debug step.
-   **Shared code.** A helper script sent to a colleague or posted to a forum with the key still inside.

## What to do in the first hour

1.  **Check which kind of key it is.** Look at the project in the Firebase console and see whether the value is a legacy server key or another credential. Note the project, because a key only sends to devices registered with that project.
2.  **Move your senders to a service account first.** Create or use a service account with the messaging role, store its private key in your secret manager, and send a test notification to a device you control. Google’s current send API uses service-account credentials, not the server key.
3.  **Retire the exposed key.** Use the steps in the Firebase revoke section below. If the console no longer offers a way to remove the legacy key, stop every system that uses it and confirm that sends with it fail.
4.  **Review recent sends.** Look at the messaging reports and the logs of your sending service for the period since the exposure. Look for notifications you did not trigger, unusual volume, and titles or links that do not match your product.
5.  **Warn your users if pushes were abused.** If a fake notification reached them, tell them through a channel you trust, and explain what the real notifications look like.
6.  **Check the other credentials in the same file.** Service account keys, API keys and app secrets that sat next to the server key should be rotated too.
7.  **Clean the repository.** Remove the value from the working tree and rewrite history if the repository is public. 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](/).

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

## Revoke it at Firebase

Open the Firebase console, choose the project, and go to the project settings. The Cloud Messaging section lists the server keys and sender IDs for that project. For a legacy key, check whether the console still offers a way to delete or disable it. If it does not, the reliable steps are to stop using the key everywhere, confirm that sends with it fail, and turn off the legacy messaging API in the Google Cloud console for that project. Google has been retiring the legacy send API, so if the page differs from this description, follow Firebase’s current documentation on migrating to HTTP v1 and removing legacy credentials.

## How LeakWatch detects it

The rule is called “Firebase Cloud Messaging Server Key”. It looks for a word boundary, the literal prefix `AAAA`, seven letters, digits, underscores or hyphens, a colon, and then exactly 140 of the same characters, followed by a word boundary. There is no context keyword, so the match depends on the structure alone. A value with a shorter body after the colon does not match, and a web API key starting with `AIza` is a different rule. The severity is **high**. **This type is not checked live**: LeakWatch does not send any request to Firebase with the key it found, so a hit shows that the value has the expected shape and not that it still works. The 140-character length comes from the observed format of legacy keys and should be read as an approximation.

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

Can someone read my app's user data with this key?

No. A server key is for sending messages. It does not give access to Firestore, Realtime Database or user accounts. The risk is the messages themselves, and the chance of users installing or trusting something they should not.

Is the legacy server key still valid?

Do not assume it is. Google has retired the legacy send API, but projects and integrations vary. Test it on a device you control, then treat it as exposed either way and retire it.

Does moving to a service account fix the leak?

It fixes the design, not the exposure. The leaked key still needs to be stopped, and the service account’s private key must be kept out of the repository as well.

## Related

-   [Slack Webhook URL](/secrets/slack-webhook-url)
-   [Discord Bot Token](/secrets/discord-bot-token)
-   [Telegram Bot Token](/secrets/telegram-bot-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 Firebase.

![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)
