| ▲ | I found 39 Algolia admin keys exposed across open source documentation sites(benzimmermann.dev) |
| 132 points by kernelrocks 13 hours ago | 30 comments |
| |
|
| ▲ | tcbrah 9 hours ago | parent | next [-] |
| 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 5 hours ago | parent [-] | | Why contact Algolia when it is the users' responsibility to handle their keys? Contact all the users. | | |
| ▲ | interstice 44 minutes ago | parent | next [-] | | It is the users responsibility to operate foot guns responsibly. | |
| ▲ | Kwpolska 2 hours ago | parent | prev [-] | | 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. |
|
|
|
| ▲ | pmdr 3 hours ago | parent | prev | next [-] |
| Twenty years ago every PHP website had search. We forgot how to do it. |
| |
| ▲ | gus_massa 2 minutes ago | parent | next [-] | | I remember that time, it was usually better to to to google and use "site:". | |
| ▲ | omnimus 3 hours ago | parent | prev [-] | | To be fair, the search was thanks to databases and it was usually not very good (it takes work to set correctly). |
|
|
| ▲ | netsharc 13 hours ago | parent | prev | next [-] |
| 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"... |
| |
| ▲ | binarymax 12 hours ago | parent | next [-] | | 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. | |
| ▲ | throwaway5465 12 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | osos2 5 hours ago | parent | prev | next [-] |
| https://www.algolia.com/security.txt 404 |
| |
| ▲ | kay_o 2 hours ago | parent [-] | | still 404 but the standard is .well-known/security.txt |
|
|
| ▲ | stickynotememo 13 hours ago | parent | prev | next [-] |
| So why hasn't the HomeAssistant docs page been nuked yet? |
|
| ▲ | trrra 5 hours ago | parent | prev | next [-] |
| Is this aloglia's (or any provider) responsability or each individual integration ? |
|
| ▲ | TechSquidTV 11 hours ago | parent | prev | next [-] |
| I have been developing an OpenClaw-like agent that automates exactly this type of attack. |
| |
| ▲ | _pdp_ 11 hours ago | parent | next [-] | | Why? This is just regex search and there are plenty of tools that do this perfectly fine. | | |
| ▲ | emotiveengine 8 hours ago | parent | next [-] | | 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. | |
| ▲ | system2 10 hours ago | parent | prev [-] | | None of those proven tools would make a man feel like a wannabe Mr. Robot. |
| |
| ▲ | hrmtst93837 5 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | fix4fun 13 hours ago | parent | prev | next [-] |
| Interesting how many people already are playing with these API keys ? ;) |
|
| ▲ | toomuchtodo 13 hours ago | parent | prev [-] |
| 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 13 hours ago | parent [-] | | 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 13 hours ago | parent | next [-] | | ? 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 12 hours ago | parent [-] | | 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 12 hours ago | parent [-] | | 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 10 hours ago | parent [-] | | 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 12 hours ago | parent | prev [-] | | 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 12 hours ago | parent [-] | | 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>). | | |
| ▲ | wat10000 11 hours ago | parent | next [-] | | It's more useful than telling someone that their statement is a tautology in formal logic. | |
| ▲ | richbell 12 hours ago | parent | prev [-] | | How is reminding people that they can safely revoke exposed API keys not informative? Why are you being so combative? |
|
|
|
|
