CVE-2026-42767

What it actually does

This vulnerability is a denial-of-service flaw in OpenSSL code used by CMP/CRMF client processing. If a CMP client receives a crafted CRMF CertRepMessage containing an EncryptedValue whose symmAlg field includes an algorithm OID but omits the expected parameters field, OpenSSL can dereference a NULL pointer and crash the client process. The issue affects applications that process untrusted CMP/CRMF messages using affected OpenSSL code. It does not provide code execution, data disclosure, or privilege escalation based on the described impact. OpenSSL FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected because the vulnerable code is outside the FIPS module boundary.

Why it matters to the business

Successful exploitation can interrupt certificate enrollment, renewal, or management workflows that depend on OpenSSL CMP clients. In environments where automated certificate lifecycle operations are time-sensitive, repeated crashes could delay certificate issuance or renewal and create operational outages for services relying on valid certificates. Overall urgency is moderate: the CVSS availability impact is high, but exploitation requires the victim client to communicate with an attacker-controlled CMP server or for an attacker to successfully act as a man-in-the-middle; EPSS is low at 0.00557 with no 30-day increase, it is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no public exploit maturity is reported.

How an attack unfolds

An attacker first needs a position where they can influence CMP traffic: either by operating a CMP server that the target client contacts, compromising a legitimate CMP service, manipulating configuration so the client connects to an attacker-controlled endpoint, or intercepting and modifying CMP responses in transit. When the client requests certificate management operations, the attacker returns a malformed CMP response containing a CRMF CertRepMessage with an EncryptedValue structure whose symmAlg contains an algorithm OID but lacks the parameters field. The vulnerable OpenSSL CMP processing path assumes the missing field is present and dereferences a NULL pointer. The result is a crash of the CMP client application. An attacker can repeat this interaction to cause recurring denial of service for certificate enrollment or renewal processes.

How to fix it

Upgrade OpenSSL packages and any statically linked applications to vendor-fixed versions as soon as your operating system, distribution, appliance, or application vendor provides patched builds. No exact fixed versions were provided in the input, so use the relevant vendor advisory and package metadata as the source of truth. After patching OpenSSL shared libraries, restart dependent services and redeploy or rebuild applications that statically link OpenSSL. If immediate patching is not possible, reduce exposure by disabling CMP/CRMF functionality where not required, allowing CMP clients to communicate only with explicitly trusted CMP servers, enforcing TLS certificate validation and endpoint pinning where supported, preventing untrusted network paths from modifying CMP responses, and monitoring/restarting affected client processes. Do not assume FIPS mode alone mitigates the application-level exposure unless the affected CMP code path is confirmed not to be used.

How to confirm the fix worked

Inventory systems and applications that use OpenSSL CMP client functionality, including command-line use of `openssl cmp`, applications linked against libcrypto, and certificate lifecycle automation tooling. Confirm installed OpenSSL versions and vendor patch status using package manager data, `openssl version -a`, software bills of materials, and application dependency manifests. For statically linked binaries or container images, verify the embedded OpenSSL build was rebuilt with a patched version. Confirm CMP is disabled or restricted where not needed. Validate that only trusted CMP endpoints are configured and that TLS verification is enforced. In a controlled test environment, regression-test certificate enrollment and renewal workflows with patched builds and confirm malformed CMP/CRMF responses no longer crash the client process. Review service uptime, process restart counters, and core dump generation before and after remediation to ensure the denial-of-service condition is no longer reproducible.

Typical attack path

1. Identify an application or service that uses OpenSSL CMP/CRMF client functionality.
2. Gain the ability to provide or modify CMP server responses, such as by controlling a CMP server, compromising a trusted CMP endpoint, or performing a man-in-the-middle attack.
3. Wait for or trigger the CMP client to initiate certificate enrollment, renewal, or management communication.
4. Send a crafted CMP response containing a CRMF CertRepMessage with an EncryptedValue where symmAlg has an algorithm OID but no parameters field.
5. Cause the vulnerable OpenSSL CMP client process to dereference a NULL pointer and crash.
6. Repeat delivery of malformed responses to sustain denial of service against certificate management workflows.

How to detect it

Look for evidence of prior exploitation by correlating CMP network activity with sudden crashes of applications using OpenSSL. Relevant log sources include system journals, syslog, Windows Application/System event logs for OpenSSL-based services, application logs from certificate enrollment tooling, process supervisor logs, container restart events, EDR telemetry, crash dump directories, and network proxy or packet metadata for CMP over HTTP/TLS. Key signs include `SIGSEGV`, `segfault`, access violation, or core dump events involving `openssl`, CMP client binaries, or applications linked to `libcrypto`, especially immediately after inbound CMP responses. Network telemetry may show CMP/CRMF traffic, often with `Content-Type: application/pkixcmp`, unusual CMP server endpoints, repeated failed enrollment attempts, or certificate lifecycle jobs crashing after contacting a CMP endpoint. Because the expected outcome is a crash rather than persistence, there may be no malware artifact; detection should focus on denial-of-service symptoms, malformed CMP response handling, and repeated client restarts. If threat hunting, compare configured CMP server destinations against expected certificate management infrastructure and investigate any unexpected CMP endpoints or man-in-the-middle indicators.

• Content-Type: application/pkixcmp
• application/pkixcmp
• openssl cmp
• OSSL_CMP
• CRMF
• CertRepMessage
• EncryptedValue
• symmAlg
• SIGSEGV
• segfault
• NULL pointer dereference
• core dumped
• libcrypto
• /var/lib/systemd/coredump/core.openssl
• /var/crash/openssl
• /var/crash
• coredumpctl

What your security team should do

• Prioritize patching systems that run automated certificate enrollment, renewal, or CMP client workflows using OpenSSL.
• Identify any exposed or untrusted CMP communication paths and restrict CMP clients to known, trusted certificate management servers.
• Search for crashes, segmentation faults, and core dumps involving OpenSSL CMP clients or applications processing CMP/CRMF messages since the publication date.
• Update detection content to alert on repeated CMP client crashes and suspicious CMP responses preceding process termination.
• Confirm whether any applications statically link OpenSSL and require rebuilds rather than only operating-system package updates.
• If patching is delayed, disable CMP/CRMF processing where business operations allow and add compensating monitoring for certificate lifecycle failures.
• Track vendor advisories for exact fixed OpenSSL package versions because none were supplied in the input.