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

Vulnerability from cvelistv5 – Published: 2026-10-21 11:43 – Updated: 2026-10-21 11:43
VLAI
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
No CVSS data available.
CWE
  • CWE-297 - Improper Validation of Certificate with Host Mismatch
Assigner
apache CNA under the mitre root
CNA scorecard B 76/100 over 1088 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
Apache Software Foundation Apache bRPC Affected: 0 , < 1.18.0 (semver)
guessed Create a notification for this product.
Credits
ZenDuk
Show details on NVD website
To clipboard 

{
  "containers": {
    "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-21T11:43:52.622Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-66392",
      "date": "2026-10-22",
      "epss": "0.00101",
      "percentile": "0.00864"
    },
    "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."
          }
        ],
        "id": "CVE-2026-66392",
        "lastModified": "2026-10-22T16:56:37.023",
        "metrics": {},
        "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": "Primary"
          }
        ]
      }
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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

JSON

Loading timeline…




    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.