PHP corrige dos fallas críticas: versiones que debes actualizar
El equipo de PHP publicó este 21 de octubre de 2026 actualizaciones de seguridad para corregir dos vulnerabilidades críticas que pueden permitir ejecutar código de manera remota sin autenticación. La alerta tiene alcance internacional y afecta a instalaciones que atienden solicitudes web. Para negocios, instituciones y propietarios de sitios en México, la prioridad es confirmar con su proveedor de alojamiento que el motor PHP del servidor recibió la corrección correspondiente.
Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Los parches ya están disponibles: la situación pasó del aviso preventivo difundido el martes a una actualización que los administradores pueden aplicar. La publicación del arreglo no significa que todos los servidores hayan quedado protegidos automáticamente.
PHP: cuáles son las dos fallas críticas
Los problemas están identificados como CVE-2026-109618 y CVE-2026-109619, y se conocen conjuntamente como PHP2Shell. Ambos recibieron una calificación de severidad de 9.2 en la escala CVSS 4.0, cuyo máximo es 10. La evaluación describe un riesgo técnico elevado; no permite calcular por sí sola cuántos sitios han sufrido intrusiones.
El primer fallo está relacionado con el manejo de situaciones en las que se agota la memoria. Bajo determinadas condiciones, una interrupción puede dejar datos internos de una solicitud parcialmente preparados y provocar que después se procesen como si fueran válidos.
El segundo implica información interna que puede permanecer accesible después de liberarse la memoria que la respaldaba. Una solicitud posterior atendida por el mismo proceso podría utilizar ese estado obsoleto. Las dos descripciones apuntan al funcionamiento del motor, por lo que la respuesta requiere revisar la instalación de PHP y su entorno.
Quiénes deben revisar sus servidores
El aviso del proyecto incluye las instalaciones de PHP que sirven solicitudes web, entre ellas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. La existencia de configuraciones distintas no permite asumir que un sitio está fuera de riesgo solo por utilizar un servidor diferente al de otro negocio.
El equipo considera especialmente elevado el riesgo en mod_php, donde validó una explotación sin autenticación que puede activarse antes de ejecutarse el código de la aplicación. Esa demostración no debe confundirse con una confirmación de que todos los sitios afectados hayan sido atacados.
La exposición y la fiabilidad de una explotación dependen de factores como la compilación de PHP, sus extensiones y la configuración del entorno. Para el responsable de un sitio, la comprobación útil es identificar el servicio realmente utilizado y verificar qué actualización le corresponde.
Las versiones corregidas y los equipos antiguos
- Rama PHP 8.5: actualizar a 8.5.12.
- Rama PHP 8.4: actualizar a 8.4.27.
- Rama PHP 8.3: actualizar a 8.3.36.
- Rama PHP 8.2: actualizar a 8.2.35.
Los distribuidores de Linux y proveedores con soporte extendido recibieron los parches con anticipación. Algunos incorporan correcciones a sus propios paquetes sin adoptar exactamente la numeración de las descargas generales. En esos casos, corresponde revisar el aviso del proveedor y confirmar que el paquete instalado resuelve ambos identificadores CVE.
PHP 8.1 y las ramas anteriores ya no reciben actualizaciones ordinarias del proyecto. Existen proveedores que ofrecen correcciones adaptadas y se publicaron cambios mínimos para determinadas ramas antiguas, pero eso no equivale a reactivar su soporte normal. Quienes dependan de ellas necesitan confirmar la cobertura de su proveedor o preparar una migración a una rama mantenida.
Qué cambia para los sitios con WordPress
WordPress aclaró que estas vulnerabilidades no son exclusivas de su plataforma y que no requiere ni tiene prevista una actualización propia para resolverlas. El componente que debe corregirse es PHP. Por ello, ver un panel de WordPress actualizado no basta para dar por atendida esta alerta.
Dentro del administrador de WordPress, la versión utilizada puede consultarse en Herramientas, Salud del sitio, Información y Servidor. Muchos servicios de alojamiento también muestran ese dato en su panel. Esa revisión permite comenzar la conversación con el proveedor, especialmente cuando el propietario del sitio no administra directamente el servidor.
En un alojamiento gestionado, el proveedor puede estar aplicando los cambios y las protecciones correspondientes. Aun así, conviene comprobar su comunicación sobre el incidente y pedir confirmación del parche. La existencia de mantenimiento automático en otra parte del sitio no acredita por sí misma que PHP ya esté corregido.
Por qué un firewall no sustituye la actualización
Cloudflare comunicó que desplegó reglas de protección para sus clientes de firewall de aplicaciones web y que observó tráfico de ataque. Se trata de una señal operativa reportada por ese proveedor, no de un balance global de intrusiones confirmadas ni de una garantía aplicable a servidores que no utilizan sus servicios.
El equipo de PHP mantiene que actualizar es la única solución completa. Las medidas temporales reducen determinadas vías de exposición, pero no convierten una instalación vulnerable en segura. Aplicar ajustes aislados sin evaluar su efecto en el servicio puede dejar una falsa sensación de protección.
CERT-EU y el Centro Nacional de Ciberseguridad del Reino Unido recomendaron preparar la corrección inmediata y considerar el aislamiento o la desconexión temporal de sistemas cuando no sea posible remediarlos. Esa decisión corresponde a los equipos responsables, según su exposición y las necesidades de continuidad del servicio.
Qué debe quedar confirmado después del parche
El siguiente paso es verificar que la corrección está en uso, no solamente descargada. Para quienes contratan alojamiento, la pregunta concreta es si el servicio que ejecuta su sitio ya incorpora los arreglos de ambas vulnerabilidades y si queda alguna acción pendiente.
La alerta exige actuar con rapidez y con información precisa: identificar PHP, aplicar la actualización oficial o del distribuidor y confirmar su despliegue. Un sitio accesible no demuestra que esté protegido; la comprobación decisiva es que su entorno haya recibido las correcciones correspondientes.