39 Exposed Algolia Admin Keys Found in Open Source Documentation Sites

I recently discovered 39 exposed Algolia admin API keys across open source documentation sites, including major projects like Home Assistant, KEDA, and vcluster. These keys had full administrative permissions that could allow attackers to modify search indexes, delete data, or redirect users to malicious content.

The discovery began with a single exposed key on vuejs.org that I reported last October. After that was resolved, I wondered how widespread this issue might be across the thousands of sites using Algolia's DocSearch service.

How DocSearch Works and Where It Goes Wrong

Algolia's DocSearch provides free search for open source documentation. The service crawls your site, creates an index, and gives you an API key to embed in your frontend. This key should be search-only, but many sites accidentally ship with full admin permissions instead.

The problem stems from how DocSearch is implemented. Some sites use Algolia's hosted crawler service, which provides proper search-only keys. Others run their own crawler and end up using their write or admin key in the frontend configuration.

Discovery Methodology

I used multiple approaches to find exposed keys:

Frontend Scraping: I scraped roughly 15,000 documentation sites, looking for embedded credentials. This caught keys injected at build time that don't exist in any repository. Using regex patterns, I extracted potential Algolia application IDs and API keys from deployed sites.

GitHub Code Search: I searched for keys in documentation framework configurations.

Git History Analysis: I cloned over 500 documentation site repositories and ran TruffleHog to find keys that had been committed and later removed.

Public Config Repository: Algolia maintains a public (now archived) repo called docsearch-configs with configurations for over 3,500 sites, which I used as a target list.

Of the 39 admin keys found, 35 came from frontend scraping alone. The remaining 4 were discovered through git history analysis.

Scale of the Problem

The affected projects represent some of the largest open source initiatives:

• Home Assistant: 85,000+ GitHub stars, millions of active installations
• KEDA: CNCF project used in production Kubernetes clusters
• vcluster: Kubernetes infrastructure with the largest affected search index at over 100,000 records
• SUSE/Rancher: Enterprise Kubernetes management platform

Every single key discovered was active at the time of discovery.

What These Keys Can Do

Nearly all 39 keys shared the same dangerous permission set:

• search
• addObject
• deleteObject
• deleteIndex
• editSettings
• listIndexes
• browse

Some keys had even broader access including analytics, logs, and NLU capabilities.

With these permissions, an attacker could:

• Add, modify, or delete any record in the search index
• Delete the entire index and wipe out site search
• Change index settings and ranking configuration
• Browse and export all indexed content
• Poison search results with malicious links
• Redirect users to phishing pages

Disclosure and Response

SUSE/Rancher acknowledged the report within two days and rotated their key. That key is now fully revoked.

Home Assistant also responded and began remediation, though the original key remains active.

I compiled the full list of affected keys and emailed Algolia directly several weeks ago. As of today, no response has been received and all remaining keys are still active.

The Root Cause

This isn't about 39 individual misconfigurations. It's a systemic issue where sites running their own DocSearch crawler accidentally use admin keys instead of search-only keys. Algolia's own documentation warns against this practice, but it clearly happens at scale.

How to Check Your Own Setup

The fix is straightforward: if you're running DocSearch, check what key is in your frontend configuration and verify it's search-only. You can test this by attempting to perform administrative actions with the key - if it works, you have a problem.

If I found 39 admin keys with a few scripts, the real number is almost certainly much higher. This represents a significant security risk across the open source ecosystem that needs immediate attention from both site maintainers and Algolia.