ClearPass PHP Fixes Require the Matching Hotfix
A ClearPass upgrade record needs more than the base version. HPE’s 29 October revision adds an exceptional hotfix route for 6.12.8 alongside its existing 6.14.1 and 6.11.16 patches. Each route requires the matching additional PHP hotfix, so seeing one of those base releases on an appliance is not sufficient evidence of remediation.
The HPE security bulletin addresses two unauthenticated remote-code-execution flaws, CVE-2026-109618 and CVE-2026-109619. HPE rates both Critical at 9.8 under CVSS 3.1. The important operational question is which appliance patch has actually been applied.
Keep the base release and hotfix together
The listed combinations are ClearPass 6.14.1 with its PHP hotfix, 6.11.16 with its corresponding hotfix, and 6.12.8 with the exceptional patch added on 29 October. Obtain the exact package and applicable installation guidance through HPE’s support channel.
Record the appliance identity, base release and installed hotfix as separate fields in the maintenance evidence. A filename in a download folder establishes only that somebody obtained a file. A change request establishes intent. Neither shows that the correct software is running on the intended system.
For a deployment containing several appliances, reconcile that evidence against the actual inventory. Identify any node still awaiting maintenance and any uncertainty about its patch state. Keep the remaining work explicit instead of treating the first successful change as proof that the whole deployment is complete.
An exceptional patch is not a support renewal
HPE still lists 6.14.x and 6.11.x as supported at the bulletin’s publication date. The exceptional 6.12.8 addition does not announce renewed branch support. End-of-maintenance releases are presumed affected; exposure on end-of-support releases has not been assessed.
Keep the immediate security correction and the longer-term migration decision visible as separate responsibilities. An exceptional package can address a specific vulnerability without settling the future maintenance of that software branch. Obtain a supported destination and a workable transition plan from the responsible product owner.
Reduce exposure while the correction is outstanding
HPE recommends restricting administrative access through dedicated network segments or firewall policies, with activity accounting. It also asks customers to consider removing guest portals and all management interfaces from public access. The base releases offer some mitigation; HPE identifies the final hotfixes as the complete correction.
Any access restriction needs an authorised owner who understands the service dependency. Establish how administrators will retain a safe management route and how a guest-access change will affect users. Record the decision, its scope and its review point alongside the patch work.
A temporary control should have a clear end condition. Retain evidence of the interface exposure that was reviewed, the systems covered by the decision and any exceptions. Do not translate a restricted management path into a claim that an unpatched appliance is fixed.
Close the appliance change on observed evidence
After the authorised maintenance, confirm the intended base-and-hotfix combination on each in-scope appliance and check the services it provides. Retain the observed result and any recovery action with the change record. Download success and a closed ticket are useful records, but they are not a substitute for the resulting software and service state.
Use the current ClearPass bulletin for this appliance decision. HPE directs Juniper products to a separate assessment, and an appliance-specific hotfix is not a general PHP update for every other system in the estate. Keep each product’s correction tied to its own vendor guidance.
