Florida DAVID breach: 200,000 licenses via a police account

Two versions, two fixes

The official version (one account, poorly stored credentials) and the attackers' version (a reset flaw, several accounts, mass enumeration) call for different remedies. A stolen credential on a personal phone is handled with MFA and device rules. A password reset that lets someone take over arbitrary accounts is a product defect that affects every user. The agency has confirmed neither the volume nor the method and points to the ongoing investigation.

This kind of system exists in many B2B products: a high-privilege back office where institutional accounts (customers, partners, authorities, support) view individual records.

Why institutional accounts are targeted

Partner accounts (police officers, staff from other agencies, contractors) are often less closely monitored than employee accounts: they belong to another organization, with its own device and password rules, and nobody on your side is responsible for them day to day. Yet they open the same records. When one of them is compromised, the signals that would catch an employee account (a new device, an unusual location) are often not even collected.

Flaw 1: credentials outside the controlled perimeter

Credentials saved in a file, a browser or a notes app on a personal device, without effective MFA: device theft, spyware or a cloud backup is enough to recover them.

Test: for every account able to view records, is sign-in possible from an unmanaged device? Is MFA required at every sign-in, or only the first time on a new browser? Do long sessions survive a password change, or are they all revoked at once?

Flaw 2: an under-verified password reset

The mechanism meant to rescue authentication becomes the main attack path. The classic mistakes: a predictable or reusable reset token, a link sent to an address that can be changed in the same request, a security question, a Host header used to build the link, a reset that disables MFA. They are detailed in our article on the 7 password reset mistakes.

Test:

1. Request two resets for a test account: is the first link invalidated? Does the token expire in under an hour?
2. Intercept the request and add a second email, or change the Host header: does the link go elsewhere or point to another domain?
3. After the reset, is MFA still required? Are existing sessions terminated? Does a notification go to the known address?

Flaw 3: enumerable records

Harvesting records by iterating over IDs means thousands of sequential requests triggered no limit and no alert.

Test: with a test account, chain a few hundred lookups on consecutive IDs. Does the API slow down or block, and is anyone notified? Are the IDs sequential, or random enough that guessing them is pointless? See our article on enumeration and rate limiting.

How to fix it

1. Phishing-resistant MFA on every access to personal data, with no exception for "trusted" accounts, which are precisely the ones targeted.
2. Managed devices only for high-privilege accounts.
3. Treat the reset flow as an attack surface: random, single-use, short-lived tokens, no MFA bypass, systematic notification.
4. Per-account viewing caps and alerts on sequential lookups.
5. Logs kept and protected: when a group claims a breach and the organization downplays it, only complete access logs establish the real scope.

An industrialized playbook

ShinyHunters shows up in several 2026 cases, such as the Trezor phishing sent through Brevo. The pattern is constant: one access, one database, one ransom demand, publication on refusal. The useful question becomes: how many records can a single compromised account extract overnight, and what stops it?

What shifts for an AI agent because of the DAVID breach?

An AI agent connected to this kind of back office (to answer staff, check a record, prepare a report) combines all three flaws: it holds a privileged account, its credentials live in a configuration file, and it can chain lookups without ever getting tired. A prompt injection in a document or message it processes can make it walk through records by ID and copy their contents. Its lookups must be capped, limited to the record in the request and logged under the name of the person actually using it.

To check how many records a manipulated agent can extract from your back office, the Agent Red Team Express tests that scenario in five days.