Advisory · CVE-2026-80110
Red Hat Certificate System ACL tie-break lets agents author CA issuance profiles
A tie-breaking bug in the pki-core v2 REST ACL filter resolves colliding literal and wildcard ACL keys by lexicographic comparison instead of specificity, letting the Certificate Manager Agents group's lower-privileged profiles.approve override the Administrator-only profiles.create required by POST /v2/profiles/raw.
- Vendor
- Red Hat
- Product
- Red Hat Certificate System
- Identifier / CWE
- CVE-2026-80110
CWE-863 - Action timing
- Immediate
Explain it like I’m five
The certificate authority's doorman checks a permission list for every request. When two rules cover the same door, the doorman picks the tie winner alphabetically instead of picking the more specific rule. An agent with a junior badge can therefore walk through an administrator-only door and rewrite the certificate-issuing rulebook.
- 01Colliding ACL keys
The v2 REST ACL filter encounters both a literal and a wildcard key matching a profile-management request.
- 02Wrong tie-break
It resolves the collision by lexicographic string comparison instead of specificity, letting the wildcard-mapped profiles.approve win over the literal-mapped profiles.create.
- 03Agent credential
An authenticated member of the default Certificate Manager Agents group sends POST /v2/profiles/raw, which is authorized under their profiles.approve permission.
- 04Profile authored
The agent authors and activates an arbitrary certificate-issuance profile, an operation meant to require Administrator privilege.
What happened
Red Hat published CVE-2026-80110 on September 21, 2026, rating it Important with a CVSS base score of 8.1. The flaw sits in pki-core, the component behind Red Hat Certificate System and the dogtag-pki packages on Red Hat Enterprise Linux.
When the v2 REST ACL filter sees both a literal and a wildcard ACL key matching the same request, it breaks the tie with a lexicographic string comparison rather than choosing the more specific rule. In the CA’s profile-management REST API, that means the wildcard-mapped profiles.approve permission overrides the literal-mapped profiles.create permission that POST /v2/profiles/raw is supposed to require. A member of the default Certificate Manager Agents group, which holds the lower-privileged approval right, can therefore author and activate an arbitrary certificate-issuance profile.
Red Hat’s statement is direct: an authenticated non-administrative agent can compromise the integrity of the CA’s issuance policy and create a confidentiality risk for relying parties trusting the resulting certificates. Per the NVD record, RHEL 9 (pki-core), RHEL 10 (dogtag-pki), and RHEL 8 (pki-core:10.6) are affected.
What to do
- Inventory Red Hat Certificate System 9 and RHEL deployments running dogtag-pki / pki-core, including internal CAs that operators forget are CAs.
- Apply the Red Hat security update as soon as it is available. Red Hat states there is no way to mitigate this issue other than applying an update once available.
- Until the update lands, limit membership in the Certificate Manager Agents group to trusted users only, since exploitation requires an authenticated credential in that role.
- Review CA audit logs for certificate profile creation or modification events (particularly via
/v2/profiles/raw) by non-administrator principals. - Check whether any profiles were created or activated since exposure began and whether any certificates issued under them are still trusted; plan revocation if so.
- Verify the deployed package version after patching and confirm the fix is in place before restoring normal agent group membership.
Management note
This is a privilege boundary failure inside a certificate authority, the one service whose trust relationships everything else depends on. The remediation is straightforward once the update ships, but the review of profiles and issued certificates is the part that determines whether the trust store is still clean. Treat the update and the audit as one task.