Preguntas frecuentes
¿Qué versiones de PHP están afectadas?
Todas las versiones anteriores a 8.5.12, 8.4.27, 8.3.36 y 8.2.35 en las ramas con soporte. PHP 8.1 y anteriores han llegado al fin de su soporte y no reciben ninguna versión del proyecto PHP; considérelas afectadas salvo que su proveedor confirme una corrección mediante backport.
Mi sitio no muestra ninguna versión de PHP. ¿Estoy a salvo?
No necesariamente. Ocultar la versión (expose_php = Off) es una buena práctica, pero no parchea nada. Compruébelo en el servidor con php -v o pregunte a su proveedor.
El comprobador muestra una versión antigua, pero mi proveedor dice que está parcheada. ¿Quién tiene razón?
Posiblemente ambos. Distribuciones Linux como Debian, Ubuntu y RHEL suelen aplicar backports de correcciones de seguridad sin cambiar el número de versión. Pregunte a su proveedor qué compilación del paquete está instalada y si su changelog menciona CVE-2026-109618 y CVE-2026-109619.
¿Están afectados WordPress, Laravel o mi CMS?
Los fallos están en el propio PHP, por lo que cualquier aplicación que se ejecute sobre un PHP afectado está expuesta. Los investigadores demostraron ataques sin autenticación contra WordPress, Drupal y Joomla, pero eran solo ejemplos: basta incluso con una simple página «Hello World». Actualizar WordPress o los plugins no lo corrige: hay que actualizar PHP.
¿Pueden filtrarse datos aunque no se haya ejecutado código?
Sí. CVE-2026-109619 puede divulgar la memoria del proceso PHP —contraseñas, tokens de sesión, claves de API y certificados de otras solicitudes— sin que el atacante ejecute código. Estas filtraciones no dejan archivos y son difíciles de detectar, así que cambie los secretos de cualquier sitio que haya ejecutado una versión afectada en Internet.
¿Desactivar session.upload_progress lo corrige?
No. php.net incluye session.upload_progress.enabled=0 como mitigación parcial para algunas vías confirmadas de CVE-2026-109619. No cubre todas las variantes y no hace nada frente a CVE-2026-109618.
¿Basta con un firewall de aplicaciones web?
Un WAF o los límites de solicitudes pueden reducir la exposición mientras actualiza, pero los problemas están en cómo PHP gestiona las solicitudes y la memoria. Sigue siendo necesario actualizar.
¿Tengo que reiniciar algo después de actualizar?
Sí. PHP-FPM, Apache, LiteSpeed y los procesos de larga duración siguen ejecutando el código antiguo hasta que se reinician. Los contenedores deben volver a crearse a partir de la nueva imagen.
¿Qué hace realmente este comprobador?
Envía una solicitud HEAD (o GET si HEAD no está permitida) a la dirección que introduce, sigue hasta tres redirecciones y lee cabeceras de respuesta como X-Powered-By y Server. Nunca envía cargas de explotación, solicitudes grandes ni subidas de archivos, y no explora otras rutas.
¿Es legal comprobar cualquier sitio web?
Compruebe solo sitios de su propiedad o que esté autorizado a evaluar. La solicitud es la misma que una visita normal, pero el uso responsable es responsabilidad suya. Limitamos las comprobaciones por red y por sitio.
¿Se corrigió PHP 8.5.12 por completo?
El 22 de octubre de 2026 circularon informes de una caída en 8.5.12, pero no se confirmaron como vulnerabilidad remota. Seguimos a php.net; si aparece una nueva versión, este sitio se actualizará y cambiará la fecha de «última verificación».
¿Dónde puedo leer los detalles oficiales?
En php.net y en los avisos de GitHub del proyecto PHP GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp. El equipo de investigación (Wiz Research, OpenAI Codex Security y Calif) publicó sus hallazgos en php2shell.com.
¿Quién descubrió las vulnerabilidades?
Investigadores de Wiz Research, OpenAI Codex Security y Calif, mediante una divulgación coordinada con el equipo de seguridad de PHP, que preparó las correcciones. Consulte la publicación de The PHP Foundation sobre la versión.