Do Flock Cameras Use Wi-Fi? What the “Hidden SSID” Probe Traffic Actually Shows

Yes. Flock Safety license-plate-reader cameras contain and use Wi-Fi hardware even though their normal cloud data connection is cellular. Recent field research has captured operational Flock cameras transmitting repeated Wi-Fi probe requests, which means the camera’s Wi-Fi client is actively scanning for nearby wireless networks.

But one part of the viral interpretation needs to be tightened.

A packet analyzer displaying the SSID as <hidden> does not by itself prove that the camera is repeatedly calling a specific secret Wi-Fi network. In ordinary 802.11 networking, a probe request with an empty SSID field is generally a wildcard probe: the device is asking nearby access points what networks are available.

That distinction matters.

The new observation does not establish that Flock cameras secretly upload license-plate data through a municipal Wi-Fi hotspot. Flock’s own documentation says its LPR cameras use cellular LTE for data communications, and a September 2026 forensic examination of a compromised camera found selected images and metadata being sent to Flock over the cellular network.

What the observation does establish is more interesting than a simple “gotcha” about Wi-Fi:

Deployed Flock cameras have an active wireless layer beyond their advertised cellular uplink, and that layer deserves scrutiny because previous Flock security research has already found serious vulnerabilities involving Wi-Fi, local administrative services, credentials and device management.

The unanswered question is not merely whether the cameras have Wi-Fi.

It is what that Wi-Fi client is configured to trust, what it is used for in normal operation, and whether shared configuration across many cameras can turn a local wireless feature into a fleet-wide security dependency.

What the researcher actually captured

The recent observation appears to come from cybersecurity researcher Jacob Swinsinski, also known as JakeSwiz, who modified an existing passive Flock-detection project so that an ESP32 device would monitor Wi-Fi management traffic instead of relying only on Bluetooth.

In a field test near a known Flock automated license-plate reader, Swinsinski reported capturing 12 Wi-Fi probe requests over roughly 50 seconds from a radio address using an OUI associated with Lite-On, a hardware manufacturer whose prefixes have been observed on Flock-related equipment.

His published log shows the camera transmitting probe requests across multiple 2.4 GHz Wi-Fi channels while its normal Flock-XXXX service hotspot was not visibly broadcasting.

Swinsinski also reported that the probe activity increased shortly after the camera’s infrared strobe fired as a vehicle passed. He interpreted that timing as evidence that the camera was searching for an uplink after capturing a vehicle.

The observation is significant. But the last step is still an inference.

The packets show that a Wi-Fi radio associated with the camera was actively scanning.

They do not, by themselves, show:

• which access point the camera ultimately intended to join;
• whether it joined any access point at all;
• whether a specific hidden SSID was configured;
• whether license-plate images were sent through Wi-Fi;
• whether the Wi-Fi activity was related to telemetry, servicing, failover, provisioning or another internal function.

Swinsinski’s public project is valuable precisely because it exposes the radio behavior for others to examine. Multiple later counter-surveillance tools now use similar Wi-Fi probe behavior as one signal for identifying Flock hardware in the field.

That suggests the behavior is not unique to one camera.

It is not yet a statistically representative measurement of Flock’s entire deployed fleet.

Why <hidden> does not necessarily mean a secret hidden SSID

This is the most important technical correction to the viral retelling.

In Wi-Fi, a client can actively scan for networks by sending a probe request. The request can name a particular SSID, or it can contain a wildcard/empty SSID and effectively ask compatible nearby access points to identify themselves.

Cisco documentation describes probe requests with an empty or wildcard SSID as a normal mechanism used by clients looking for available networks.

That means a packet-capture tool displaying something like:

ssid:"<hidden>"

may simply be labeling an empty SSID field in a wildcard probe.

It does not automatically mean:

“This camera is trying to connect to a hidden network whose name the researcher uncovered.”

A directed probe for a specific network is a different thing.

This does not make the observation unimportant. An operational roadside camera repeatedly activating its Wi-Fi client is still worth explaining. It simply means the packet evidence should not be asked to prove more than it does.

What the capture establishes

How Flock cameras normally send data

Flock’s public explanation is straightforward.

Its current FAQ says the company reduced infrastructure requirements by using a cellular network instead of Wi-Fi. The same page says Flock cameras use cellular LTE for data communications.

Flock gave a more technical description in its May 2025 Gunshot Detection and License Plate Reader Security Alert, saying its LPR and gunshot-detection sensors connect to the cloud through cellular networks and transmit images, audio and metadata using TLS encryption.

Independent evidence now supports the cellular-uplink part of that description.

In September 2026, WIRED and 404 Media analyzed software and data recovered from a physically removed Flock LPR. Their forensic examination of the camera found that the device takes rapid bursts of images, performs local filtering and cropping, and then sends selected frames and associated data to Flock over the cellular network.

That same investigation is the basis of our earlier sherafy.com report, Inside the Flock Camera Hack: What 1.6 Million Images Reveal About How the Cameras Actually Work.

So the strongest current evidence points to this architecture:

camera sensors → local processing → cellular LTE/private IoT network → Flock cloud

Wi-Fi exists alongside that path.

The unanswered question is what role it plays when the camera is not being actively serviced.

The Wi-Fi interface is not hypothetical

Even if normal evidence upload occurs over cellular, Wi-Fi is not an irrelevant leftover radio.

Security researcher Jon “GainSec” Gaines demonstrated in 2025 that Flock Falcon/Sparrow LPR units could expose a local Wi-Fi hotspot used for servicing after a physical activation sequence. His research showed that the camera’s local wireless network could provide access to administrative services on the device.

One of the resulting vulnerability records, CVE-2025-59403, describes Flock’s Android Collins application exposing administrative API endpoints without authentication on the local network. The record says an attacker who could reach that LAN/WLAN surface could trigger administrative functions and, in the affected version, enable Android Debug Bridge access.

CISA’s enrichment of that vulnerability assigned it a 9.8 Critical CVSS score.

Another record, CVE-2025-59409, says production Falcon and Sparrow firmware contained development Wi-Fi credentials stored in cleartext. CISA scored that issue 7.5 High.

Gaines also documented a common default credential on the local service hotspot in the hardware he tested. We are not reproducing the credential or exploitation procedure here because neither is necessary to understand the security issue.

The important point is architectural:

The Wi-Fi radio was connected to real administrative functionality on the camera, not merely present as an unused chip.

That is why a new pattern of unexplained Wi-Fi probing deserves more than a shrug.

The bigger question is shared trust, not one mystery hotspot

The most consequential theory is not that every Flock camera in a city secretly connects to one Wi-Fi hotspot.

There is currently no evidence for that architecture.

The stronger question is whether many cameras share the same assumptions about what wireless infrastructure they should trust.

For example, a fleet-scale risk could exist if large numbers of cameras shared any of the following:

• the same service-network credentials;
• reusable provisioning credentials;
• a common SSID or network profile;
• identical authentication material;
• a weakly validated access-point identity;
• a common fallback or recovery network;
• a common local administrative configuration.

None of those conditions should be assumed.

But they are exactly the details needed to determine whether Wi-Fi is merely a local maintenance convenience or a meaningful common trust layer.

If every camera uses unique credentials and authenticated per-device provisioning, the blast radius of a local wireless problem can be relatively small.

If thousands of cameras are configured to trust common wireless credentials or network identities, the architecture becomes much more centralized than the physical deployment suggests.

That is the real security question hiding inside the viral clip.

Flock has already had a shared-network failure affect multiple cameras

There is an important precedent, although it involved a different Flock product and the cellular layer rather than Falcon/Sparrow Wi-Fi.

Flock says its devices normally connect to the cloud through private IoT cellular networks.

According to Flock’s own cybersecurity response, one of its cellular carrier partners moved a group of Flock PTZ cameras in 2025 from that private IoT network onto the public cellular network used by ordinary phones.

That change unexpectedly exposed diagnostic interfaces to the public internet.

Security researcher Jon Gaines subsequently reported finding 67 exposed Flock camera feeds or debug interfaces associated with the incident and related discovery work. Independent reporting also documented publicly reachable Condor camera feeds.

Flock characterizes the event as a limited carrier-side configuration error affecting a small number of PTZ cameras. The company says the incident did not provide access to its cloud environment, that it corrected the carrier configuration, added detection for similar changes and later required authentication on the diagnostic interface.

The details of that incident should not be conflated with the Wi-Fi probes now being observed from LPR cameras.

But it demonstrates the underlying systems principle:

A physically distributed camera network can still depend on shared infrastructure where one configuration decision changes the exposure of many devices at once.

That is the centralized-risk concept worth investigating.

The latest firmware dispute makes the question more timely

The wireless observation also arrives during an unresolved disagreement over how completely earlier Flock vulnerabilities have been remediated.

After the September 2026 camera teardown produced a copy of deployed Flock LPR firmware, Gaines compared that firmware against the versions he had analyzed during his earlier research.

In a September 17 remediation-verification report, he said his static analysis found:

• 23 previously reported findings that he assessed as still unremediated;
• two that appeared likely unremediated;
• three requiring live-device confirmation;
• one confirmed remediated.

There is an important limitation.

Gaines no longer had matching live Flock hardware for the September review. His conclusions were based on static analysis, reverse engineering and comparison of the newly obtained firmware with previously studied versions.

That is strong evidence about code state.

It is not the same thing as demonstrating every issue against every currently deployed camera.

Five days later, Flock published the results of a separate 2026 penetration test performed by Bishop Fox. Flock says the clear-box test covered ALPR and PTZ hardware, gunshot detection, compute hardware, applications, cloud infrastructure and source code.

According to Flock’s September 22 security-testing disclosure, Bishop Fox identified 36 findings. Flock says:

• both Critical findings were fixed and independently verified;
• all seven High findings were fixed and independently verified;
• 13 of 16 Medium findings were fully remediated;
• two Medium findings were partially remediated;
• one Medium finding involving Android 8.1 on first-generation Falcon hardware remained unremediated under a documented risk-management decision;
• all three Low findings were remediated.

Those two public accounts are not directly comparable.

Gaines was checking a specific set of vulnerabilities he had previously reported against a particular recovered firmware build. Bishop Fox performed a separate penetration test with its own finding set and methodology. Flock says customers can obtain the full Bishop Fox and retest reports, but the public summary does not provide enough detail to map every Bishop Fox finding against every GainSec finding.

So the responsible conclusion is not that one side has automatically disproved the other.

It is that the public record still does not provide a clean finding-by-finding reconciliation of the camera’s current attack surface.

That makes the unexplained Wi-Fi behavior more relevant, not less.

What would actually prove the “secret hotspot” theory?

A passive probe request is only the first step in Wi-Fi discovery.

To establish that a deployed camera is actually using Wi-Fi as an uplink, researchers would need evidence showing substantially more than wildcard probes. For example:

1. the camera identifying or selecting a particular access point;
2. an authentication and association sequence;
3. evidence that the camera obtained network connectivity through that WLAN;
4. subsequent data traffic attributable to the camera;
5. ideally, a way to distinguish routine management traffic from actual evidence upload.

A packet capture containing only repeated wildcard probes cannot establish all of that.

Likewise, if the camera is probing more frequently after a vehicle capture, that correlation is worth investigating, but timing alone does not prove that the Wi-Fi radio is carrying the captured plate data.

There are several plausible explanations that remain open:

• the Wi-Fi subsystem periodically scans regardless of data upload;
• the scan is part of a health or diagnostics routine;
• the camera is searching for a service or provisioning network;
• Wi-Fi exists as a fallback communications path;
• another process happens to run after a capture event;
• some deployments use Wi-Fi differently from others.

The evidence is not yet sufficient to choose confidently among them.

The questions Flock should answer

Flock can clear up much of this without revealing anything that would meaningfully help an attacker.

The company should be able to answer:

1. Why do deployed Falcon/Sparrow LPR units emit wildcard Wi-Fi probe requests during normal operation?
2. Is Wi-Fi ever used to transmit LPR images, metadata or telemetry to Flock, or is cloud communication exclusively cellular in normal deployments?
3. What functions require the Wi-Fi client when the service hotspot is not active?
4. Are saved Wi-Fi profiles or credentials unique per device, per customer, per deployment or shared across fleets?
5. How does a camera authenticate the identity of a wireless network before trusting it?
6. Can a camera automatically associate with a previously configured wireless network without a technician physically activating service mode?
7. Are local administrative services reachable through the Wi-Fi client interface during normal operation?
8. Do current production firmware versions still contain development or shared Wi-Fi credentials of the type documented in CVE-2025-59409?
9. What remediation specifically addressed CVE-2025-59403 on currently deployed Falcon/Sparrow hardware?
10. Why does Wi-Fi probe activity appear, in at least one field capture, to increase shortly after a vehicle triggers the camera?

Those are not accusations.

They are the missing architectural facts needed to determine the actual risk.

So are Flock cameras secretly using city Wi-Fi?

There is no evidence yet that a typical Flock LPR depends on a citywide municipal hotspot network.

The best-supported model remains:

roadside camera → cellular LTE/private IoT network → Flock cloud

But that is not the end of the story.

The cameras also contain an active Wi-Fi subsystem. Researchers have demonstrated that the same wireless/local-network layer has historically been connected to administrative functionality, and deployed cameras are now being detected through repeat Wi-Fi scanning behavior even when their visible service hotspot is off.

The viral clip therefore appears to have found something real while overstating one technical conclusion.

The cameras are not proven to be “phoning home to a hidden SSID.”

They are phoning the airwaves with probe requests.

And because this is a centrally managed surveillance platform deployed at large scale, the important question is whether those otherwise ordinary Wi-Fi packets reveal a shared trust model that could turn one configuration weakness into a much larger problem.

That is the part that still needs an answer.

For the broader surveillance implications of the network itself, see our investigation Can Flock Cameras Track You? What the Nationwide Network Can—and Can’t—Actually Do.

References and Further Reading

Primary and Company Sources

• Flock Safety Frequently Asked Questions — Flock’s current public description of its LPR architecture, including its statements that cameras use cellular LTE for data communications rather than customer Wi-Fi.

• Flock Safety: Gunshot Detection and License Plate Reader Security Alert — Flock’s May 2025 description of cellular transmission and its response to earlier hardware-security findings.

• Flock Safety Cybersecurity: How We Protect Customer and Community Data — Flock’s account of the 2025 carrier-side configuration incident that exposed diagnostic interfaces on a group of PTZ cameras.

• Flock Security Testing 2026: Bishop Fox Penetration Test Results — Flock’s September 2026 public summary of 36 findings from its Bishop Fox penetration test and the company’s stated remediation status.

• CVE-2025-59403 — CVE record describing unauthenticated administrative API functionality in the Flock Collins Android application reachable from a LAN/WLAN context.

• CVE-2025-59409 — CVE record describing development Wi-Fi credentials stored in cleartext in production Falcon/Sparrow firmware.

Security Research

• JakeSwiz: Flock Wi-Fi Recon — Source code, field logs and methodology behind the recent passive detection of repeated Wi-Fi probe requests from a known Flock-associated radio.

• GainSec: Button Presses to Wireless RCE on Flock License-Plate Readers — Documents the Falcon/Sparrow service hotspot and local administrative surface on researcher-owned hardware. The article contains offensive technical details; sherafy.com references it here as evidence of the Wi-Fi architecture, not as an instruction to test deployed systems.

• GainSec: Bird Hunting Season — Molting — September 2026 static-analysis comparison of newly obtained Flock LPR firmware against previously reported vulnerabilities.

Wi-Fi Protocol Reference

• Cisco IOS Command Reference: Empty or Wildcard SSID Probe Requests — Cisco documentation explaining that probe requests can specify an empty or wildcard SSID, useful for distinguishing a wildcard scan from proof of a specific hidden target network.

Independent Reporting

• WIRED: Hackers Got Inside a Flock Camera. Its Data Shows How the System Really Works — September 16, 2026 forensic analysis of recovered Flock LPR software and data, including evidence that selected camera data is sent over the cellular network.

Related sherafy.com Research

• Inside the Flock Camera Hack: What 1.6 Million Images Reveal About How the Cameras Actually Work — sherafy.com‘s detailed explanation of the September 2026 camera teardown, image bursts, short clips and on-device object detection.

• Can Flock Cameras Track You? What the Nationwide Network Can—and Can’t—Actually Do — sherafy.com‘s broader examination of how individual roadside observations become searchable movement records across the Flock network.

Editorial currency note: Flock’s firmware, network architecture, security controls and vulnerability-remediation status are changing. This article reflects public documentation and research checked through October 2, 2026. A future Flock technical statement explaining the observed Wi-Fi probe behavior, or additional packet captures showing actual association and traffic flow, could materially refine the conclusions above.