Un atacante no siempre necesita robar una contraseña para comprometer un sitio web. En ocasiones, basta con encontrar una falla en el software que lo mantiene funcionando. Ese es el riesgo que encendió las alertas el 21 de octubre de 2026, cuando el equipo de seguridad de PHP publicó actualizaciones de emergencia para corregir dos vulnerabilidades críticas capaces de permitir la ejecución remota de código sin autenticación.
En términos sencillos, un ciberdelincuente podría aprovechar estos errores para conseguir que un servidor ejecute instrucciones maliciosas sin iniciar sesión previamente.
Las dos vulnerabilidades críticas, identificadas como CVE-2026-109618 y CVE-2026-109619, recibieron una puntuación de 9.2 sobre 10 en la escala CVSS 4.0, utilizada para evaluar la gravedad de los fallos de seguridad. La primera está relacionada con un error en el manejo de memoria cuando el sistema se queda sin recursos; la segunda, con información interna que puede permanecer disponible después de que la memoria asociada ha sido liberada. Aunque los detalles técnicos son diferentes, ambas pueden abrir la puerta a la ejecución de código malicioso en un servidor vulnerable.
La gravedad del problema radica en el alcance de PHP, un lenguaje de programación utilizado para construir sitios web, aplicaciones y sistemas de gestión de contenidos. Plataformas como WordPress, Drupal, Joomla y Magento pueden utilizar PHP en su funcionamiento, al igual que numerosos servicios de alojamiento y aplicaciones empresariales.
Una organización podría estar expuesta sin que su equipo administrativo sepa qué versión del lenguaje opera detrás de su página web. La Agencia de la Unión Europea para la Ciberseguridad (ENISA) advirtió que también deben revisarse los productos de terceros que incorporan PHP como componente interno.
El organismo de ciberseguridad de la Unión Europea, CERT-EU, recomendó a las organizaciones que no puedan aplicar la actualización de inmediato que consideren desconectar sus sitios de internet hasta tener el parche instalado. El Centro Nacional de Ciberseguridad del Reino Unido y la agencia equivalente de Australia emitieron alertas similares.
En España, el Centro Criptológico Nacional, mediante su equipo CCN-CERT, emitió una alerta de peligrosidad crítica y aconsejó desactivar temporalmente los servicios expuestos que no sean indispensables.
Una filtración adelantó la publicación de los parches
La divulgación de las vulnerabilidades no siguió el calendario previsto inicialmente. Según el análisis publicado por la empresa de ciberseguridad Tenable, los identificadores de las fallas circularon en foros y redes sociales el 20 de octubre, antes de la fecha de divulgación coordinada prevista para el día siguiente o posterior.
PHP adelantó el proceso y publicó las actualizaciones el 21 de octubre. La situación ilustra uno de los riesgos de la divulgación prematura: los administradores pueden disponer de menos tiempo para preparar sus sistemas antes de que los atacantes conozcan los detalles del problema.
La firma de investigación watchTowr confirmó que las vulnerabilidades eran reales y señaló que había conseguido reproducir una de ellas en un entorno de pruebas. Sin embargo, la preocupación no se limitó a la posibilidad teórica de explotación.
En una actualización publicada el 21 de octubre, Tenable informó que Amazon Threat Intelligence había observado un intento de explotación el 17 de octubre, cuatro días antes del anuncio público. Este dato cambia el panorama: la amenaza no debe tratarse únicamente como un riesgo futuro, sino como una vulnerabilidad para la que ya se han reportado intentos de ataque.
Para los responsables de un sitio web, el peligro es comparable al de descubrir que la cerradura de una oficina tiene un defecto que permite abrirla sin llave. Instalar una protección provisional puede reducir algunas vías de entrada, pero no garantiza que el problema haya desaparecido.
PHP advirtió expresamente que no existen medidas de mitigación completas que sustituyan a la actualización. Por ello, los administradores deben instalar la versión corregida y revisar sus registros de actividad para investigar posibles accesos o comportamientos anómalos.
Los sistemas desactualizados enfrentan un riesgo mayor
PHP publicó las correcciones para cuatro ramas que siguen recibiendo mantenimiento: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Los administradores deben comprobar qué versión ejecutan y actualizar a la correspondiente versión corregida. Si utilizan paquetes proporcionados por una distribución de Linux o un proveedor de soporte a largo plazo, también deben consultar sus avisos de seguridad, ya que estos proveedores pueden distribuir correcciones adaptadas a sus propios paquetes.
El panorama es más complicado para las instalaciones antiguas. PHP 8.1 y las versiones anteriores ya no reciben actualizaciones ordinarias de seguridad directamente del proyecto. No obstante, PHP publicó parches mínimos de código fuente para las ramas 7.4, 8.0 y 8.1, dirigidos a quienes compilan el lenguaje por su cuenta o no cuentan con un proveedor que les entregue una corrección.
Lo anterior no significa que todas las instalaciones antiguas estén protegidas automáticamente: cada administrador debe confirmar que la solución correspondiente se haya aplicado y que su proveedor no tenga instrucciones adicionales.
Otro riesgo aparece después de la publicación de un parche. Los investigadores y atacantes pueden comparar el código vulnerable con el corregido para comprender qué cambió y desarrollar métodos de explotación. Por esa razón, dejar la actualización para la semana siguiente puede ampliar innecesariamente la ventana de exposición.
Las organizaciones deben priorizar los servidores públicos, inventariar las aplicaciones que utilizan PHP (incluidas aquellas que lo incorporan de forma indirecta) y comprobar que la corrección esté realmente instalada.
Qué deben hacer las empresas para proteger sus sitios web
La primera medida es actualizar PHP inmediatamente a una versión corregida o aplicar el paquete de seguridad confirmado por el proveedor correspondiente. Después, conviene verificar que los servicios se hayan reiniciado cuando sea necesario para cargar la versión nueva y que todos los servidores, contenedores y entornos de alojamiento estén cubiertos.
Si no es posible aplicar la corrección de inmediato, se deben reducir las conexiones externas y aislar temporalmente los servicios expuestos que no sean indispensables, sin asumir que las medidas provisionales eliminan la vulnerabilidad.
La segunda medida es investigar si hubo actividad sospechosa antes de instalar el parche. Los equipos de tecnología deben revisar los registros del servidor web y de PHP, los procesos iniciados, los archivos modificados y las conexiones salientes que no correspondan al funcionamiento habitual.
Si se encuentran indicios de ejecución de código no autorizada, deben tratar el incidente como un posible compromiso: aislar el sistema afectado, preservar las evidencias y activar su procedimiento de respuesta. Actualizar el software es indispensable, pero no demuestra por sí solo que un servidor no haya sido atacado previamente.
