CVE-2019-12423 in Commerce Guided Search
Summary
by MITRE
Apache CXF ships with a OpenId Connect JWK Keys service, which allows a client to obtain the public keys in JWK format, which can then be used to verify the signature of tokens issued by the service. Typically, the service obtains the public key from a local keystore (JKS/PKCS12) by specifing the path of the keystore and the alias of the keystore entry. This case is not vulnerable. However it is also possible to obtain the keys from a JWK keystore file, by setting the configuration parameter "rs.security.keystore.type" to "jwk". For this case all keys are returned in this file "as is", including all private key and secret key credentials. This is an obvious security risk if the user has configured the signature keystore file with private or secret key credentials. From CXF 3.3.5 and 3.2.12, it is mandatory to specify an alias corresponding to the id of the key in the JWK file, and only this key is returned. In addition, any private key information is omitted by default. "oct" keys, which contain secret keys, are not returned at all.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 04/24/2021
The vulnerability described in CVE-2019-12423 affects Apache CXF versions prior to 3.3.5 and 3.2.12, specifically within the OpenId Connect JWK Keys service implementation. This service enables clients to retrieve public keys in JSON Web Key (JWK) format for token signature verification purposes, which is a standard practice in modern identity and access management systems. The flaw exists in how the system handles key retrieval when configured to use a JWK keystore file rather than a traditional Java Keystore (JKS/PKCS12) format. When the configuration parameter "rs.security.keystore.type" is set to "jwk", the system processes key material from JWK files without proper security controls that would normally be present in traditional keystore handling.
The technical implementation flaw stems from insufficient validation and filtering of key material when retrieving keys from JWK files. In vulnerable versions, the system returns all keys contained in the JWK file exactly as they appear, including private keys, secret keys, and other sensitive credentials that should never be exposed through public key retrieval endpoints. This represents a critical security oversight because JWK files can contain multiple key types including symmetric keys (oct), private keys, and public keys all within the same file structure. The vulnerability essentially transforms a legitimate public key retrieval service into a potential information disclosure mechanism that could expose cryptographic secrets to unauthorized parties.
The operational impact of this vulnerability is severe and aligns with CWE-200 (Information Exposure) and CWE-312 (Sensitive Data Exposure) categories. An attacker who can access the JWK keys service endpoint could potentially extract private keys, symmetric secrets, or other confidential cryptographic material that would normally be protected within the keystore. This exposure could compromise the entire token-based authentication system, allowing attackers to forge tokens, impersonate users, or decrypt sensitive information. The vulnerability particularly affects systems using the OpenId Connect protocol where token integrity and authenticity are paramount for security, making it a significant concern for organizations relying on Apache CXF for identity management services.
The security implications extend beyond simple information disclosure to encompass potential privilege escalation and authentication bypass scenarios. According to ATT&CK framework category T1566 (Phishing) and T1552 (Unsecured Credentials), this vulnerability creates opportunities for attackers to obtain credentials and secrets that could be used to gain unauthorized access to protected systems. The fix implemented in CXF versions 3.3.5 and 3.2.12 addresses the core issue by enforcing mandatory alias specification for JWK files, ensuring that only the explicitly identified key is returned, and by default omitting private key information. Additionally, the implementation now excludes "oct" keys containing secret keys from the response entirely, which aligns with security best practices for key management and the principle of least privilege. This remediation approach effectively eliminates the information disclosure risk while maintaining the service's functionality for legitimate public key retrieval operations. Organizations should prioritize upgrading to these patched versions and review their JWK file configurations to ensure proper key management practices are implemented.