Thirteen of ClearPass's twenty-eight flaws are in the agent, not the server

The interim mitigation in HPE's advisory fits in one sentence and names two things: the CLI and the web-based management interface. Both sit on the server. Thirteen of the twenty-eight vulnerabilities in that same advisory do not.

The advisory is HPESBNW05158 rev.1, "Multiple Vulnerabilities in HPE Networking ClearPass Policy Manager (CPPM)", published on 6 October 2026. It carries 28 CVEs: ten critical, eleven high and seven medium. HPE Networking's own internal research found most of them —the advisory says "generally", and one, CVE-2026-79811, is credited to their bug bounty programme—, which is the best possible way for a list like this to arrive. As of the advisory date HPE says it is aware of no public discussion and no exploit code, and immediately after that asks you to patch now "due to the complexity, breadth, and impact of these vulnerabilities".

ClearPass Policy Manager is a NAC: the thing that decides whether a switch port or an SSID lets you in, and with which VLAN and which permissions. It is the RADIUS server the switches and access points ask. If you have never run one, the mental equivalent is the doorman: it holds nothing valuable, it only says yes or no, and that is why almost nobody counts it among the critical systems until it stops saying one of the two.

The affected versions, exactly as the advisory lists them: CPPM 6.14.0 and below and CPPM 6.11.15 and below. The fixed ones: 6.14.1 and above and 6.11.16 and above. Keep those four lines, because further down they decide whether yours is a patch or a migration.

The workaround sentence, in full

To minimize the likelihood of an attacker exploiting these
vulnerabilities, HPE Networking recommends that the
CLI and web-based management interfaces be restricted to a
dedicated layer 2 segment/VLAN and/or controlled by firewall
policies at layer 3 and above along with accounting controls
for tracking and logging user activities and resource usage.

It is good advice and we would sign it without changing a comma. Plain old management-plane hygiene: administration does not live on the user network, you put a firewall in front of it and you log who walks in. We have argued for it right here when the hole was in another vendor's management console, and we still do.

What that sentence does is draw a perimeter around one machine. The CLI is on the machine. The web-based management interface is on the machine. A dedicated layer 2 segment protects the machine. And the advisory containing that sentence splits its twenty-eight flaws between that machine and somewhere else.

The count, and the criterion behind it

We classified all twenty-eight by the component HPE names in each vulnerability title. If the title says OnGuard Agent, Client Agent, Client Software, Android Client Application or Client Interface, it goes on the client side. The rest go on the server side. The criterion is ours and it is arguable —some server-side flaws fire from a client and the other way round— but it has the virtue that you can redo it yourself with the advisory open. The result: thirteen on the client side and fifteen on the server side.

A detail that helps if you redo the list: the identifiers do not run consecutively. There is a short block in the CVE-2026-767xx series and a much longer one in CVE-2026-79xxx, which starts at CVE-2026-79794 and has two gaps inside it, 79795 and 79804, that do not belong to this advisory. The quick way to know whether you missed one is to reconcile your count against the split the advisory itself declares: ten, eleven and seven.

Two of those thirteen are 9.8 and ask for no credentials

The description of CVE-2026-76751 says where the code lands, and it is worth reading slowly because the word that matters sits at the end: "Successful exploitation could allow an unauthenticated, remote attacker to execute arbitrary code on the affected endpoint with the elevated privileges of the agent". On the endpoint. With the agent's privileges, which are the ones a posture agent needs to inspect your antivirus and your disk encryption, that is to say, high.

CVE-2026-76751
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Over the network, low complexity, no prior privileges and nobody has to click anything. CVE-2026-79801 belongs to the same family —missing integrity verification in the client agent— and carries the same vector. Neither goes through the web-based management interface, so neither is slowed down by putting that interface on its own VLAN. The workaround is correct for what it names. What it does not reach are those thirteen, and an uncomfortable caveat is due on the remaining fifteen: four sit in the API (79803, 79809, 79811 and 79818) and the 9.8 format string one, 76753, is placed by the advisory in "an affected service interface", without saying which. Assuming that segmenting the management web covers them all is your assumption, not HPE's claim.

Where the agent lives (the answer is not "on the LAN")

OnGuard is ClearPass's posture agent. HPE's documentation describes the persistent one as a program installed on the end system that runs in the background and periodically reports health information to the Policy Manager's posture check service. What it checks is a long list —antivirus, firewall, patch management, disk encryption, USB devices, processes— and checking all of that means being inside the operating system, not looking at it from outside.

That changes this advisory's asset list. The asset is the appliance and also every company laptop carrying the agent, including the ones that this week are at somebody's house or in a client's office. CVE-2026-79797 is the most awkward of the thirteen for a very concrete inventory reason: it is the Android client application, and an app somebody installed by hand on their own phone shows up in no installed-software report anywhere in the estate.

The 6.12 and the note almost nobody reads

The advisory fixes on two branches and only two: 6.14.1 and 6.11.16. But ClearPass's published branches are not two. 6.12 exists, it is deployed, and it falls inside the "CPPM 6.14.0 and below" the advisory declares affected — and it has no fixed version in this list. For that case the answer is not in the version table, it is in a note inside the resolution section that is easy to skim past:

NOTE: Product software versions that have reached End of
Maintenance (EoM) are presumed to be affected by the
vulnerabilities unless explicitly stated otherwise and are
not covered by this security advisory. For deployments
running software versions that are past End of Support
(EoS), HPE Networking has not assessed exposure to the
vulnerabilities referenced in this advisory. As a result,
such installations should be considered potentially impacted
by the listed CVE. Customers are strongly encouraged to
upgrade to a supported software release to ensure proper
evaluation and remediation.

Read slowly, that says two different things. If your branch is at end of maintenance, you are presumed affected and this advisory will tell you nothing further. If it is past end of support, HPE has not looked at all. In both cases your job stops being a change window to apply a patch and becomes planning a branch jump, with its policy testing, its profile validation and its rollback prepared. That is the difference between a maintenance task and a small project, and finding it out on Tuesday afternoon is worse than finding it out today. So the first step is not the patch: it is checking which branch you are on and whether HPE's lifecycle still has it in maintenance.

The question the advisory does not ask

If your ClearPass is a single appliance, patching it means stopping it. In a cluster it rolls node by node and nobody notices, as long as the switches and controllers have more than one RADIUS server configured — and that is exactly what is worth checking beforehand, not during. Either way there is a stretch where the thing that says yes or no to a port or a wireless association may not be there, and at that point the question stops being a security question and becomes an architecture one: what does your network do when RADIUS does not answer?

There are three possible states and only two of them get chosen on purpose. The first: if nothing is written in the switch template for that case, a port whose authentication server does not reply is not authorised. The second: if somebody planned for the scenario, it is written down. In Cisco's documentation that plan has a name and a command —critical authentication, with authentication event server dead action authorize vlan vlan-id— and what it does is authorise the port into a VLAN you chose, with the access you decided, for as long as the server is away. And the third, the one almost nobody remembers configuring: authentication open, the port wide open, left that way during the rollout so nobody got locked out, and still there.

A caveat before dramatising: already-authenticated sessions tend to survive a short server outage, so what breaks first are new connections and reauthentications. The person who arrives at nine and plugs in their laptop notices; the one already inside does not. That makes the scenario trickier, not milder: the impact depends on what time you touched it and how often your network reauthenticates, two things nobody checks before asking for the window.

Failure is inevitable, an outage is a design decision. The NAC will go down at some point, for a patch or for anything else; whether the company stops working when it does, whether everybody walks in unasked, or whether laptops land in a contingency VLAN with access to the ERP and nothing else, is a decision somebody made or failed to make. We said this in September about a different NAC and a different advisory, and we are saying it again here because HPE's advisory puts the date of the window back on the table. With other parts it has the same shape: a certificate that expires and takes the VPN down is a question of what nobody wrote for the day that part goes missing, and a site-to-site tunnel that asks nobody for a second factor is too. The component changes; the gap does not.

The order we would work in

What we are not claiming

With one console, a small laptop estate and an endpoint manager that works, your own people can do this unaided: the version is on one screen and the agent census is one report. It gets complicated when the network has been growing in layers for years —switches from three generations, a wireless setup installed by a supplier who is long gone, port templates nobody has reread— and the question in point 5 has no written answer. That work, leaving the network documented and its failure behaviour decided on purpose, is networks and communications, and putting judgement behind a branch jump nobody wants to sign off is consultancy. We sell both, so read it with the conflict of interest up front. If your people already have both answers, good. If you looked away when you got to point 5, let us talk.

Sources