En 30 segundos
- Dos fallos en el núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, permiten a un atacante sin contraseña ejecutar código en el servidor. Gravedad: 9,2 sobre 10.
- Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores ya no reciben actualizaciones oficiales.
- Actualizar WordPress o sus plugins no basta: hay que actualizar PHP en el servidor y reiniciar sus procesos.
- INCIBE-CERT lo califica de importancia crítica y recoge que se comunicaron ataques antes de que salieran los parches.
Qué ha pasado
El equipo de seguridad de PHP anunció el 20 de octubre una actualización urgente y la publicó el 21. En su aviso explica que las dos vulnerabilidades «pueden permitir la ejecución remota de código sin autenticación» y pide a todos los usuarios de PHP que actualicen «de inmediato».
El primer fallo aparece cuando PHP se queda sin memoria a mitad de procesar una petición: al cerrarla, puede usar datos a medio preparar y corromper la memoria. El segundo deja restos de una petición anterior en el proceso que atiende la siguiente. En ambos casos, una petición manipulada puede acabar ejecutando código del atacante con los permisos de la web.
Según INCIBE-CERT, el centro de respuesta a incidentes de referencia en España, «se han comunicado ataques contra servidores PHP antes de la publicación de las actualizaciones». En su tabla de vulnerabilidades, a la hora de publicar el aviso, figuraba que no había explotación confirmada de cada CVE por separado.
A quién afecta
A cualquier servidor que use PHP para atender visitas web: con PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed. PHP considera que el riesgo es mayor con Apache y mod_php, donde ha demostrado que una sola petición sin autenticar puede lanzar el ataque antes de que se ejecute el código de la propia web.
Eso incluye las webs hechas con WordPress, Drupal, Joomla o Laravel, que funcionan sobre PHP. No afecta a las webs estáticas ni a las que funcionan con otros lenguajes. Tampoco a tu móvil ni a tu ordenador: el fallo está en los servidores.
Qué hacer, según quién seas
Si solo navegas
- No tienes que instalar nada.
- Si una web que usas avisa de un incidente, cambia allí tu contraseña y no la repitas en otros sitios.
Si tienes una web y no la gestionas tú
- Pide por escrito a tu proveedor de alojamiento qué versión de PHP usa tu web y si ya incluye los parches de CVE-2026-109618 y CVE-2026-109619.
- Pregunta si han reiniciado los servicios después de actualizar.
Si administras servidores
- Actualiza a 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Si usas paquetes de tu distribución, comprueba en sus notas que citan los dos CVE: PHP avisó a las distribuciones antes de publicar.
- Reinicia Apache, PHP-FPM y cualquier proceso PHP de larga duración. Instalar el paquete sin reiniciar deja el proceso vulnerable en memoria.
- Si sigues en PHP 8.1 o anterior, aplica los parches de código que PHP publicó para 7.4, 8.0 y 8.1, pide a tu proveedor una versión corregida o migra a una rama mantenida.
- Si no puedes actualizar un sistema expuesto a internet, INCIBE-CERT recomienda aislarlo de las redes públicas hasta corregirlo.
PHP describe medidas temporales, como fijar memory_limit=-1 de forma administrativa, reducir post_max_size, desactivar session.upload_progress.enabled y, en PHP 8.5, fatal_error_backtraces, siempre reiniciando todos los procesos. Advierte de que reducen algunas vías de ataque pero no hacen segura la instalación: la única solución completa es actualizar.
PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026. Quien la use tiene que planificar ya el cambio de versión.
Lo que no sabemos
- Si las webs de la Generalitat, los ayuntamientos y las sedes electrónicas valencianas que funcionan con PHP ya están actualizadas. Vamos a preguntarlo y añadiremos aquí las respuestas, con fecha.
- A la hora de cierre no hemos encontrado un aviso propio del CSIRT-CV, el centro de ciberseguridad de la Generalitat. El aviso de referencia en España es el de INCIBE-CERT.
- Cuántos ataques ha habido y contra quién. Ningún organismo oficial ha publicado todavía esa cifra.
Lo que circula y no hemos podido comprobar
Varios medios atribuyen el hallazgo a modelos de inteligencia artificial de OpenAI y Google, citan caídas de grandes webs y recomendaciones de agencias de otros países, y dan cifras de entre 1,3 y 2,2 millones de servidores expuestos. No lo hemos verificado con fuentes primarias, así que no lo afirmamos. Lo que sí coincide con los avisos oficiales: los dos CVE, su gravedad, las versiones corregidas, el mayor riesgo de mod_php y las medidas temporales.
Fuentes
- PHP: aviso de seguridad «Critical remote code execution vulnerabilities, update now», 21/10/2026 · consultada el 22 de octubre de 2026
- PHP: notas de versión de 8.5.12, 8.4.27, 8.3.36 y 8.2.35 · consultada el 22 de octubre de 2026
- PHP en GitHub: aviso GHSA-w8hw-w9fx-j79w (CVE-2026-109618, corrupción por agotamiento de memoria) · consultada el 22 de octubre de 2026
- PHP en GitHub: aviso GHSA-6wmf-4rv5-p3rp (CVE-2026-109619, estado global obsoleto) · consultada el 22 de octubre de 2026
- INCIBE-CERT: aviso INCIBE-2026-762 «Múltiples vulnerabilidades en PHP», importancia crítica, 21/10/2026 · consultada el 22 de octubre de 2026
- CERT-EU: aviso de seguridad 2026-018 «Critical Vulnerabilities in PHP» · consultada el 22 de octubre de 2026
- NIST NVD: ficha de CVE-2026-109618 · consultada el 22 de octubre de 2026
- Elaboración
- Investigación y borrador asistidos por IA
- Revisión
- Revisado y aprobado por la dirección de Voto Vivo
- Verificación
- Cada dato contrastado con el aviso de PHP y el de INCIBE-CERT
- Género
- Información y servicio. No contiene opinión.
Correcciones
Esta pieza no tiene correcciones. Si las tuviera, verías aquí qué decía antes, qué dice ahora y por qué cambió. Cómo corregimos.