A hacked Flock camera shows the gap between what the vendor says it collects and what its firmware does

Four items on the list, one detector that is not

On 1 September 2026 Flock Safety told its private-sector customers exactly what its licence plate readers collect: "license plate text, date and time, camera location, and basic vehicle attributes such as make, model, and color". That is the whole list. Fifteen days later, WIRED and 404 Media published a joint analysis of the software and data copied out of one of those cameras. The code on the device runs a detector for people, and when it finds one it records where the person sits in the frame and how confident it is.

The same camera's logs covered about 21 days of activity across several periods. In that time it photographed roughly 50,200 vehicles and generated about 1.6 million images. Divide one by the other and the camera took about 32 images for every vehicle that passed; the reporters describe a typical vehicle as producing about 28, with some producing more than 100. It also held 27,321 short video clips on its own storage, recorded to a disk that was 85% full, in a volume that was encrypted but whose key file sat on the same partition.

Now the limits, because they matter as much as the finding. This is one camera and one firmware image, taken from a pole by an activist collective, and nobody outside that group has established how it was acquired or handled before publication. The analysis found no face recognition in use. The camera does not appear to read plates or identify make, model and colour itself; that seems to happen on Flock's servers. People were detected in 11 of the 27,321 clips, all of them motorcyclists, which says more about where the camera pointed than about what it can do. And nothing published so far establishes whether person detections are sent to Flock, kept there, or made searchable.

What the evidence does establish is narrower and, for anyone buying camera analytics, more useful: a vendor's description of its product and the behaviour of its firmware are two different documents, and only one of them is usually in the contract. This briefing sets out what was found, what Flock has said, how the UK regulates the same technology, and what a UK buyer should demand before a camera goes up.

Who did the work, and what they examined

Three separate efforts feed this story, and they should not be blurred together.

The acquisition. A collective calling itself stegan0gram pulled a Flock camera down from above a road, copied its storage and handed the files to 404 Media and to Distributed Denial of Secrets, the leak archive, which published the partition images on 16 September. One of the hackers told the reporters: "Why just destroy them when we can reverse engineer them and find the secrets of those spying on us?" The hackers say they will publish details of how they obtained the software. As of 21 September we could find no such write-up, so everything below rests on the analyses of the files, not on the collective's own account. Flock's response was that "the unauthorized removal and tampering of a Flock camera is illegal."

The analysis. Joseph Cox and Dhruv Mehrotra ran the joint WIRED and 404 Media investigation, which Ars Technica republished on 17 September and Bruce Schneier summarised on 21 September. WIRED extracted the detection models and ran them against test images and the recovered footage. The same day the files were released, the journalist and developer Micah Lee published his own analysis of the dataset in his newsletter; we cite its findings but do not link it, because it reproduces credential values from the device.

The verification. Jon Gaines, the independent researcher who publishes as GainSec, spent 2025 testing Flock hardware he had bought on the second-hand market, in a lab, and reported what he found to Flock. His November 2025 white paper documents 51 findings across Flock's Raven gunshot detector, its Falcon and Sparrow plate readers and its Picard or Bravo compute box, with 22 carrying CVE identifiers at the time. On 17 September 2026 he published a remediation verification that checks those earlier findings against the stegan0gram image. He states plainly that he did not take part in acquiring the camera and that its acquisition, custody and deployment state were not independently established.

The hardware and firmware. Gaines identifies the image as a Falcon or Sparrow plate reader, 54 partition images totalling 28.55 GiB. WIRED describes a processor similar to those in midrange smartphones running about 20 Flock-built apps that handle motion detection, capture, object classification, upload and remote updates. The system partition reports Android 8.1.0 with a security patch level of 5 June 2018 and a build date of 5 June 2025, according to Lee's reading of the build properties, and Gaines records the same Android version and build timestamp with the main Flock app suite at version 6.35.47. Lee reports a Linux 3.18.71 kernel. Google's security updates for Android 8.1 ended in 2021; the patch level is seven years older than the build that shipped it.

What the camera actually captures and infers

According to the code WIRED examined, the sequence is this. Motion in the frame triggers a rapid burst of photos at different exposures, so that both the plate and the wider scene come out. The software scans those images with on-device models, selects and crops useful frames, and sends them with other data to Flock over the cellular network. The plate read, and the vehicle's make, model and colour, do not appear to be produced on the camera. The reporters infer they are produced on Flock's servers, which is consistent with Flock's own description of its product, but the cloud side was not examined.

Three findings go beyond what Flock's public descriptions say.

People. The on-device software "explicitly detects people" alongside vehicles, plates and bicycles, logging each person's position in the image and a confidence score. WIRED's test of the extracted models detected people readily, including in a selfie of a reporter. Across the 27,321 clips on the camera, the models found people in 11, all on motorcycles; the camera looked down on a roadway where pedestrians were unlikely to appear.

Video, not only stills. Flock's May 2025 security advisory describes its plate cameras as recording "still images of vehicles when triggered by motion". The recovered device also held 27,321 MP4 clips, each one to two seconds long at 1,024 by 768 pixels without audio, separate from the higher-resolution stills. Gaines independently counted and hashed the same 27,321 MP4 records.

Things that are not plates. The plate detector sometimes cropped bumper stickers, dealership frames and other graphics as if they were plates, and in one clip cropped an American flag patch on a motorcyclist's saddlebag. That matters for accuracy and for data minimisation: a crop of a sticker is a record about a person's views, captured by a system that is only supposed to be reading a registration.

On face recognition the evidence supports Flock. WIRED and 404 Media found no face recognition capability beyond what Android includes by default, and those components did not appear to be enabled or in use. Flock's product page says face recognition is "not included" and "not planned". The finding is not that Flock lied about faces. It is that "not facial recognition" and "does not look at people" are different claims, and only the first has been made.

Flock's public statements against the firmware evidence. Sources: Flock blog posts of 5 May 2025 and 1 September 2026, Flock LPR product page, WIRED and 404 Media joint analysis, Gaines remediation verification (17 September 2026).

Flock has said	The firmware image shows	What it does not establish
LPR collects plate text, time, location and basic vehicle attributes	An on-device detector for people, with position and confidence logged	Whether person detections are uploaded, stored or searchable
LPR is not facial recognition	No face recognition found beyond Android defaults, not in use	Anything about Flock's cloud or other products
Plate cameras record still images when triggered	27,321 MP4 clips of one to two seconds on the device	Whether clips are uploaded routinely or only on request
On-device data kept for a very limited time after upload	Evidence deletion defaults to 30 days, with an 85% disk fallback	The retention setting actually configured on this camera
Flock has described on-device encryption (as reported by WIRED)	Media volume encrypted, key stored on the same partition	That every deployed camera is built the same way

Where the data goes, and how long it stays

Off the device. Frames and metadata leave over cellular data to Flock's backend. Lee found that the camera obtains its cloud credentials by calling a Flock provisioning service with an API key that is hard-coded into a shared library bundled in 19 of the 20 Flock apps, and that the service returns client credentials issued through Auth0, the Okta-owned identity service. The camera then stores those credentials in plaintext on its persist partition, which is unencrypted and designed to survive a factory reset. Lee's further inference, that the same key could request credentials for any Flock camera given its hardware address, is his own and he says he did not test it. Gaines's paper separately recorded a Datadog API token in earlier firmware, and his September review classes the version in this image as a retained historical token whose current impact is unconfirmed.

In the cloud. Flock's May 2025 advisory says images and metadata are sent over TLS and stored encrypted in the cloud for 30 days. On 13 August 2026 Flock announced a new seven-day default retention for new law enforcement customers; its 1 September note says private-sector customers keep whatever retention terms their accounts already have. WIRED also reports that records from one Georgia city's Flock cameras were searchable by more than 2,000 agencies through Flock's national network. None of the cloud-side behaviour was tested by anyone in this story.

On the device. Here the vendor's words and the code diverge most clearly. In May 2025 Flock said someone who got physical access to a camera "would still not be able to gain access to footage, as the data is only stored for a very limited time duration on the device following its transmission to the cloud." Gaines's review of this image finds a scheduled deletion task whose default removes evidence sessions older than 30 days, then applies a separate clean-up when disk use passes 85%. The recovered clips spanned about 6.3 days and the filesystem was 85.0% full, which is consistent with the disk-pressure rule doing the work. WIRED counted more than 27,000 "no space left on device" errors in the logs. Gaines is careful: the effective runtime setting is not in the files, so he does not claim any deployment breaches a retention policy. But a 30-day default and nearly a week of video on a pole-mounted device is not what "a very limited time" leads a buyer to picture.

There is a correction in Flock's favour too. Gaines's 2025 paper said on-device retention relied solely on disk capacity. His September review found age-based deletion in older app versions as well, and records that this may correct his original finding rather than show a later fix. It is marked closed.

The security findings, at the level a defender needs

Encryption with the key beside the lock. Much of the most sensitive storage stayed encrypted and inaccessible, WIRED reports. But the media volume holding the clips and logs could be opened because the file containing its key sat on the same partition. Schneier's verdict was that this is "pretty bad security engineering." Gaines's review scores this area as partially remediated: userdata and adopted media are now encrypted at rest, but the media can still be recovered offline from the image.

An operating system out of support. Android 8.1 stopped receiving Google security fixes in 2021, and this build carries a June 2018 patch level. Lee lists publicly known Android and Qualcomm vulnerabilities that the patch level predates, while noting he could not test them on a live unit. Gaines rated the end-of-life operating system finding medium in 2025 and marks it unremediated in this image.

Earlier findings, mostly still present. Gaines's review walks through 29 entries from his earlier work. His count: 14 unremediated, 4 likely unremediated, 7 unconfirmed, 3 partially remediated and 1 closed. He stresses these are report entries that overlap and chain, not 29 separate vulnerabilities. Among those he marks unremediated are the root shell, the unlocked bootloader, unauthenticated Android Debug Bridge access and sideloading, and the unauthenticated administrative interface in the camera's Collins service, which NVD records as CVE-2025-59403 with a 9.8 critical score assigned by CISA's ADP, not by Flock. The hard-coded Auth0 secret he reported in 2025 has been removed and replaced; the replacement credentials, he says, are still stored in plaintext.

Gaines draws one further point that UK buyers should take seriously. The camera's services listened on every network interface, and public reachability appears to have been limited at the mobile carrier's network rather than by authentication in the service itself. He did not test the carrier path and does not claim an ordinary subscriber could reach these cameras. His point is that carrier-grade network address translation is a routing arrangement, not an access control, and that it places the camera's security in the hands of a telecoms network that state actors have been shown to compromise.

Disclosure, and what Flock has said

The stegan0gram material did not come through any disclosure process. Asked about the encryption key, Flock told WIRED that it "maintains a public Vulnerability Disclosure Policy", that it "received no report through that process", and that on the limited information provided it did not "have enough detail to assess the claims". It invited the individuals to submit technical findings. That is a fair procedural point about this dataset. It sits less comfortably next to Gaines's record, which went through disclosure from the start and which Flock has had since February 2025.

Disclosure and response timeline. Sources: Gaines white paper timeline (v1.2, November 2025), Gaines remediation verification (17 September 2026), Flock blog posts, WIRED and 404 Media.

Date	Event
8 Feb 2025	Gaines first contacts Flock; Flock responds on 10 February
7 Mar 2025	Flock requests CVE numbers for 10 of the reported issues
5 May 2025	Flock advisory: issues "not material", no need yet to remediate deployed devices, fixes via over-the-air updates and new factory settings from Q2 2025
5 Jun 2025	Build date of the firmware later taken from the camera, patch level June 2018
27 Jun 2025	First batch of CVEs published
5 Nov 2025	Gaines publishes the white paper: 51 findings, 22 with CVEs
6 Nov 2025	Flock response: no customer action required
Feb 2026	Flock retains Bishop Fox for continuous adversarial testing
13 Aug 2026	Flock announces a disclosure programme and promises a Bishop Fox summary in September
16 Sep 2026	Partition images published; WIRED and 404 Media analysis
17 Sep 2026	Gaines remediation verification: 14 of 29 entries unremediated

From Gaines's first contact on 8 February 2025 to his verification on 17 September 2026 is 586 days. From Flock's May 2025 advisory, which promised updates "starting today, in Q2 2025", it is 500 days. The image carries a June 2025 build date, and its logs date from 2026, so it was running firmware built after that advisory. What it cannot tell us is whether this camera had received Flock's latest release, or whether other deployed cameras are in the same state. Gaines says signed release mapping and live-device checks would be needed to extend his conclusions.

Flock's 13 August post said it would publish Bishop Fox's summary of findings and Flock's remediations in September. When we checked Flock's blog on 21 September, no such summary was listed. In February Flock explained why it works with Bishop Fox and sets strict criteria for anyone testing its platform, criteria it calls contractual requirements to its agencies. A paid engagement with a reputable firm is worth having. It is not independent in the way an unpaid researcher is, and it does not substitute for publishing what the firmware does.

Separating the method from the accusation

Every party here has an interest. The collective took the camera as an act of protest and says so; removing and dumping a device you do not own is, in Flock's words, illegal, and nothing in this briefing endorses it. Distributed Denial of Secrets is an activist archive. Lee writes a newsletter funded by paying supporters and hopes the reporting leads councils to cancel contracts. WIRED and 404 Media have been reporting critically on Flock for months. Flock sells the product, and Bishop Fox is paid by Flock.

Gaines is the closest to a neutral technical witness. His papers state that the work was self-funded, that devices were bought legally, that no production system was touched, and that his conclusions apply only to the supplied files. He also records findings that went Flock's way, such as the closed retention finding and the blocked route in one earlier exploit chain.

The custody gap is real, and the right response is to hold the findings to what the files support, not to dismiss them. The analyses are internally consistent: WIRED and Gaines counted the same 27,321 clips, and Lee and Gaines describe the same plaintext credential store. Flock has not, in anything we have seen, said the files are not from its camera. The claims that matter for buyers are about design choices embodied in code, and those do not depend on how the device came off its pole.

The UK position: who runs ANPR, and who checks it

Flock in the UK. We found no evidence that Flock Safety sells or deploys its cameras in the UK. A Companies House search returns no UK company under that name, only unrelated businesses called Flock, including a UK motor insurer. Absence of evidence is not proof, but nothing below assumes Flock is operating here. The lesson transfers regardless: UK buyers deploy plate readers and camera analytics from other vendors built on the same kinds of embedded Android or Linux platforms.

Police ANPR. Law enforcement ANPR in the UK runs through the National ANPR Service under the Home Office's National ANPR Standards for Policing and Law Enforcement, version 3.5 dated July 2026. The Home Office's NAS data protection impact assessment says 12,076 camera sets and 1,878 mobile ANPR cameras submit on average over 100 million reads a day; other passages of the same document cite 80 and 90 million, so treat the figure as an order of magnitude. A read must include the registration, time, location and camera identifier. A plate patch image is mandatory for police systems and an overview image, "to allow identification of the make, model and colour", is optional. Reads are deleted from national systems 12 months after capture and from local systems after 90 days, unless kept under the Criminal Procedure and Investigations Act. Components connecting to the national capability must be assessed so they "do not pose a threat" to it, and forces must carry out a risk analysis and an IT health check annually.

The Surveillance Camera Code. The code, updated in force from 12 January 2022, binds relevant authorities under section 33 of the Protection of Freedoms Act 2012, chiefly police and local authorities in England and Wales, who must have regard to it. Others are encouraged to adopt it voluntarily. Two provisions bite on procurement. Paragraph 10 says contracts with third-party providers must oblige them to have regard to the code. Principle 9 requires security measures against unauthorised access, including "cyber and physical security"; Principle 6 says no more images and information should be stored than the purpose strictly requires.

The Commissioner, and a role in flux. The Biometrics and Surveillance Camera Commissioner encourages compliance with the code; it advises and cannot enforce. Professor William Webster was appointed in November 2025. In a letter of 19 November 2025 he noted a 12-month hiatus with no Surveillance Camera Commissioner in post, and closed the commissioner's third-party certification scheme with immediate effect, citing concerns about its integrity given the time since audits and the unresolved future of the role and the code. That scheme had been kept alive only because the Data Protection and Digital Information Bill, which would have abolished both, fell at the 2024 election. The Home Office's consultation on a new legal framework, open from 4 December 2025 to 12 February 2026, proposes a single regulatory and oversight body for law enforcement use of biometrics, facial recognition and similar technologies, likely to build on the commissioner's role, and asks whether the framework should cover object recognition of things such as vehicles. As of 21 September 2026 the consultation page shows no published outcome.

Private ANPR. Car parks, retail sites and estates running plate recognition are outside the National ANPR Service and the code's statutory duty, and are governed by UK GDPR and the Data Protection Act 2018. The ICO's ANPR guidance says a registration is personal data in most circumstances, that a DPIA should be done before deployment regardless of sector, and that retention must match the purpose. Its accountability guidance says a DPIA is a legal requirement where processing systematically monitors publicly accessible places on a large scale, that processors need written contracts with guarantees about security and storage, and that organisations should not buy a system "because it is new, available, affordable". The ICO notes this guidance is under review following the Data (Use and Access) Act 2025.

UK controls over ANPR and camera analytics. Sources: NASPLE v3.5, NAS DPIA, Surveillance Camera Code 2021, BSCC letter of 19 November 2025, Home Office consultation, ICO video surveillance guidance.

Regime	What it requires	What it does not reach
NASPLE and the National ANPR Service	Defined read data, 12 month and 90 day deletion, accreditation before connection, annual IT health check	Private ANPR; what camera firmware does before a read is sent
Surveillance Camera Code	Police and councils must have regard; contracts must bind suppliers; security and minimisation principles	Private operators, except voluntarily; no firmware inspection duty
Biometrics and Surveillance Camera Commissioner	Advice and encouragement; standards lists	Enforcement; certification scheme closed November 2025
UK GDPR and ICO guidance	DPIA, processor contracts, retention matched to purpose, data protection by design	Independent testing of a vendor's device
Proposed new oversight body	Consulted on standards, codes and investigating misuse or hacking	Not yet legislated; outcome not published

The gap the table shows is the same one the Flock files expose. Every UK regime above regulates the organisation operating the camera. None of them, on its face, requires anyone to look at what the camera's own software detects, stores or retains before the data reaches a system the regulations do cover. A UK controller relying on a vendor's feature sheet is making the same assumption Flock's American customers made.

What a UK buyer should require of a camera analytics vendor

Whether you are a council, a force, a retailer or a car park operator, the controller is you, and the DPIA is only as good as what you know about the device. In the order worth doing:

The question that exposes the gap

Flock's statements are not, on the evidence, false in their own terms. The camera does not do face recognition. The storage is encrypted. Cloud retention is stated in days. Each claim survives, and each one leaves out the thing a data protection officer most needed to know: that the device looks for people, that the key sits next to the lock, that video stays on the pole for days by default.

So the question for any UK organisation buying camera analytics is not whether the vendor has a privacy page. It is this: if someone took one of your cameras down tomorrow and published its firmware, would anything in it surprise you? If you cannot answer that from documents you already hold, your DPIA describes the brochure, not the device.

Key facts