Critical Chrome Extension Vulnerability Exposed 1.6M User Passwords

Key Takeaways

• The popular ModHeader Chrome and Edge extension, with 1.6 million users, was found to contain dormant code capable of collecting and exfiltrating user browsing data.
• Although the data collection feature was not actively enabled in the analyzed version (7.0.18), the complete framework for exfiltration was present and could be activated remotely.
• Google and Microsoft have removed ModHeader from their respective extension stores, with Google classifying it as malware.
• Users are advised to remove the extension, rotate sensitive API keys/tokens, and monitor for associated indicators of compromise.

A widely adopted browser extension, ModHeader, has been pulled from both the Chrome Web Store and Microsoft Edge Add-ons marketplace following the discovery of embedded code designed to collect, encrypt, and potentially transmit users’ browsing activity. This utility, popular among developers for modifying HTTP headers, had amassed approximately 1.6 million installations across Chrome and Microsoft Edge.

While ModHeader’s core functionality necessitated broad permissions to interact with web traffic and pages, researchers identified a hidden data exfiltration pipeline within its signed release. This capability, though inactive in the analyzed version, raised significant security concerns due to its completeness and potential for remote activation.

Detailed Analysis of the ModHeader Vulnerability

Dormant Data Collection Framework

Researchers examining ModHeader version 7.0.18 uncovered a browsing-history collection mechanism within the extension’s background service worker. This sophisticated logic was engineered to extract domain names from visited URLs, encrypt them using a hardcoded AES-GCM key, and then store these encrypted records in IndexedDB.

The exfiltration pipeline utilized two local data stores: a ‘settings’ store for maintaining a persistent installation fingerprint, an encryption initialization vector, and upload timing data; and a ‘temp’ store for encrypted domain records and visit counters. The system was configured to retain up to 1,000 unique domains before initiating an upload. The code also included an outbound POST request routine directed to https://api.stanfordstudies.com/app/log.

According to StripeOlt’s analysis, the intended payload would have contained encrypted browsing data, device fingerprint information, and browser specifics. The uploader was designed with retry logic for failed transmissions and would erase local domain data upon successful upload, thereby reducing forensic traceability.

Crucially, the history-collection function in the examined build was gated by an empty allow-list. Since no specific browser identifier was present in this list, the data collection and upload path did not execute in ModHeader version 7.0.18. However, the primary concern remains that the entire framework for collection, encryption, storage, scheduling, and transmission was fully implemented and could be enabled through a routine extension update, bypassing the need for new user permissions.

Additional Telemetry and Vendor Response

Beyond the dormant exfiltration capability, the ModHeader extension also incorporated active telemetry linked to extensions-hub.com. This functionality reported install, update, and uninstall events, demonstrating the extension’s existing communication with third-party infrastructure, separate from the browsing history upload feature.

Both Google and Microsoft have acted swiftly, removing ModHeader from their respective extension stores. Microsoft’s removal occurred on July 3, with Google subsequently flagging the extension as malware. Researchers from aydinnyunus.github noted that this incident highlights a persistent browser supply chain vulnerability: while platform signatures confirm an extension’s origin, they do not guarantee the safety of all capabilities introduced in subsequent updates.

This event underscores the importance of treating high-permission extensions as third-party software, necessitating robust security practices such as allowlists, continuous inventory monitoring, and periodic behavioral reviews.

What You Should Do

• Remove the Extension: Immediately remove ModHeader (Extension ID: idgpnmonknjnojddfkpgkljpfnnfcklj) from all Chrome and Microsoft Edge browsers.
• Rotate Sensitive Credentials: If you used ModHeader for API testing or development, review and rotate any sensitive values previously placed in custom headers, including API keys, authorization tokens, and session cookies.
• Network Monitoring: Organizations should configure firewalls and proxies to block or monitor traffic to stanfordstudies.com and extensions-hub.com.
• Endpoint Detection: Hunt for the ModHeader extension ID (idgpnmonknjnojddfkpgkljpfnnfcklj) across managed browser environments.
• Security Awareness: Educate users about the risks associated with browser extensions and the importance of scrutinizing permissions and developer reputation.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.