Ben Zimmermann was poking around vuejs.org last October when he found something that should not have been there: an Algolia API key with full admin permissions sitting in the frontend JavaScript. Not a search-only key — the real deal. addObject, deleteObject, deleteIndex, editSettings. Everything you would need to completely wreck a project's search infrastructure in about forty-five seconds.
Vue acknowledged the report, added Zimmermann to their Security Hall of Fame, rotated the key, and presumably assumed that was the end of it. But Zimmermann had a different question: if one of the most well-maintained open source projects on the planet shipped an admin key in their frontend, how many others did too?
The answer, published yesterday on his blog, is 39. Thirty-nine Algolia admin API keys, all fully active at the time of discovery, exposed across documentation sites for projects including Home Assistant (85,000 GitHub stars), KEDA (a CNCF project used in production Kubernetes clusters), and vcluster (which had the largest search index of any affected site at over 100,000 records).
How DocSearch Creates This Problem
To understand why this keeps happening, you need to understand how Algolia DocSearch works. It is a free search service for open source documentation sites. Algolia crawls your docs, indexes the content, and gives you an API key to embed in your frontend so visitors can search. That key is supposed to be search-only — a restricted key that can query the index but cannot modify it.
The problem is that some projects ship with keys that have far more permissions than they should. This is not an Algolia bug per se — it is a configuration mistake on the project side. But it is a configuration mistake that Algolia's onboarding process makes disturbingly easy to make, and one that affects some of the most critical infrastructure projects in the open source ecosystem.
Derek, who manages our infrastructure team and has spent the last eight months building a DocSearch integration for our internal docs (he is extremely thorough to the point where it occasionally becomes a problem), immediately checked our own key after reading Zimmermann's post. "We are fine," he said, looking visibly relieved. "But only because I read the Algolia docs three times and accidentally set up the restricted key correctly." The word "accidentally" in that sentence should concern everyone.
The Scale of Zimmermann's Research
What makes this disclosure particularly impressive is the methodology. Zimmermann did not just grep a few repos. He started with Algolia's own public (now archived) docsearch-configs repository, which contains a configuration file for every site in the DocSearch program — over 3,500 of them. He used that as a target list and scraped approximately 15,000 documentation sites for embedded credentials.
His scraping approach was straightforward but effective. Two regex patterns — one for Algolia application IDs (10-character uppercase alphanumeric strings) and one for API keys (32-character lowercase hex strings) — applied against the JavaScript source of every documentation site he could find. This catches keys that never appear in any source code repository because they are injected at build time and only exist in the deployed frontend.
On top of that, he ran GitHub code search across documentation framework configurations and then cloned and ran TruffleHog on over 500 documentation site repositories to find keys that had been committed to git and later removed (but remained in the git history, as committed secrets always do).
35 of the 39 admin keys came from frontend scraping alone. The remaining 4 were found through git history analysis. Sandra from our security team called this "depressingly predictable," which tracks with her general outlook on the state of secrets management in open source.
What Someone Could Actually Do With These Keys
Nearly all 39 keys share the same permission set: search, addObject, deleteObject, deleteIndex, editSettings, listIndexes, and browse. A few have even broader access including analytics, logs, and natural language understanding capabilities.
In practical terms, anyone with one of these keys could:
Poison search results with malicious links. Add records to the search index that redirect users to phishing pages or malware downloads. When someone searches the project's documentation for "installation guide," they get a link that looks legitimate but leads to a compromised download. This is especially dangerous for projects like Home Assistant, where the installation process involves running scripts with elevated privileges on a home network.
Delete the entire search index. One API call. The project's documentation search stops working entirely until someone notices, figures out what happened, and rebuilds the index from scratch. For a project like KEDA, which Kubernetes operators rely on for autoscaling documentation during production incidents, search downtime at the wrong moment could cascade into real operational problems.
Export all indexed content. The browse permission allows exporting every record in the index. For most documentation sites this is not sensitive information (it is public docs, after all), but some projects index internal pages, draft documentation, or changelogs with unreleased feature details.
Tom, who has spent 14 years in infrastructure and has a visceral reaction to any sentence containing the words "exposed" and "API key," estimated that exploiting the Home Assistant key alone could potentially affect millions of installations. "85,000 stars means millions of users," he said, pulling up the Home Assistant analytics dashboard. "People run this on their home networks with access to their lights, locks, cameras, thermostats. A poisoned search result leading to a malicious integration plugin is a nightmare scenario."
The Disclosure Process
Zimmermann responsibly disclosed all 39 keys to the affected projects. The response, predictably, was mixed. Some projects responded within hours. SUSE/Rancher acknowledged the issue and rotated their key quickly. Others took weeks. A few still have not responded at all, though Zimmermann waited the standard 90-day disclosure window before publishing.
Algolia itself was notified about the systemic nature of the problem. Whether they will update their onboarding process or add warnings when keys with broad permissions are used in frontend contexts remains to be seen. The docsearch-configs repository has been archived, which may be coincidental or may be a response to it being used as a target list for exactly this kind of research.
What You Should Do Right Now
If your project uses Algolia DocSearch — or any search service that requires an API key in frontend code — here is the immediate action list:
1. Check your key permissions. Log into the Algolia dashboard, find the API key you are shipping in your frontend, and verify that it only has the search permission. If it has addObject, deleteObject, deleteIndex, or editSettings, rotate it immediately and create a new search-only key.
2. Check your git history. Even if your current deployed key is correct, your repo might contain a commit from three years ago where someone pushed an admin key. Run TruffleHog or GitLeaks against your repository. Derek ran this against 12 of our client repos after reading Zimmermann's post and found two historical secrets that had been "removed" but were still sitting in git history. One of them was still active.
3. Set up key rotation alerts. Algolia supports webhook notifications for key usage anomalies. Enable them. If someone is using your search key to do things a search key should not be able to do, you want to know about it before your index gets nuked.
4. Consider rate limiting and IP restrictions. Algolia allows you to restrict API keys by IP range and set rate limits. For a documentation site search key, there is no reason a single IP should be making more than a few hundred search queries per minute. Set a reasonable limit and flag anything over it.
Zimmermann's research is a reminder that the most dangerous security problems are not exotic zero-days — they are mundane misconfigurations that persist because nobody thinks to check. Thirty-nine admin keys, sitting in plain text in frontend JavaScript, on some of the most popular open source documentation sites on the internet. For months. Sometimes years.
Greg from our DevOps team, who has a framed printout of the OWASP Top Ten above his desk (he thinks it is ironic; it is not), summed it up perfectly: "The frontend is not a secret-keeping service. It never was. But every six months someone discovers this for the first time and we all get to be surprised again."
Related Reading
More on cloud security: cloud attackers are getting faster than ever and FortiGate firewalls are being actively exploited.
Related Reading
If you found this useful, check out these related articles:
