A flaw was found in pki-core. The v2 REST ACL filter selects a tie-breaking permission for colliding literal and wildcard ACL keys using lexicographic string comparison rather than specificity, causing a wildcard-mapped permission to override a more specific literal-mapped permission when both match. In the CA's profile-management REST API this allows a request to POST /v2/profiles/raw -- intended to require Administrator-level profiles.create permission -- to instead be authorized under the lower-privileged profiles.approve permission held by the default Certificate Manager Agents group. The highest threat from this vulnerability is to confidentiality and integrity of the certificate authority's issuance policy.
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. 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).