CVE-2026-80110

Executive Summary

CVE-2026-80110 is an authorization-logic flaw in pki-core (the Red Hat / Dogtag Certificate System codebase) in which the v2 REST ACL filter resolves a collision between a literal ACL key and a wildcard ACL key by lexicographic string comparison instead of by specificity. This causes the wildcard-mapped permission to win, allowing a caller holding only the lower-privileged profiles.approve permission (granted by default to the Certificate Manager Agents group) to invoke POST /v2/profiles/raw, an endpoint intended to require Administrator-level profiles.create. Because this endpoint governs the CA's issuance policy, successful abuse undermines the confidentiality and integrity of the certificate authority itself. CVSS v3.1 base score is 8.1 (High), reflecting network reachability, low attack complexity, and high confidentiality and integrity impact, tempered by the requirement for low-privileged authentication.

Technical Analysis

The vulnerability resides in the access-control evaluation logic of the pki-core v2 REST interface. Authorization in this interface is expressed as a set of ACL entries mapping request attributes to permissions. When two ACL entries both match a given request — one via a literal key and one via a wildcard key — the implementation must decide which entry's permission applies. Correct behavior in ACL systems (for example, classless inter-domain routing longest-prefix matching, filesystem path resolution, and role-based inheritance models) is to select the most specific match, so that a narrowly scoped rule always overrides a broad catch-all rule.

CVE-2026-80110 records that pki-core instead performs a lexicographic string comparison to break the tie. A wildcard key and a literal key are compared as raw strings, and the lexicographically greater (or otherwise winning) form is selected regardless of which one is more specific. Because the ordering imposed by string comparison is unrelated to the semantic specificity of the ACL entries, a wildcard-mapped permission can be selected over a literal-mapped permission when both match the same request. This is a classic authorization-ordering defect: the set of rules evaluated is correct, but the precedence function is wrong, yielding an unintended effective permission for a request that matches both.

The concrete consequence described in the advisory is a privilege escalation across named permissions in the CA's profile-management REST API. POST /v2/profiles/raw is intended to be gated on the Administrator-level profiles.create permission. Under the flawed tie-break, the endpoint is instead authorized using the profiles.approve permission. profiles.approve is held by the default Certificate Manager Agents group — a materially lower-privileged role than Administrator. The result is that an authenticated Certificate Manager Agent can reach an endpoint whose authorization model assumes Administrator authority.

The attack surface is the CA's v2 REST management interface, which is normally bound to an administrative network segment but is frequently reachable from internal management networks, jump hosts, and CI/CD or automation infrastructure that holds agent credentials. The flaw requires authentication (PR:L) and no user interaction (UI:N), and is reachable over the network (AV:N) with low complexity (AC:L). There is no scope change (S:U), meaning the exploit stays within the same security authority — but within that authority it yields high impact on both confidentiality (C:H) and integrity (I:H) because the affected endpoint controls the CA's issuance policy. Availability is not impacted (A:N), consistent with an authorization-bypass defect rather than a resource-exhaustion or crash condition.

CWE-863 (Incorrect Authorization) accurately describes the class: the system checks that the caller is authorized, and returns an authorization decision, but the decision is computed against the wrong rule. No public exploit code, Nuclei template, or proof-of-concept is known, and the vulnerability has not been added to CISA KEV. No affected version ranges, OSV package mappings, upstream patches, or vendor workarounds were published in any tracked source at the time of writing, so operators cannot currently identify fixed builds by version number and must treat all versions of the affected component as potentially vulnerable.

Exploitation Scenarios

No public proof-of-concept exists for CVE-2026-80110; the chain below is inferred from the vulnerability class and the endpoints and permissions named in the advisory. No further function names, parameters, or payload syntax are asserted, because none are provided in the source data.

1. Reconnaissance and target identification. An adversary operating from an internal network position identifies a Certificate System instance exposing the v2 REST management interface. This is typically discovered by port and HTTP title scanning against common PKI management ports, or by enumerating internal asset inventories and DNS for CA hostnames. The goal at this stage is not to find the ACL bug — which is invisible externally — but to acquire credentials that carry the profiles.approve permission.

2. Credential acquisition for the lower-privileged role. The attacker obtains the credentials of a Certificate Manager Agent, or compromises a host, service account, or automation pipeline that holds agent credentials. This is the precondition the CVSS vector encodes as PR:L: exploitability depends on possession of a low-privileged authenticated identity, not on breaking authentication.

3. Triggering the tie-break flaw. The attacker sends an authenticated request to the CA's profile-management REST API, specifically POST /v2/profiles/raw. In a correct implementation this request is matched to the literal ACL governing profiles.create and therefore denied for an agent identity. Because of the lexicographic tie-break described in the advisory, the colliding wildcard ACL entry wins and the request is authorized under profiles.approve, which the Certificate Manager Agents group holds by default. The attacker therefore reaches an Administrator-level endpoint without ever holding Administrator rights.

4. Post-exploitation impact. Having reached POST /v2/profiles/raw, the attacker can act against the CA's issuance policy — the artifact this endpoint is designed to control. The advisory explicitly frames the highest threat as loss of confidentiality and integrity of that issuance policy. Downstream, manipulation of issuance policy can cause the CA to issue certificates under attacker-influenced constraints, weakening the trust guarantees that relying parties assume when they validate certificates from this authority. Because the action is performed with a legitimately authenticated low-privileged identity, it may blend into normal agent activity and not trip naive authentication-failure alerting.

An important limitation: the advisory does not describe the request body, header requirements, CSRF posture, or exact privilege required beyond profiles.approve. Analysts should not assume any particular payload structure.

Impact Assessment

The primary business impact is a breach of trust in the certificate authority's issuance policy. The affected endpoint, POST /v2/profiles/raw, is the programmatic control for profile (issuance policy) management; unauthorized modification of issuance profiles has effects that extend well beyond the CA host itself, because every certificate the CA subsequently issues is produced under whatever policy is in force at issuance time.

Blast radius. The immediately affected asset is a pki-core / Certificate System deployment exposing the v2 REST interface. The downstream blast radius includes all relying parties that trust certificates issued by that CA: internal TLS endpoints, client authentication for VPN and wireless, code-signing and device-identity chains, and any federation or cross-signing relationships. Because a compromised or altered issuance policy can persist until it is discovered and corrected, the exposure window is measured in issuance events, not in the duration of a single request.

CVSS subscores in context. AV:N (network) means the flaw is exploitable remotely with no physical or adjacent access requirement; the practical bar is network reachability to the management interface plus valid agent credentials. AC:L (low complexity) means no race condition, timing window, or memory-layout grooming is required — the flawed decision is deterministic for a colliding request. PR:L (low privileges) confirms that a default Certificate Manager Agent identity is sufficient, which is the crux of the escalation: the attacker does not need Administrator rights, only the weaker role. UI:N (no user interaction) removes the need to coax a privileged operator into any action. S:U (unchanged) means the exploit does not cross a security authority boundary in the CVSS sense, but C:H/I:H indicates that within that authority the confidentiality and integrity damage is high. A:N indicates no denial-of-service component is claimed.

Severity context. A CVSS v3.1 base score of 8.1 is High. The score reflects high integrity and confidentiality impact offset by the low-privilege precondition. It is not Critical (9.0+) strictly because PR:L rather than PR:N is required and availability is unaffected; operators should not read the "sub-Critical" score as a reason to deprioritize, because the asset is a CA and the integrity loss is in the trust anchor itself.

EPSS. As of the data provided, FIRST.org has not yet assigned an EPSS score for this CVE. No probabilistic exploitation-likelihood estimate is asserted here. Exploitation does not appear in CISA KEV, and no public exploit code or Nuclei template is known, which lowers near-term likelihood but not potential severity.

Detection Guidance

The detection problem here is unusual: the exploit uses valid credentials and a well-formed request to an administrative API, so signature-based detection on malformed input will not fire. Detection should focus on the authorization anomaly (a lower-privileged identity reaching an Administrator-gated endpoint) and on the audit trail of the profile-management API. The rules below are behavioral baselines; they will require tuning to local log schemas, group names, and host inventories.

Sigma Rule

title: Dogtag PKI v2 REST Profile API Authorized via Lower-Privileged profiles.approve Permission
id: 9f2c1a44-7c0e-4f0b-9b1e-3d5a6e7f8011
status: experimental
description: >
  Detects authorization of CA profile-management REST requests against the
  lower-privileged profiles.approve permission instead of the intended
  Administrator-level profiles.create permission (CVE-2026-80110).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-80110
author: valtersit.com
date: 2026/01/01
logsource:
  product: pki
  service: dogtag
detection:
  selection_endpoint:
    - cs_uri|contains: '/v2/profiles/raw'
    - request_uri|contains: '/v2/profiles/raw'
  selection_permission:
    - permission|contains: 'profiles.approve'
    - acl_result|contains: 'profiles.approve'
    - authz_permission|contains: 'profiles.approve'
  selection_method:
    method: 'POST'
  condition: selection_endpoint and selection_permission and selection_method
falsepositives:
  - Legitimate administrator activity that logs both approvals and profile writes
  - Environments where profiles.approve is intentionally granted to trusted automation
level: high
tags:
  - attack.t1190
  - cve.2026.80110
  - cwe.863

YARA Rule

rule CVE_2026_80110_PKICORE_ACL_TIEBREAK
{
    meta:
        description = "Identifies pki-core / Dogtag artifacts referencing the v2 profiles raw REST endpoint and profiles.approve ACL material; hunting aid, not an exploit signature"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-80110"
        cve = "CVE-2026-80110"
        date = "2026-01-01"

    strings:
        $ep1 = "/v2/profiles/raw" ascii wide nocase
        $perm1 = "profiles.approve" ascii wide nocase
        $perm2 = "profiles.create" ascii wide nocase
        $acl1 = "profiles" ascii wide nocase
        $wild = "*" ascii

    condition:
        uint32be(0) != 0x7f454c46 and
        filesize < 20MB and
        (
            ($ep1 and ($perm1 or $perm2)) or
            ($perm1 and $perm2 and $acl1)
        )
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-80110 pki-core v2 Profile API privilege escalation attempt (POST /v2/profiles/raw)"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/v2/profiles/raw"; nocase; reference:cve,2026-80110; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-80110; classtype:attempted-admin; metadata:created_at 2026_01_01, updated_at 2026_01_01; sid:202680110; rev:1;)

Elastic Detection

sequence by user.name, source.ip with maxspan=5m
  [ authentication where event.action == "authentication_success"
      and user.name != null ]
  [ network where http.request.method == "POST"
      and url.path == "/v2/profiles/raw"
      and user.name != null ]

Splunk SPL Query

index=pki sourcetype=dogtag:access OR sourcetype=dogtag:audit
| eval uri=coalesce(cs_uri, request_uri, url_path, uri)
| eval perm=coalesce(permission, authz_permission, acl_permission, required_permission)
| where like(uri, "%/v2/profiles/raw%")
| where (like(perm, "%profiles.approve%") OR like(perm, "%profiles.approve%"))
| stats count min(_time) as first_seen max(_time) as last_seen
        values(clientip) as client_ips values(dn) as identities
        by host, uri, perm
| where count > 0
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

<group name="pki,dogtag,cve-2026-80110,">
  <rule id="202680110" level="12">
    <decoded_as>json</decoded_as>
    <field name="uri">/v2/profiles/raw</field>
    <field name="method">POST</field>
    <field name="permission">profiles.approve</field>
    <description>CVE-2026-80110: CA profile-management request authorized under lower-privileged profiles.approve permission</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>attack, privilege_escalation,</group>
  </rule>

  <rule id="202680111" level="10">
    <decoded_as>json</decoded_as>
    <field name="uri">/v2/profiles/raw</field>
    <field name="method">POST</field>
    <description>CVE-2026-80110: POST to CA profile-management raw endpoint by any identity - review authorization context</description>
    <group>attack,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, fixed version, affected-version range, or official workaround was published in any tracked source as of writing. The following are operator-side mitigations and hardening steps, not vendor remedies.

1. Immediate mitigations.

• Restrict network reachability of the v2 REST management interface to the smallest possible set of administrative networks, jump hosts, and automation subnets. Because the flaw is authorization-side, network segmentation is the most reliable near-term containment.
• Audit group membership for the default Certificate Manager Agents role and remove profiles.approve from any identity that does not strictly require it. The escalation depends on an agent identity holding that permission, so tightening it reduces the exploitable population.
• Rotate credentials for Certificate Manager Agent accounts and any automation identity holding agent privileges, particularly if those services are reachable from less-trusted networks.
• If a configuration-only profiles.approve grant is in place for agent groups, consider whether it can be narrowed or removed until an upstream fix is confirmed.
• Enable and forward the CA's REST access logs and audit logs, including the permissions evaluated per request, to the SIEM so the detection guidance above is actionable.

2. Patch/upgrade steps.

• Monitor the upstream pki-core project, Red Hat security advisories, and the NVD record for CVE-2026-80110 for a fixed build. No fixed version is currently identified.
• Maintain an inventory of every pki-core / Dogtag / Certificate System deployment in the environment, including secondary CAs, OCSP responders, and KRA/TPA instances, so that a patch can be applied immediately upon release.
• Prepare a change window and rollback plan now; CA upgrades typically require coordination with dependent services that trust the CA.
• Treat the absence of a version range as meaning all installed versions should be assumed vulnerable until an advisory states otherwise.

3. Long-term hardening.

• Adopt ACL review practices that explicitly test rule precedence: when two rules can match the same request, the resulting effective permission should be asserted in a test, not inferred. The class of defect here is undetectable by inspection of the rule set alone — only by evaluating precedence.
• Ensure administrative REST endpoints are governed by a default-deny model. A wildcard entry should never be capable of silently overriding a literal entry for a higher-privileged operation.
• Reduce reliance on shared, broadly granted agent roles. Apply least privilege to the profiles.approve and profiles.create permissions specifically, since these directly control issuance policy.
• Instrument the CA so that every profile-management write records the requesting identity, the permission evaluated, and whether a tie-break occurred. This turns a currently silent authorization anomaly into an auditable event.
• Include "authorization-precedence override" as an explicit test case in PKI change management, and periodically exercise it against the v2 profiles API.

References

• NVD — CVE-2026-80110: https://nvd.nist.gov/vuln/detail/CVE-2026-80110
• CWE-863 — Incorrect Authorization: https://cwe.mitre.org/data/definitions/863.html
• Dogtag Certificate System (pki-core) upstream project: https://www.dogtagpki.org/
• Red Hat Product Security advisories (pki-core) — monitor for a fixed build: https://access.redhat.com/security/
• CISA Known Exploited Vulnerabilities Catalog — CVE-2026-80110 is NOT listed: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• FIRST EPSS — no score currently assigned for this CVE: https://www.first.org/epss/

Threat actor and in-the-wild notes: there is currently no evidence of exploitation in the wild, no public proof-of-concept, no Nuclei template, and no known threat actor campaign associated with CVE-2026-80110. The vulnerability is not in CISA KEV. This absence of observed activity reflects a short observation window and the requirement for authenticated access, not an assessment that the flaw is unexploitable. Given the asset type — a certificate authority — any confirmed exploitation should be treated as a trust-anchor compromise requiring re-issuance and revocation review rather than a routine incident.