> "I'm writing to you directly because I want there to be zero confusion about what's happening. Flock has never been hacked. Ever."
They are just lying at this point. If you get involved in advocacy related to flock you will likely hear their reps parrot this. Be ready to combat it with concrete examples like this!
You could just read the article before knee-jerking to state repression.
> November 13, 2025 — Initial disclosure sent to Flock Safety security team
> November 14, 2025 — First follow-up requesting confirmation of receipt
> November 19, 2025 — Second follow-up; Flock Safety finally acknowledges receipt
> January 7, 2026 — Vulnerability remains unpatched (55+ days)
> I am withholding specific technical details to prevent exploitation while the vulnerability remains unpatched. However, its existence more than 55 days after responsible disclosure with no remediation, demonstrates a systemic pattern of credential mismanagement.
Sheer incompetence. I hope (probably in vain) that police departments and local governments become more savvy technical evaluators of fancy tech solutions.
There was a huge fracas re: ShotSpotter in my town, where both the municipality's CIO and auditor (+ their internal research capacity) were sidelined. It took a sad amount of handholding elected officials through ShotSpotter's technical claims for them to shelve a planned deployment.
Who could have guessed that the greedy, opportunistic, evil corporation whose sole intent is to invade our privacy in the name of "security" would be run by incompetents in the security realm?
Does anyone else feel like the LLM-tone of this article makes it difficult to understand what's actually important in it? It's not clear to me if the issue is ongoing (like it says) or that it's been resolved by rotating the API key (like it also says). And that's like, the most basic piece of information the article could have in it.
In fairness to flock, they just hired a CISO and are actively recruiting for a head of product security and privacy as well. So I'm not surprised they're dealing with some of this.
Edit: I'm standing by it. The person they hired for it has a good track record elsewhere. And much as I don't like what Flock is building as a company, at least they're building security in now, even if it wasn't front of mind for them in the past.
There should be no "Fairness to Flock" they're building the panopticon.
Freethinking Americans should do what they can to dismantle this overreach, lobby their city leaders with their poor track record on security and thereby safety.
I'm fine giving the new employees a pass on this, but not the company as a whole. Not building security into a product like this from day one should be a criminal offense.
Has anyone had success getting their city to take down the Flock cameras? Ours just added them maybe a year and a half ago. They popped up in multiple nearby municipalities around the same time, I'm not sure if it was coordinated action or somehow pulled off at the county level.
Although I don’t like Flock, I’m a bit skeptical of the claims in the article. Most screenshots appear to be client-side JavaScript snippets, not API responses from this key.
In the bug bounty community, Google Maps API key leaks are a common false positive, because they are only used for billing purposes and don’t actually control access to any data. The article doesn’t really prove ArcGIS is any different.
I have a controversial question; In the UK, they have blade runners who take down CCTV. I would have expected a more aggressive response in the USA, considering the culture. Is this not happening?
I think the issue with Flock isn't that they're a joke security wise the issue is that they exist. If you want to police somebody you don't have to police everyone. I'd argue watching my location at all times is unreasonable search.
Just a reminder here of this experiment using adversarial techniques to confuse the license plate readers. Just an experiment, may not be legal in all locations, check your local laws.
https://youtu.be/Pp9MwZkHiMQ?si=nas4dOH4vKyAW_5h
With respect to a different public organization with a reach of millions of people, I reported a similar vulnerability where there was an exposed key that services sensitive data. Usually, I don't bother but this time it was bad. I now understand how these things are left exposed for several months to years despite notification. The level of burnout or ignorance that leads to these vulnerabilities elicits harsh backlash where admitting there was ever a problem is worse than exposing a vast amount of people's private data.
I don't care that Flock was involved, I care that there's no consequence for it when any corporation does this. How can this not result in fines or jail time?
Maybe it was on purpose. They might have been forced by the FBI to implement those keys, so they left everything open to be able to track the enforcers also. 53 = 52 states plus gov
I am apprehensive of the surveillance state and it's potential for misuse. However this disclosure content is less than ideal:
- It mixes two separate issues 1) embedded default API key and 2) unauthenticated token minting
- The bulk of the disclosure focuses on enumeration of sensitive data that is implied could have been exposed via the default API key, but what is actually exposed is unclear: "The 50 "portal:app:access:item" privileges reference private item IDs that cannot be inventoried without actively querying each one which I did not do"
- The default API key was for "development" and there is no assertion that live data existed in that environment (though it wouldn't surprise me)
- The default API key was fixed in June 2025, it is only the token minting that has not been.
- The token minting issue is only asserted to "grant access to the geographic mapping of Flock's camera network locations" which would certainly be useful as a source for unethical updates to https://deflock.me/ but obviously not nearly as sensitive.
(And I've always used bullets/lists in my communications, long before AI did this)
39 comments
[ 2.7 ms ] story [ 60.9 ms ] thread> "I'm writing to you directly because I want there to be zero confusion about what's happening. Flock has never been hacked. Ever."
They are just lying at this point. If you get involved in advocacy related to flock you will likely hear their reps parrot this. Be ready to combat it with concrete examples like this!
House guest: but sir, where are all of your belongings?
Flock CEO: oh that, well I leave my front door open at all times. My home has never been broken into
> November 13, 2025 — Initial disclosure sent to Flock Safety security team
> November 14, 2025 — First follow-up requesting confirmation of receipt
> November 19, 2025 — Second follow-up; Flock Safety finally acknowledges receipt
> January 7, 2026 — Vulnerability remains unpatched (55+ days)
> I am withholding specific technical details to prevent exploitation while the vulnerability remains unpatched. However, its existence more than 55 days after responsible disclosure with no remediation, demonstrates a systemic pattern of credential mismanagement.
There was a huge fracas re: ShotSpotter in my town, where both the municipality's CIO and auditor (+ their internal research capacity) were sidelined. It took a sad amount of handholding elected officials through ShotSpotter's technical claims for them to shelve a planned deployment.
https://news.ycombinator.com/item?id=46355548
So annoying.
That being said I also don't wonder if there is a point where we're just crowdsourcing the police state?
Edit: I'm standing by it. The person they hired for it has a good track record elsewhere. And much as I don't like what Flock is building as a company, at least they're building security in now, even if it wasn't front of mind for them in the past.
He's got his work cut out for him though.
This phrasing implies that the "building security in now" part improves (or decreases the awfulness of) what you don't like.
If what you don't like = bulk, systemic surveillance (of people not suspected of a crime) - how does fixing broke security make that less awful?
In the bug bounty community, Google Maps API key leaks are a common false positive, because they are only used for billing purposes and don’t actually control access to any data. The article doesn’t really prove ArcGIS is any different.
- It mixes two separate issues 1) embedded default API key and 2) unauthenticated token minting
- The bulk of the disclosure focuses on enumeration of sensitive data that is implied could have been exposed via the default API key, but what is actually exposed is unclear: "The 50 "portal:app:access:item" privileges reference private item IDs that cannot be inventoried without actively querying each one which I did not do"
- The default API key was for "development" and there is no assertion that live data existed in that environment (though it wouldn't surprise me)
- The default API key was fixed in June 2025, it is only the token minting that has not been.
- The token minting issue is only asserted to "grant access to the geographic mapping of Flock's camera network locations" which would certainly be useful as a source for unethical updates to https://deflock.me/ but obviously not nearly as sensitive.
(And I've always used bullets/lists in my communications, long before AI did this)