A flaw was found in pki-core. The v2 REST ACL filter (org.dogtagpki.server.rest.v2.filters.ACLFilter) resolves a request to an ACL permission by regex-matching candidate keys and then selecting the lexicographically largest match via Comparator.reverseOrder().findFirst(), rather than the most specific match. Because the wildcard placeholder character '{' (0x7B) sorts above lowercase ASCII letters, a wildcard key beats a colliding literal key. In the CA's ProfileACL filter, the literal key "POST:raw" (intended to require the profiles.create permission, gated to the Administrators group via the certServer.profile.configuration ACI) collides with the wildcard key "POST:{}" (mapped to profiles.approve, gated to the Certificate Manager Agents group via the certServer.ca.profile ACI). For a request to POST /v2/profiles/raw, both keys match and the wildcard wins, so the endpoint is authorized under profiles.approve instead of profiles.create. Routing to the handler itself is correct (PKIServlet's dispatcher and the sibling AuthMethodFilter both use Comparator.naturalOrder() for the identical collision shape and pick the literal match) -- only ACLFilter's independent authorization tie-break disagrees with its own sibling filters and picks the wrong permission. As a result, an authenticated user holding only the Certificate Manager Agents role -- not an Administrator -- can invoke createProfileRaw, which builds a new certificate profile directly from an attacker-supplied raw byte stream, and can then enable that profile using their own legitimate profiles.approve permission. This lets a CA Agent author and activate an arbitrary certificate-issuance profile, a privilege-escalation path from the CA Agent role to effective control over the CA's issuance policy. The vulnerable code was confirmed present, by direct source and bytecode inspection, in the pki-core 11.6.0 and 11.7.1 lines (RHEL 9); it is absent from the older pki-core 10.x line (RHEL 7/8), which uses a different, unaffected REST architecture. No non-default configuration is required to reach this path on affected versions; the v2 REST API is network-reachable and cert-auth-wired identically to v1 in production IdM/RHCS deployments (confirmed via the ipa-pki-proxy.conf reverse-proxy configuration).

A flaw was found in pki-core. In the Dogtag/pki-core Certificate Authority (CA) profile framework, the certificate enrollment path (EnrollmentProcessor) calls AuthzSubsystem.checkRealm() to verify that the calling principal is authorized to act within the request's configured realm before the request is submitted. The certificate renewal path (RenewalProcessor), which is reachable from the same public REST endpoint (caProfileSubmit, and the legacy v1/CertRequestDAO and ProfileSubmitServlet entry points) and is selected purely by a client-controlled 'isRenewal' flag in the posted request body, runs the same populate-then-submit sequence and stamps the same realm onto the request via the shared AuthzRealmDefault policy default, but never calls checkRealm. As a result, a caller who is only entitled in realm A can submit a renewal naming the serial number of a certificate originally issued under realm B; the renewal request is repopulated with realm B and submitted to realm B's request queue without realm B's authorization manager ever being consulted. This was dynamically reproduced end-to-end in an isolated sandbox: an identity with zero entitlement to a configured realm, freshly confirmed denied on the equivalent enrollment call, successfully renewed another user's certificate in that realm via a single authenticated request, with checkRealm never invoked. Direct testing established the practical impact is narrower than a realm-authorization bypass might suggest: the resulting certificate's content is already retrievable by any unauthenticated caller via the product's own intended read API, confirmed both same-host and across a genuine cross-container network boundary (no net-new confidentiality exposure); no private key material is ever exposed (no impersonation path); and the victim's own certificate and their own ability to renew it are both completely unaffected (no denial-of-service capability via revocation, side-effects, or resource exhaustion -- all tested directly). Attack Complexity is assessed High because exploitability additionally requires a non-default, supported deployment configuration (a realm-mapped authorization manager, the multi-realm/delegated-CA deployment mode), per Red Hat's documented CVSS scoring practice for configuration-dependent flaws. This affects the Dogtag PKI CA codebase across all current Red Hat package names for it: pki-core (RHEL 6-9, Certificate System 9), dogtag-pki (RHEL 10, RHIVOS 2, Fedora), and redhat-pki (Certificate System 10/11) -- the same missing checkRealm call was independently confirmed present in EnrollmentProcessor and absent from RenewalProcessor at the exact upstream versions shipped as dogtag-pki 11.9.0 and redhat-pki 11.10.0, not merely inferred from shared upstream provenance. Git history analysis shows the gap was introduced by omission in commit e2de26769761af04b9c56071bd1a1926903c49b6 (2016-05-09), which added the realm check only to EnrollmentProcessor roughly 63 hours after a separate commit had modified both EnrollmentProcessor and RenewalProcessor symmetrically at the same code location -- indicating an oversight rather than an intentional design decision.