我发现了39个Algolia管理密钥暴露在开源文档站点上。

我发现了39个Algolia管理密钥暴露在开源文档站点上。
I found 39 Algolia admin keys exposed across open source documentation sites

原始链接: https://benzimmermann.dev/blog/algolia-docsearch-admin-keys

一名安全研究人员在使用DocSearch（一项免费搜索服务）时，在大量开源文档站点中发现了39个暴露的Algolia管理API密钥。这些密钥原本仅用于搜索，却授予了完全控制权——包括修改、删除甚至清除整个搜索索引的能力，从而带来了恶意链接注入和完全搜索中断等风险。该研究人员通过对超过15,000个站点的前端抓取、GitHub代码搜索以及已提交代码历史的分析，发现了这些密钥。值得注意的是，35个密钥*仅*通过抓取已部署的前端代码发现。受影响的项目包括Home Assistant、KEDA和vcluster等知名项目。一些项目，如SUSE/Rancher，已经迅速解决了这个问题，而另一些项目，包括Home Assistant，尚未撤销受损的密钥。Algolia已被直接通知，但尚未回应。根本原因在于项目在前端DocSearch配置中无意使用了管理密钥，尽管Algolia已经发布了警告。该研究人员强调，可能存在更多暴露的密钥，并敦促项目验证他们是否在使用仅搜索的API密钥。

## Algolia Admin Keys Exposed: A Summary A security researcher discovered 39 Algolia admin keys publicly exposed in open-source documentation. This sparked a Hacker News discussion highlighting the recurring issue of improperly secured API keys and the challenges of implementing effective search functionality. Many commenters noted a historical reliance on basic, often inadequate, search implementations, leading to a preference for using search engines like Google with site-specific queries. Concerns were raised about Algolia’s response (or lack thereof) to the issue, with some criticizing their documentation for inadvertently facilitating the exposure through easily accessible admin keys. The discussion also touched on responsible disclosure, the balance between helpful criticism and tone, and the effectiveness of automated tools for detecting exposed keys. Some debated the necessity of complex tools when simpler methods like regex searches suffice, while others highlighted the value of visual aids in security write-ups. Finally, users pointed out GitHub’s secret scanning feature as a potential mitigation strategy for exposed keys.

原文

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?

Turns out, a lot.

How Algolia DocSearch works

Algolia's DocSearch is a free search 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 search-only, but some ship with full admin permissions.

What I found

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:

APP_RE = re.compile(r'["\']([A-Z0-9]{10})["\']')
KEY_RE = re.compile(r'["\']([\da-f]{32})["\']')

def extract(text, app_ids, api_keys):
    if not ALGOLIA_RE.search(text):
        return
    for a in APP_RE.findall(text):
        if valid_app(a):
            app_ids.add(a)
    api_keys.update(KEY_RE.findall(text))

On top of that I ran GitHub code search 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.

Discovery Method Breakdown

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:

Top Affected Projects by GitHub Stars

Home 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 search index of any affected site at over 100,000 records.

What these keys can do

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 NLU capabilities.

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

Add, modify, or delete any record in the search index
Delete the entire index
Change index settings and ranking configuration
Browse and export all indexed content

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

Disclosure

SUSE/Rancher acknowledged the report within two days and rotated the 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 a few weeks ago. No response. As of today, all remaining keys are still active.

The root cause

This isn't really about 39 individual misconfigurations. Algolia's DocSearch program provides search-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 search-only. If I found 39 admin keys with a few scripts, the real number is almost certainly higher.