CVE-2026-17039
Description
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.
Statement
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.
Mitigation
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.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 3.1 | N/A | 3.1 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | High | N/A | High |
| Privileges Required | Low | N/A | Low |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | None | N/A | None |
| Integrity Impact | Low | N/A | Low |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N
cve.org: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N
Red Hat CVSS v3 Score Explanation
Attack Complexity assessed High per Red Hat's documented CVSS practice for non-default-but-supported configuration dependencies (realm-mapped authorization manager required). Confidentiality/Integrity assessed based on direct empirical testing in an isolated sandbox, not inferred from the authorization-bypass finding alone: no confidentiality gain (cert content already readable via standard API, confirmed cross-container), no impersonation (no key material exposed), no denial-of-service (revocation, side-effect, and resource-exhaustion hypotheses all tested and falsified). Reporter proposed CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N (5.9).
Understanding the Weakness (CWE)
Confidentiality
Technical Impact: Read Application Data; Read Files or Directories
An attacker could bypass intended access restrictions to read sensitive data, either by reading the data directly from a data store that is not correctly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.
Integrity
Technical Impact: Modify Application Data; Modify Files or Directories
An attacker could bypass intended access restrictions to modify sensitive data, either by writing the data directly to a data store that is not correctly restricted, or by accessing insufficiently-protected, privileged functionality to write the data.
Access Control
Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism
An attacker could bypass intended access restrictions to gain privileges by modifying or reading critical data directly, or by accessing privileged functionality.
Confidentiality,Integrity,Availability
Technical Impact: Execute Unauthorized Code or Commands
An attacker could use elevated privileges to execute unauthorized commands or code.
Availability
Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)
An attacker could gain unauthorized access to resources on the system and excessively consume those resources, leading to a denial of service.
Acknowledgements
Red Hat would like to thank Arpit Jain (Github: arpitjain099) for reporting this issue.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
