La noche del 21 de octubre parché un sitio de noticias con más de un millón de páginas vistas al año contra una de las peores vulnerabilidades de PHP en años. Tomó unos 90 minutos. El sitio estuvo caído unos segundos. Nadie en el cliente notó nada.

Esa última frase es toda la historia. También es la razón por la que la mayoría de la gente nunca llega a ver cómo se ve un buen trabajo técnico.

¿Qué es PHP2Shell?

PHP es el software que hace funcionar WordPress y, con él, una gran parte de los sitios web de internet. Si tu sitio está en WordPress, corre sobre PHP, aunque nadie te lo haya dicho nunca.

El 21 de octubre se hicieron públicas dos fallas críticas en el propio PHP (CVE-2026-109618 y CVE-2026-109619). Los investigadores de seguridad las bautizaron PHP2Shell, porque permiten que un atacante tome el control del servidor desde afuera. Sin contraseña, sin iniciar sesión, sin ayuda de nadie adentro. Las firmas de seguridad las calificaron con 9,2 sobre 10 y, según Patchstack, todas las versiones de PHP desde la 5.4 están afectadas por al menos una de las dos.

Lo peor fue el momento. Los detalles se filtraron antes de que el parche estuviera listo, así que el equipo de PHP tuvo que publicar una actualización de emergencia, y casi de inmediato empezaron a reportarse intentos de ataque. Google Cloud y varias empresas de seguridad publicaron alertas ese mismo día.

Dicho simple: si tenías un sitio WordPress esa noche, alguien podía estar intentando entrar, y lo único que lo iba a frenar era que alguien de tu lado hubiera instalado el parche.

Cómo fue realmente esa noche

Leí la alerta, revisé el servidor del cliente y confirmé lo que sospechaba. El sitio corría una versión vulnerable, en una de las configuraciones que las firmas de seguridad consideraban de mayor riesgo. El parche ya estaba disponible. Simplemente no se había instalado.

La actualización en sí es un solo comando. No es ahí donde se fueron los 90 minutos.

Antes de tocar nada, hice un respaldo completo del servidor, una copia capaz de devolverlo exactamente al estado en que estaba antes del cambio. También guardé la configuración y la lista de cada versión de software que iba a cambiar. Después instalé el parche, reinicié el servidor web y comprobé que la portada cargara, que los editores pudieran seguir entrando, que los feeds funcionaran y que los registros de errores siguieran limpios.

Recién entonces lo di por terminado.

Un parche sin respaldo es una apuesta. La mayoría de las veces sale bien. Pero en un sitio que publica todos los días, "la mayoría de las veces" no alcanza, y los pocos minutos que toma el respaldo son lo que permite moverse rápido sin ser imprudente.

Nadie llama para decir que el sitio funciona

Esta es la parte incómoda de este trabajo. Cuando el backend se hace bien, no hay nada que contar. El sitio carga. Los artículos se publican. El newsletter sale. Nadie manda un mensaje diciendo "hoy no hackearon el servidor, gracias".

Cuando algo se rompe, pasa lo contrario. Todos lo notan al mismo tiempo. El sitio se cae, suena el teléfono, alguien reenvía una captura de pantalla, y de repente el equipo técnico tiene la atención de todos, toda en contra.

Ese desequilibrio no es culpa de nadie. Así funciona la atención: notamos los cambios, no la estabilidad. Pero tiene un costo real. Hace que el buen mantenimiento parezca innecesario, y que quienes lo hacen parezcan no estar haciendo nada.

El ejemplo clásico es el Y2K. Miles de ingenieros pasaron años arreglando sistemas antiguos antes del 1 de enero de 2000. Llegó la fecha, casi no pasó nada, y hasta hoy mucha gente recuerda el Y2K como una falsa alarma. No fue una falsa alarma. Fue un problema resuelto tan bien que desapareció.

Si PHP2Shell hubiera alcanzado el sitio de este cliente, habría sido noticia, quizás literalmente. Como no pasó, lo más dramático de esa noche fue un reinicio de tres segundos.

La emergencia fue la parte fácil

Quiero ser honesto con algo, porque es la lección más útil.

Parchar rápido durante una emergencia es el tipo de mantenimiento visible y satisfactorio. El más difícil es el trabajo rutinario que nadie pide: aplicar actualizaciones cada mes cuando no hay alerta, ni titular, ni plazo. Cuando revisé el servidor esa noche, el parche de PHP2Shell no era la única actualización pendiente. Había otras que se habían acumulado en silencio, porque nada estaba en llamas.

Eso es normal, y también es como la mayoría de los sitios terminan expuestos. No por un error dramático, sino por meses de "funciona, mejor no lo toquemos". Por eso el próximo paso para este cliente no es otra emergencia. Es una ventana de mantenimiento corta y programada, para que la próxima alerta encuentre un servidor que ya está al día.

Hacer visible el trabajo invisible, sin hacer ruido

Si el buen mantenimiento es silencioso, ¿cómo sabe alguien que está ocurriendo?

La respuesta que uso es simple: dejarlo por escrito. Cada intervención queda en una nota corta, en lenguaje claro, para alguien que no es técnico. Qué pasó, por qué importaba, qué hice y qué viene después. Con PHP2Shell, el cliente recibió exactamente eso esa misma noche, antes de que nadie tuviera que preguntar.

No es un informe dramático. No necesita serlo. Solo significa que cuando alguien pregunte "¿qué hace realmente el equipo técnico?", habrá una respuesta que no sea una suposición.

¿Tu sitio está afectado por PHP2Shell?

Si tienes un sitio en WordPress, o cualquier sitio hecho con PHP, no necesitas entender los detalles. Necesitas poder obtener respuestas claras a tres preguntas de quien lo mantiene:

  • ¿Qué versión de PHP corre mi sitio, y ya incluye el parche de PHP2Shell? Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Cualquier versión anterior de esas ramas está expuesta. Las ramas antiguas que ya no tienen soporte no recibirán parche.
  • ¿Quién se habría enterado de PHP2Shell, y cuándo? Si la respuesta honesta es "nadie, hasta que algo se rompiera", ese es el problema real, no esta falla en particular.
  • ¿Hay un respaldo antes de cada actualización? No "tenemos respaldos en alguna parte". Un respaldo hecho justo antes del cambio, que alguien sepa restaurar.

Si las respuestas son vagas, no significa que tu sitio esté comprometido. Significa que nadie lo está vigilando, y eso vale la pena arreglarlo antes de la próxima alerta, no después.

El mejor cumplido que puede recibir el trabajo de backend es el silencio. Solo vale la pena saber que ese silencio se ganó.