Safeguard
Application Security•

PDF Identity Verifier Firefox add-on delivered its payload after install

Socket reported a Firefox add-on with no malicious code at review time that fetched a Google account takeover payload after install, aimed at Portuguese and Spanish speakers.

Safeguard Security Team
3 min read

On 23 September 2026 Socket published research on a Firefox add-on called PDF Identity Verifier (ID pdf-para-texto@extensao.local). It was listed on 3 September and, per Socket, gained its malicious behavior in version 1.4 on 11 September. Socket says the add-on has no significant user base and the expected impact is fairly low. Its value as a case study is the evasion design.

What happened

Socket says the code shipped to the add-on store contains no hardcoded malicious logic, no target URLs and no exfiltration endpoint. It is a generic dispatcher. After install, a tab opens to a lookalike domain, pdf.gusercontent.com, and a loader writes configuration into browser.storage.local.

The add-on then injects a script into real accounts.google.com pages to automate sign in, hides the activity behind a fake "Validating your identity" overlay, and streams page transcripts to the attacker. Socket lists what is taken: a Google oauth_token session cookie, a password the attacker sets when Google forces a reset, and the victim's email. Socket assesses the targeting as Portuguese and Spanish speaking users.

Confirmed, reported and unknown

Reported by Socket from analysis: everything above, with hashes for the landing page, loader and payload.

Unknown: the actor, install and compromised account counts, whether the listing has been removed, whether Google was notified, and the hash algorithm used for the listed values. Socket calls one WebAuthn related patch in the content script "not conclusive on its own".

What to do now

  1. Look for the extension ID in Firefox profiles, and block gusercontent.com lookalikes at DNS.
  2. If a user installed it, treat their Google account as compromised. Change the password from a clean device, sign out all sessions and check recovery options, forwarding rules and connected apps.
  3. Add the extension ID to your browser enterprise policy blocklist.

How this could have been avoided

  • Reviewing the published code was not enough here, because the payload arrived later. Allow only extensions you have approved by ID, and re-review on every update.
  • Restrict extensions that request access to accounts.google.com or all sites.
  • Use phishing resistant sign in, such as passkeys, for important accounts, so an automated login flow has less to work with.
  • Watch for extension updates that add new permissions or new remote hosts.

Quick check

Why did store review not see the malicious behavior?

The shipped code was a generic dispatcher. The configuration and payload were fetched from attacker servers after install.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.