WIRED and 404 Media's analysis found that one Flock Safety camera logged roughly 50,200 vehicles and 1.6 million images across about three weeks on a single pole.
What the recovery team actually recovered
After gaining physical access to a deployed Flock Safety automated license-plate reader (ALPR) camera, attackers or researchers imaged its storage, recovered software and data, and extracted an on-device encryption key, enabling access to stored video and logs. Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity at Suzu Labs, summarized reporting that the recovery team made a near-complete copy of the drive, pulled the encryption key stored on the device, and unlocked thousands of roadside clips and still bursts — although WIRED reported that much of the most sensitive storage remained encrypted.
Micah Lee then examined the published filesystem images from that teardown, producing the detailed technical findings described below.
Firmware and software weaknesses identified
Larry Pesce, VP of Services at Finite State, laid out a short list of concrete firmware problems that emerged from Lee’s analysis and the published images:
- The device runs a modified Android 8.1 with a security patch level of June 2018.
- The Linux kernel on the unit is 3.18.71, a 2017 release from a kernel series that reached end-of-life in 2019.
- A hard-coded API key is present in a shared library bundled into 19 separate on-device apps and appears to let a caller request credentials for a camera by MAC address.
- Device credentials sit in plaintext on an unencrypted partition designed to survive factory reset, and the key protecting the media partition is stored on the same partition it protects.
Pesce noted an important caveat: this analysis covers one camera, and the unit’s age and fleet status are not known. The build found on the device was compiled in June 2025, which Pesce said suggests a platform decision to build recent software on an old base rather than a simple lapse in patching.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildHow physical deployment factors magnified the problem
Jacob Krell pointed out that Flock’s install documentation places units on public poles and roadway arms roughly 8 to 12 feet high, locations technicians — and attackers with a ladder — can readily reach. Krell warned that theft and vandalism of such pole-mounted devices are already occurring in public, and that the physical threat to roadside units is therefore higher than to rack-mounted equipment in locked facilities.
Krell also described the privacy stakes if the decryption key remains stored on a publicly reachable device: one successful pull becomes a bulk export of neighbor travel history, including scene-level detail such as bumper stickers, flag patches on saddlebags, and riders flagged as people — all accessible “with no Flock login and no law-enforcement audit trail on the read,” he said. On-device software also flagged people in frame, increasing the sensitivity of locally stored imagery.
Security leaders’ recommended mitigations
Security practitioners quoted in the reporting offered a consistent set of architectural prescriptions:
- John Strand, owner of Black Hills Information Security, urged organizations to include physical device security in threat models and to ask, “How do we actually secure the physical device itself?”
- Damon Small, board member at Xcape Inc., called for hardware-backed roots of trust, unique per-device secrets, and mandatory data minimization to constrain the blast radius of compromised hardware.
- Larry Pesce argued for knowing what is in firmware before it ships, threat-modeling for physical possession, provisioning per-device credentials, and committing to a software lifecycle that outlives the board support package (BSP) the chip vendor provides.
The published “critical takeaways” distilled from these remarks were blunt: edge deployments fail when encryption keys and sensitive logs reside unencrypted in local memory; massive surveillance apparatuses carry severe liability when physical tampering uncovers systemic data collection practices; and defenders must enforce hardware key isolation, distinct device credentials, and immediate data ephemeralization across all remote nodes.
What this means for technologists, policymakers, and residents
Technologists and security teams will need to prioritize per-device credentialing, hardware key isolation, and pre-shipment firmware audits rather than relying on post-deployment bug bounties — a shift Pesce said “gets fixed by knowing what's actually in your firmware before it ships.”
Policymakers and regulators should note that experts pointed to regulatory pressure already emerging, citing the EU CRA’s update and support obligations as an example of where rules are moving toward mandatory lifecycle and update commitments.
Residents and local councils debating ALPR deployments now have concrete, technical material to consider: Krell suggested placing the teardown in front of any council vote on ALPRs, pointing to the camera’s local storage of detailed imagery and the practical ease with which a device can be physically compromised.
“If your product runs on hardware, someone will eventually have your hardware. Design like it,” Pesce concluded — a brisk admonition that ties the teardown’s technical details to a broader engineering imperative.
