ALPR is the part of Security Center most people forget is even running. The cameras and doors get the attention. The license plate reader role sits in the background, quietly doing its job, until a CVE lands on it. This week one did.
Genetec disclosed CVE-2025-43028, a high-severity vulnerability in the ALPR Manager role of Security Center. CVSS 8.2. The legacy protocol that Genetec Patroller and SharpV G1 and G2 cameras use to talk to the ALPR Manager can be abused to exfiltrate sensitive data the role handles. Genetec’s own engineering team found it, and there’s no evidence anyone has exploited it in the wild. Yet.
This is not only an AutoVu problem, and that’s the part worth slowing down on. The obvious read is that it hits plate-reading shops: municipalities, parking enforcement, campus and toll operators, anyone running Patroller in a vehicle or SharpV cameras on a pole. Those are squarely in the blast radius. But this is also the second serious bug in the ALPR Manager role in a matter of months. Back in October, CVE-2025-43027 was a 9.8 critical auth bypass in the same role, and the detail that caught everyone flat was this: the ALPR Manager has been enabled by default on every Security Center instance since 5.11.0.0, whether or not you ever licensed AutoVu. Meaning the role is probably running on your system even if you have never read a license plate in your life. So before you decide this isn’t you, go look.
The newer protocol is fine. The old one is the problem. SharpV cameras connected to the ALPR Manager over the LPM protocol are not affected. The LPM protocol is the secure path, and it’s the one you want everything on. SharpV G3 is already there by default, so G3 deployments sit this round out. It’s the legacy protocol, the one G1 and G2 cameras and older Patrollers still use, that carries the exposure.
Here’s the trap, and it’s the reason I’m writing this instead of just linking the advisory. Patching does not finish the job. To keep fleets from dropping offline mid-migration, the updated ALPR Manager role keeps temporary backward compatibility, which means it will still accept connections from old, unsecure Patrollers after you patch. Update the role, update your Patrollers, walk away feeling done, and the legacy door is still propped open. You are not mitigated until legacy connectivity is off.
That toggle turns off 2 ways. Automatically, once every previously connected Patroller has been updated to version 7.0.2 and has checked in at least once. Or manually, through the legacy Patroller connectivity (unsecure) switch in Config Tool, under ALPR, roles and units, live settings. Flip it off and any Patroller still running version 6 or below gets disconnected until it’s upgraded. One thing to know going in: once legacy support is off, you cannot turn it back on. There’s no undo, which is the point.
The order of operations is not optional either. Update the ALPR Manager role first, then the Patrollers. Do it backwards and you’ll have new Patrollers with nothing current to talk to. Genetec has also wired in a couple of guardrails worth knowing about: Config Tool now throws a warning when a Patroller connects on the legacy protocol, and Patrollers on version 6 and below can no longer be added at all.
The steps, in plain order
- Update Config Tool to the patch build for your Security Center version (table below).
- Update the ALPR Manager role first. Grant the “register Patroller” privilege to whoever is going to register the units.
- Update every Patroller to version 7.0.2 and connect each one to the ALPR Manager so the update registers.
- Confirm the legacy Patroller connectivity (unsecure) toggle is off in Config Tool. Don’t assume it flipped on its own. Go look at it.
- Update all SharpV G1 and G2 cameras to the latest SharpV OS and make sure they’re connected over LPM, not the legacy protocol.
Affected versions and patches
| Product | Affected versions | Patch |
|---|---|---|
| AutoVu Patroller | 6.7.1 and before | 7.0.2 |
| Security Center 5.13 | 5.13.3.5 and before | 5.13.3.6 |
| Security Center 5.12 | 5.12.2.13 and before | 5.12.2.14 |
| Security Center 5.11 | 5.11.3.25 and before | 5.11.3.26 |
| Security Center 5.10 | 5.10.4.29 and before | 5.10.4.30 |
| Security Center 5.9 | 5.9.5.10 and before | 5.9.5.11 |
| SharpV G1 | 13.8.3 and before | SharpV OS 13.8.4 |
| SharpV G2 | 13.8.3 and before | SharpV OS 13.8.4 |
| SharpV G3 | Not affected (already on LPM) | NA |
| Any other Security Center version | All | Move to a supported version |
If you can’t patch the fleet quickly, you still have a move. Set legacy Patroller connectivity to off now. That mitigates the vulnerability and keeps old Patrollers out until they’re upgraded to 7.0.2. And if you can’t touch the ALPR Manager role or the SharpV cameras promptly, fall back to the basics: restrict network access to trusted sources only, and put the traffic behind a VPN or equivalent controls. None of that is a fix. It’s a fence around the problem until you fix it.
One more thing about that table. Yes, there’s a patch for 5.9. No, that doesn’t mean you should feel comfortable on 5.9, because Security Center 5.9 is end of life as of December 2025 and stopped receiving security patches. Read a late CVE fix for a dying version as exactly what it is, a courtesy, not a reprieve. Patch this, then plan your way off 5.9 before the next advisory shows up and there’s nothing waiting for you.
The patch closes the code. Turning legacy connectivity off closes the hole. Go confirm the toggle.