CWE-296
Improper Following of a Certificate's Chain of Trust
The product does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate.
CVE-2025-48057 (GCVE-0-2025-48057)
Vulnerability from cvelistv5 – Published: 2025-05-27 16:32 – Updated: 2025-05-27 18:27
VLAI
Title
Icinga 2 certificate renewal might incorrectly renew an invalid certificate
Summary
Icinga 2 is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. Prior to versions 2.12.12, 2.13.12, and 2.14.6, the VerifyCertificate() function can be tricked into incorrectly treating certificates as valid. This allows an attacker to send a malicious certificate request that is then treated as a renewal of an already existing certificate, resulting in the attacker obtaining a valid certificate that can be used to impersonate trusted nodes. This only occurs when Icinga 2 is built with OpenSSL older than version 1.1.0. This issue has been patched in versions 2.12.12, 2.13.12, and 2.14.6.
Severity
CWE
- CWE-296 - Improper Following of a Certificate's Chain of Trust
Assigner
References
6 references
| URL | Tags |
|---|---|
| https://github.com/Icinga/icinga2/security/adviso… | x_refsource_CONFIRM |
| https://github.com/Icinga/icinga2/commit/34c93a25… | x_refsource_MISC |
| https://github.com/Icinga/icinga2/commit/4023128b… | x_refsource_MISC |
| https://github.com/Icinga/icinga2/commit/60f75f4a… | x_refsource_MISC |
| https://github.com/Icinga/icinga2/commit/9ad5683a… | x_refsource_MISC |
| https://github.com/Icinga/icinga2/commit/9b2c05d0… | x_refsource_MISC |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-48057",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-05-27T18:20:40.298192Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-05-27T18:27:57.002Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "icinga2",
"vendor": "Icinga",
"versions": [
{
"status": "affected",
"version": "\u003e= 2.14.0, \u003c 2.14.6"
},
{
"status": "affected",
"version": "\u003e= 2.13.0, \u003c 2.13.12"
},
{
"status": "affected",
"version": "\u003c 2.12.12"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Icinga 2 is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. Prior to versions 2.12.12, 2.13.12, and 2.14.6, the VerifyCertificate() function can be tricked into incorrectly treating certificates as valid. This allows an attacker to send a malicious certificate request that is then treated as a renewal of an already existing certificate, resulting in the attacker obtaining a valid certificate that can be used to impersonate trusted nodes. This only occurs when Icinga 2 is built with OpenSSL older than version 1.1.0. This issue has been patched in versions 2.12.12, 2.13.12, and 2.14.6."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.3,
"baseSeverity": "CRITICAL",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "LOW",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "LOW",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-296",
"description": "CWE-296: Improper Following of a Certificate\u0027s Chain of Trust",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-05-27T16:32:29.931Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/Icinga/icinga2/security/advisories/GHSA-7vcf-f5v9-3wr6",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/Icinga/icinga2/security/advisories/GHSA-7vcf-f5v9-3wr6"
},
{
"name": "https://github.com/Icinga/icinga2/commit/34c93a2542bbe4e9886d15bc17ec929ead1aa152",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/Icinga/icinga2/commit/34c93a2542bbe4e9886d15bc17ec929ead1aa152"
},
{
"name": "https://github.com/Icinga/icinga2/commit/4023128be42b18a011dda71ddee9ca79955b89cb",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/Icinga/icinga2/commit/4023128be42b18a011dda71ddee9ca79955b89cb"
},
{
"name": "https://github.com/Icinga/icinga2/commit/60f75f4a3d5cbb234eb3694ba7e9076a1a5b8776",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/Icinga/icinga2/commit/60f75f4a3d5cbb234eb3694ba7e9076a1a5b8776"
},
{
"name": "https://github.com/Icinga/icinga2/commit/9ad5683aab9eb392c6737ff46c830a945c9e240f",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/Icinga/icinga2/commit/9ad5683aab9eb392c6737ff46c830a945c9e240f"
},
{
"name": "https://github.com/Icinga/icinga2/commit/9b2c05d0cc09210bdeade77cf9a73859250fc48d",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/Icinga/icinga2/commit/9b2c05d0cc09210bdeade77cf9a73859250fc48d"
}
],
"source": {
"advisory": "GHSA-7vcf-f5v9-3wr6",
"discovery": "UNKNOWN"
},
"title": "Icinga 2 certificate renewal might incorrectly renew an invalid certificate"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2025-48057",
"datePublished": "2025-05-27T16:32:29.931Z",
"dateReserved": "2025-05-15T16:06:40.940Z",
"dateUpdated": "2025-05-27T18:27:57.002Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2026-27133 (GCVE-0-2026-27133)
Vulnerability from cvelistv5 – Published: 2026-02-20 22:38 – Updated: 2026-02-25 21:32
VLAI
Title
Strimzi All CAs from CA chain will be trusted in Kafka Connect and Kafka MirrorMaker 2 target clusters
Summary
Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. From 0.47.0 to before 0.50.1, when a chain consisting of multiple CA (Certificate Authority) certificates is used in the trusted certificates configuration of a Kafka Connect operand or of the target cluster in the Kafka MirrorMaker 2 operand, all of the certificates that are part of the CA chain will be trusted individually when connecting to the Apache Kafka cluster. Due to this error, the affected operand (Kafka Connect or Kafka MirrorMaker 2) might accept connections to Kafka brokers using server certificates signed by one of the other CAs in the CA chain and not just by the last CA in the chain. This issue is fixed in Strimzi 0.50.1.
Severity
5.9 (Medium)
CWE
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/strimzi/strimzi-kafka-operator… | x_refsource_CONFIRM |
| https://github.com/strimzi/strimzi-kafka-operator… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| strimzi | strimzi-kafka-operator |
Affected:
>= 0.47.0, < 0.51.1
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-27133",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-02-25T21:32:25.189755Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-02-25T21:32:33.009Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "strimzi-kafka-operator",
"vendor": "strimzi",
"versions": [
{
"status": "affected",
"version": "\u003e= 0.47.0, \u003c 0.51.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. From 0.47.0 to before 0.50.1, when a chain consisting of multiple CA (Certificate Authority) certificates is used in the trusted certificates configuration of a Kafka Connect operand or of the target cluster in the Kafka MirrorMaker 2 operand, all of the certificates that are part of the CA chain will be trusted individually when connecting to the Apache Kafka cluster. Due to this error, the affected operand (Kafka Connect or Kafka MirrorMaker 2) might accept connections to Kafka brokers using server certificates signed by one of the other CAs in the CA chain and not just by the last CA in the chain. This issue is fixed in Strimzi 0.50.1."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "HIGH",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295: Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-296",
"description": "CWE-296: Improper Following of a Certificate\u0027s Chain of Trust",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-02-20T22:38:27.721Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-6x85-j2f7-4xc5",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-6x85-j2f7-4xc5"
},
{
"name": "https://github.com/strimzi/strimzi-kafka-operator/releases/tag/0.50.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/strimzi/strimzi-kafka-operator/releases/tag/0.50.1"
}
],
"source": {
"advisory": "GHSA-6x85-j2f7-4xc5",
"discovery": "UNKNOWN"
},
"title": "Strimzi All CAs from CA chain will be trusted in Kafka Connect and Kafka MirrorMaker 2 target clusters"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-27133",
"datePublished": "2026-02-20T22:38:27.721Z",
"dateReserved": "2026-02-17T18:42:27.044Z",
"dateUpdated": "2026-02-25T21:32:33.009Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-27134 (GCVE-0-2026-27134)
Vulnerability from cvelistv5 – Published: 2026-02-20 23:05 – Updated: 2026-02-25 21:32
VLAI
Title
Strimzi: All CAs from a custom CA chain consisting of multiple CAs are trusted for mTLS user autentication
Summary
Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. In versions 0.49.0 through 0.50.0, when using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs, Strimzi incorrectly configures the trusted certificates for mTLS authentication on the internal as well as user-configured listeners. All CAs from the CA chain will be trusted. And users with certificates signed by any of the CAs in the chain will be able to authenticate. This issue affects only users using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs. It does not affect users using the Strimzi-managed Cluster and Clients CAs. It also does not affect users using custom Cluster or Clients CA with only a single CA (i.e., no CA chain with multiple CAs). This issue has been fixed in version 0.50.1. To workaround this issue, instead of providing the full CA chain as the custom CA, users can provide only the single CA that should be used.
Severity
8.1 (High)
CWE
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/strimzi/strimzi-kafka-operator… | x_refsource_CONFIRM |
| https://github.com/strimzi/strimzi-kafka-operator… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| strimzi | strimzi-kafka-operator |
Affected:
>= 0.49.0, < 0.50.1
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-27134",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-02-25T21:31:51.539855Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-02-25T21:32:00.282Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "strimzi-kafka-operator",
"vendor": "strimzi",
"versions": [
{
"status": "affected",
"version": "\u003e= 0.49.0, \u003c 0.50.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. In versions 0.49.0 through 0.50.0, when using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs, Strimzi incorrectly configures the trusted certificates for mTLS authentication on the internal as well as user-configured listeners. All CAs from the CA chain will be trusted. And users with certificates signed by any of the CAs in the chain will be able to authenticate. This issue affects only users using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs. It does not affect users using the Strimzi-managed Cluster and Clients CAs. It also does not affect users using custom Cluster or Clients CA with only a single CA (i.e., no CA chain with multiple CAs). This issue has been fixed in version 0.50.1. To workaround this issue, instead of providing the full CA chain as the custom CA, users can provide only the single CA that should be used."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287: Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295: Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-296",
"description": "CWE-296: Improper Following of a Certificate\u0027s Chain of Trust",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-02-20T23:05:04.320Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-2qwx-rq6j-8r6j",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-2qwx-rq6j-8r6j"
},
{
"name": "https://github.com/strimzi/strimzi-kafka-operator/releases/tag/0.50.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/strimzi/strimzi-kafka-operator/releases/tag/0.50.1"
}
],
"source": {
"advisory": "GHSA-2qwx-rq6j-8r6j",
"discovery": "UNKNOWN"
},
"title": "Strimzi: All CAs from a custom CA chain consisting of multiple CAs are trusted for mTLS user autentication"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-27134",
"datePublished": "2026-02-20T23:05:04.320Z",
"dateReserved": "2026-02-17T18:42:27.044Z",
"dateUpdated": "2026-02-25T21:32:00.282Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-33779 (GCVE-0-2026-33779)
Vulnerability from cvelistv5 – Published: 2026-04-09 21:30 – Updated: 2026-04-13 18:06
VLAI
Title
Junos OS: SRX Series: Insufficient certificate verification for device to SD cloud communication
Summary
An Improper Following of a Certificate's Chain of Trust vulnerability in J-Web of Juniper Networks Junos OS on SRX Series allows a PITM to intercept the communication of the device and get access to confidential information and potentially modify it.
When an SRX device is provisioned to connect to Security Director (SD) cloud, it doesn't perform sufficient verification of the received server certificate. This allows a PITM to intercept the communication between the SRX and SD cloud and access credentials and other sensitive information.
This issue affects Junos OS:
* all versions before 22.4R3-S9,
* 23.2 versions before 23.2R2-S6,
* 23.4 versions before 23.4R2-S7,
* 24.2 versions before 24.2R2-S3,
* 24.4 versions before 24.4R2-S2,
* 25.2 versions before 25.2R1-S2, 25.2R2.
Severity
CWE
- CWE-296 - Improper Following of a Certificate's Chain of Trust
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://kb.juniper.net/JSA107823 | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Juniper Networks | Junos OS |
Affected:
0 , < 22.4R3-S9
(semver)
Affected: 23.2 , < 23.2R2-S6 (semver) Affected: 23.4 , < 23.4R2-S7 (semver) Affected: 24.2 , < 24.2R2-S3 (semver) Affected: 24.4 , < 24.4R2-S2 (semver) Affected: 25.2 , < 25.2R1-S2, 25.2R2 (semver) |
Date Public
2026-04-08 16:00
Credits
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-33779",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-04-13T17:40:14.109893Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-04-13T18:06:19.571Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"platforms": [
"SRX Series"
],
"product": "Junos OS",
"vendor": "Juniper Networks",
"versions": [
{
"lessThan": "22.4R3-S9",
"status": "affected",
"version": "0",
"versionType": "semver"
},
{
"lessThan": "23.2R2-S6",
"status": "affected",
"version": "23.2",
"versionType": "semver"
},
{
"lessThan": "23.4R2-S7",
"status": "affected",
"version": "23.4",
"versionType": "semver"
},
{
"lessThan": "24.2R2-S3",
"status": "affected",
"version": "24.2",
"versionType": "semver"
},
{
"lessThan": "24.4R2-S2",
"status": "affected",
"version": "24.4",
"versionType": "semver"
},
{
"lessThan": "25.2R1-S2, 25.2R2",
"status": "affected",
"version": "25.2",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Juniper SIRT would like to acknowledge and thank Konrad Porzezynski for responsibly reporting this vulnerability."
}
],
"datePublic": "2026-04-08T16:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "An Improper Following of a Certificate\u0027s Chain of Trust vulnerability in J-Web of Juniper Networks Junos OS on SRX Series allows a PITM to intercept the communication of the device and get access to confidential information and potentially modify it.\u003cbr\u003e\u003cbr\u003eWhen an SRX device is provisioned to connect to Security Director (SD) cloud, it doesn\u0027t perform sufficient verification of the received server certificate. This allows a PITM to intercept the communication between the SRX and SD cloud and access credentials and other sensitive information.\u003cbr\u003e\u003cbr\u003eThis issue affects Junos OS:\u003cbr\u003e\u003cul\u003e\u003cli\u003eall versions before 22.4R3-S9,\u003c/li\u003e\u003cli\u003e23.2 versions before 23.2R2-S6,\u003c/li\u003e\u003cli\u003e23.4 versions before 23.4R2-S7,\u003c/li\u003e\u003cli\u003e24.2 versions before 24.2R2-S3,\u003c/li\u003e\u003cli\u003e24.4 versions before 24.4R2-S2,\u003c/li\u003e\u003cli\u003e25.2 versions before 25.2R1-S2, 25.2R2.\u003c/li\u003e\u003c/ul\u003e\u003cbr\u003e"
}
],
"value": "An Improper Following of a Certificate\u0027s Chain of Trust vulnerability in J-Web of Juniper Networks Junos OS on SRX Series allows a PITM to intercept the communication of the device and get access to confidential information and potentially modify it.\n\nWhen an SRX device is provisioned to connect to Security Director (SD) cloud, it doesn\u0027t perform sufficient verification of the received server certificate. This allows a PITM to intercept the communication between the SRX and SD cloud and access credentials and other sensitive information.\n\nThis issue affects Junos OS:\n * all versions before 22.4R3-S9,\n * 23.2 versions before 23.2R2-S6,\n * 23.4 versions before 23.4R2-S7,\n * 24.2 versions before 24.2R2-S3,\n * 24.4 versions before 24.4R2-S2,\n * 25.2 versions before 25.2R1-S2, 25.2R2."
}
],
"exploits": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Juniper SIRT is not aware of any malicious exploitation of this vulnerability."
}
],
"value": "Juniper SIRT is not aware of any malicious exploitation of this vulnerability."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.3,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/RE:M",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "MODERATE"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-296",
"description": "CWE-296 Improper Following of a Certificate\u0027s Chain of Trust",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-04-09T21:30:56.635Z",
"orgId": "8cbe9d5a-a066-4c94-8978-4b15efeae968",
"shortName": "juniper"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://kb.juniper.net/JSA107823"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "The following software releases have been updated to resolve this specific issue: 22.4R3-S9, 23.2R2-S6, 23.4R2-S7, 24.2R2-S3, 24.4R2-S2, 25.2R1-S2, 25.2R2, 25.4R1, and all subsequent releases."
}
],
"value": "The following software releases have been updated to resolve this specific issue: 22.4R3-S9, 23.2R2-S6, 23.4R2-S7, 24.2R2-S3, 24.4R2-S2, 25.2R1-S2, 25.2R2, 25.4R1, and all subsequent releases."
}
],
"source": {
"advisory": "JSA107823",
"defect": [
"1877553"
],
"discovery": "EXTERNAL"
},
"title": "Junos OS: SRX Series: Insufficient certificate verification for device to SD cloud communication",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "There are no known workarounds for this issue."
}
],
"value": "There are no known workarounds for this issue."
}
],
"x_generator": {
"engine": "Vulnogram 0.1.0-dev"
}
}
},
"cveMetadata": {
"assignerOrgId": "8cbe9d5a-a066-4c94-8978-4b15efeae968",
"assignerShortName": "juniper",
"cveId": "CVE-2026-33779",
"datePublished": "2026-04-09T21:30:56.635Z",
"dateReserved": "2026-03-23T19:46:13.669Z",
"dateUpdated": "2026-04-13T18:06:19.571Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-42789 (GCVE-0-2026-42789)
Vulnerability from cvelistv5 – Published: 2026-05-27 12:23 – Updated: 2026-05-27 15:46
VLAI
Title
Non-CA certificate accepted as intermediate issuer in public_key path validation
Summary
Improper Following of a Certificate's Chain of Trust vulnerability in Erlang OTP public_key (pubkey_cert module) allows a non-CA certificate to be accepted as an intermediate issuer, enabling certificate chain forgery.
In lib/public_key/src/pubkey_cert.erl, pubkey_cert:validate_extensions/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 public_key:pkix_path_validation/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. public_key:pkix_path_validation/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 public_key from 0.22 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.
Severity
CWE
Assigner
References
6 references
| URL | Tags |
|---|---|
| https://github.com/erlang/otp/security/advisories… | vendor-advisoryrelated |
| https://cna.erlef.org/cves/CVE-2026-42789.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-42789 | related |
| https://www.erlang.org/doc/system/versions.html#o… | x_version-scheme |
| https://github.com/erlang/otp/commit/471cd2f66430… | patch |
| https://github.com/erlang/otp/commit/59c8d824386b… | patch |
Impacted products
Credits
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42789",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-27T15:41:47.903975Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-27T15:43:46.333Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"cpes": [
"cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"modules": [
"pubkey_cert"
],
"packageName": "public_key",
"packageURL": "pkg:otp/public_key?repository_url=https:%2F%2Fgithub.com%2Ferlang%2Fotp\u0026vcs_url=git%20https:%2F%2Fgithub.com%2Ferlang%2Fotp.git",
"product": "OTP",
"programFiles": [
"src/pubkey_cert.erl"
],
"programRoutines": [
{
"name": "pubkey_cert:validate_extensions/7"
}
],
"repo": "https://github.com/erlang/otp",
"vendor": "Erlang",
"versions": [
{
"changes": [
{
"at": "1.15.1.7",
"status": "unaffected"
},
{
"at": "1.17.1.3",
"status": "unaffected"
},
{
"at": "1.20.3.1",
"status": "unaffected"
},
{
"at": "1.21.1",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "0.22",
"versionType": "otp"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"modules": [
"pubkey_cert"
],
"packageName": "erlang/otp",
"packageURL": "pkg:github/erlang/otp",
"product": "OTP",
"programFiles": [
"lib/public_key/src/pubkey_cert.erl"
],
"programRoutines": [
{
"name": "pubkey_cert:validate_extensions/7"
}
],
"repo": "https://github.com/erlang/otp",
"vendor": "Erlang",
"versions": [
{
"changes": [
{
"at": "26.2.5.21",
"status": "unaffected"
},
{
"at": "27.3.4.12",
"status": "unaffected"
},
{
"at": "28.5.0.1",
"status": "unaffected"
},
{
"at": "29.0.1",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "17.0",
"versionType": "otp"
},
{
"changes": [
{
"at": "471cd2f664300a95353c467873800bbe706005db",
"status": "unaffected"
},
{
"at": "59c8d824386b2eb1614ff9340624843ef6aca0fd",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "84adefa331c4159d432d22840663c38f155cd4c1",
"versionType": "git"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "26.2.5.21",
"versionStartIncluding": "17.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "27.3.4.12",
"versionStartIncluding": "27.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "28.5.0.1",
"versionStartIncluding": "28.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:erlang:erlang\\/otp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "29.0.1",
"versionStartIncluding": "29.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "John Downey"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Ingela Anderton Andin"
},
{
"lang": "en",
"type": "analyst",
"value": "Jakub Witczak"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Improper Following of a Certificate\u0027s Chain of Trust vulnerability in Erlang OTP \u003ctt\u003epublic_key\u003c/tt\u003e (\u003ctt\u003epubkey_cert\u003c/tt\u003e module) allows a non-CA certificate to be accepted as an intermediate issuer, enabling certificate chain forgery.\u003cp\u003eIn \u003ctt\u003elib/public_key/src/pubkey_cert.erl\u003c/tt\u003e, \u003ctt\u003epubkey_cert:validate_extensions/7\u003c/tt\u003e contains two flaws that together allow a certificate with \u003ctt\u003ebasicConstraints cA:false\u003c/tt\u003e and no \u003ctt\u003ekeyUsage\u003c/tt\u003e extension to be used as an intermediate issuer in a chain passed to \u003ctt\u003epublic_key:pkix_path_validation/3\u003c/tt\u003e: the \u003ctt\u003ecA:false\u003c/tt\u003e clause recurses into the remaining extensions without rejecting the certificate when it is in issuer position, and the \u003ctt\u003ekeyUsage\u003c/tt\u003e check only fires when the extension is present, so a certificate lacking \u003ctt\u003ekeyUsage\u003c/tt\u003e entirely bypasses the \u003ctt\u003ekeyCertSign\u003c/tt\u003e enforcement.\u003c/p\u003e\u003cp\u003eAny party holding an end-entity certificate with \u003ctt\u003ebasicConstraints cA:false\u003c/tt\u003e and no \u003ctt\u003ekeyUsage\u003c/tt\u003e extension, issued by any CA in the victim\u0027s trust store, can use that certificate\u0027s private key to sign forged leaf certificates for arbitrary identities. \u003ctt\u003epublic_key:pkix_path_validation/3\u003c/tt\u003e accepts the resulting chain, and by extension every TLS or mTLS endpoint built on the OTP \u003ctt\u003essl\u003c/tt\u003e application that relies on the default verifier is affected, including server identity verification on the client side and client certificate verification on mTLS servers.\u003c/p\u003e\u003cp\u003eThis 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 \u003ctt\u003epublic_key\u003c/tt\u003e from 0.22 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.\u003c/p\u003e"
}
],
"value": "Improper Following of a Certificate\u0027s Chain of Trust vulnerability in Erlang OTP public_key (pubkey_cert module) allows a non-CA certificate to be accepted as an intermediate issuer, enabling certificate chain forgery.\n\nIn lib/public_key/src/pubkey_cert.erl, pubkey_cert:validate_extensions/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 public_key:pkix_path_validation/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.\n\nAny party holding an end-entity certificate with basicConstraints cA:false and no keyUsage extension, issued by any CA in the victim\u0027s trust store, can use that certificate\u0027s private key to sign forged leaf certificates for arbitrary identities. public_key:pkix_path_validation/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.\n\nThis 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 public_key from 0.22 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1."
}
],
"impacts": [
{
"capecId": "CAPEC-475",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-475 Signature Spoofing by Improper Validation"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "LOW"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-296",
"description": "CWE-296 Improper Following of a Certificate\u0027s Chain of Trust",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-27T15:46:57.832Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/erlang/otp/security/advisories/GHSA-c99q-jmpx-v8qq"
},
{
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-42789.html"
},
{
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-42789"
},
{
"tags": [
"x_version-scheme"
],
"url": "https://www.erlang.org/doc/system/versions.html#order-of-versions"
},
{
"tags": [
"patch"
],
"url": "https://github.com/erlang/otp/commit/471cd2f664300a95353c467873800bbe706005db"
},
{
"tags": [
"patch"
],
"url": "https://github.com/erlang/otp/commit/59c8d824386b2eb1614ff9340624843ef6aca0fd"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Non-CA certificate accepted as intermediate issuer in public_key path validation",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "The \u003ctt\u003everify_fun\u003c/tt\u003e option in the \u003ctt\u003essl\u003c/tt\u003e or \u003ctt\u003epublic_key\u003c/tt\u003e application can be used to ensure that path validation rejects chains where an intermediate certificate does not have \u003ctt\u003ebasicConstraints cA:true\u003c/tt\u003e."
}
],
"value": "The verify_fun option in the ssl or public_key application can be used to ensure that path validation rejects chains where an intermediate certificate does not have basicConstraints cA:true."
}
],
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-42789",
"datePublished": "2026-05-27T12:23:06.355Z",
"dateReserved": "2026-04-29T18:06:33.251Z",
"dateUpdated": "2026-05-27T15:46:57.832Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Mitigation
Phase: Architecture and Design
Description:
- Ensure that proper certificate checking is included in the system design.
Mitigation
Phase: Implementation
Description:
- Understand, and properly implement all checks necessary to ensure the integrity of certificate trust integrity.
Mitigation
Phase: Implementation
Description:
- If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the full chain of trust.
No CAPEC attack patterns related to this CWE.