Building a Browser Extension Threat Intelligence Feed with Flat Files and Local-First Scanning
Hook
Over 1,000 malicious Chrome extensions have been removed from the Web Store, yet no regularly-updated public database existed to check if you’d installed any of them—until now.
Context
Browser extensions have become a major attack vector in the cybersecurity landscape. Between 2025-2026, security researchers documented multiple campaigns: fake AI assistant extensions targeting Chrome users through injected iframes, malicious tools stealing Meta Business Manager exports and TOTP 2FA seeds, and extensions harvesting ChatGPT conversations. The common thread? Extensions that initially appear legitimate but turn malicious after ownership transfers or updates.
The problem isn’t just detection—it’s historical awareness. When Google removes an extension from the Chrome Web Store, that information disappears into the void. Security blogs might mention specific campaigns, researchers publish findings, but there’s no centralized, continuously-updated database tracking which extension IDs have been flagged as malicious. toborrm9’s Malicious Extension Sentry fills this gap with a simple but effective approach: a flat-file database of 1,042 tracked extensions, automatically updated and paired with a privacy-first local scanner that runs entirely on your machine.
Technical Insight
The architecture is deliberately minimal, rejecting complex infrastructure in favor of three simple components that work together: a version-controlled database, a standalone Python scanner, and an optional Chrome extension for continuous monitoring.
The database itself lives as Markdown and CSV files directly in the GitHub repository, updated automatically by aggregating information from Chrome extension monitoring services, security research blogs and publications, and threat intelligence feeds. This flat-file approach means the entire threat intelligence feed is version-controlled, auditable, and accessible without API rate limits or authentication. Every extension entry includes its ID, name, and the date it was added to the database—no proprietary formats, no vendor lock-in.
The local scanner (malext.py) demonstrates how effective security tooling doesn’t require cloud infrastructure. Here’s the core workflow from the one-line installation:
curl -O https://raw.githubusercontent.com/toborrm9/malicious_extension_sentry/main/malext.py && python3 malext.pyThis single command downloads the scanner and executes it immediately—requiring only Python 3. The scanner performs three operations: (1) downloads the latest malicious extension database from GitHub, (2) auto-discovers Chromium-based browsers on your system by checking standard installation paths for Chrome, Edge, Brave, Vivaldi, Opera, and generic Chromium variants, and (3) reads each browser’s local extension manifest files to extract installed extension IDs for comparison.
The privacy implications are significant. Unlike cloud-based security tools that upload your extension list to remote servers for analysis, MalExt runs entirely locally. It downloads a public database (the list of known-bad extension IDs) and compares it against your locally-installed extensions without transmitting anything externally. No telemetry, no phone-home behavior, no data collection. You can verify this by reading the source code directly from the repository—transparency is built into the distribution model.
For users who prefer continuous monitoring over one-time scans, the MalExt Sentry Chrome extension provides background scanning automatically every 6 hours. The extension reads from the same database but operates per-browser-profile, meaning if you use Chrome’s profile feature for work/personal separation, you’ll need to install it in each profile independently. This is actually a security feature—it respects Chrome’s profile isolation boundaries rather than attempting to bypass them.
The live dashboard at malext.toborrm.com adds a web interface layer, enabling real-time search and filtering by threat category with source attribution for each entry. This separates concerns effectively: the database remains simple and portable, the scanner stays lightweight and local, and the dashboard provides advanced querying for researchers who need it.
What makes this architecture compelling is its resilience. Because the database is just text files in a Git repository, it can’t go offline due to API quotas, server costs, or vendor shutdowns. Anyone can fork it, mirror it, or build alternative tooling on top of it. The scanner is designed to work cross-platform on Windows, macOS, and Linux. This is infrastructure-free threat intelligence that will keep working as long as GitHub exists and Python maintains backwards compatibility.
Gotcha
The fundamental limitation is right there in the project description: this database tracks Chrome extensions that have been removed from the Chrome Web Store for containing malware, policy violations, or bundling unwanted software. If a malicious extension is currently live and actively being distributed, MalExt won’t detect it. This is post-mortem intelligence, not real-time protection. The scanner tells you if you installed something that was later flagged and removed, but it can’t warn you about zero-day threats or targeted campaigns that haven’t been publicly disclosed yet.
Coverage depends entirely on what security researchers publicly report and what the database’s sources capture. Stealthy campaigns that avoid detection, region-specific malware, or targeted attacks against specific organizations might never make it into the database. The 1,042 tracked extensions in the database represent documented threats—the actual number of malicious extensions that have existed is likely higher. Additionally, the scanner provides binary detection without detailed context: it tells you an extension is malicious, but the database entry includes only the extension ID, name, and date added—not necessarily what specific threat it posed, what data it exfiltrated, or how severe the risk was. For incident response or forensic investigation, you may need to research the extension independently.
Verdict
Use MalExt if you need a quick, zero-trust way to audit browser extensions across your organization’s endpoints, want a historical reference for security research on extension-based threats, or simply care about browser hygiene and want a privacy-respecting check that runs locally. It’s perfect for IT teams doing quarterly security audits, paranoid users who want periodic extension verification, and researchers building datasets on browser extension malware trends. The flat-file database format makes it trivial to integrate into CI/CD pipelines or automated security scanning workflows. Skip it if you need proactive protection against currently-active threats (use CRXcavator’s risk scoring or commercial browser security platforms instead), require detailed threat intelligence beyond binary detection of known-bad extension IDs, or want behavioral analysis of extension permissions and API usage patterns. This tool answers one question exceptionally well—‘Did I install something that was later flagged as malicious?’—but it won’t prevent you from installing the next malicious extension before security researchers document and report it.
