El parche no es lo difícil. Saber quién lo aplica, sí

1. Esta vez revisé el mismo día

La alerta de PHP me llevó a revisar las cuentas que administro.

Antes de saber si alguna estaba expuesta, tuve que descubrir qué tenía. Una cuenta seguía en PHP 5.6, una versión para la que ya no existe una corrección oficial. Actualizarla no era aplicar un parche: era mover el sitio a otra versión y comprobar que siguiera funcionando.

Otra cuenta estaba en PHP 8.1. Esa rama ya no recibe actualizaciones normales del proyecto, aunque algunos proveedores pueden ofrecer correcciones trasladadas desde versiones más nuevas. Depende de que alguien las empaquete y las ponga a disposición.

La mayoría estaba en la rama 8.2. El parche ya existía, pero el servidor todavía no lo traía. Esa capa no la actualizo yo, sino el proveedor de alojamiento. La revisión podía hacerla el mismo día. La última palabra no era mía.

La configuración observada tampoco era mod_php, el modo que el aviso señalaba como el de mayor riesgo. Es una buena noticia, pero no una medida que yo hubiera elegido o aplicado. Venía dada por el servidor.

Ahí estaba el problema completo: no bastaba con saber que había un parche. Tenía que saber qué versiones tenía, qué podía cambiar yo y qué dependía de alguien más.

2. Tres problemas, tres capas

La conversación pública de esta semana resumió el problema desde el punto de vista de quien visita una página. Freddy Montes lo contó en X con una frase sobre un internet que amaneció «borracho, sin plata y no sabe cómo llegó ahí», seguida de tres consejos: cuidado con PHP, actualiza el navegador y actualiza Node.

El resumen era claro. El destinatario estaba equivocado, al menos para el problema que nos ocupa.

PHP no es una aplicación que el visitante pueda actualizar desde su navegador. Es una pieza que corre en el servidor y que sostiene sitios como WordPress. El 21 de octubre, el proyecto de PHP publicó correcciones para dos vulnerabilidades críticas que podían permitir ejecución remota de código sin autenticación. Las versiones corregidas fueron 8.2.35, 8.3.36, 8.4.27 y 8.5.12.

Si el sitio está en un hosting compartido, quizá el dueño no pueda instalar esa actualización. Puede pedirla, comprobarla y cambiar la versión que el proveedor le permite elegir. Pero alguien tiene que actualizar el software del servidor.

Los certificados de eMudhra eran otra capa. Cloudflare informó que se habían comprometido las claves privadas asociadas con ocho certificados intermedios. Un certificado falso puede hacer que un programa crea que está hablando con el sitio correcto cuando en realidad alguien está interceptando o modificando la conexión.

En ese caso, la respuesta puede estar en el navegador, el sistema operativo, una biblioteca, un almacén de certificados, un contenedor o una aplicación que trae sus propias reglas. El sitio puede seguir cargando y, aun así, haber una pieza de confianza que necesita actualización.

Node.js es otra cosa más: un entorno para ejecutar JavaScript en el servidor. El visitante tampoco lo actualiza desde su navegador. El proyecto publicó actualizaciones para sus ramas 22, 24 y 26, entre ellas una actualización relacionada con el certificado intermedio de eMudhra y otras dependencias.

Tres avisos. Tres capas. Tres responsables posibles.

Por eso la pregunta útil no es «¿hay un parche?». Es «¿en qué parte está el parche y quién tiene permiso para aplicarlo?».

3. Mitigar no es arreglar

Cloudflare desplegó reglas de protección contra PHP2shell antes de la publicación oficial y reportó tráfico de ataque dirigido a sus clientes. Es una capa importante. También es una capa que compra tiempo.

La propia recomendación es mantener la protección mientras se actualiza PHP. Una regla del cortafuegos puede bloquear algunas solicitudes maliciosas. No cambia la versión vulnerable que sigue instalada en el servidor.

Con los certificados sucede algo parecido. Después de una actualización pueden aparecer errores porque una aplicación ya no confía en un certificado que antes aceptaba. Desactivar la verificación para que el error desaparezca no es arreglarlo. Es quitar la comprobación que impedía aceptar una conexión falsa.

Una mitigación reduce una ruta de ataque. Una corrección elimina el defecto. No son sinónimos, aunque ambas cosas aparezcan en el mismo aviso.

En algunos entornos puede ser necesario sacar un servicio de línea mientras se contiene una emergencia. Eso es una decisión de emergencia, no una solución general para cualquier sitio. El aviso del proyecto PHP es más sencillo: las medidas temporales reducen la exposición; sólo actualizar ofrece una solución completa.

4. «Funciona» no significa «está mantenido»

Un sitio viejo puede cargar rápido, recibir formularios y mostrar el logotipo correcto. Eso sólo demuestra que funciona hoy.

No demuestra que el lenguaje que lo ejecuta siga recibiendo correcciones. PHP 5.6 ya no tiene un parche oficial para este problema. PHP 8.1 depende de correcciones que alguien más debe trasladar y empaquetar. Una versión más nueva puede tener el parche en el proyecto, pero no en el servidor donde vive el sitio.

La diferencia importa porque muchas personas creen que mantener un sitio consiste en comprobar si abre. Si abre, se da por hecho que está bien.

Pero el sitio no es sólo lo que ves. También hay un sistema operativo, un servidor web, un lenguaje, extensiones, certificados, dependencias, copias de seguridad y cuentas con permisos. Algunas de esas piezas no tienen una pantalla que el dueño pueda revisar. Es la misma diferencia que aparece cuando una primera versión funciona pero todavía no es un sistema: la barrera no era programar, sino saber cuándo ya tenías un sistema.

La tranquilidad de «alguien se encarga» funciona hasta que llega una alerta y nadie sabe quién es ese alguien.

5. El consejo llegó a la persona equivocada

«Actualiza tu navegador» es un consejo razonable para quien usa una computadora. Los navegadores suelen recibir actualizaciones automáticas y pueden retirar certificados comprometidos sin que el usuario tenga que conocer el nombre de la autoridad certificadora.

Pero ese no es el caso de PHP, Node.js o muchas bibliotecas que usa un sitio. El dueño puede pagar el alojamiento durante años sin saber qué versión está instalada. Puede pensar que el hosting incluye mantenimiento porque el sitio está alojado ahí. Puede descubrir después de un incidente que nadie había pactado quién revisaba los avisos, quién aplicaba las actualizaciones o quién respondía un fin de semana.

El problema no es que el cliente no sepa distinguir PHP de Node.js. El problema es que compró una responsabilidad repartida en capas y recibió la impresión de que era una sola cosa.

6. La ventana se acortó

Durante esta semana hubo detalles técnicos que cambiaron en horas: primero rumores, luego un aviso, después medidas temporales, parches, reglas de protección y tráfico que intentaba encontrar una forma de pasar.

La historia que contó la propia PHP Foundation agrega una capa incómoda. Una de las fallas había aparecido como señal en una auditoría externa de 2024. Convertir esa señal en una corrección tomó mucho más: algunas soluciones rompían compatibilidad, podían crear nuevos problemas de disponibilidad o exigían cambios difíciles de coordinar entre extensiones. El equipo reconoce que el trabajo se detuvo y reinició durante meses por una combinación de decisiones lentas y falta de personas con conocimiento profundo del motor.

Después llegaron más herramientas y más investigadores. La Foundation cuenta que usó herramientas como Claude Mythos y Daybreak Red para revisar informes y validar pruebas, mientras Calif, OpenAI y Wiz encontraron o confirmaron distintos caminos hacia la ejecución remota de código. Las herramientas aceleraron la búsqueda. Las personas siguieron tomando las decisiones y escribiendo los parches.

El problema no fue solamente que alguien encontrara una vulnerabilidad. Fue que el hallazgo, la validación, la decisión técnica, la coordinación con distribuidores y la instalación en cada servidor son trabajos distintos.

Cuando la información se filtró, el proyecto PHP adelantó un día la publicación para que los distribuidores alcanzaran a empaquetar la corrección. La Foundation dijo que no había identificado exploits funcionales en el momento de la divulgación. Aun así, la velocidad de los intentos fue otra. Según Matthew Prince, la red de Cloudflare registró miles de intentos durante las diez horas previas al anuncio público, decenas de miles en los primeros 45 minutos, cientos de miles en dos horas y millones después.

Eso no significa que todos los sitios fueran atacados ni que todos estuvieran expuestos de la misma manera. Sí significa que esperar a que «alguien lo vea» ya no es un plan suficiente.

Entre el aviso y el ataque puede caber un fin de semana. A veces caben menos horas.

7. Tres preguntas antes de pagar por tranquilidad

No necesitas saber programar para hacerte cargo de esta parte. Necesitas que la responsabilidad tenga nombre.

Pregúntale a quien lleva tu sitio:

• ¿Qué versión de PHP tengo y quién puede actualizarla?
• ¿Quién revisa y actualiza WordPress, las extensiones, los certificados y las dependencias del servidor?
• ¿Cómo me avisan cuando aparece una alerta y quién actúa si ocurre fuera del horario de oficina?

Añadiría una cuarta: ¿qué queda fuera del servicio?

Si la respuesta es «eso lo ve el hosting», pregunta qué significa exactamente. ¿El proveedor instala los parches? ¿Sólo ofrece una versión nueva para que tú la elijas? ¿Reinicia los procesos? ¿Confirma que el cambio quedó activo?

El parche de julio tardaba minutos. Lo caro fue no tener a nadie que lo aplicara a tiempo.

El parche de octubre podía estar disponible y, aun así, quedar fuera de mi alcance. Tener un sitio no consiste sólo en que cargue. También consiste en saber qué tiene, quién lo mantiene y cómo te enteras cuando algo cambia.