Serious Flaws in Flock Surveillance Cameras: Outdated OS and Hardcoded Credentials

Disk images of automated license plate reader cameras deployed by Flock Safety have leaked externally, and the analysis results are causing ripples. The nonprofit public records organization DDoSecrets published disk images said to have been obtained from devices in operation. 404 Media and Wired published a joint investigative report. Reporting on Lobsters via micahflee.com via robey describes how a researcher independently obtained and verified the material. The subject is the core equipment of a roadside surveillance network installed in combination with solar power. As equipment widely introduced by municipalities and investigative agencies, the details of its implementation are of high public interest.

Disk Images Published by DDoSecrets

What DDoSecrets published is described as copies of multiple partitions from Flock cameras that were in use in the field. According to the investigation by 404 Media and Wired, a group calling itself stegan0gram secured and analyzed the devices. The group told interviewers why it chose analysis rather than destruction.

Why just destroy [Flock cameras] when we can reverse engineer them and find the secrets of those spying on us?

In another statement, it explained that it secured and disarmed hardware in the field before proceeding to reverse engineer the cameras and associated solar equipment.

We liberated hardware in the field, disarmed them, and proceeded with reverse engineering of the cameras and associated solar equipment.

A researcher obtained this material and examined the installed OS, kernel, and contents. It was reportedly running a modified Android, with a build date recorded as June 5, 2025. Despite the relatively recent build, the underlying platform remained an older-generation version. It is drawing attention as a case where long-term operation of roadside equipment overlapped with stalled updates.

The Structural Danger of Continuing to Use an

Outdated OS

The camera in question was based on Android 8.1. Android 8.1 was released in 2017, and Google support ended in 2021. Nevertheless, the patch level remained at June 5, 2018. That is equivalent to missing eight years of Android fixes. Even in a modified version, an unmaintained base widens the attack surface. Mechanisms such as privilege separation, media encryption, and boot verification also remain tied to old designs.

For long-term installed devices, updates via carriers may not arrive. When power and connectivity depend on solar power and cellular links, the unit cost of maintenance work rises. This makes it easy to fall into operation that maintains the factory configuration with updates stopped. This case highlights issues in both the manufacturer’s maintenance design and the operator’s update system. Designs are needed that align hardware service life with software maintenance periods.

Kernel and GPU Driver Flaws

Underneath Android, Linux kernel 3.18.71 was running. The 3.18 series was a branch from 2017, with maintenance ending at 3.18.140 in May 2019. The device in question was 69 revisions older than the final version. It continued to use a kernel more than nine years old. Kernel flaws lead directly to privilege seizure and information leaks. For devices left unattended on streets, physical approach must also be assumed.

One flaw cited in the reporting is CVE-2021-1905. It is a use-after-free issue in Qualcomm’s Adreno graphics processing unit. A low-privilege process running on the device could corrupt kernel memory and seize control of the whole system. A fix was provided in May 2021. Given the spread of Qualcomm-based computing platforms, driver maintenance can be seen as a supply-chain-wide challenge, just as the diversification of peripherals shown by Snapdragon Reality Elite, New Chip for AR/MR suggests.

The other is CVE-2018-9568, known as WrongZone. Due to type confusion in a junction for IPv6, a process on the device could gain administrator privileges. A fix was provided in December 2018, and proof-of-concept code has been made public. Neither was disclosed after the patch level of the device in question. This directly reflects the impact of not applying fixes for a long period. While moves toward open graphics stacks can also be seen in Mesa RustiCL Enables Mali Panfrost by Default, products that remain on old proprietary drivers will not receive the benefits.

Hardcoded Credentials as an Intrusion Path

The headline points to the presence of hardcoded credentials alongside vulnerabilities. In embedded devices, maintenance passwords, keys, and tokens for connection destinations are sometimes embedded in storage media. If a common value is used across all devices, analysis of a single unit spreads to the whole fleet. Device transfers, disposal, and failure to recover stolen units become fatal. If default authentication remains on remote management paths, it becomes a target for scanning attacks.

Within the scope summarized here, specific usernames or key formats have not been identified. Still, given the nature of roadside devices, they should be designed on the assumption of physical acquisition. Storage encryption, per-device key issuance, and boot-time verification are fundamental. Designs that leave no maintenance backdoors and operation with revocable temporary tokens are essential. Procurement teams also need to include checks for shared credentials in inspection criteria.

Conflicting Claims Over the Vulnerability

Disclosure Process

Flock told interviewers that it maintains a vulnerability disclosure policy. Its position is that no report has arrived through official channels and that it cannot evaluate the issue with limited information.

Flock takes security seriously and maintains a public Vulnerability Disclosure Policy for security researchers to report potential vulnerabilities directly to us.

The researchers, for their part, are building up reproducible facts based on public materials. Patch levels, kernel versions, and published flaw numbers are verifiable evidence. It is reasonable that they explicitly stated that dynamic verification on actual hardware is incomplete and avoided definitive conclusions. Still, the fact that the patch level predates the disclosure dates of known flaws carries weight. The focus is less on formalities of disclosure channels than on notifying users and planning fixes. As shown by GNOME OS Test Center, Inspired by Apple TestFlight, moves to establish verification and distribution mechanisms are advancing in various fields. Similar verification infrastructure is needed for surveillance equipment.

In publicly procured surveillance networks, the user municipalities and police have difficulty grasping the patch status. Contracts requiring disclosure of bills of materials and patch levels, rather than relying solely on manufacturer explanations, become important. The publication by DDoSecrets invites debate over the legitimacy of its methods. However, the fact that software on roadside devices has become verifiable is highly significant. Going forward, third-party re-verification and technical rebuttals from the manufacturer will be closely watched.

Editorial Opinion

On short-term impact. Procurement departments of municipalities and investigative agencies are expected to demand explanations of Flock devices’ configurations and fix plans. The manufacturer will be pressed to accept reports under its disclosure policy and to publish versions and fix schedules. Competing products are also likely to undergo reviews of legacy platforms. Organizations may add explicit patch-level requirements to procurement criteria within three to six months.

On the long-term perspective. For roadside surveillance equipment, a mismatch between decade-long operation and software maintenance periods is expected to become normalized. Designs premised on per-device keys, remote updates, and revocable tokens will become standard. Once procurement-side inspection systems are in place, shared credentials and unsupported platforms will be excluded at adoption. Society as a whole will continue to debate the balance between surveillance effectiveness and protection of private rights.

On questions from the editorial team. How much secrecy should be entrusted to devices that can be physically acquired. Can verification based on public materials be positioned as complementing formal disclosure procedures. Does the manufacturer’s accountability lie less in denying the existence of vulnerabilities than in disclosing reproducible configurations. Readers are urged to build up verification materials from procurement and operational sites.

References

• “Flock cameras are riddled with security vulnerabilities and hard-coded credentials”, by micahflee.com via robey — Lobsters, 2026-09-17T21:21:18.000Z (ARR)
• Source URL: https://micahflee.com/flock-cameras-are-riddled-with-security-vulnerabilities-and-hard-coded-credentials/