[HN Gopher] I found 39 Algolia admin keys exposed across open so...
___________________________________________________________________
I found 39 Algolia admin keys exposed across open source
documentation sites
Author : kernelrocks
Score : 152 points
Date : 2026-03-13 22:52 UTC (1 days ago)
(HTM) web link (benzimmermann.dev)
(TXT) w3m dump (benzimmermann.dev)
| toomuchtodo wrote:
| Great write up. Reminder that if you commit these to a Github
| Gist and the provider partners with GitHub for secrets scanning,
| they'll rapidly be invalidated.
| pwdisswordfishy wrote:
| That's just a tautology.
|
| "If the secrets issuer partners with X-corp for secret scanning
| so that secrets get invalidated when you X them, then when you
| X them the secrets will be invalidated".
|
| The above is a true statement for all X.
| nightpool wrote:
| ? Yes? Toomuchtodo is reminding the author (and other
| commenters), that github gists are one way to make sure
| secrets are secured / remediated before making a public post
| like this. Maybe not the most responsible whitehat action,
| but I can see it being useful in some cases where outreach is
| impractical / has failed.
|
| Unfortunately, it doesn't look like Algolia has implemented
| this
| TurdF3rguson wrote:
| I'm not following this at all. It seems like OP is saying
| if you share a secret in your (private?) gist and give
| Algolia permission to read the gist, they will invalidate
| it. But why would the secret be in a gist and not a repo?
| Also if you're aware enough to add that partner it seems
| you're aware to not do dumb things like that in the first
| place.
| richbell wrote:
| If you find an exposed token in the wild, for a service
| supported by GitHub Secret Scanning, uploading it to a
| Gist will either immediately revoke it or notify the
| owner.
| TurdF3rguson wrote:
| Ok I see, so any public gist with an algolia key in it
| will get invalidated? And it would have to follow some
| pattern like ALGOLIA_KEY=xxx ?
| wat10000 wrote:
| English is not formal logic.
|
| In formal logic, that statement is true whether X is GitHub,
| or Lockheed-Martin, Safeway, or the local hardware store.
|
| In English, the statement serves to inform (or remind) you
| that GitHub _has_ a secret scanning program that many
| providers actually do partner with.
| pwdisswordfishy wrote:
| Yes, and in the real world where Grice's Maxim of Relevance
| is in force, then when the secrets issuer that is the
| subject of the discussion isn't one of those partners, then
| an informative "reminder" that GitHub "has a secret
| scanning program" with a bunch of other partners is _not_
| actually informative. It 's as superfluous and unhelpful as
| calling to let someone know you're not interested in the
| item they've posted for sale on Craiglist
| (<https://www.youtube.com/watch?v=xWG3jKzKcm8>).
| richbell wrote:
| How is reminding people that they can safely revoke
| exposed API keys not informative? Why are you being so
| combative?
| wat10000 wrote:
| It's more useful than telling someone that their
| statement is a tautology in formal logic.
| pwdisswordfishy wrote:
| No it's not.
| wat10000 wrote:
| Yes it is. Reminding somebody of this feature is useful
| to somebody, even if it's not completely relevant to the
| topic being discussed. Calling out a supposed tautology
| is the opposite of useful: it helps nobody and just
| clutters things up.
| fix4fun wrote:
| Interesting how many people already are playing with these API
| keys ? ;)
| stickynotememo wrote:
| So why hasn't the HomeAssistant docs page been nuked yet?
| netsharc wrote:
| Man, talk about unnecessary graphs... ok graph 2 is maybe
| tolerable, although it's showing the popularity of the projects,
| not a metric of how many errors/vulnerabilities found in those
| projects.
|
| I'm not a newspaper editor, but I think if this was an article
| for one, they'd also say the graphs are unnecessary. It smells of
| "I need some visual stuff to make this text interesting"...
| throwaway5465 wrote:
| It's Friday night / Saturday morning. Who wants to be reading
| text?
|
| Especially on night mode themes.
|
| Besides, can we read anymore? In the age of 'GPT summarise it
| me' attention spans and glib commentary not about the content
| of the article being all many people have to add, perhaps
| liberal application of visualisations adds digestive value.
| binarymax wrote:
| Dude there's only three graphs in there. Do they really bother
| you that much? The third may be a bit unnecessary but I think
| the visuals add to the post.
| TechSquidTV wrote:
| I have been developing an OpenClaw-like agent that automates
| exactly this type of attack.
| _pdp_ wrote:
| Why? This is just regex search and there are plenty of tools
| that do this perfectly fine.
| system2 wrote:
| None of those proven tools would make a man feel like a
| wannabe Mr. Robot.
| emotiveengine wrote:
| Have to agree with _pdp_ on this one. I just don't see the
| need for an LLM agent to do a recursive grep for API keys in
| public repos.
|
| Not saying people shouldn't build these tools, but the use
| case is lost on me.
|
| It feels like the industry is in this weird phase of trying
| to replace 30-year-old, perfectly optimized shell utilities
| with multi-shot agent workflows that literally cost money to
| run. A basic Python script with a regex matcher and the
| GitHub API will find these keys faster, cheaper, and more
| reliably.
| jgalt212 wrote:
| because the poster works for Accenture.
|
| https://timesofindia.indiatimes.com/technology/tech-
| news/acc...
| hrmtst93837 wrote:
| Automating these sweeps works fine until you need to escalate
| beyond public misconfig and start hitting rate limits or WAF
| traps, at that point, blending in gets harder than it looks. If
| you focus on fast key discovery, expect a lot of false
| positives unless you build context awareness for the apps those
| keys unlock, otherwise you just end up chasing useless tokens
| all day.
| tcbrah wrote:
| the wildest part is algolia just not responding. you email them
| saying "hey 39 of your customers have admin keys in their
| frontend" and they ghost you? thats way worse than the keys
| themselves imo. like the whole point of docsearch is they manage
| the crawling FOR you, but then the "run your own crawler" docs
| basically hand you a footgun with zero guardrails. they could
| just... not issue admin-scoped keys through that flow
| gregoriol wrote:
| Why contact Algolia when it is the users' responsibility to
| handle their keys? Contact all the users.
| Kwpolska wrote:
| If this happens so often, perhaps Algolia should improve
| their stuff to prevent this? For example, by implementing a
| dedicated search endpoint that doesn't accept normal API
| keys, but only dedicated read-only keys.
| interstice wrote:
| It is the users responsibility to operate foot guns
| responsibly.
| jgalt212 wrote:
| because if it's easy to dangerously use one's product that
| reflect poorly on the product. Algolia should help its
| clients from making silly mistakes.
| pwdisswordfishy wrote:
| The comment you're responding to is output of an LLM.
| mmooss wrote:
| Note all the very similar grey comments at the bottom of
| the page.
| osos2 wrote:
| https://www.algolia.com/security.txt 404
| kay_o wrote:
| still 404 but the standard is .well-known/security.txt
| trrra wrote:
| Is this aloglia's (or any provider) responsability or each
| individual integration ?
| pmdr wrote:
| Twenty years ago every PHP website had search. We forgot how to
| do it.
| omnimus wrote:
| To be fair, the search was thanks to databases and it was
| usually not very good (it takes work to set correctly).
| gus_massa wrote:
| I remember that time, it was usually better to go to google and
| use "site:".
| NicuCalcea wrote:
| I still do that for almost everything.
| Etheryte wrote:
| Having a search and having a functional search are two very
| different things though. To this day, the search on many sites
| is so bad that it's actually better to use a search engine and
| scope by site rather than use the site search.
| dawnerd wrote:
| Algolia really needs to make using the admin key less easy. I've
| almost copied it before when setting up a frontend. It should be
| tucked away and require auth to view.
| Dazzler5648 wrote:
| Thanks for this. I was maybe using one of these keys until this
| morning. When I logged in at dashboard.algolia.com and went to
| Settings -> API Keys, I found that none of the keys (Search,
| Analytics, Usage, Monitoring) matched the key I was using on a
| frontend. I made a decent attempt looking for that old key
| anywhere in their admin panels and could not find it. _poof!_
|
| So perhaps at some point, they were only giving admin keys
| (because I don't remember there being a choice; and I would think
| given the choice I'd make the right one) and when called out (or
| sometime prior) realized the problem and made a new Settings ->
| API Keys page. Currently on the page the first one listed is the
| Search Key, with the subtext "This is the public API key which
| can be safely used in your frontend code. This key is usable for
| search queries and it's also able to list the indices you've got
| access to."
| profer602 wrote:
| This highlights a systemic problem: developers often prioritize
| speed of integration over security hygiene, especially when
| dealing with third-party services. The tradeoff is acceptable
| until it isn't. We need better tooling to automatically detect
| and flag these types of exposures _before_ they make it to
| production.
| ErneX wrote:
| LLM.
___________________________________________________________________
(page generated 2026-03-14 23:01 UTC)