CVE-2026-42789: Non-CA certificate accepted as intermediate issuer in public_key path validation

Published May 27, 2026
·
Updated

Improper Following of a Certificate's Chain of Trust vulnerability in Erlang OTP publickey (pubkeycert module) allows a non-CA certificate to be accepted as an intermediate issuer, enabling certificate chain forgery.

In lib/publickey/src/pubkeycert.erl, pubkeycert:validateextensions/7 contains two flaws that together allow a certificate with basicConstraints cA:false and no keyUsage extension to be used as an intermediate issuer in a chain passed to publickey:pkixpathvalidation/3: the cA:false clause recurses into the remaining extensions without rejecting the certificate when it is in issuer position, and the keyUsage check only fires when the extension is present, so a certificate lacking keyUsage entirely bypasses the keyCertSign enforcement.

Any party holding an end-entity certificate with basicConstraints cA:false and no keyUsage extension, issued by any CA in the victim's trust store, can use that certificate's private key to sign forged leaf certificates for arbitrary identities. publickey:pkixpathvalidation/3 accepts the resulting chain, and by extension every TLS or mTLS endpoint built on the OTP ssl application that relies on the default verifier is affected, including server identity verification on the client side and client certificate verification on mTLS servers.

This issue affects OTP from OTP 17.0 before OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to publickey from 0.22 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.

Other sources

Improper Following of a Certificate's Chain of Trust vulnerability in Erlang OTP publickey (pubkeycert module) allows a non-CA certificate to be accepted as an intermediate issuer, enabling certificate chain forgery.

In lib/publickey/src/pubkeycert.erl, pubkeycert:validateextensions/7 contains two flaws that together allow a certificate with basicConstraints cA:false and no keyUsage extension to be used as an intermediate issuer in a chain passed to publickey:pkixpathvalidation/3: the cA:false clause recurses into the remaining extensions without rejecting the certificate when it is in issuer position, and the keyUsage check only fires when the extension is present, so a certificate lacking keyUsage entirely bypasses the keyCertSign enforcement.

Any party holding an end-entity certificate with basicConstraints cA:false and no keyUsage extension, issued by any CA in the victim's trust store, can use that certificate's private key to sign forged leaf certificates for arbitrary identities. publickey:pkixpathvalidation/3 accepts the resulting chain, and by extension every TLS or mTLS endpoint built on the OTP ssl application that relies on the default verifier is affected, including server identity verification on the client side and client certificate verification on mTLS servers.

This issue affects OTP from OTP 17.0 before OTP 29.0.1, OTP 28.5.0.1, OTP 27.3.4.12 and OTP 26.2.5.21, corresponding to publickey from 0.22 before 1.21.1, 1.20.3.1, 1.17.1.3 and 1.15.1.7.

MITRE

Non-CA certificate accepted as intermediate issuer in publickey path validation

Microsoft

Affected Software

7 affected componentsFixes available
Erlang/OTP OTP>=17.0<26.2.5.21, >=17.0<27.3.4.12, >=17.0<28.5.0.1, >=17.0<29.0.1
Erlang/OTP public_key (pubkey_cert module)>=0.22<1.15.1.7, >=0.22<1.17.1.3, >=0.22<1.20.3.1, >=0.22<1.21.1
Erlang Erlang\/otp>=17.0<26.2.5.21
Erlang Erlang\/otp>=27.0<27.3.4.12
Erlang Erlang\/otp>=28.0<28.5.0.1
Erlang Erlang\/otp>=29.0<29.0.1
Microsoft azl3 erlang 26.2.5.20-1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Erlang OTP (public_key / pubkey_cert module) to a version that resolves this vulnerability.

    Fixed in OTP 26.2.5.21
  2. Upgrade

    Upgrade Erlang/OTP public_key (Erlang module public_key) to a version that resolves this vulnerability.

    Fixed in 1.15.1.7
  3. Upgrade

    Upgrade Erlang/OTP public_key (Erlang module public_key) to a version that resolves this vulnerability.

    Fixed in 1.17.1.3
  4. Upgrade

    Upgrade Erlang/OTP public_key (Erlang module public_key) to a version that resolves this vulnerability.

    Fixed in 1.20.3.1
  5. Upgrade

    Upgrade Erlang/OTP public_key (Erlang module public_key) to a version that resolves this vulnerability.

    Fixed in 1.21.1
  6. Compensating control

    If you cannot patch immediately, avoid relying on OTP ssl endpoints that use the default verifier for TLS/mTLS certificate validation, since public_key:pkix_path_validation/3 is affected.

Event History

May 27, 2026
CVE Published
via MITRE·12:23 PM
Data Sourced
via MITRE·12:23 PM
DescriptionWeakness
Data Sourced
via NVD·02:16 PM
RemedyDescriptionSeverityWeaknessAffected Software
Data Sourced
via Red Hat·03:10 PM
DescriptionSeverityAffected Software
May 31, 2026
Data Sourced
via Microsoft·08:01 AM
DescriptionSeverityWeaknessAffected Software
Updated
via Microsoft·08:01 AM
DescriptionSeverity
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-42789?

CVE-2026-42789 has a severity rating of high, with a CVSS score of 7.

2

How do I fix CVE-2026-42789?

To fix CVE-2026-42789, apply the available patches provided by the Erlang OTP team.

3

What is the impact of CVE-2026-42789?

CVE-2026-42789 allows a non-CA certificate to be accepted as an intermediate issuer, potentially enabling certificate chain forgery.

4

Which software is affected by CVE-2026-42789?

CVE-2026-42789 affects the Erlang/OTP public_key module, specifically in the pubkey_cert module.

5

When was CVE-2026-42789 published?

CVE-2026-42789 was published on May 27, 2026.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203