I Found 39 Algolia Admin Keys Exposed Across Open Source Documentation Sites

Last October I reported an exposed Algolia admin API key on vuejs.org. The key had full permissions: addObject, deleteObject, deleteIndex, editSettings, the works. Vue acknowledged it, added me to their Security Hall of Fame , and rotated the key.

That should have been the end of it. But it got me thinking: if Vue.js had this problem, how many other DocSearch sites do too?

Algolia's DocSearch is a free service for open source docs. They crawl your site, index it, and give you an API key to embed in your frontend. That key is supposed to be -only, but some ship with full admin permissions.

Most keys came from frontend scraping. Algolia maintains a public (now archived) repo called docsearch-configs with a config for every site in the DocSearch program, over 3,500 of them. I used that as a starting target list and scraped roughly 15,000 documentation sites for embedded credentials. This catches keys that don't exist in any repo because they're injected at build time and only appear in the deployed site:

On top of that I ran GitHub code to find keys in doc framework configs, then cloned and ran TruffleHog on 500+ documentation site repos to catch keys that had been committed and later removed.

35 of the 39 admin keys came from frontend scraping alone. The remaining 4 were found through git history. Every single one was active at the time of discovery.

The affected projects include some massive open source projects:

Assistant alone has 85,000 GitHub stars and millions of active installations. KEDA is a CNCF project used in production Kubernetes clusters. vcluster, also Kubernetes infrastructure, had the largest index of any affected site at over 100,000 records.

Nearly all 39 keys the same permission set: , addObject, deleteObject, deleteIndex, editSettings, listIndexes, and browse. A few have even broader access including analytics, logs, and NLU capabilities.

In practical terms, anyone with one of these keys can:

Someone could poison a project's results with malicious links, redirect users to phishing pages, or just nuke the entire index and wipe out for the site completely.

SUSE/Rancher acknowledged the report within two days and rotated the key. That key is now fully revoked. Assistant also responded and began remediation, though the original key remains active.

I compiled the full list of affected keys and emailed Algolia directly a few weeks ago. No response. As of today, all remaining keys are still active.

This isn't really 39 individual misconfigurations. Algolia's DocSearch program provides -only keys, but many sites run their own crawler and end up using their write or admin key in the frontend config instead. Algolia's own docs warn against this, but it clearly happens at scale.

The fix is straightforward: if you're running DocSearch, check what key is in your frontend config and make sure it's -only. If I found 39 admin keys with a few scripts, the real number is almost certainly higher.