PHP en alerta máxima, dos fallas críticas obligan a actualizar servidores de inmediato
Cuando aparece una vulnerabilidad en un plugin podemos actualizar ese plugin, cuando aparece en WordPress podemos actualizar WordPress, pero el problema que se conoció este 21 de octubre de 2026 ocurre bastante más abajo, en la tecnología que permite que WordPress y millones de aplicaciones web funcionen en el servidor.
PHP publicó una actualización extraordinaria para corregir dos vulnerabilidades críticas capaces, bajo determinadas condiciones, de permitir que una persona que ni siquiera inició sesión consiga ejecutar código de manera remota en un servidor.
Las fallas fueron identificadas como CVE-2026-109618 y CVE-2026-109619, ambas recibieron una valoración crítica de 9,2 sobre 10 y el propio proyecto PHP fue bastante claro al comunicar la solución, no existe una mitigación completa que reemplace la actualización.
La situación además dejó rápidamente de ser solamente teórica, Cloudflare confirmó que ya observó tráfico intentando aprovechar estas vulnerabilidades y que los atacantes comenzaron incluso a modificar las peticiones utilizadas para intentar evadir las primeras protecciones.
Eso no significa que todos los servidores PHP estén siendo hackeados ni que cualquier página pueda comprometerse automáticamente, pero sí significa que el reloj ya empezó a correr y que durante las próximas horas veremos una carrera entre quienes actualizan sus servidores y quienes intentan encontrar sistemas que todavía siguen expuestos.
Qué está pasando con PHP, explicado sin complicarnos
El problema es técnico, pero las consecuencias pueden entenderse perfectamente sin saber programar.
Se encontraron dos vulnerabilidades críticas dentro de PHP relacionadas con el manejo de memoria entre peticiones web.
Bajo determinadas condiciones pueden permitir ejecutar código remotamente sin que el atacante tenga una cuenta previa.
No, el problema pertenece a PHP y puede afectar a cualquier aplicación web que utilice una versión vulnerable.
Sí, PHP ya publicó versiones corregidas y recomienda actualizar inmediatamente.
No, porque la vulnerabilidad está en PHP, no en WordPress, un tema o un plugin.
Cloudflare informó que ya detectó tráfico intentando aprovechar estas vulnerabilidades.
PHP trabaja detrás de la página y normalmente ni siquiera pensamos en él
Cuando entramos a una página WordPress vemos textos, fotografías, productos, formularios y botones, pero detrás de todo eso existe un servidor que necesita ejecutar instrucciones, consultar una base de datos, procesar información y construir la página que finalmente aparece en nuestra pantalla.
PHP es una de las tecnologías que realiza ese trabajo.
WordPress está desarrollado principalmente sobre PHP, pero no es el único sistema que lo utiliza, también existen tiendas, sistemas internos, plataformas administrativas y aplicaciones desarrolladas a medida que dependen de él.
Por eso esta vulnerabilidad tiene un alcance diferente al de una falla encontrada solamente dentro de WordPress, el problema existe en una capa inferior sobre la que pueden estar funcionando muchísimas aplicaciones completamente distintas.
No apareció una sola vulnerabilidad, aparecieron dos problemas relacionados con la memoria de PHP
Las fallas recibieron los identificadores CVE-2026-109618 y CVE-2026-109619, las dos fueron clasificadas como críticas y pueden terminar en ejecución remota de código.
La primera está relacionada con lo que ocurre cuando PHP se queda sin memoria mientras procesa determinada información, especialmente en situaciones donde recibe peticiones preparadas deliberadamente para llevar al sistema hasta ese límite.
PHP necesita reservar memoria mientras trabaja, después liberarla y dejar todo en condiciones para la siguiente petición, pero los investigadores encontraron situaciones donde un error podía interrumpir ese proceso en un momento especialmente peligroso.
La segunda vulnerabilidad está relacionada con algo todavía más curioso, información interna perteneciente a una petición puede quedar referenciada después de que esa memoria ya fue liberada y una petición posterior puede terminar intentando utilizarla nuevamente.
En programación este tipo de situación puede transformarse en un problema muy serio porque esa zona de memoria puede haber sido ocupada por otra información y un atacante puede intentar manipular qué termina encontrando PHP cuando vuelve a mirar allí.
El objetivo no es solamente hacer caer PHP, el riesgo real es conseguir que ejecute algo que nunca debería ejecutar
Quedarse sin memoria puede sonar inicialmente como un problema de funcionamiento, imaginamos una página que deja de responder, un error en pantalla o un proceso que simplemente se reinicia.
En este caso el problema va mucho más lejos.
Bajo determinadas condiciones, los investigadores pudieron utilizar el estado incorrecto de la memoria para conseguir ejecución remota de código, lo que significa que alguien desde Internet puede intentar lograr que el proceso PHP ejecute instrucciones elegidas por el atacante.
Eso no significa automáticamente obtener control absoluto de toda la máquina ni convertirse en administrador del servidor, porque el alcance posterior depende de cómo esté configurado cada entorno y de qué permisos tenga el proceso PHP, pero sí representa una de las categorías de vulnerabilidad que más preocupa en seguridad informática.
PHP ya publicó las versiones corregidas y acá el número exacto importa mucho
Decir solamente que utilizamos PHP 8.3, 8.4 u 8.5 no alcanza, porque dentro de cada rama existe una revisión específica que incorpora la corrección.
| Rama de PHP | Versiones anteriores afectadas | Versión corregida |
|---|---|---|
| PHP 8.2 | Anteriores a 8.2.35 | 8.2.35 |
| PHP 8.3 | Anteriores a 8.3.36 | 8.3.36 |
| PHP 8.4 | Anteriores a 8.4.27 | 8.4.27 |
| PHP 8.5 | Anteriores a 8.5.12 | 8.5.12 |
Las ramas anteriores a PHP 8.2 ya no reciben actualizaciones de seguridad del proyecto PHP, por eso mantener una página pública sobre PHP 7.x, PHP 8.0 o PHP 8.1 agrega un problema adicional, aunque hoy funcionen perfectamente necesitamos migrarlas a una versión que todavía reciba mantenimiento.
WordPress publicó una alerta, pero no va a publicar una actualización para solucionar esto
WordPress.org reaccionó rápidamente y publicó una advertencia específica porque una enorme cantidad de sitios WordPress funcionan sobre PHP.
La aclaración más importante es que estas vulnerabilidades no pertenecen a WordPress, por eso no existe una actualización de WordPress capaz de corregirlas y tampoco se espera que aparezca una.
Podemos tener WordPress 7.1.3 completamente actualizado y aun así necesitar una intervención del servidor si la versión de PHP sigue siendo vulnerable.
WordPress y PHP son dos actualizaciones diferentes
Actualizar WordPress corrige problemas de WordPress, actualizar PHP corrige problemas del entorno que ejecuta WordPress, una cosa no reemplaza a la otra.
Esto también explica por qué un plugin de seguridad de WordPress no puede solucionar completamente una vulnerabilidad que ocurre antes o debajo del código de la aplicación.
Si tenemos un hosting administrado, probablemente la solución dependa del proveedor
En un servidor propio podemos instalar las nuevas versiones directamente, pero la mayoría de las pequeñas empresas utilizan servicios de hosting donde PHP es administrado por el proveedor.
En esos casos no deberíamos intentar modificar archivos internos del servidor siguiendo instrucciones encontradas al azar en Internet, lo correcto es comprobar qué versión está funcionando realmente y verificar que el proveedor haya desplegado la revisión corregida.
Los grandes proveedores seguramente van a desplegar estas revisiones de manera acelerada porque no estamos frente a una actualización opcional, el propio proyecto PHP está recomendando aplicarla inmediatamente.
Un firewall puede frenar intentos, pero PHP sigue necesitando el parche
Cloudflare trabajó antes de la publicación pública para desplegar reglas destinadas a detectar y bloquear intentos relacionados con estas vulnerabilidades, incluso dentro de su protección gratuita.
Eso es una excelente capa adicional, porque permite detener determinadas peticiones antes de que lleguen al servidor, pero no significa que podamos conservar PHP vulnerable indefinidamente.
Los propios investigadores advierten que no existe una mitigación genérica completa, porque existen diferentes caminos internos capaces de producir las condiciones necesarias.
El problema sigue existiendo en el servidor.
Puede bloquear determinados intentos y reducir exposición.
Es la solución que elimina las vulnerabilidades conocidas.
En seguridad normalmente buscamos trabajar por capas, por eso tener firewall y PHP actualizado es muchísimo mejor que elegir solamente una de las dos cosas.
El dato que cambia la urgencia es que ya se observó tráfico intentando aprovechar la falla
Antes de que una vulnerabilidad sea pública existe un grupo muy limitado de personas que conoce los detalles, investigadores, desarrolladores y empresas que participan en una divulgación coordinada pueden trabajar durante días o semanas preparando una corrección antes de que el resto del mundo se entere.
Cuando finalmente se publica el parche ocurre algo inevitable, los defensores reciben la información necesaria para actualizar, pero quienes buscan sistemas vulnerables también empiezan a estudiar exactamente qué fue corregido.
Cloudflare informó que en este caso ya detectó tráfico atacante y observó cómo los intentos iban modificándose para intentar superar las primeras defensas.
Eso tampoco significa que exista hoy una ola mundial de servidores comprometidos, pero sí elimina uno de los motivos que a veces utilizamos para postergar una actualización, no podemos suponer que nadie está mirando.
Qué podemos esperar durante las próximas horas
A partir de ahora comienza una etapa bastante previsible en cualquier vulnerabilidad crítica de este tamaño.
Los proveedores de hosting van a desplegar las versiones corregidas en sus servidores, empresas de seguridad van a ajustar reglas conforme aparezcan nuevas variantes y los investigadores van a continuar analizando qué configuraciones resultan más fáciles o más difíciles de explotar.
Al mismo tiempo, quienes intentan atacar sistemas van a automatizar cada vez más las pruebas, buscando servidores que continúan utilizando revisiones anteriores.
Proveedores: despliegues rápidos de PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
Seguridad: nuevas reglas de WAF y mejores firmas para identificar intentos.
Atacantes: más escaneo automatizado buscando servidores sin actualizar.
Investigación: más detalles sobre configuraciones vulnerables, alcance y técnicas utilizadas.
La información puede cambiar rápidamente durante esta etapa, por eso cualquier recomendación publicada hoy debería revisarse nuevamente si aparecen nuevos datos técnicos.
En WordPress podemos comprobar la versión de PHP en menos de un minuto
WordPress permite consultar la versión utilizada sin instalar ningún plugin adicional.
También podemos encontrarla dentro del panel de administración de muchos proveedores de hosting.
Lo importante hoy no es saber solamente que tenemos PHP 8.3, necesitamos comprobar si tenemos PHP 8.3.36 o una versión posterior de esa rama, exactamente lo mismo ocurre con 8.2, 8.4 y 8.5.
WordPress 7.1.3 también llegó con correcciones de seguridad, pero es un problema diferente
WordPress publicó recientemente siete correcciones de seguridad propias, ahora la alerta ocurre en PHP, la tecnología que ejecuta WordPress desde el servidor.
Preguntas frecuentes sobre la vulnerabilidad crítica de PHP
¿Qué vulnerabilidades fueron encontradas?
Son CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades críticas relacionadas con el manejo de memoria de PHP que pueden permitir ejecución remota de código bajo determinadas condiciones.
¿Un atacante necesita iniciar sesión?
No necesariamente, los casos demostrados permiten ataques sin autenticación previa, aunque la posibilidad y confiabilidad de explotación depende de la configuración del servidor y otros factores.
¿Qué versiones corrigen el problema?
PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 y PHP 8.5.12 incorporan las correcciones publicadas el 21 de octubre de 2026.
¿Tengo que migrar inmediatamente de PHP 8.3 a PHP 8.5?
No por estas vulnerabilidades, PHP 8.3.36 ya contiene las correcciones correspondientes a la rama 8.3, una migración hacia otra rama puede planificarse por separado comprobando compatibilidad.
¿Actualizar WordPress soluciona la vulnerabilidad?
No, WordPress.org confirmó que estas vulnerabilidades pertenecen a PHP y que no hay una actualización de WordPress destinada a corregirlas.
¿Cloudflare protege contra el ataque?
Cloudflare desplegó reglas destinadas a detectar y bloquear intentos relacionados con estas vulnerabilidades, pero mantener PHP actualizado sigue siendo necesario porque un firewall no reemplaza la corrección del software vulnerable.
¿Ya se están intentando explotar estas fallas?
Sí, Cloudflare informó que observó tráfico atacante dirigido contra estas vulnerabilidades y modificaciones de las peticiones utilizadas para intentar evadir protecciones.
¿Qué pasa si uso una versión anterior a PHP 8.2?
Las ramas anteriores a PHP 8.2 ya no reciben actualizaciones de seguridad del proyecto PHP, por eso una aplicación pública debería migrarse hacia una rama actualmente soportada en lugar de permanecer indefinidamente sobre una versión antigua.
Cuando existe una vulnerabilidad crítica y el parche ya está disponible, esperar deja de aportar demasiado
Durante las últimas semanas hablamos de vulnerabilidades en WordPress, contraseñas absurdamente débiles y hasta sistemas de refrigeración que terminaron afectados por problemas de seguridad, ahora tenemos un caso diferente porque el problema aparece en una tecnología que funciona silenciosamente debajo de una enorme cantidad de páginas y aplicaciones.
Eso también demuestra por qué mantener una web no consiste solamente en entrar al panel de WordPress para comprobar si apareció algún plugin nuevo.
Hay servidor, PHP, base de datos, WordPress, plugins, temas, usuarios, servicios externos y muchas capas que necesitan mantenerse con el tiempo.
Hoy la prioridad está bastante clara, comprobar qué versión de PHP está ejecutando nuestro servidor y confirmar que ya recibió la revisión corregida.
Una web segura no depende de una sola actualización
En byteStudio preferimos construir cada proyecto desde una base propia, entendiendo el negocio, la estrategia y los objetivos desde el comienzo, porque cuando acompañamos todo el proceso también podemos hacernos responsables de cómo evoluciona.
Eso también implica mirar más allá de WordPress, mantener PHP, plugins, servidor y las diferentes capas que sostienen una página, porque una web profesional continúa necesitando atención mucho después del día en que fue publicada.
