PHP2Shell y el récord de vulnerabilidades críticas: qué cambió y cómo priorizar parches

PHP es el lenguaje con el que funcionan millones de sitios web, incluidos los hechos en WordPress. Esta semana se conocieron dos fallas graves, bautizadas PHP2Shell, que permiten tomar el control del servidor sin usuario ni contraseña.

• 17 de octubre: Amazon detectó el primer intento de ataque, cuatro días antes de que la falla fuera pública.
• 21 de octubre: horas antes del parche ya circulaba en internet código para atacarla. PHP publicó la corrección, el CSIRT emitió su alerta y Cloudflare informó que bloqueaba intentos de ataque desde esa madrugada.
• 23 de octubre: PHP avisó de una tercera falla, que solo afecta a servidores con una configuración específica y que todavía no tiene parche.

Ojo con un matiz: hay intentos de ataque masivos, pero todavía no hay confirmación de empresas comprometidas a gran escala. Aun así, con más de 22 millones de instalaciones que podrían ser vulnerables según Palo Alto Networks, no es para esperar.

Fabricantes e investigadores están usando inteligencia artificial para revisar código, y encuentran errores a una velocidad que antes era imposible. En octubre, Microsoft corrigió 1.413 vulnerabilidades, más que en todo su año récord anterior.

Las fallas de PHP, por ejemplo, las descubrió un grupo de investigadores que incluía a OpenAI. Y los atacantes también tienen estas herramientas.

Mi lectura es que el software no empeoró de un día para otro. Son fallas que llevaban años ahí: según varios investigadores, las de PHP afectarían versiones publicadas desde 2012. A largo plazo es bueno que aparezcan. El problema es el corto plazo: el equipo de TI de una empresa mediana sigue siendo de dos o tres personas, y no alcanza a parchar todo. Hay que decidir bien qué va primero.

Durante años se parchaba según la nota de gravedad de cada falla, de 0 a 10, una vez al mes. Eso ya no alcanza. Cuando Microsoft califica 75 fallas como críticas en un solo mes, la nota deja de ordenar. Y un mes es demasiado si los ataques empiezan horas después de publicada la falla.

Mi recomendación parte con dos preguntas: ¿la están usando para atacar?, y ¿el equipo está expuesto a internet? Si ambas respuestas son sí, se corrige en días, sin esperar la ventana mensual. Después se ordena según qué tan crítico es el sistema para el negocio: no pesa lo mismo el ERP que un sitio informativo.

Para la primera pregunta hay fuentes públicas: la lista de fallas explotadas de CISA, en Estados Unidos, y las alertas del CSIRT Nacional. Conviene mirar ambas. CISA solo agrega una falla cuando tiene evidencia confirmada, y eso toma días. Con PHP, la alerta del CSIRT llegó antes.

Explico estas herramientas y una matriz para aplicarlas en nuestra guía de priorización de vulnerabilidades.

Esto es lo que haría yo, en este orden:

• Listar todo lo expuesto a internet: firewalls, VPN, correo, accesos remotos y sitios web, con su versión.
• Cruzar esa lista con las alertas del CSIRT y de CISA. Lo que coincida se corrige esta semana.
• Confirmar que PHP está actualizado: pedir a TI o al proveedor de hosting que confirme por escrito que los sitios con PHP ya tienen el parche. Las versiones 8.1 y anteriores ya no reciben actualizaciones oficiales; solo existen parches mínimos para quien compila PHP por su cuenta, así que lo recomendable es migrar.
• Tener listo un cambio de emergencia: quién autoriza, qué se prueba y cómo volver atrás si algo falla. Parchar apurado y sin plan también es un riesgo.
• Revisar si alguien entró en los equipos que tuvieron fallas atacadas. Si tu empresa está bajo la Ley 21.663 y hubo un incidente, hay que reportarlo a la ANCI en plazos cortos.
• Dejar la política de parches por escrito, ordenando por ataques reales, exposición y criticidad, no solo por gravedad.

Creo que vamos a vivir varios meses así. El desafío ya no es enterarse de las alertas, porque llegan solas. Es tener a alguien que las lea con criterio y decida cada semana qué va primero. Eso es lo que hacemos en Brumaz con empresas medianas del sur de Chile.

Si quieres revisar cómo está priorizando tu empresa, agenda una conversación de 30 minutos.