<Vulnerability name="CVE-2026-17039">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Low</ThreatSeverity>
    <PublicDate>2026-07-24T00:00:00</PublicDate>
    <Bugzilla id="2506720" url="https://bugzilla.redhat.com/show_bug.cgi?id=2506720" xml:lang="en:us">
pki-core: dogtag-pki: redhat-pki: pki-core: CA renewal request processing omits realm authorization check performed by enrollment path
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>3.1</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N</CVSS3ScoringVector>
    </CVSS3>
    <CWE>CWE-863</CWE>
    <Details xml:lang="en:us" source="Mitre">
A flaw was found in pki-core. The certificate authority (CA) renewal request path does not perform the realm-based authorization check that the enrollment path performs, allowing an authenticated user entitled to one realm to cause a certificate belonging to a different realm to be renewed without that realm's authorization.
    </Details>
    <Details xml:lang="en:us" source="Red Hat">
A flaw was found in pki-core. The certificate authority (CA) renewal request path does not perform the realm-based authorization check that the enrollment path performs, allowing an authenticated user entitled to one realm to cause a certificate belonging to a different realm to be renewed without that realm's authorization.
    </Details>
    <Statement xml:lang="en:us">
Red Hat Product Security assessed this issue as having Low impact. The certificate authority (CA) renewal request path does not perform the same realm-based authorization check as the enrollment path, which is a genuine authorization gap. However, exploitation additionally requires a non-default, though supported, deployment configuration: a realm-mapped authorization manager configured for multi-tenant or delegated sub-CA (MSP-style) use. Deployments that do not configure this feature are not exposed to this issue. Direct testing was performed to determine the practical consequences of the confirmed bypass rather than relying on the authorization gap alone to drive severity. That testing found no confidentiality impact, since the resulting certificate's content is already retrievable by any user through the product's own standard, intended certificate-lookup functionality, independent of this issue. No private key material is exposed at any point, so the issue cannot be used for impersonation. The victim's original certificate and their own ability to renew it are both unaffected, and revocation requires a separate, unrelated authentication mechanism this issue does not touch, so there is no denial-of-service capability. The concrete, demonstrated impact is limited to the creation of one additional, correctly and non-deceptively attributed certificate record outside the issuing realm's approval.
    </Statement>
    <Acknowledgement xml:lang="en:us">
Red Hat would like to thank Arpit Jain (Github: arpitjain099) for reporting this issue.
    </Acknowledgement>
    <Mitigation xml:lang="en:us">
Deployments that do not configure a realm-mapped authorization manager (AuthzRealmDefault with a non-default realm-to-authorization-manager mapping) for multi-tenant or delegated sub-CA use are not exposed to this issue. For deployments that do use realm-based authorization, using a renewal profile that additionally restricts renewal requests to the original requester narrows exposure: the shipped caDirUserRenewal.cfg profile configures authz.acl=user_origreq="auth_token.uid", which independently blocks cross-user renewal by comparing the renewing caller's UID against the UID that submitted the original request. This is a partial mitigation only -- it is realm-blind rather than realm-aware, so a UID collision across two independently-administered realms' user directories would still bypass it -- and it does not apply to caManualRenewal.cfg or other shipped renewal profiles that configure no authz.acl, which remain exploitable as described. No complete mitigation is available; apply the update once released.
    </Mitigation>
    <PackageState cpe="cpe:/a:redhat:certificate_system:10">
        <ProductName>Red Hat Certificate System 10</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>redhat-pki</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/a:redhat:certificate_system:11">
        <ProductName>Red Hat Certificate System 11</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>redhat-pki</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/a:redhat:certificate_system:9">
        <ProductName>Red Hat Certificate System 9</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>pki-core</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:10">
        <ProductName>Red Hat Enterprise Linux 10</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>dogtag-pki</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:6">
        <ProductName>Red Hat Enterprise Linux 6</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>pki-core</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>pki-core</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>pki-core</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>pki-core</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-17039
https://nvd.nist.gov/vuln/detail/CVE-2026-17039
https://access.redhat.com/security/cve/CVE-2021-20179
https://github.com/dogtagpki/pki/blob/master/base/ca/database/ds/acl.ldif
https://github.com/dogtagpki/pki/blob/master/base/ca/src/main/java/com/netscape/cms/servlet/cert/EnrollmentProcessor.java
https://github.com/dogtagpki/pki/blob/master/base/ca/src/main/java/com/netscape/cms/servlet/cert/RenewalProcessor.java
https://github.com/dogtagpki/pki/blob/master/base/ca/src/main/java/org/dogtagpki/server/ca/rest/v2/CertServlet.java
https://github.com/dogtagpki/pki/commit/e2de26769761af04b9c56071bd1a1926903c49b6
    </References>
</Vulnerability>