Vulnerability-Lookup

CVE-2026-66392 (GCVE-0-2026-66392)

Vulnerability from cvelistv5 – Published: 2026-10-21 11:43 – Updated: 2026-10-30 17:54

Title

Apache bRPC: TLS Client Accepts Certificates for Mismatched Peer Names

Summary

Apache bRPC versions before 1.18.0 validate the server certificate chain when client TLS peer verification is enabled, but do not bind the certificate to an expected DNS name or IP address. A network attacker who can redirect or intercept a connection and who possesses a certificate issued by a CA trusted by the client for another name may impersonate the requested TLS endpoint. Affected Scenarios: Applications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint. How to Fix: Upgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from https://github.com/apache/brpc/pull/3408 . Note: The new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected.

Severity

5.9 (Medium)


                        
                          CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-30 17:54 UTC

CWE

CWE-297 - Improper Validation of Certificate with Host Mismatch

Assigner

apache CNA under the mitre root

CNA scorecard B 76/100 over 1236 records in the last 180 days details

References

1 reference

URL	Tags
https://lists.apache.org/thread/2pf15ojj0vr7rtx95…	vendor-advisory

Impacted products

1 product

Vendor	Product	Version	CPE status
Apache Software Foundation	Apache bRPC	Affected: 0 , < 1.18.0 (semver)	guessed

Credits

ZenDuk

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "HIGH",
              "attackVector": "NETWORK",
              "availabilityImpact": "NONE",
              "baseScore": 5.9,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "NONE",
              "integrityImpact": "HIGH",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-66392",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-30T17:54:43.784196Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-30T17:54:51.981Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://github.com",
          "defaultStatus": "unaffected",
          "packageName": "apache/brpc",
          "packageURL": "pkg:github/apache/brpc",
          "product": "Apache bRPC",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "1.18.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "ZenDuk"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\u003cdiv\u003eApache bRPC versions before 1.18.0 validate the server certificate chain when client TLS peer verification is enabled, but do not bind the certificate to an expected DNS name or IP address. A network attacker who can redirect or intercept a connection and who possesses a certificate issued by a CA trusted by the client for another name may impersonate the requested TLS endpoint.\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eAffected Scenarios:\u003cbr\u003eApplications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint.\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eHow to Fix:\u003cbr\u003eUpgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/apache/brpc/pull/3408\"\u003ehttps://github.com/apache/brpc/pull/3408\u003c/a\u003e.\u003cbr\u003e\u003cbr\u003eNote:\u003cbr\u003eThe new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected.\u003c/div\u003e\u003c/div\u003e\n\n\u003cbr\u003e"
            }
          ],
          "value": "Apache bRPC versions before 1.18.0 validate the server certificate chain when client TLS peer verification is enabled, but do not bind the certificate to an expected DNS name or IP address. A network attacker who can redirect or intercept a connection and who possesses a certificate issued by a CA trusted by the client for another name may impersonate the requested TLS endpoint.\n\n\nAffected Scenarios:\nApplications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint.\n\n\nHow to Fix:\nUpgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from  https://github.com/apache/brpc/pull/3408 .\n\nNote:\nThe new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "Medium"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-297",
              "description": "CWE-297 Improper Validation of Certificate with Host Mismatch",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-21T11:43:52.622Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache bRPC: TLS Client Accepts Certificates for Mismatched Peer Names",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-66392",
    "datePublished": "2026-10-21T11:43:52.622Z",
    "dateReserved": "2026-07-26T03:42:05.836Z",
    "dateUpdated": "2026-10-30T17:54:51.981Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-66392",
      "date": "2026-11-10",
      "epss": "0.00206",
      "percentile": "0.10727"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "collectionURL": "https://github.com",
                "defaultStatus": "unaffected",
                "packageName": "apache/brpc",
                "packageURL": "pkg:github/apache/brpc",
                "product": "Apache bRPC",
                "vendor": "Apache Software Foundation",
                "versions": [
                  {
                    "lessThan": "1.18.0",
                    "status": "affected",
                    "version": "0",
                    "versionType": "semver"
                  }
                ]
              }
            ],
            "source": "security@apache.org"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "Apache bRPC versions before 1.18.0 validate the server certificate chain when client TLS peer verification is enabled, but do not bind the certificate to an expected DNS name or IP address. A network attacker who can redirect or intercept a connection and who possesses a certificate issued by a CA trusted by the client for another name may impersonate the requested TLS endpoint.\n\n\nAffected Scenarios:\nApplications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint.\n\n\nHow to Fix:\nUpgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from  https://github.com/apache/brpc/pull/3408 .\n\nNote:\nThe new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected."
          },
          {
            "lang": "es",
            "value": "Versiones de Apache bRPC anteriores a 1.18.0 validan la cadena de certificados del servidor cuando la verificaci\u00f3n de pares TLS del cliente est\u00e1 habilitada, pero no vinculan el certificado a un nombre DNS o direcci\u00f3n IP esperado. Un atacante de red que pueda redirigir o interceptar una conexi\u00f3n y que posea un certificado emitido por una CA de confianza del cliente para otro nombre puede suplantar el endpoint TLS solicitado.\\n\\nEscenarios afectados:\\nLas aplicaciones usan un Canal cliente bRPC para conectarse a una red no confiable con la verificaci\u00f3n de certificado habilitada y conf\u00edan en una CA que puede emitir certificados para identidades distintas del endpoint previsto.\\n\\nC\u00f3mo corregir:\\nActualice a Apache bRPC 1.18.0 y habilite VERIFY_PEER con un verify_depth positivo. Los canales HTTPS verifican autom\u00e1ticamente el certificado contra el host en la URL del Canal. Los llamadores pueden establecer VerifyOptions::expected_peer_name expl\u00edcitamente cuando la identidad del certificado difiere del host de la URL. Alternativamente, aplique el parche de https://github.com/apache/brpc/pull/3408.\\n\\nNota:\\nLa nueva opci\u00f3n realiza la verificaci\u00f3n de DNS SAN o IP SAN durante el apret\u00f3n de manos TLS. Las configuraciones que establecen expected_peer_name mientras la verificaci\u00f3n de pares est\u00e1 deshabilitada son rechazadas."
          }
        ],
        "id": "CVE-2026-66392",
        "lastModified": "2026-10-30T18:18:03.973",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "HIGH",
                "attackVector": "NETWORK",
                "availabilityImpact": "NONE",
                "baseScore": 5.9,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
                "version": "3.1"
              },
              "exploitabilityScore": 2.2,
              "impactScore": 3.6,
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-66392",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-30T17:54:43.784196Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-10-21T12:17:22.417",
        "references": [
          {
            "source": "security@apache.org",
            "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
          }
        ],
        "sourceIdentifier": "security@apache.org",
        "vulnStatus": "Deferred",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-297"
              }
            ],
            "source": "security@apache.org",
            "type": "Secondary"
          }
        ]
      }
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "cvssV3_1": {
                  "attackComplexity": "HIGH",
                  "attackVector": "NETWORK",
                  "availabilityImpact": "NONE",
                  "baseScore": 5.9,
                  "baseSeverity": "MEDIUM",
                  "confidentialityImpact": "NONE",
                  "integrityImpact": "HIGH",
                  "privilegesRequired": "NONE",
                  "scope": "UNCHANGED",
                  "userInteraction": "NONE",
                  "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
                  "version": "3.1"
                }
              },
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-66392",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-10-30T17:54:43.784196Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-10-30T17:54:38.376Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "collectionURL": "https://github.com",
              "defaultStatus": "unaffected",
              "packageName": "apache/brpc",
              "packageURL": "pkg:github/apache/brpc",
              "product": "Apache bRPC",
              "vendor": "Apache Software Foundation",
              "versions": [
                {
                  "lessThan": "1.18.0",
                  "status": "affected",
                  "version": "0",
                  "versionType": "semver"
                }
              ]
            }
          ],
          "credits": [
            {
              "lang": "en",
              "type": "finder",
              "value": "ZenDuk"
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "supportingMedia": [
                {
                  "base64": false,
                  "type": "text/html",
                  "value": "\u003cdiv\u003e\u003cdiv\u003eApache bRPC versions before 1.18.0 validate the server certificate chain when client TLS peer verification is enabled, but do not bind the certificate to an expected DNS name or IP address. A network attacker who can redirect or intercept a connection and who possesses a certificate issued by a CA trusted by the client for another name may impersonate the requested TLS endpoint.\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eAffected Scenarios:\u003cbr\u003eApplications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint.\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eHow to Fix:\u003cbr\u003eUpgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/apache/brpc/pull/3408\"\u003ehttps://github.com/apache/brpc/pull/3408\u003c/a\u003e.\u003cbr\u003e\u003cbr\u003eNote:\u003cbr\u003eThe new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected.\u003c/div\u003e\u003c/div\u003e\n\n\u003cbr\u003e"
                }
              ],
              "value": "Apache bRPC versions before 1.18.0 validate the server certificate chain when client TLS peer verification is enabled, but do not bind the certificate to an expected DNS name or IP address. A network attacker who can redirect or intercept a connection and who possesses a certificate issued by a CA trusted by the client for another name may impersonate the requested TLS endpoint.\n\n\nAffected Scenarios:\nApplications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint.\n\n\nHow to Fix:\nUpgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from  https://github.com/apache/brpc/pull/3408 .\n\nNote:\nThe new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected."
            }
          ],
          "metrics": [
            {
              "other": {
                "content": {
                  "text": "Medium"
                },
                "type": "Textual description of severity"
              },
              "scenarios": [
                {
                  "lang": "en",
                  "value": "GENERAL"
                }
              ]
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-297",
                  "description": "CWE-297 Improper Validation of Certificate with Host Mismatch",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-10-21T11:43:52.622Z",
            "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
            "shortName": "apache"
          },
          "references": [
            {
              "tags": [
                "vendor-advisory"
              ],
              "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
            }
          ],
          "source": {
            "discovery": "EXTERNAL"
          },
          "title": "Apache bRPC: TLS Client Accepts Certificates for Mismatched Peer Names",
          "x_generator": {
            "engine": "Vulnogram 0.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "assignerShortName": "apache",
        "cveId": "CVE-2026-66392",
        "datePublished": "2026-10-21T11:43:52.622Z",
        "dateReserved": "2026-07-26T03:42:05.836Z",
        "dateUpdated": "2026-10-30T17:54:51.981Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

FKIE_CVE-2026-66392

Vulnerability from fkie_nvd - Published: 2026-10-21 12:17 - Updated: 2026-10-30 18:18

Severity

5.9 (Medium) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

Summary

References

	URL	Tags
	security@apache.org	https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "collectionURL": "https://github.com",
          "defaultStatus": "unaffected",
          "packageName": "apache/brpc",
          "packageURL": "pkg:github/apache/brpc",
          "product": "Apache bRPC",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "1.18.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "source": "security@apache.org"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Apache bRPC versions before 1.18.0 validate the server certificate chain when client TLS peer verification is enabled, but do not bind the certificate to an expected DNS name or IP address. A network attacker who can redirect or intercept a connection and who possesses a certificate issued by a CA trusted by the client for another name may impersonate the requested TLS endpoint.\n\n\nAffected Scenarios:\nApplications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint.\n\n\nHow to Fix:\nUpgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from  https://github.com/apache/brpc/pull/3408 .\n\nNote:\nThe new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected."
    },
    {
      "lang": "es",
      "value": "Versiones de Apache bRPC anteriores a 1.18.0 validan la cadena de certificados del servidor cuando la verificaci\u00f3n de pares TLS del cliente est\u00e1 habilitada, pero no vinculan el certificado a un nombre DNS o direcci\u00f3n IP esperado. Un atacante de red que pueda redirigir o interceptar una conexi\u00f3n y que posea un certificado emitido por una CA de confianza del cliente para otro nombre puede suplantar el endpoint TLS solicitado.\\n\\nEscenarios afectados:\\nLas aplicaciones usan un Canal cliente bRPC para conectarse a una red no confiable con la verificaci\u00f3n de certificado habilitada y conf\u00edan en una CA que puede emitir certificados para identidades distintas del endpoint previsto.\\n\\nC\u00f3mo corregir:\\nActualice a Apache bRPC 1.18.0 y habilite VERIFY_PEER con un verify_depth positivo. Los canales HTTPS verifican autom\u00e1ticamente el certificado contra el host en la URL del Canal. Los llamadores pueden establecer VerifyOptions::expected_peer_name expl\u00edcitamente cuando la identidad del certificado difiere del host de la URL. Alternativamente, aplique el parche de https://github.com/apache/brpc/pull/3408.\\n\\nNota:\\nLa nueva opci\u00f3n realiza la verificaci\u00f3n de DNS SAN o IP SAN durante el apret\u00f3n de manos TLS. Las configuraciones que establecen expected_peer_name mientras la verificaci\u00f3n de pares est\u00e1 deshabilitada son rechazadas."
    }
  ],
  "id": "CVE-2026-66392",
  "lastModified": "2026-10-30T18:18:03.973",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 5.9,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.2,
        "impactScore": 3.6,
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-66392",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-10-30T17:54:43.784196Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-10-21T12:17:22.417",
  "references": [
    {
      "source": "security@apache.org",
      "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
    }
  ],
  "sourceIdentifier": "security@apache.org",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-297"
        }
      ],
      "source": "security@apache.org",
      "type": "Secondary"
    }
  ]
}

GHSA-QV5C-VJ5J-FG9Q

Vulnerability from github – Published: 2026-10-21 12:31 – Updated: 2026-10-30 18:32

Details

Affected Scenarios: Applications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint.

How to Fix: Upgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from https://github.com/apache/brpc/pull/3408 .

Note: The new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected.

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-66392"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-21T12:17:22Z",
    "severity": "MODERATE"
  },
  "details": "Apache bRPC versions before 1.18.0 validate the server certificate chain when client TLS peer verification is enabled, but do not bind the certificate to an expected DNS name or IP address. A network attacker who can redirect or intercept a connection and who possesses a certificate issued by a CA trusted by the client for another name may impersonate the requested TLS endpoint.\n\n\nAffected Scenarios:\nApplications use a bRPC client Channel to connect to an untrusted network with certificate verification enabled and trust a CA that can issue certificates for identities other than the intended endpoint.\n\n\nHow to Fix:\nUpgrade to Apache bRPC 1.18.0 and enable VERIFY_PEER with a positive verify_depth. HTTPS Channels automatically verify the certificate against the host in the Channel URL. Callers may set VerifyOptions::expected_peer_name explicitly when the certificate identity differs from the URL host. Alternatively, apply the patch from  https://github.com/apache/brpc/pull/3408 .\n\nNote:\nThe new option performs DNS SAN or IP SAN verification during the TLS handshake. Configurations that set expected_peer_name while peer verification is disabled are rejected.",
  "id": "GHSA-qv5c-vj5j-fg9q",
  "modified": "2026-10-30T18:32:20Z",
  "published": "2026-10-21T12:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66392"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2026-66392 (GCVE-0-2026-66392)

FKIE_CVE-2026-66392

GHSA-QV5C-VJ5J-FG9Q

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour