Hidden Spy for 1.6 Million Users: Popular Browser Extension ModHeader Secretly Collected Browsing History
Google and Microsoft have removed the widely used ModHeader browser extension from their official stores after researchers uncovered a hidden mechanism capable of secretly collecting users' browsing history. The extension, which boasted roughly 1.6 million installations, had maintained a reputation as a legitimate developer tool for years before the malicious functionality was exposed.
ModHeader enables users to modify HTTP headers exchanged between the browser and websites. It is commonly employed by developers and QA specialists to test web applications, inject authorization tokens, and simulate different request parameters without altering source code.
Discovery and Removal Timeline
Researchers at the British company Stripe OLT analyzed the extension's code using signatures from the Chrome Web Store and confirmed that the suspicious module was present in the authentic build, not a counterfeit. Microsoft removed the extension from the Edge store on July 3, while Google removed the Chrome version on July 10.
How the Hidden Collector Worked
Although ModHeader continued to perform its advertised functions, its background code contained a separate data-collection mechanism. Upon launch, the extension generated a device fingerprint, extracted domains from open pages, encrypted the data, and could store up to 1,000 addresses locally. Once per day, the list was scheduled to be sent to api.stanfordstudies[.]com together with the device fingerprint, after which the local copy would be deleted.
The collector remained inactive because it was configured to activate only for browsers listed in an internal array that was supplied empty. No evidence of actual data collection or transmission was found. However, the developer could have enabled the feature at any time through a routine update without requesting additional permissions or user interaction.
Active Telemetry and Data Exposure
Partial telemetry was already operational. On installation, update, and removal, ModHeader sent product, version, and browser information to extensions-hub[.]com. Additionally, a script running on every page saved request metadata in plaintext. Automated security scanners rated the extension as low-risk because the history-collection feature was disabled, data was encrypted, and the code was hidden inside a legitimate project.
Recommendations for Users and Administrators
- Immediately remove ModHeader from Chrome and Edge and verify that it has not been restored via profile synchronization or corporate policy.
- Replace any API keys, access tokens, or session cookies that were entered through the extension.
- Administrators should block the domains stanfordstudies[.]com and extensions-hub[.]com and review logs for connections to these domains or the extension identifier.
Related articles
Secure Boot on Arch Linux: Enabling Protection for UKI Without Replacing Factory Keys
A detailed guide explains how to configure Secure Boot on Arch Linux for Unified Kernel Images without replacing the motherboard's factory keys or relying on Microsoft certificates. The author chose the minimal-intervention approach of adding a custom key to the existing DB section via the UEFI interface instead of using sbctl enroll-keys or shim. The process begins with backing up existing keys to a FAT-formatted USB drive directly from the BIOS menu. New keys are then generated using sbsigntools and openssl, converted to DER format, and enrolled through the ASUS Prime 790-P UEFI interface. A post-hook script for mkinitcpio automatically signs the UKI after every kernel update, ensuring the entire unified image remains protected. The method preserves the original Microsoft and vendor certificates while adding only the user's own signing key.
What Server Logs Reveal About Attackers: Analyzing Suspicious Requests on Linux
Server logs provide critical insights into potential intrusions by recording events from the operating system, SSH authentication, and web applications. The guide explains how to examine Linux system journals with journalctl, review authentication logs on Debian and RHEL systems, and inspect Nginx access logs for unusual HTTP requests. Analysts learn to identify patterns such as rapid failed login attempts using multiple usernames from a single IP address, which may indicate brute-force or automated scanning activity. The article also covers counting the most active IP addresses with awk and sort commands while stressing the need to compare findings against normal traffic baselines. Additional recommendations include logging structured security events in JSON format with fields for timestamp, user ID, resource, and outcome, following OWASP guidelines. The text warns against storing sensitive data like passwords in logs and highlights limitations such as possible log tampering or unsynchronized server clocks. A practical seven-step investigation plan helps responders preserve evidence and verify hypotheses before taking action.
UserGate Details FPGA Acceleration to Turbocharge Next-Generation Firewalls
UserGate product manager Pavel Molodan explains why adding security features like IDS/IPS, SSL/TLS inspection, and application control turns a high-performance NGFW into a bottleneck. The company outlines four groups of acceleration methods, with a focus on FPGA-based hardware offloading for packet parsing, firewall rules, NAT, and encryption tasks. Research from 254 respondents shows strong demand for these functions in data center B2E segments at 50-200 Gbit/s. Experimental platforms including Katun-2 PCIe cards and the FG system demonstrate concrete gains, such as scaling IDPS from 5 to 90 Gbit/s and achieving 85 Gbit/s firewall throughput on EMIX profiles. FPGA delivers microsecond latency and better energy efficiency compared with CPU-only designs while preserving full NGFW functionality for elephant flows.
Curator Reveals Detailed Architecture of Its Network Filtering System After October 2026 Outage
Curator published a technical post-mortem analyzing the 38-minute outage that affected its entire traffic filtering network on October 8, 2026. The company operates nine filtering sites across Russia, each containing multiple nodes connected via high-performance switches to upstream providers. Traffic is isolated using two VRF contexts—external for inbound dirty traffic and internal for cleaned traffic—ensuring sequential processing through the protection system. Each node runs a custom Linux kernel firewall and a watchdog service that monitors BGP sessions to detect failures and remove unhealthy nodes from rotation. Centralized configuration management via CControl allows rapid rollout of rules but also introduces systemic risk when faulty changes propagate across all nodes. The post-mortem emphasizes the need for isolation, staged deployments, and independent recovery mechanisms in large-scale filtering infrastructures.