Security researcher Ben Zimmermann discovered 39 exposed Algolia admin API keys embedded in the frontend JavaScript of major open source documentation sites, disclosed March 13, 2026. The victims include Home Assistant (85,000 GitHub stars), KEDA (CNCF Kubernetes project), and vcluster. Admin keys grant dangerous permissions—addObject, deleteObject, deleteIndex, editSettings—allowing attackers to inject malicious search results, delete entire indices, and manipulate documentation rankings.
This isn’t a one-off bug. Furthermore, Zimmermann systematically scanned approximately 15,000 documentation sites after finding an exposed key on vuejs.org in October 2025. The result: 35 admin keys from frontend scraping, 4 from git history via TruffleHog. All 39 keys were still active at publication.
Systematic Discovery, Not Lucky Find
Zimmermann didn’t stumble on this vulnerability—he hunted for it. The investigation began when Vue.js acknowledged his report of an exposed admin key in October 2025. Consequently, that discovery prompted a broader question: how many other DocSearch sites made the same mistake?
Using Algolia’s public docsearch-configs repository as a starting point (containing 3,500+ site configurations), Zimmermann scraped roughly 15,000 documentation sites looking for API keys embedded in frontend JavaScript. Moreover, he ran TruffleHog against 500+ GitHub repositories to catch keys lurking in git history. The methodology was thorough, and the results damning.
The high-profile victims demonstrate this isn’t just a problem for obscure projects. Home Assistant serves millions of installations. KEDA is a CNCF project deployed in production Kubernetes clusters. These are security-conscious teams—yet the mistake happened anyway.
Root Cause: Algolia API Key Architecture Meets Developer Error
DocSearch offers two deployment models. The standard approach uses Algolia-managed crawlers, which provide search-only API keys for frontend integration. Safe configuration, no admin access needed.
However, the dangerous path is self-hosted crawlers. Organizations running their own crawlers receive admin API keys for backend use—keys with full index control. The problem: developers mistakenly embed these admin keys in frontend configs instead of creating separate search-only keys. Frontend JavaScript is public code. Anyone can view source in a browser and extract the API key.
// WRONG: Admin key exposed in frontend
docsearch({
apiKey: 'admin_key_with_deleteIndex_permissions', // Dangerous!
indexName: 'docs'
});
// RIGHT: Search-only key in frontend
docsearch({
apiKey: 'search_only_key', // Safe
indexName: 'docs'
});The permission difference is stark. Search-only keys grant one permission: search. In contrast, admin keys expose addObject, deleteObject, deleteIndex, editSettings, listIndexes, and browse. That’s the difference between querying data and destroying it.
Attack Scenarios Worth Worrying About
Admin keys enable practical attacks, not theoretical ones. An attacker with addObject permission could inject fake search results for “API authentication tutorial” that redirect to a credential-harvesting site. Developers trust documentation search as an authoritative source—making this an effective phishing vector.
Supply chain attacks are even more insidious. Modify code examples in search results to include malicious package names instead of legitimate ones. Consequently, developers copy-paste commands from trusted documentation, unknowingly installing compromised dependencies. The attack spreads through what should be a safe channel.
Sabotage is simpler: delete the entire search index with deleteIndex. Documentation search breaks for millions of users. Support tickets flood in. The project’s reputation takes a hit while scrambling to restore functionality.
Related: n8n RCE Alert: CISA Orders Fix as 24,700 Instances Exposed
Algolia’s Silence, Projects’ Quick Action
Zimmermann emailed Algolia weeks before publication with the full list of 39 exposed keys. The company provided no response. Furthermore, all keys remained active at disclosure time. Hacker News developers criticized this silence more harshly than the vulnerability itself—the expectation being that vendors contact affected customers and force key rotation.
In contrast, some projects responded quickly. SUSE/Rancher acknowledged the report within two days and fully revoked the compromised key. Home Assistant initiated remediation. Moreover, Vue.js, the original discovery case from October, acknowledged the finding and added Zimmermann to their Security Hall of Fame.
The divergent responses highlight accountability. Individual projects took ownership and acted. The platform provider went silent.
Check Your Own DocSearch Config Now
If your documentation site uses DocSearch, audit your frontend config immediately. Open your docs site, view page source (Ctrl+U), and search for “docsearch” or “apiKey”. Copy the API key value and verify its permissions in the Algolia dashboard under API Keys.
If you find an admin key in frontend code: create a new search-only key in the Algolia dashboard, replace the frontend config with the search-only key, and revoke the old admin key completely. Don’t just disable it—revoke it.
Also scan git history. Four of the 39 keys in this disclosure were found in historical commits, not current code. Use TruffleHog or GitHub’s secret scanning to catch credentials that were committed and later removed. Attackers check git history too.
Key Takeaways
- 39 Algolia admin API keys were exposed across major open source documentation sites, discovered through systematic scanning of 15,000 sites
- Self-hosted DocSearch crawlers create a footgun: admin keys intended for backend use get mistakenly embedded in public frontend JavaScript
- Admin keys grant destructive permissions (addObject, deleteObject, deleteIndex) enabling phishing, supply chain attacks, and sabotage through trusted documentation channels
- Algolia received the disclosure weeks before publication but provided no response; affected projects like SUSE/Rancher and Home Assistant responded within days
- Check your own DocSearch config now: view source, verify API key permissions, replace admin keys with search-only keys, and scan git history for historical leaks
Frontend code is public code. Treat it accordingly. Never embed credentials with destructive permissions in client-side JavaScript, no matter how convenient it seems during setup.
