CISA confirma ataques activos contra dos fallos críticos de PHP

La agencia estadounidense de ciberseguridad CISA ha confirmado este lunes la explotación activa de dos vulnerabilidades recientes en PHP, el lenguaje de programación que sostiene buena parte de las webs y aplicaciones que usan las pymes. Ambas fallas, identificadas como parte del grupo PHP2Shell, tienen una puntuación de 9,2 sobre 10 en el sistema CVSS, lo que las sitúa en el rango crítico. El vector de ataque es especialmente delicado: permiten ejecución remota de código sin necesidad de autenticarse en el sistema afectado.

La noticia no es un aviso teórico más. Que CISA incluya una vulnerabilidad en su catálogo de vulnerabilidades explotadas conocidas (KEV) implica que hay evidencias de uso real contra sistemas en producción. Una de las fallas, CVE-2026-109618, se asocia a un problema de agotamiento de memoria (out-of-memory) que termina derivando en la ejecución de código por parte del atacante. La otra comparte la misma gravedad y el mismo tipo de impacto.

Por qué esto importa a una pyme

PHP no es un detalle técnico menor en el tejido empresarial español. Es la base de la mayoría de gestores de contenido y de un buen número de aplicaciones internas que se han ido acumulando en las pymes durante años: la web corporativa, la tienda online, el portal de clientes, el panel de facturación heredado de un proveedor anterior. Cuando una vulnerabilidad de este tipo se explota en la naturaleza, el atacante no necesita credenciales ni engañar a nadie con un correo: le basta con encontrar una instalación sin parchear y lanzar su carga.

La ejecución remota de código sin autenticación es una de las categorías más peligrosas que existen. Significa que el atacante puede tomar el control del servidor, leer bases de datos, instalar herramientas persistentes o usar la infraestructura como punto de partida para moverse hacia otros sistemas. En una pyme con recursos limitados, ese escenario puede traducirse en una parada completa de la actividad comercial, en una brecha de datos personales con obligaciones de notificación o en ambas cosas a la vez.

Conviene además tener en cuenta el contexto: los atacantes no esperan a que la comunidad técnica reaccione. La inclusión en el catálogo KEV suele ir acompañada de un incremento de escaneos automatizados en busca de servidores vulnerables. Es cuestión de horas, no de semanas.

Qué recomendamos hacer desde el equipo de IT

Lo primero es localizar todas las instalaciones de PHP que tengamos en el inventario, incluidas las que no gestionamos directamente porque vienen dentro de un producto de terceros. Muchas pymes descubren en estos momentos que tienen PHP en sitios que ni recordaban: un plugin antiguo, un panel de administración olvidado, una herramienta de marketing instalada por un proveedor. Sin ese mapa, cualquier plan de parcheo es una lotería.

1. Inventariar y priorizar. Identificar las versiones de PHP y los componentes afectados, y ordenar la actuación por exposición: primero lo que está publicado en internet, después lo interno.
2. Parchear sin demora. Aplicar las actualizaciones disponibles para las versiones afectadas. Si algún sistema no se puede actualizar de inmediato, aislarlo detrás de controles de acceso o retirarlo temporalmente.
3. Revisar indicios de compromiso. No basta con parchear si el atacante ya ha entrado. Buscar procesos anómalos, archivos nuevos en directorios de subida, conexiones salientes no esperadas y cuentas creadas recientemente.
4. Reforzar la vigilancia. Activar o revisar alertas sobre errores de memoria, picos de tráfico hacia rutas de administración y ejecuciones de comandos del sistema desde el servidor web.
5. Documentar el proceso. Dejar constancia de lo parcheado, lo pendiente y el responsable de cada sistema. En una auditoría o en un incidente, ese registro marca la diferencia.

Este tipo de avisos encaja con una tendencia que ya hemos comentado en otras entradas: la superficie de ataque de una pyme crece más rápido que su capacidad de mantenerla. Lo vimos con los agentes de IA que se escapan y con casos como el de uCreator y el spyware Android. El patrón se repite: componentes que se instalan, se olvidan y se convierten en la puerta de entrada.

Una oportunidad para ordenar la casa

Más allá de la urgencia del parche, este incidente debería servir para replantear cómo se gestiona el ciclo de vida del software en la empresa. Un calendario de actualizaciones, un inventario actualizado y un procedimiento claro de respuesta ante vulnerabilidades críticas son medidas baratas comparadas con el coste de un incidente. No hace falta un departamento de ciberseguridad de veinte personas: hace falta constancia y alguien con la responsabilidad asignada.

Si tu equipo no tiene claro por dónde empezar, un buen primer paso es revisar qué servicios exponen PHP hacia internet y comprobar si están en la última versión estable. Es una tarea de una tarde que puede evitar un problema de semanas.

Fuente: The Hacker News. Análisis y adaptación: ForgeNEX.