PHP: corregir CVE-2026-91767 y CVE-2026-91769 (OpenSSL)

Qué corrigen estos dos avisos

Lo esencial en siete puntos

• CVE-2026-91769 — gravedad moderada, CVSS 3.1 de 4.3. La verificación del nombre del par consulta primero los subjectAltName y luego recurre al Common Name, incluso cuando el certificado presenta un SAN DNS que no coincide.
• CVE-2026-91767 — gravedad moderada, CVSS 3.1 de 6.5 (CWE-122). En php_openssl_matches_wildcard_name(), un desbordamiento por defecto de longitud pasado a memchr() provoca una lectura fuera de límites cuando el nombre con comodín del certificado tiene más caracteres literales que el host verificado.
• Versiones corregidas — PHP 8.2.34, 8.3.35, 8.4.26 y 8.5.11, para ambos fallos. Las versiones 8.4.26 y 8.5.11 figuran en el changelog de PHP con fecha del 24 de septiembre de 2026.
• Quién está afectado — los clientes que dependen del valor por defecto de verify_peer_name, mediante file_get_contents(), fopen() y stream_socket_client() sobre https:// y tls://.
• Solución provisional — el aviso no indica ninguna. Desactivar la verificación no lo es, es un fallo más.
• Ramas 8.1 y anteriores — fin de vida, sin corrección del proyecto. Puede haber correcciones de la distribución o backports de terceros: compruébelo paquete por paquete.
• Explotación — en las fuentes que consultamos, no encontramos ninguna explotación constatada de estos dos fallos.

Qué permiten estos fallos y qué no permiten

Calificados como moderados: ¿es urgente?

Medir su exposición en cuatro pasos

1. 01

   Lea la versión de PHP que realmente se sirve

   En el servidor, ejecute php -r 'echo PHP_VERSION, PHP_EOL;'. No se fíe de OPENSSL_VERSION_TEXT: lo que se corrige no es la biblioteca OpenSSL del sistema, sino el código de la extensión, es decir, la versión de PHP. Atención, la CLI puede diferir de lo que sirven sus sitios: en un servidor con varias ramas, lea también la versión de cada pool de PHP-FPM (paso de verificación más abajo). En cPanel, la versión se lee por dominio, vea nuestra guía del selector de PHP.

2. 02

   Busque las llamadas que pasan por los flujos de PHP

   Liste las llamadas salientes con una URL literal en el código: grep -rnE "(file_get_contents|fopen)\(\s*['\"]https?://|stream_socket_client\(\s*['\"]tls://" /var/www --include='*.php'. En un alojamiento cPanel, sustituya /var/www por /home. Complete con las llamadas cuya URL viene de una variable: grep -rnE "(file_get_contents|fopen|stream_socket_client)\(\s*\$" /var/www --include='*.php'. Piense en los plugins de WordPress y en la carpeta vendor: las llamadas salientes suelen esconderse ahí.

3. 03

   Localice las verificaciones ya desactivadas

   Ejecute grep -rn "verify_peer_name" /var/www --include='*.php'. Un valor a false significa que no se verifica ningún nombre de host: ese código está expuesto a mucho más que estos dos avisos, sea cual sea la versión de PHP. Corríjalo antes que nada.

4. 04

   Clasifique sus sitios

   Un sitio es prioritario si suma una rama por debajo del mínimo de la tabla siguiente y llamadas salientes por flujos. Las llamadas hechas con la extensión cURL no las cita el aviso, que enumera los flujos de PHP. WordPress y la mayoría de las bibliotecas HTTP suelen usar cURL cuando está disponible, pero recurren a los flujos si no lo está: no las descarte sin comprobarlo.

Qué versión instalar según su rama

Desplace la tabla

Aplicar la corrección según su entorno

1. 05

   Debian y Ubuntu

   Actualice el índice con sudo apt update y después los paquetes de su rama con sudo apt install --only-upgrade 'php8.3*' (sustituya 8.3 por su rama). Para ver lo pendiente: apt list --upgradable 2>/dev/null | grep -i php. Las distribuciones suelen corregir mediante backport sin cambiar el número del proyecto: lea el registro del paquete con apt changelog php8.3-cli | grep -i CVE-2026-91769. Con un repositorio de terceros como Sury, se aplican los mismos comandos.

2. 06

   RHEL, AlmaLinux y Rocky Linux

   Ejecute sudo dnf update 'php*'. Si usa un flujo de módulos, la rama sigue al módulo activado: dnf module list --enabled php la indica. Después compruebe el registro con rpm -q --changelog php-cli | grep -i CVE-2026-91769. Con un repositorio de terceros, los nombres de paquete cambian: adapte el patrón a lo que devuelva rpm -qa 'php*'.

3. 07

   cPanel: EasyApache 4 y selector de PHP

   Las ramas de EasyApache 4 son paquetes ea-php83, ea-php84, etc. Si tiene root, lístelas con rpm -qa 'ea-php*' | sort y actualícelas con sudo dnf update 'ea-php*'. Lea el registro con rpm -qa --changelog 'ea-php83*' | grep -i CVE-2026-91769 y la versión real con /opt/cpanel/ea-php83/root/usr/bin/php -v. En un alojamiento compartido, la actualización la hace el proveedor: su parte consiste en comprobar, en el selector de PHP de cPanel (MultiPHP Manager, o Select PHP Version en CloudLinux), que cada dominio funciona con una rama corregida.

4. 08

   Docker

   Una imagen no se corrige en el sitio: reconstruya tirando de la base actualizada con docker build --pull --no-cache -t su-imagen ., o docker compose build --pull --no-cache con Compose, y reinicie con docker compose up -d. Compruebe el resultado dentro del contenedor con docker run --rm su-imagen php -v. Una etiqueta flotante como php:8.4-fpm solo avanza si se reconstruyó la imagen de origen: manda el número mostrado, no el nombre de la etiqueta.

5. 09

   Reinicie los servicios de PHP

   PHP-FPM y Apache conservan el código antiguo en memoria mientras no se recarguen. En Debian o Ubuntu: sudo systemctl restart php8.3-fpm (adapte la rama), y sudo systemctl restart apache2 si usa mod_php. En RHEL o AlmaLinux: sudo systemctl restart httpd. En cPanel con PHP-FPM, systemctl list-units 'ea-php*' da el nombre exacto del servicio que hay que reiniciar.

6. 10

   Verifique la versión realmente servida

   La CLI no es el servicio web. Consulte el binario de FPM: php-fpm8.3 -v en Debian y Ubuntu, php-fpm -v en RHEL y derivados, o la versión del dominio en cPanel. El número debe alcanzar el mínimo de su rama, o su registro debe citar CVE-2026-91769. Termine con una llamada saliente de prueba: php -r 'echo strlen(file_get_contents("https://su-dominio.com/")), PHP_EOL;'.

Si su rama está en fin de vida (8.1 y anteriores)

Una tercera corrección de OpenSSL en el mismo trimestre

Solución de problemas tras la actualización

Los errores encontrados y sus remedios

• SSL operation failed with code 1 y luego certificate verify failed — mensaje completo típico: stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages: error:0A000086:SSL routines::certificate verify failed. Causa probable: el certificado presenta un SAN DNS que no contiene el host llamado, pero su CN sí. La verificación antigua lo aceptaba recurriendo al CN, la nueva lo rechaza. Lea el certificado con openssl s_client -connect interne.su-dominio.com:443 -servername interne.su-dominio.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName. Remedio: reemitir el certificado con un SAN DNS correcto para cada nombre utilizado, nunca desactivar la verificación.
• file_get_contents(): Failed to enable crypto — advertencia que acompaña a la anterior. Lea el mensaje completo que sigue: según la versión, también puede aparecer Peer certificate CN=… did not match expected CN=…. Misma causa, mismo remedio.
• Un certificado sin ningún SAN, solo con CN, sigue fallando — la corrección conserva el recurso al CN para los certificados sin identificador de servicio. La causa está, por tanto, en otro sitio: autoridad no aceptada por el cliente, host llamado por un alias o una dirección IP que no figuran en el certificado, certificado caducado. Remedio: añadir la autoridad interna a cafile en el contexto del flujo y reemitir el certificado con un SAN.
• child exited on signal 11 (SIGSEGV) en el registro de PHP-FPM — un worker que falla durante una llamada saliente TLS es compatible con CVE-2026-91767. No concluya solo con ese indicio: compruebe la versión, actualice y vea si el patrón desaparece.
• php -v sigue mostrando la versión antigua — servicio no reiniciado, CLI y FPM de ramas distintas, imagen Docker reconstruida sin --pull, o versión del dominio sin cambios en cPanel. Retome el paso de verificación.
• El registro de la distribución no cita la CVE — su ausencia no prueba ni que la corrección esté ni que falte. Consulte el seguimiento de seguridad de la distribución y, en su defecto, compare el número del proyecto con el mínimo de la tabla.

Integrar la actualización en su rutina

1. 11

   Anote el mínimo en su inventario

   Añada a su inventario de parque una columna de "versión mínima" por rama, con los valores de la tabla. Una versión por debajo del mínimo se vuelve visible sin investigar.

2. 12

   Planifique las actualizaciones de PHP

   Una corrección de seguridad de PHP es una actualización menor de la misma rama: prevea una ventana regular en lugar de un proyecto por cada aviso, con reinicio de los servicios y verificación de la versión servida.

3. 13

   Pruebe una llamada saliente tras cada actualización

   Repita php -r 'echo strlen(file_get_contents("https://su-dominio.com/")), PHP_EOL;' desde cada servidor, y una llamada a sus servicios internos. Un error de certificado aparece entonces de inmediato, no en casa de un cliente.

4. 14

   Enlace esta corrección con el resto de su vigilancia

   Para el método de inventario de un parque, lea el inventario de versiones PHP de un parque de clientes. Para el fallo más crítico del momento, vea PHP2Shell. Para cambiar la versión de un sitio, siga la guía del selector de PHP de cPanel. Para una rama que se apaga, retome la checklist de migración de PHP 8.2.