On September 16, 2026, WIRED and 404 Media published findings from a physically removed Flock Safety camera, documenting what a hacker collective recovered from local storage: 27,321 video clips, 1.6 million images, and an encryption key stored in an unencrypted partition. What follows is not a story about novel remote exploitation, but about the durability of a familiar architectural error.
In this article
What Happened and When
A hacker collective calling itself stegan0gram physically removed a Flock Safety camera positioned above a roadway and copied much of its stored data, according to a joint investigation by WIRED and 404 Media. The camera held 27,321 short video clips, and over 21 days it photographed about 50,000 vehicles and generated roughly 1.6 million images. The group copied the data and sent it to 404 Media and WIRED through the transparency organization Distributed Denial of Secrets.
The Android-based device contained two unencrypted partitions called “vendor” and “media,” and investigators found an encryption key in the media partition that unlocked another section containing videos and still images. The device’s most sensitive encrypted storage stayed out of reach, and nothing in the reporting suggests the hackers ever touched Flock’s cloud systems. This was a compromise of one edge device, not the central platform.
Flock Safety, a license plate reader company valued at $7.5 billion in March 2025 according to reporting on its Series F round, had cameras installed in over 4,000 cities across 42 states by 2024. The company had stated in a May 2025 security alert that even with physical access to a device, an attacker “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”. That finding directly contradicts Flock’s public position that on-device encryption protects footage even if someone gains physical access, because the key was recoverable from the device itself.
Precedent From Earlier in 2025
Earlier in 2025, security researcher Jon “GainSec” Gaines had already documented root-level access vulnerabilities in a Flock camera, and Flock downplayed the severity at the time, arguing stored footage remained out of reach. Flock’s security team was alerted about limited, localized security vulnerabilities on its license plate readers and gunshot detection devices, and upon notification analyzed the impact of these vulnerabilities and made submissions to Mitre for inclusion in the National Vulnerability Database. The company described those vulnerabilities as requiring physical access and device debugging knowledge.
Security vulnerabilities reported in February 2025 remain unpatched as of November 2025, according to an independent analysis by Footnote4a. The stegan0gram extraction demonstrates that the theoretical vulnerability documented by Gaines translated into a practical data-recovery scenario when a device was removed from deployment.
The logs also contained more than 27,000 errors saying there was no space left on the device. That detail matters: storage exhaustion on an edge surveillance device implies either that local retention windows are longer than marketing materials suggest, or that upload pipelines fail often enough to create a backlog. Either way, the promise of brief local retention becomes conditional on infrastructure performance.
The Volume and the Scope
During 21 days of activity, the camera photographed roughly 50,200 vehicles and generated approximately 1.6 million images, with a typical day containing about 3,300 vehicle detections and a peak of 4,454. A typical passing vehicle triggered about 28 images, while some triggered more than 100. That per-vehicle capture rate reflects a design choice: sample aggressively at the edge, then filter server-side.
The device runs roughly 20 custom Flock-built Android apps, covering motion detection, image capture, object classification, cellular upload, and remote firmware updates. The camera took several pictures when something entered its view, then picked useful images and sent them to Flock’s servers through a cellular connection; the camera itself did not appear to work out details such as a vehicle’s make, model or color, as that task was handled on the company’s servers.
The investigation found that the recovered software explicitly detects people, alongside vehicles, bicycles, and license plates; when the cameras detect a person, the software records their position in the images and how confident it is that it has spotted a human. Flock maintains its cameras do not perform facial recognition, and the outlets said they found no evidence of active facial recognition capability beyond default features built into the Android operating system, which did not appear enabled. The distinction is between detection (locating a person in a frame) and identification (matching a face to a database). The recovered software performs the former.
What This Tells Us About Edge Architecture
The recovery of an encryption key from the same physical device it is meant to protect is not a novel vulnerability class. It is an implementation of encryption theater: the presence of cryptographic operations without a threat model that survives contact with the physical environment. A public roadside computer should be designed on the assumption that determined people will eventually reach it, remove it and inspect every component.
Storing a decryption key on the device it protects is functionally equivalent to locking a filing cabinet and leaving the key taped to the back. The encryption still happens; an observer watching the storage partition will see ciphertext. But the security boundary collapses the moment someone obtains the physical device, because both the locked container and the key travel together. This is not a sophisticated exploit requiring zero-day research. It is filesystem access.
The pattern is not unique to Flock. Edge devices with local storage face a structural problem: if the device must decrypt its own data (to upload, to display, to process), the key must be accessible to the device’s operating system. Remote attestation, secure enclaves, and hardware security modules exist to address this, but they add cost and complexity. The cheaper path is to encrypt data at rest, store the key somewhere in firmware or an adjacent partition, and rely on the assumption that physical access is rare.
That assumption might hold for a data center, where physical security is a controlled perimeter. It does not hold for a camera mounted on a pole above a public street. Flock raised $275 million at a reported $7.5 billion valuation in March 2025, with participation from Andreessen Horowitz, Greenoaks, Meritech Capital, Matrix Partners and Y Combinator, and TechCrunch reported at the time that Flock had surpassed $300 million in annual recurring revenue during 2024. A company operating at that scale, deploying hardware in adversarial physical environments, treats the physical security boundary as an engineering constraint, not an afterthought.
Implications for Email and Encrypted Communication
The Flock case is a reminder that “encrypted” is an incomplete sentence. Encrypted by whom, with a key held where, accessible to which processes, under what threat model? A surveillance camera and an email server occupy different threat landscapes, but the architectural principle is the same: if the system that holds the ciphertext also holds the key, encryption protects against one class of attacker (the remote observer, the unprivileged process) but not another (the operator, the physical possessor, the state with legal process).
For email, this surfaces in the difference between transport encryption (TLS, which protects messages in transit but allows the server to read plaintext), at-rest encryption with provider-held keys (which protects against database leaks but not subpoenas or breaches of the key management system), and end-to-end encryption where the user holds the private key (which protects against the provider but requires the user to manage key custody and availability).
Flock’s cameras perform encryption, but the company also operates the servers that process the footage, holds the keys, and mediates access. That is a reasonable architecture for a service where the customer (a police department) expects the vendor to manage the system and provide search interfaces. It is not an architecture that survives physical device capture with confidentiality intact, and the May 2025 security alert’s claim that footage would remain inaccessible even with physical access has now been tested in the field.
The equivalent email scenario is a provider that encrypts an inbox on disk with a key stored in the same database. An attacker who dumps the database gets both the encrypted emails and the key to decrypt them. The encryption provides compliance theater and protection against certain classes of opportunistic access, but it is not end-to-end, and it is not zero-knowledge.
Architectures that separate key custody from data custody exist. PGP and S/MIME allow users to encrypt email such that the server never sees the plaintext. Server-side implementations can encrypt incoming mail with user public keys before storage, where only the user’s private key (held client-side) can decrypt it. Open-source post-quantum infrastructure – such as PQCServer, released under AGPL-3.0 – extends that model to include algorithms resistant to quantum cryptanalysis. The tradeoff is operational: the user must manage their key, and if they lose it, the data is unrecoverable. There is no customer support reset flow that can bypass cryptographic access control.
That tradeoff is unacceptable for many users and many applications. It is acceptable, and necessary, for others. The Flock case does not prove that all edge encryption is flawed; it proves that edge encryption without a physical security model adequate to the deployment environment will eventually be tested, and the test will not be kind.
Where This Leads
Flock has not announced a recall or a firmware update that relocates key storage to a secure enclave. Flock said removing and tampering with its cameras is illegal, and the company also said it had not received the hackers’ technical findings through its vulnerability disclosure program and did not have enough information to fully assess their claims. That response is legally accurate and operationally insufficient. The legality of device removal does not alter the cryptographic fact that the key was recoverable.
The No FLOCK Act, introduced the same week as the reporting, stands for Federal License-Plate Observation and Camera Keeping and directs the US transportation secretary to withhold 10% of a state’s annual federal funding for highways, roads and bridges if the state does not restrict the cameras; the bill text allows only five uses, including toll enforcement, finding stolen vehicles, finding missing or endangered people, vehicles registered to people with a felony warrant, and vehicles involved in a felony. Whether that bill advances is a political question, but its introduction signals that legislative scrutiny is no longer theoretical.
The stegan0gram extraction will likely serve as a reference case in procurement decisions, civil liberties litigation, and legislative hearings. A vendor claim that footage is protected by encryption can now be tested against a specific, documented instance where the encryption key was extracted from the device using no exploit more sophisticated than filesystem access. The case is not about whether Flock’s cloud was compromised (it was not), or whether the company experienced a remote breach (it did not). It is about whether the on-device encryption provided the protection the company’s public statements described. The evidence suggests it did not.
For encrypted communication systems, the lesson is not new, but it is durable: encryption is a tool, not a guarantee. The security property it provides depends entirely on where the keys live, who can access them, and whether the threat model accounts for the environment in which the system operates. A camera on a public street and an email server in a data center face different physical threats, but both must answer the same question: if an attacker gets the hardware, what do they get with it?