The Password Reset That Shipped Its Own API Key in a Shortened URL

Firebase's password-reset flow is a legitimate service that sends cryptographically signed emails on behalf of application developers. That same legitimacy makes it a reliable delivery vehicle for credential theft when the application behind it is attacker-controlled. This case demonstrates exactly how much sensitive material an attacker can expose in a single URL and still land in a recipient's inbox.

A password-reset email arrived at a regional financial institution, claiming to be from "Mass Sender," a service name with no connection to the recipient's work. The email contained a single link: a t.co shortened URL with a live Google API key, a one-time password-reset token, and a Firebase tenant identifier embedded directly in the query string. The message passed DKIM verification, transited a legitimate content-disarm relay, and was delivered at SCL -1.

Three mailboxes were affected before community intelligence flagged the incident.

The URL That Contained Everything

The link in the email body was a t.co shortened URL wrapping a Firebase authentication endpoint. The query parameters included:

• apiKey=AIzaSyC9z_vE3XmxYhyGIO0oG2OwYURjkICARPY (a live Google API key)
• oobCode=GioD2oxaHqlgoehAQK5s82lI_YIMoVUXiM48GFQGJnAAAAGdpzKzDg (a one-time password-reset token)
• tenantId=niw364-njose (the Firebase tenant identifier)
• mode=resetPassword

These parameters are not metadata. They are the operational payload. An oobCode is a one-time out-of-band code that, if valid and unexpired, allows anyone who possesses it to complete a password reset without additional verification. Publishing it in a URL that passes through a t.co shortener, SafeLinks rewriting, and potentially multiple proxy logs means the token is exposed at every hop in the delivery chain.

The API key prefix (AIzaSy) is consistent with Google Cloud project keys. While API keys alone do not grant account access, they identify the Firebase project and can be used to enumerate project configuration, including authentication providers and tenant settings. Combined with the tenantId, an attacker (or a secondary attacker intercepting the URL) has enough information to probe the backend directly.

See Your Risk: Calculate how many threats your SEG is missing

Authentication Passed. DMARC Did Not.

The email was sent from noreply@olasimos[.]firebaseapp[.]com. DKIM passed with a valid signature under d=firebaseapp.com, which is expected because Firebase signs outbound messages using Google's infrastructure. This DKIM pass is legitimate in the cryptographic sense: Google's key signed the message, and the signature verified correctly.

SPF told a more complicated story. The original hop from Google's mail infrastructure (2607:f8b0:4864:20::a48) passed SPF for olasimos[.]firebaseapp[.]com. But the message then transited a Votiro CDR relay (44.206.213.130, an AWS EC2 instance running votiro-relay1.prod.votiro.com). When the message arrived at the recipient's Microsoft 365 tenant from the Votiro IP, SPF evaluated against that IP and returned a softfail because Votiro's infrastructure is not listed in Firebase's SPF record.

DMARC returned a permerror. Firebase subdomains inherit a DMARC configuration that the evaluating gateway could not process to completion, producing neither pass nor fail. With DMARC unable to enforce and SPF broken by the relay, the only surviving authentication signal was DKIM, which confirmed the message was signed by firebaseapp.com but said nothing about whether the application behind it was legitimate.

The Votiro relay IP was allow-listed by the receiving tenant (IPV:CAL in the antispam headers). Microsoft Exchange Online Protection reset the SCL from 5 (the untrusted evaluation) to -1 (the trusted evaluation), delivering the message directly to inboxes.

A CDR Relay as an Accidental Reputation Laundering Hop

Votiro's CDR service is a legitimate email security product that scans and sanitizes attachments before forwarding mail to the recipient's tenant. The X-MTConnectorResult header confirmed the message was processed ("Sanitized"), and the X-Votiro-Connector headers confirmed the relay handled the message.

The problem is not with Votiro's scanning. The problem is that allow-listing a CDR relay IP means every message that transits that relay inherits the allow-list's trust, regardless of origin. In this case, a phishing email from an unknown Firebase app transited the same relay as legitimate business correspondence and received the same SCL -1 treatment. The relay did its job (scanning for malicious attachments), but the message contained no attachments. The entire payload was a URL with embedded credentials.

IRONSCALES Adaptive AI assigned a 50% confidence score and flagged the VIP Recipient label. Community intelligence across the IRONSCALES network was more decisive: historical resolutions of similar incidents produced a high-confidence phishing classification that triggered quarantine for three affected mailboxes.

MITRE ATT&CK Alignment

IOC Summary Table

What This Case Demands From Your Stack

Firebase, like SendGrid, Mailgun, and other platform services, produces DKIM-signed emails that will pass cryptographic verification regardless of the application's intent. Blocking firebaseapp.com wholesale is impractical for organizations that use Firebase services. The detection surface has to be behavioral.

Audit your CDR relay allow-lists. If your content-disarm provider is allow-listed by IP, every message that transits that relay bypasses your SCL evaluation. Consider applying allow-list exceptions only to known sender domains or implementing conditional trust that preserves SCL scoring for first-time senders.

Flag URLs with exposed authentication tokens. An oobCode or apiKey parameter in a link is not normal business correspondence. URL parameter inspection for authentication tokens (oobCode, apiKey, access_token, bearer) is a high-signal, low-noise detection rule that catches this class of attack without generating false positives on legitimate mail.

Treat DMARC permerror as a risk signal, not a non-event. A permerror means the policy could not be evaluated. For enforcement purposes, that is functionally equivalent to having no DMARC policy at all. Messages with DMARC permerror should receive elevated scrutiny, not a pass.