Dos fallas críticas en PHP y el sistema que nadie ve

Qué pasó, en una frase

El 21 de octubre de 2026 se publicaron dos vulnerabilidades en PHP, el lenguaje que corre detrás de buena parte de los sitios y sistemas internos de la región. Ambas permiten ejecución remota de código: quien las explota no obtiene una copia de los datos, obtiene control del servidor.

Las dos están calificadas como CRITICAL, con 9.8 sobre 10 en la escala CVSS 3.1 y 9.2 en la 4.0 (CVE-2026-109618 y CVE-2026-109619). La corrección ya existe en cuatro versiones publicadas ese mismo día.

Si su empresa tiene un sitio en WordPress, una aplicación en Laravel, un panel administrativo montado hace años, o un plugin de facturación que se conecta al ERP, hay una probabilidad razonable de que PHP esté en su infraestructura. La pregunta útil es quién sabe qué versión corre dónde.

Control del servidor, no una filtración

Vale la pena traducir "ejecución remota de código", porque suena técnico y es mucho peor que técnico. Una filtración de datos significa que alguien leyó algo que no debía. Una ejecución remota de código significa que alguien puede hacer correr sus propias instrucciones en la máquina. Desde ahí puede leer lo que quiera, instalar lo que quiera, y quedarse.

En términos de negocio, eso cambia el dueño del servidor. Y como los sistemas viejos suelen compartir la misma máquina, base de datos o red interna, el alcance no se limita al sitio que quedó expuesto.

Las dos fallas son distintas en su origen pero llegan al mismo lugar. La primera ocurre cuando PHP se queda sin memoria y su rutina de limpieza trabaja con memoria que no se inicializó bien. La segunda ocurre cuando el lenguaje conserva por un momento una referencia a memoria que ya se liberó, y un request posterior lee ese estado viejo antes de inicializarlo. Ambas condiciones producen ejecución de código desde la red, sin necesidad de credenciales y sin interacción de un usuario.

Ese último detalle es el que suele subestimarse. No hace falta que nadie haga clic en un correo. No hace falta una cuenta.

El equipo de seguridad de PHP confirmó que la ejecución remota ya se demostró por HTTP contra Apache mod_php, antes de que corra una sola línea de la aplicación. En FPM el análisis de código indica que la falla también aplica, aunque no se ha demostrado un exploit completo.

El riesgo no está en el servidor que alguien mantiene

Aquí está el punto que importa para una empresa y no para un administrador de sistemas.

La organización que mantiene actualizado su servidor moderno va a parchear en horas. El problema real está en el resto del inventario: el sistema de la bodega que alguien montó hace ocho años, el portal de proveedores que ya nadie recuerda quién construyó, la aplicación interna que sigue funcionando tan bien que nadie la tocó, el WordPress con once plugins de los que tres no se actualizan desde 2023.

Todos esos corren PHP. Ninguno aparece en la lista de sistemas críticos. Ninguno tiene dueño asignado.

Es el mismo problema que Byxel ve en las integraciones: la empresa conoce los sistemas que decidió tener, no los que fue acumulando. La diferencia es que en seguridad no basta con documentar el inventario. Hay que actuar sobre él, y hay un plazo.

Por qué actualizar PHP no es actualizar el sitio

Esta es la confusión más cara de esta semana, y conviene decirlo claro.

Actualizar PHP es actualizar el motor. No es actualizar el sitio.

Si el equipo actualiza la versión de PHP en el servidor, el motor queda corregido. Pero WordPress, Laravel y cada plugin o librería que su equipo escribió encima tienen sus propias dependencias y su propio calendario. Algunos paneles de hosting permiten cambiar la versión de PHP con un clic y dejan intactas las aplicaciones que dependen de ella. Peor aún: una actualización de PHP puede romper código viejo que dependía de comportamiento obsoleto, y por eso muchas empresas la posponen indefinidamente.

Por eso la tarea es de inventario: saber qué versión corre, en qué aplicación, quién la mantiene y qué se rompe si se sube.

Los plazos que no se negocian

Las versiones corregidas son las siguientes, publicadas el 21 de octubre de 2026:

Rama	Versión corregida
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Cualquier instalación anterior a esas versiones en su rama correspondiente está expuesta.

Y acá viene la parte que no admite comodidad: PHP 8.1 y las versiones anteriores ya no tienen soporte. No van a recibir parche. Su rama se cerró antes de esta falla, y ninguna actualización va a llegar.

Quedarse en 8.1 significa aceptar el riesgo de forma permanente. La única salida es migrar.

Las próximas 48 horas, en orden

Esto cabe en media jornada y necesita a alguien con autoridad para ordenar.

Primero, haga la lista. Qué aplicaciones usan PHP, en qué servidor vive cada una, y qué versión corre. Incluya lo que no está en el inventario oficial: el sitio de marketing, el portal viejo, el panel del proveedor.

Segundo, pregunte por las que nadie reclama. Si una aplicación no tiene dueño claro, esa es la más urgente, no la menos. Nadie la va a parchear por iniciativa propia.

Tercero, parchee lo que tiene soporte. Las cuatro versiones de la tabla. Empiece por lo que está expuesto a internet, que es donde entra el ataque.

Cuarto, decida sobre lo que quedó en 8.1. No hay parche. La decisión es migrar, aislar o apagar. Dejar como está es una decisión también, y es la peor de las tres.

Quinto, deje registro. Anote qué versión quedó en cada aplicación y quién lo hizo. En tres meses, cuando salga la próxima falla, ese registro es lo que convierte una emergencia en una tarea.

La lección que se repite

Cada vez que aparece una falla crítica como esta, la diferencia entre las empresas que la resuelven en un día y las que se enteran en marzo es si saben qué tienen.

PHP es una pieza de infraestructura invisible: sostiene sitios que funcionan tan bien que nadie los mira. Esa invisibilidad es la misma que hace difícil mantener un inventario de integraciones. Y es exactamente el tipo de pasivo que se descubre tarde, cuando ya hay una factura.

Para seguir leyendo: la deuda de integración como pasivo que crece, el costo de mantener sistemas conectados a mano y los permisos de sus agentes de IA.

Si su empresa no tiene claro qué versiones de PHP corren en su infraestructura, o quedó un sistema viejo que nadie reclama, vale la pena una conversación de 30 minutos. En Byxel hacemos integraciones entre sistemas que no se hablan, y la primera puede ser la de su inventario con el sistema que ya tiene. Escribanos por WhatsApp.