CVE-2026-91769: 
PHP vulnerability analysis and mitigation

CVE-2026-91769 is a TLS hostname verification bypass vulnerability in PHP's OpenSSL extension where certificate validation incorrectly falls back to the Common Name (CN) after a Subject Alternative Name (SAN) mismatch. This violates RFC 6125, which requires CN to be ignored once a certificate presents any service identity via SAN. Affected versions include PHP < 8.2.34, < 8.3.35, < 8.4.26, and < 8.5.11. It was published on September 24, 2026, and carries a CVSS v3.1 score of 4.3 (Moderate) (GitHub Advisory).

The root cause lies in php_openssl_apply_peer_verification_policy() within ext/openssl/xp_ssl.c, which checks the certificate's SAN list and then unconditionally falls back to the CN when no SAN entry matches — regardless of whether any SAN was present. This violates RFC 6125, which mandates that CN verification must be skipped if the certificate contains any service identity (DNS SAN, URI SAN, or SRV-ID otherName). The fix modifies php_openssl_matches_san_list() to report whether a service identity was present; if one was present but none matched, verification now fails with "Peer certificate subjectAltName did not match expected name" instead of consulting the CN. Certificates with no service identity at all retain the CN fallback for backward compatibility. This is classified as an improper certificate validation issue (CWE-295) and affects all client streams using the default verify_peer_name, including file_get_contents(), fopen(), and stream_socket_client() over https:// and tls:// (GitHub Advisory).

An attacker who can obtain a certificate from a trusted CA (including private or internal CAs) with the target hostname in the CN and an unrelated hostname in the SAN can impersonate the target host to PHP clients. This enables man-in-the-middle attacks against PHP applications making outbound TLS connections, potentially exposing sensitive data transmitted over those connections. The confidentiality impact is limited (low), with no direct integrity or availability impact, but the risk is elevated in environments using private PKIs or internal CAs where certificate issuance is less strictly controlled (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date. The advisory includes a detailed PoC certificate configuration demonstrating the bypass, making reproduction straightforward for researchers. The vulnerability requires an adjacent network position (CVSS AV:A) and the ability to obtain or present a certificate with a mismatched SAN and a matching CN, limiting opportunistic exploitation. The CVE status was "Reserved" at the time of Feedly ingestion, and no CISA KEV listing or EPSS score data is currently available (GitHub Advisory, Feedly).

1. Obtain a certificate: Acquire a TLS certificate from a CA trusted by the target PHP client, with CN=victim.example.com and SAN=DNS:attacker.example.com (i.e., the attacker controls the SAN domain but targets the CN domain).
2. Set up a rogue TLS server: Configure a TLS server (e.g., using OpenSSL's s_server) to present this crafted certificate on a port reachable by the target PHP application.
3. Intercept or redirect traffic: Use ARP spoofing, DNS poisoning, or network-level redirection to route the PHP client's outbound HTTPS/TLS connection to victim.example.com toward the rogue server.
4. Trigger PHP client connection: Cause the PHP application to make an outbound TLS request (e.g., via file_get_contents('https://victim.example.com/...'), fopen(), or stream_socket_client()) with default verify_peer_name=true.
5. Bypass verification: PHP's vulnerable php_openssl_apply_peer_verification_policy() finds no matching SAN entry but falls back to CN, which matches victim.example.com, and accepts the certificate — completing the impersonation.
6. Intercept data: The attacker's server can now read and optionally modify the plaintext of the TLS session, capturing credentials, API tokens, or other sensitive data (GitHub Advisory).

Upgrade PHP to one of the patched versions: 8.2.34, 8.3.35, 8.4.26, or 8.5.11, all released on September 24, 2026 (GitHub Advisory, PHP NEWS). As a temporary workaround, applications can explicitly set peer_name and ensure certificates used in internal PKIs do not carry DNS SANs for unrelated domains. Auditing internal CA issuance policies to prevent certificates with mismatched CN/SAN combinations is also recommended. There is no configuration-only mitigation within PHP itself for unpatched versions.

The vulnerability was reported by security researchers christos-cantina-security and DavidKorczynski and fixed by Jakub Zelenka of the PHP core team (GitHub Advisory). Security community coverage noted the issue alongside several other PHP vulnerabilities patched in the same release cycle, with outlets such as SecurityOnline and Remi's blog highlighting the batch of fixes (SecurityOnline, Remi's Blog). Nessus detection plugins were published shortly after disclosure, indicating prompt uptake by vulnerability management vendors.