A Police Technology Vendor Told CISA That No Further Actions Are Required by Customers. Nothing on Earth Can Check That.
Three times this week we measured the same gap: a fix existed, shipped, and never took effect, and no instrument anywhere reported the difference. A patched Collabora server that sat off the federal exploited list for forty-two days. A boot-manager flaw patched in January 2022 and exploited again last week. Our own laptop, which still trusts a compromised certificate authority after a full major operating-system upgrade.
Those were low stakes. This one is license plate readers holding criminal justice records.
What the advisory says
In June 2024, CISA published ICS advisory ICSA-24-165-19 covering the Motorola Solutions Vigilant Fixed LPR Coms Box, versions 3.1.171.9 and prior. Seven vulnerabilities:
CVE-2024-38281 — hard-coded credentials. CVSS v4 8.6.
CVE-2024-38284 — authentication bypass by capture-replay. CVSS v4 8.7.
CVE-2024-38282 — insufficiently protected credentials. CVSS v4 8.5.
CVE-2024-38280 — cleartext storage on disk. CVSS v4 7.0.
CVE-2024-38285 — insufficiently protected credentials. CVSS v4 7.0.
CVE-2024-38279 — authentication bypass via an alternate path. CVSS v4 5.1.
CVE-2024-38283 — missing encryption of sensitive data. CVSS v4 5.1.
Hard-coded credentials and replay-based authentication bypass, on roadside hardware that collects and stores vehicle movement.
Now the remediation status, in CISA's published wording, for all seven: Motorola Solutions "has already remediated this vulnerability for all vulnerable systems," and "No further actions are required by customers."
We have no evidence that is untrue. That is not the problem with it.
The problem is that it cannot be checked
Here is what would normally let an outsider verify a remediation claim, and what exists in this case.
A fixed version number. The advisory names affected versions, 3.1.171.9 and prior, and never names a fixed one. There is no number a police department can check its own hardware against.
A CVE record from the vendor. Motorola Solutions is not a CVE Numbering Authority. We checked this against the CVE Program's own published list of CNAs — 559 organizations — and neither Motorola Solutions nor Avigilon appears in it. Its product advisories are posted to vendor documentation pages, and the index of those entries carries dates rather than CVE identifiers.
For scale, we ran the same check against fifteen security vendors: fourteen of the fifteen are CNAs. Issuing your own CVE identifiers is the expensive, unglamorous half of product security, and the security industry overwhelmingly does it. A surveillance vendor selling to police departments does not.
A KEV entry. None of the seven has ever appeared in CISA's Known Exploited Vulnerabilities catalog. We pulled the catalog directly: version 2026.10.23, 1,756 entries, and there is no Motorola Solutions or Avigilon entry in it at all. That is not reassuring, because a vendor that does not issue CVEs is a vendor whose product flaws cannot reach the list in the first place. The silence is structural, not evidential.
A way to tell them. There is no security.txt at motorolasolutions.com. We checked both the apex and the www host; both return 404. RFC 9116 has been a standard since 2022, and for a company selling surveillance and dispatch to public-safety agencies, the absence means a researcher who finds something has no published route to report it. More on that at the end, because we ran into it ourselves.
So the claim stands alone. Not disproven — unfalsifiable. And two sentences in the advisory are worth reading twice. "All devices shipped after May 10, 2024 are already using full disk encryption" tells you what the devices shipped before that date are doing. And "devices that cannot take full disk encryption have had their CJI data encrypted" says, in the vendor's own words, that there are units in the field which cannot do full disk encryption and are holding criminal justice information.
What we could measure from outside
We ran the same attack-surface pass we run on any domain, using only public data: certificate transparency logs and public DNS resolvers. We sent nothing to their infrastructure.
505 unique subdomains appear in certificate transparency for motorolasolutions.com. Of those, 124 name their own non-production tier — 78 containing "dev," 24 "test," 18 "qa," and 4 "uat." Nineteen contain "admin." Twenty sit under a "fed" label.
Checking which of those still resolve, a federal staging administrative portal answers in public DNS, on commercial Azure. So does a development administrative API. We are not publishing those hostnames. Anyone can derive them from the same public logs in about a minute, and that is rather the point, but a blog post should not be the map.
Credit where it is earned, because it is: the production federal administrative API resolves into Azure US Government cloud, through a government traffic manager. That is the correct architecture and somebody built it deliberately. The gap is not competence. It is that the staging twin of a federal admin portal is reachable from the open internet, and that 124 non-production names are permanently inscribed in a public log.
Four more names have certificates and no longer resolve, including a production Adobe Experience Manager author instance and a package-signing host. Decommissioned or renamed, most likely, and not a vulnerability. But a certificate is forever, and those two names tell an attacker exactly what to go looking for under a different one.
What this is and is not
We found surface, not vulnerabilities. We did not scan their hosts, did not test a single endpoint, and hold no evidence that anything on those 505 names is unpatched. Whether it is remains unmeasured, by us and as far as we can tell by anyone outside the company.
That restraint is the whole argument. We could find out. It would not be difficult. We are not going to, because the line between research and intrusion is the consent of the operator, and on police infrastructure it is not a close call.
But notice what that leaves. The people who respect that line can measure nothing, and the people who do not respect it already know. "No further actions are required by customers" is a statement only the second group can evaluate.
The one thing we would actually ask for
Not a product. Not an audit. A file.
Publish a security.txt. It costs nothing, it takes an afternoon, and it means the next person who finds something has somewhere to send it. We went looking for a channel to send this piece to before publishing it and did not find one — no RFC 9116 record, and a submission form with no stated timeline and no acknowledgment commitment. So we are publishing it, which is the worse option for everybody including us.
And for the police departments and municipalities running this hardware, one question is worth putting in writing to your vendor, because the advisory does not answer it: was my specific unit remediated, on what date, and what is the version number that proves it? "All vulnerable systems" is a claim about a population. You operate a device.
Patch state is not trust state. On a server that costs you a bad afternoon. On a camera holding criminal justice records, it costs somebody else considerably more, and they will never know to ask.
If you run Vigilant hardware and you get an answer to that question, we would genuinely like to hear it — and if Motorola Solutions wants to tell us we have this wrong, the rating widget below reaches us and so does a reply.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=a-police-technology-vendor-told-cisa-that-no-further-actions-are-required-by-customers-nothing-on-e
Comments