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 27.3.4.19, OTP 28.5.0.8, and OTP 29.1.2, corresponding to publickey from 0.22 before 1.17.1.7, 1.20.3.6, and 1.21.8. Whether OTP before OTP 17.0, corresponding to publickey before 0.22, is affected is unknown.

— MITRE

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

— Microsoft

Affected Software

15 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
Microsoft azl3 erlang 26.2.5.20-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
ubuntu/erlang<1:16.b.3-dfsg-1ubuntu2.2+esm3
1:16.b.3-dfsg-1ubuntu2.2+esm3
ubuntu/erlang<1:18.3-dfsg-1ubuntu3.1+esm4
1:18.3-dfsg-1ubuntu3.1+esm4
ubuntu/erlang<1:20.2.2+dfsg-1ubuntu2+esm4
1:20.2.2+dfsg-1ubuntu2+esm4
ubuntu/erlang<1:22.2.7+dfsg-1ubuntu0.5+esm3
1:22.2.7+dfsg-1ubuntu0.5+esm3
ubuntu/erlang<1:24.2.1+dfsg-1ubuntu0.8
1:24.2.1+dfsg-1ubuntu0.8
ubuntu/erlang<1:25.3.2.8+dfsg-1ubuntu4.8
1:25.3.2.8+dfsg-1ubuntu4.8
ubuntu/erlang*
ubuntu/erlang<1:27.3.4.6+dfsg-1ubuntu0.2
1:27.3.4.6+dfsg-1ubuntu0.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade ubuntu/erlang to a version that resolves this vulnerability.

    Fixed in 1:16.b.3-dfsg-1ubuntu2.2+esm3
  2. Upgrade

    Upgrade ubuntu/erlang to a version that resolves this vulnerability.

    Fixed in 1:18.3-dfsg-1ubuntu3.1+esm4
  3. Upgrade

    Upgrade ubuntu/erlang to a version that resolves this vulnerability.

    Fixed in 1:20.2.2+dfsg-1ubuntu2+esm4
  4. Upgrade

    Upgrade ubuntu/erlang to a version that resolves this vulnerability.

    Fixed in 1:22.2.7+dfsg-1ubuntu0.5+esm3
  5. Upgrade

    Upgrade ubuntu/erlang to a version that resolves this vulnerability.

    Fixed in 1:24.2.1+dfsg-1ubuntu0.8
  6. Upgrade

    Upgrade ubuntu/erlang to a version that resolves this vulnerability.

    Fixed in 1:25.3.2.8+dfsg-1ubuntu4.8
  7. Upgrade

    Upgrade ubuntu/erlang to a version that resolves this vulnerability.

    Fixed in 1:27.3.4.6+dfsg-1ubuntu0.2
  8. Upgrade

    Upgrade Erlang/OTP to a version that resolves this vulnerability.

    Fixed in 26.2.5.21
  9. Upgrade

    Upgrade Erlang/OTP to a version that resolves this vulnerability.

    Fixed in 27.3.4.12
  10. Upgrade

    Upgrade Erlang/OTP to a version that resolves this vulnerability.

    Fixed in 28.5.0.1
  11. Upgrade

    Upgrade Erlang/OTP to a version that resolves this vulnerability.

    Fixed in 29.0.1
  12. Upgrade

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

    Fixed in 1.15.1.7
  13. Upgrade

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

    Fixed in 1.17.1.3
  14. Upgrade

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

    Fixed in 1.20.3.1
  15. Upgrade

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

    Fixed in 1.21.1
  16. Upgrade

    Upgrade Erlang/OTP to a version that resolves this vulnerability.

    Fixed in 27.3.4.19
  17. Upgrade

    Upgrade Erlang/OTP to a version that resolves this vulnerability.

    Fixed in 28.5.0.8
  18. Upgrade

    Upgrade Erlang/OTP to a version that resolves this vulnerability.

    Fixed in 29.1.2
  19. Upgrade

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

    Fixed in 1.17.1.7
  20. Upgrade

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

    Fixed in 1.20.3.6
  21. Upgrade

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

    Fixed in 1.21.8

Event History

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

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