Flock Cameras Have Hard-Coded Keys. The ‘Security Company’ Didn’t Notice.

The Sting: How a Camera Became an Open Book

The stegan0gram collective didn’t just smash a camera and call it a day. They “liberated hardware in the field”, disarmed it, and reverse-engineered both the camera and its associated solar equipment. The resulting dataset landed on DDoSecrets, where security researcher Micah Lee and journalists from 404 Media and WIRED went to work.

The findings read like a checklist of every IoT security anti-pattern ever documented, except this isn’t a hobbyist ESP32 project. This is a company whose entire business model is monitoring license plates and stitching together the movements of vehicles and people across the country. The camera in question captured 1.6 million images of 50,000 vehicles in just 21 days. That’s the scale of surveillance we’re talking about when we discuss the architecture failures below.

Android 8.1 in 2026: The Zombie OS That Keeps Spying

Flock cameras run a modified version of Android. The specific build extracted was compiled on June 5, 2025, recent enough to suggest active development. But underneath that fresh build, the device was running Android 8.1, released in 2017 and abandoned by Google in 2021.

The security patch level? June 5, 2018. That’s not a typo. This camera was missing eight years of Android security updates.

Digging into the boot partition reveals an even uglier story. The device runs Linux kernel 3.18.71, released in 2017. The 3.18 series got its final patch in May 2019 at 3.18.140. This camera is 69 releases short of even that final version, over nine years out of date.

Here’s what that means in practical terms. The device is likely vulnerable to:

• CVE-2021-1905 – A use-after-free in the Qualcomm Adreno GPU driver. Any unprivileged app can corrupt kernel memory and take full control of the device. Patched May 2021.
• CVE-2018-9568 (“WrongZone”) – A kernel socket type confusion over IPv6 that allows privilege escalation to root. Patched December 2018, with public exploit code available.

In the boot partition, the kernel build string tells the story:

Linux version 3.18.71-perf-gaf770dc (android@e593ce924ef6) (gcc version 4.8 (GCC) ) #1 SMP PREEMPT Thu Jun 5 20:15:45 UTC 2025

GCC 4.8. Released in 2013. The compiler is old enough to vote in some countries. Flock took a decade-old toolchain, recompiled a kernel from 2017, and shipped it in a device that police departments mount above public roadways to track every car that drives past.

The Hard-Coded API Key: A Master Key for Every Camera

The crown jewel of the findings is a hard-coded API key in the shared library bundled into 19 of the 20 Flock apps on the device. Decompiling com.flocksafety.android.common.lib reveals this gem in the CameraSettings class:

public final String getHpnotiqApiKey() {
    return "HaJ3FgupAm8RrDJW3MHgT9X7Ft27eVaD";
}

This key authenticates to hpnotiq.flocksafety.com, Flock’s backend provisioning service. When a camera needs credentials, it makes a POST request:

POST https://hpnotiq.flocksafety.com/api/v3/devices/credentials
x-api-key: HaJ3FgupAm8RrDJW3MHgT9X7Ft27eVaD

macAddress=F46ADD5746FB

The API responds with Auth0 client credentials – an ID and secret pair – that the camera stores in plaintext on its /persist partition. Those credentials can then mint bearer tokens at https://device-login.flocksafety.com/oauth/token, granting full authenticated access to Flock’s backend servers as that camera.

The implication is staggering: this single API key could potentially obtain credentials for any Flock camera if you know its MAC address. The researcher who found this was careful not to test it against live infrastructure – connecting to Flock’s servers with leaked credentials without permission is illegal. But the architecture makes the vulnerability self-evident.

A key designed to provision credentials, hard-coded into every shipping device, with no apparent rate limiting or per-device scoping. This is the kind of flaw that would earn a failing grade in a 200-level security course.

Where the Secrets Actually Live

The forensic trail shows how deeply this problem runs. The API key sits in the system partition (partitions/24_system.img, 1.5 GB), appearing in all 19 Flock apps via the shared library. The Auth0 client credentials are on the persist partition (partitions/27_persist.img, 32 MB) at flock/auth0/auth0_cred – a partition explicitly designed to survive factory resets and left unencrypted.

The MAC address and over 2,200 provisioning calls come from logs on the media partition (partitions/53_media.img, 18 GB). Those logs sit inside an “encrypted” container whose key is stored on the same partition in a file called expand_1fcdafef903c40cab3aff81bec914d01.key. The encryption is a locked door with the key taped to the doorknob.

This is the classic secrets sprawl problem at enterprise scale – credentials copied into every layer of the stack, with no lifecycle management, no rotation, and no revocation path. Akeyless’s analysis of enterprise secrets management challenges notes that hard-coded credentials and sharing across systems are recurring problems. Flock appears to have implemented every anti-pattern they describe in a single product.

So Who Can Exploit This, Really?

Let’s be clear about the threat model here, because it’s worse than the headlines suggest.

The “We Didn’t Receive a Report” Defense

Flock’s official response deserves a specific kind of scrutiny. A spokesperson told 404 Media and WIRED:

“Flock takes security seriously and maintains a public Vulnerability Disclosure Policy for security researchers to report potential vulnerabilities directly to us. We received no report through that process, and based on the limited information provided, we do not have enough detail to assess the claims being made.”

This is the “you didn’t ask nicely enough” defense, and it’s absurd on multiple levels:

1. The researchers didn’t need to report anything. They dropped the firmware images and documented the vulnerabilities publicly because they wanted municipalities to cancel their contracts and people to understand what’s watching them.
2. Flock’s “limited information” excuse is weak when a public dataset contains filesystem images, extracted API keys, and reproducible steps for finding them.
3. An attacker wouldn’t respect a vulnerability disclosure policy anyway. The policy exists to give Flock a structured way to receive reports, not to guarantee that every security issue will be funnelled through their preferred channel.

This response pattern – deflect, minimize, ask for a proper report – is familiar to anyone who has disclosed IoT vulnerabilities. It’s the reason many researchers leak findings instead of responsibly disclosing them.

The Bigger Pattern: IoT Security as an Afterthought

The Flock debacle isn’t an isolated incident. It’s a microcosm of the IoT security crisis that keeps producing similar failures across the industry.

The Rust supply chain attack that weaponized Cargo’s safety features demonstrated how quickly a single compromised component can cascade through an ecosystem. Flock’s shared library approach – 19 apps bundling the same credentials – is the same architectural disease: reuse without isolation, convenience without governance.

There are parallels to shadow AI exposing systemic security failures in organizations. When teams deploy unauthorized tools without security review, they create exactly the kind of unmanaged credential sprawl that Flock’s firmware demonstrates. The difference is that Flock’s “shadow” infrastructure is their actual product.

What “Done Right” Looks Like for Edge Devices

For all the doom, there’s a clear playbook for IoT manufacturers who don’t want to be the next breach headline. It’s not exotic.

Who Should Be Held Accountable?

The stegan0gram collective’s stated goal is to get cities to cancel their Flock contracts. That framing might be reductionist, but the security findings support a legitimate question: should organizations that deploy surveillance infrastructure be held to a higher security bar?

The GSA’s inspector general reportedly subscribes to Flock. That means federal agencies, cities, and police departments nationwide are purchasing a product whose primary function is to track vehicles and people – and whose security posture resembles a 2017-era Android development board.

One commenter on the WIRED article noted that the camera itself likely doesn’t do facial recognition due to limited processing power – it transmits images to servers for analysis. But that distinction offers cold comfort when the device’s hard-coded key potentially allows compromised credentials for the entire fleet, and its eight-year-old kernel allows root-level compromise of the device itself.

The Real Lesson

Flock cameras are a case study in what happens when a company treats edge devices as disposable feature delivery vehicles rather than security-hardened infrastructure. The hard-coded API key, the decade-old kernel, the plaintext credentials, the “encrypted” container with a key file sitting inside it – these aren’t individual mistakes. They’re the output of a development culture that optimized for getting cameras deployed quickly without ever building the security engineering muscle required for surveillance infrastructure.

The company’s response – suggest researchers submit through the proper channel – tells you everything about how they view external scrutiny. But the camera’s own data reveals how their rearview looks: 50,000 vehicles in 21 days, tracked and logged and stored, all through a device that a patient attacker with a ladder and a USB cable could completely own.

If you’re building IoT products – regardless of whether they track cars or measure soil moisture – the Flock reverse engineering report is required reading. Ask yourself: if someone stole one of your devices and extracted its firmware, would they find hard-coded credentials, years-old vulnerabilities, and access to your production infrastructure?

If the answer makes you uncomfortable, you’re not alone. But you’re also probably not fixing it fast enough.

The exploit isn’t the story. The architecture, and the denial that follows, is the story. That’s what every security team should be taking away from the Flock debacle.