El 21 de octubre de 2026, el proyecto PHP publicó versiones nuevas para corregir dos fallos de seguridad críticos. PHP es el lenguaje con el que funcionan WordPress, WooCommerce, PrestaShop y una gran parte de las webs de negocios. Los dos fallos pueden permitir que alguien ejecute código en el servidor, y en algunas configuraciones basta con enviar una petición a la web, sin usuario ni contraseña.
Lo importante para quien dirige un negocio es esto: esta corrección no llega actualizando WordPress ni sus plugins. Se aplica en el servidor, y en la mayoría de los casos la tiene que aplicar el hosting. Te explicamos qué se corrigió, qué versión debe tener tu servidor y qué preguntas hacerle a tu proveedor para quedarte con una respuesta que se pueda comprobar.
- Los fallos están en PHP, el programa que hace funcionar tu WordPress en el servidor. Actualizar WordPress o los plugins no los corrige.
- Están corregidos en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, o en el paquete corregido que publique tu proveedor de sistema. PHP 8.1 y anteriores ya no reciben correcciones del proyecto.
- Si hay que parar la web para actualizar, lo correcto es mostrar un aviso de mantenimiento con el código 503, y por poco tiempo, para no perder páginas en Google.
Qué se corrigió y cuándo
PHP es el «motor» que corre en el servidor y arma cada página de tu web cuando alguien la visita. WordPress está escrito en PHP: sin PHP, no funciona. Por eso un fallo en PHP afecta a cualquier web hecha con él, aunque WordPress y sus plugins estén al día.
Según el archivo de noticias de php.net, los dos fallos (CVE-2026-109618 y CVE-2026-109619) tienen una puntuación de gravedad de 9,2 sobre 10. Uno aparece cuando PHP se queda sin memoria a mitad de una petición; el otro, cuando datos de una petición anterior quedan disponibles para la siguiente. El aviso dice que afectan a todas las instalaciones de PHP que atienden peticiones web, con cualquier forma habitual de conectarlo al servidor, y que el riesgo es mayor con una de ellas (mod_php de Apache), donde ya se demostró un ataque sin necesidad de iniciar sesión.
Estas son las fechas, de fuentes oficiales consultadas el 28 de octubre de 2026:
- 20 oct 2026PHP anuncia por adelantado una publicación de seguridad crítica para el día siguiente.
- 21 oct 2026PHP publica las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y pide actualizar de inmediato.
- 21 oct 2026Google Search Central recuerda que, si hay que parar una web para actualizar, se use el código 503.
- 23 oct 2026PHP publica un aviso complementario sobre una configuración relacionada con las sesiones.
¿Hay ataques reales? La empresa de seguridad Patchstack publicó el 21 de octubre un seguimiento del caso en el que recoge avisos de empresas de hosting y de Cloudflare sobre los primeros intentos de ataque. En su última actualización de ese día hablaba de sondeos, sin pruebas firmes de intrusiones. No es motivo para alarmarse, pero sí para no dejarlo para la semana que viene.
Por qué esto no se arregla desde WordPress
Este es el malentendido más común. En el escritorio de WordPress puedes actualizar el propio WordPress, los plugins y el tema. PHP no aparece ahí, porque no forma parte de tu web: es un programa del servidor donde está alojada.
Quién lo actualiza depende del tipo de alojamiento:
En el panel de muchos hostings puedes elegir la versión de PHP, por ejemplo pasar de la 8.2 a la 8.3. Eso es otra cosa: elegir la rama no garantiza que esa rama tenga ya el parche. Lo que hay que confirmar es que la versión instalada es la corregida.
Qué versión debe tener tu servidor
Para saber qué PHP usa tu web sin tocar nada del servidor, WordPress lo muestra en su informe de salud:
Con ese número, la lectura es esta:
- 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o posterior en su rama: es una versión corregida.
- Un número anterior en las ramas 8.2 a 8.5: puede estar corregido o no. Muchas distribuciones de Linux aplican la corrección sin cambiar el número de versión, y PHP indica que les envió los parches por adelantado. En ese caso el número no sirve como prueba: hay que pedir al proveedor la referencia del aviso de seguridad que incluye el arreglo.
- 8.1 o anterior: el proyecto PHP ya no publica correcciones para esas versiones. Solo algunos proveedores con soporte extendido las ofrecen. Si tu hosting no lo hace, lo seguro es pasar a una versión con soporte.
Un dato más para planificar: PHP recuerda que la rama 8.2 deja de recibir correcciones de seguridad el 31 de diciembre de 2026. Si tu web está en 8.2, conviene preparar ya el cambio a una versión más nueva.
Qué pedirle a tu hosting o a tu equipo técnico
No hace falta que lo hagas tú. Lo que sí conviene es pedir respuestas que se puedan comprobar:
Si el proveedor responde «está todo bien» sin versión ni fecha, vuelve a preguntar. Una respuesta concreta tarda lo mismo en escribirse y te deja algo que guardar.
Si tu web no puede actualizarse enseguida, PHP publica en su aviso unos ajustes de configuración que reducen el riesgo, pero aclara que no hacen segura la instalación. Son trabajo de quien administra el servidor y no sustituyen la actualización.
Si hay que parar la web: aviso de mantenimiento con código 503
A veces, actualizar PHP obliga a dejar la web fuera de servicio un rato, o el proveedor prefiere cerrarla mientras tanto. Para Google no da igual cómo se cierre. Cada vez que su robot visita una página, el servidor responde con un código: 200 significa «todo bien»; 404, «esta página no existe»; 503, «no disponible por un momento, vuelve después».
El 21 de octubre, Google Search Central recordó en LinkedIn que durante estos trabajos hay que responder con un 503, según recogió Search Engine Journal. Con un 404, o con una página de error que responde «200», Google puede entender que las páginas ya no existen o que su contenido es ese mensaje de error.
Dos detalles prácticos:
- El aviso de mantenimiento no puede depender de PHP, porque PHP es justo lo que se está tocando. Lo resuelve quien administra el servidor o el servicio que está delante de la web (por ejemplo, una red de distribución de contenidos como Cloudflare).
- El 503 es para unas horas, no para días. La documentación de Google desaconseja mantenerlo más de uno o dos días, y advierte que una página que lo devuelve durante varios días puede salir del índice.
Después de actualizar: comprobar lo que cobra
Un cambio de PHP es un cambio en el servidor. En webs antiguas, o con plugins sin mantenimiento, puede romper algo. Después de la actualización, conviene probar lo que trae clientes:
- Los formularios. Un envío de prueba que llegue de verdad a quien tiene que llegar. Si falla, el recorrido para encontrar dónde se corta está en el formulario de WordPress dice «enviado», pero el correo no llega.
- El proceso de compra, si tienes tienda: un pedido de prueba hasta la página de confirmación y el correo al cliente.
- Las páginas principales, en el móvil y en el ordenador, para comprobar que cargan bien y sin errores a la vista.
Y antes de tocar nada, una copia de seguridad que se pueda restaurar. Lo explicamos en probar una copia de seguridad de WordPress: una copia que nunca se restauró es una suposición.
Lo que no conviene hacer
- Dar por hecho que estás a salvo porque WordPress está actualizado. Esta corrección es del servidor, no de WordPress.
- Instalar un plugin que promete «arreglar» el fallo de PHP. Un plugin funciona dentro de PHP, así que no puede corregir PHP. Patchstack también desaconseja esos supuestos arreglos y los fragmentos de código copiados.
- Suponer que tu web fue atacada. Este aviso no lo demuestra. Si notas algo raro, como usuarios que no reconoces o cambios que nadie hizo, eso merece una revisión aparte.
- Cerrar la web con un 404 o dejarla caída días. Si hay que pararla, aviso de mantenimiento con 503 y el menor tiempo posible.
Si tu web está en WordPress, la otra mitad del mantenimiento son los plugins. Lo explicamos en actualizaciones automáticas en WordPress. Y si tu web depende de una versión antigua de PHP que el hosting ya no quiere mantener, la conversación es sobre modernizarla: la tenemos en desarrollo WordPress.
