El 21 de octubre de 2026, el proyecto PHP publicó correcciones para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, que pueden permitir a un atacante ejecutar código en un servidor sin iniciar sesión. Si tu web funciona con PHP, como todas las webs WordPress, conviene revisarlo hoy mismo. Te contamos qué ha pasado, qué hacer y cómo lo hemos resuelto en las webs que gestionamos.
¿Qué son CVE-2026-109618 y CVE-2026-109619?
Ambos son fallos del propio PHP, cada uno con una puntuación de 9,2 en la escala CVSS v4.0, y el proyecto PHP los califica de críticos. Permiten la ejecución remota de código sin autenticación: alguien sin cuenta en tu web podría hacer que tu servidor ejecutara su código.
- CVE-2026-109618: cuando PHP se queda sin memoria, puede interrumpirse con los datos internos de la petición a medio preparar, y la limpieza posterior puede tratar esos datos no válidos como si fueran válidos.
- CVE-2026-109619: los datos internos de una petición pueden sobrevivir a la memoria a la que apuntaban, y una petición posterior en el mismo worker puede llegar a usarlos.
¿Está afectada tu web?
Muy probablemente, si funciona con PHP y no se ha actualizado desde entonces. El aviso abarca cualquier instalación de PHP que atienda peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed, y considera que el riesgo es mayor con mod_php.
Mantener actualizados WordPress, tu tema y tus plugins es una buena práctica, y lo recomendamos en nuestra guía de seguridad para WordPress, pero no soluciona esto. El fallo está en la capa que hay por debajo.
Qué hacer ahora
- Comprueba tu versión de PHP. En WordPress: Herramientas, Salud del sitio, Información, Servidor.
- Actualiza a una versión corregida: PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Si tienes un alojamiento gestionado, pide a tu proveedor que te confirme que ya está hecho.
- Asegúrate de que la nueva versión está realmente en uso. Los procesos de PHP tienen que reiniciarse para cargarla.
- Primero, copia de seguridad; después, pruebas. Revisa la página de inicio, los formularios, el checkout y el área de administración justo después.
- Planifica con tiempo si usas una rama antigua. PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto, y PHP 8.2 llega al final de su vida útil el 31 de diciembre de 2026.
Si no puedes actualizar enseguida, el aviso recoge ajustes provisionales. Según el propio aviso, reducen la exposición pero no la eliminan, y actualizar es la única opción segura.
Cómo lo ha gestionado nuestro equipo
Nos ocupamos de las webs que creamos, en nuestro propio servidor, así que esto nos tocaba resolverlo a nosotros. El proyecto PHP publicó las correcciones el 21 de octubre a las 14:00 UTC. A las 09:27 UTC de la mañana siguiente, menos de 20 horas después, nuestra actualización ya estaba en marcha. Esto es lo que hicimos:
- Primero, una copia de seguridad. Guardamos la configuración de PHP y la lista de paquetes instalados para poder volver atrás si algo fallaba.
- Solo lo que la corrección necesitaba. Actualizamos los paquetes de PHP y nada más, y mantuvimos la configuración de cada web tal como estaba.
- Todas las ramas con soporte. Llevamos 8.2, 8.3, 8.4 y 8.5 a sus versiones corregidas, no solo la versión que usan nuestras webs.
- Una revisión de cada web. Después cargamos las webs una a una, incluidas las páginas de contacto y las versiones traducidas, y confirmamos que todas respondían con normalidad.
Nada de esto es heroico. Es, sencillamente, para lo que sirve el mantenimiento y soporte: alguien ya está atento cuando llega el aviso, sabe cómo está configurado el servidor y tiene preparada la vuelta atrás. Si quieres saber más sobre lo que implica ese trabajo, consulta nuestra lista de comprobación para el mantenimiento web.
Preguntas para quien gestiona tu web
- ¿Qué versión de PHP usa mi web y cuándo se actualizó por última vez?
- ¿Cómo te enterarías de una vulnerabilidad crítica y en cuánto tiempo actuarías?
- ¿Hay una copia de seguridad reciente y alguien ha probado a restaurarla?
- ¿Quién revisa la web después de una actualización?
Si estas preguntas no tienen una respuesta rápida, conviene resolverlo antes de que llegue el próximo aviso.
Preguntas frecuentes
¿Qué versiones de PHP corrigen CVE-2026-109618 y CVE-2026-109619?
PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, según el aviso del proyecto PHP. Tu versión debe ser esa o una posterior, o tu proveedor debe confirmarte que ha aplicado las correcciones a la versión que usas.
¿Puede verse afectada una web WordPress?
Sí, si el PHP que hay por debajo no está parcheado. Los fallos están en el propio PHP, así que no dependen de tu tema ni de tus plugins, y actualizar WordPress no los corrige. La actualización tiene que hacerse en el servidor.
¿Basta con un firewall o con un ajuste del servidor?
No del todo. El aviso recoge ajustes provisionales que reducen la exposición y advierte que no bastan para que una instalación sea segura. Actualizar es la única opción segura.
¿Y si mi web usa PHP 8.1 o una versión anterior?
El proyecto PHP ya no publica actualizaciones para esas versiones. El aviso indica que algunos proveedores aplican las correcciones a versiones antiguas, así que pregunta al tuyo o actualiza a una versión con soporte. El propio PHP 8.2 dejará de recibir correcciones de seguridad el 31 de diciembre de 2026.
¿Cómo sé qué versión de PHP usa mi web?
En WordPress, ve a Herramientas, luego a Salud del sitio, después a Información y, por último, a Servidor. En otras plataformas suele aparecer en el panel de tu alojamiento; si no, tu proveedor de alojamiento o tu desarrollador pueden decírtelo.
¿No sabes si tu web está actualizada? Envíanos la dirección y te diremos qué revisar.
