← Back to all reports

Hardcoded AES Key + Firebase Config Leak Production TLS Private Key

Reported Apr 14, 2026
Severity Critical
Platform Android
Vulnerability Class Hardcoded Credentials + Crypto Misuse (CWE-798, CWE-321)
Target Type Geolocation Compliance SDK (iGaming)
Impact Recoverable production TLS private key

The Risk

The secret key that proves the company's main server is genuine could be pulled out of the public app in under a minute by anyone who downloaded it. With that key, an attacker could stand up a fake server that any phone, browser, or laptop in the world would accept as legitimate. Rotating the key did not fix the problem because every new key was scrambled with the same hidden password baked into the app. The certificate had to be revoked at the certificate provider and the app rebuilt from scratch.

The Vulnerability

Three separate flaws compounded into a complete recovery of a production RSA private key in under sixty seconds, with no device, no root, and no man in the middle.

1. Unauthenticated Firebase Remote Config

The app fetched its production server certificate (and matching private key) from Firebase Remote Config. The endpoint was reachable with only the public Google API key bundled in the app's google-services.json. No OAuth token, no session, no device attestation. The encrypted certificate blob came back to anyone who asked.

2. Hardcoded AES-256-GCM key

The blob was encrypted with AES-256-GCM. The 32-byte key was a constant baked into the app's compiled code. Captured identically with Frida on two independent devices (a Samsung Galaxy S20FE and a Pixel 5, both with fresh app data), confirming that the key was universal across every install rather than per-device.

3. Static IV derived from the key

The GCM initialisation vector was the first 16 bytes of the AES key itself. A static IV per key is an independent cryptographic weakness on top of the hardcoded key issue.

The Attack

  1. Pull the google-services.json API key out of the app resources.
  2. POST to the Firebase Remote Config fetch endpoint for the project, passing the API key as a query parameter and any made up app instance ID. The response includes the encrypted certificate blob and a PKCS12 password.
  3. Base64 decode the blob and decrypt with the hardcoded AES-256-GCM key, using the first 16 bytes of the key as the IV.
  4. The output is a JSON object with three fields: server certificate, intermediate CA, and RSA private key, all in PEM form.

The recovered certificate was a valid production certificate issued by a major commercial CA, with a year of remaining validity. The modulus of the recovered private key matched the modulus of the recovered certificate exactly.

Impersonation server

A standalone TLS server bound to 127.0.0.1 using the recovered cert and key returned HTTP 200 to curl with TLS verify result: 0 against the system CA store, and Verification: OK to openssl s_client -CApath /etc/ssl/certs -verify_return_error. Any TLS client that trusts public CAs accepts the impersonated server with no warning.

The Impact

The recovered private key is shared across every Android install of the SDK and every gambling-industry app that embeds it. Anyone holding the key can present a valid TLS chain for the SDK's primary host that strict public CA validation accepts. With this primitive an attacker can:

  • Run a fake server that every embedding app, phone, browser, and command line tool trusts as the real one.
  • Capture or forge the geolocation compliance traffic that the SDK exists to protect, undermining the entire purpose of the integration.
  • Combined with DNS hijacking, ARP spoofing, or rogue Wi-Fi, intercept production traffic with no certificate warning on any device.

Rotating the certificate in Firebase Remote Config does not mitigate the issue. Every new certificate is encrypted with the same hardcoded key, so the next private key falls just as quickly. The certificate must be revoked at the CA and the app must ship a new release with a different protection model.

Remediation

  • Revoke the leaked certificate at the certificate authority. Issue a new certificate.
  • Stop shipping production private keys to the client at all. The TLS handshake should happen against a server that holds the key, not against a key fetched at runtime.
  • If the client must hold any sensitive material, use the platform key store (Android Keystore, iOS Keychain) and a per-install key. Never a constant baked into the app.
  • Tighten the Firebase Remote Config rules so the encrypted certificate parameter is not returned to unauthenticated clients.
  • If symmetric encryption is used, never reuse a static IV. Generate a fresh random IV per encryption and prepend it to the ciphertext.
  • Audit every other Remote Config parameter for the same protection pattern. Anything encrypted with the same hardcoded key has the same exposure.

All findings anonymized per responsible disclosure policies.