PHP2Shell: la falla de tu web que ningún plugin puede arreglar

Nos enteramos de esta por el boletín de un proveedor de software, un día antes de que saliera el arreglo. No por un panel, no por nuestro hosting, no por WordPress. Si ese correo se hubiera ido a spam, nos habríamos enterado después que los que ya andaban buscando servidores vulnerables.

Esa es la verdadera lección, y también aplica a tu página web.

Qué pasó

El 20 de octubre, el proyecto PHP publicó un aviso anticipado poco común: al día siguiente saldría una versión de seguridad para dos vulnerabilidades calificadas con 9,2 sobre 10 en la escala CVSS. El 21 de octubre a las 14:00 UTC publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, con un titular sin rodeos: «Vulnerabilidades críticas de ejecución remota de código, actualiza ya».

«Ejecución remota de código» significa que un atacante puede hacer que tu servidor corra sus propios comandos. Las dos fallas se pueden activar con una petición web anónima, sin contraseña y sin cuenta. PHP dice que el aviso aplica a toda instalación de PHP que sirve páginas web, y considera mayor el riesgo en los servidores que corren PHP dentro de Apache con mod_php, donde «una petición sin autenticar puede activar el ataque antes de que corra cualquier código de la aplicación».

Esa última parte importa. El ataque ocurre antes que WordPress, antes que tus plugins, antes de que tu plugin de seguridad alcance a mirar la petición.

Por qué tus plugins no pueden arreglar esto

La mayoría de las páginas web de las pymes están hechas en WordPress, y WordPress está escrito en PHP. PHP es el motor de abajo. El código de tu sitio, los temas y los plugins van encima.

Cuando un plugin tiene una falla, actualizas el plugin. Esto es distinto. La falla está en el motor, así que hay que cambiar el motor. Cloudflare lo dijo claro en su propio análisis: «actualizar el código del sitio o uno o varios plugins no corrige estas vulnerabilidades».

Quién cambia el motor depende de cómo esté alojado tu sitio:

• Hosting compartido o administrado (la mayoría de las pymes): tu hosting actualiza PHP. Tú no puedes hacerlo, y no deberías tener que hacerlo.
• Un servidor o VPS que rentas y administras tú: el hosting eres tú. Nadie más lo va a hacer.
• Tu diseñador web lo dejó armado y se fue: averigua hoy cuál de los dos casos anteriores es el tuyo.

¿Alguien lo está atacando de verdad?

Sí, los intentos empezaron casi de inmediato. La empresa de seguridad watchTowr informó el 21 de octubre que se había observado explotación real en su red de honeypots, que son servidores señuelo puestos para atrapar atacantes. Cloudflare dijo que detectó tráfico de ataque dirigido a sus clientes, y que los atacantes iban cambiando sus cargas para esquivar los filtros.

Al momento de escribir esto, CISA todavía no había agregado ninguna de las dos fallas a su catálogo de vulnerabilidades explotadas, y no vimos ninguna confirmación pública de una intrusión exitosa. Esa es la ventana en la que quieres tener el parche puesto, no la de después.

Si tu sitio está detrás de Cloudflare

Hay una buena noticia. Cloudflare dice que desde el 21 de octubre a las 3:02 UTC, unas nueve horas antes de que las fallas se hicieran públicas, los clientes que usan su firewall quedaron «protegidos por defecto», incluido el plan gratuito. Los clientes gratuitos no tienen que activar nada.

Pero hay dos límites. El filtro solo ve el tráfico que de verdad pasa por Cloudflare, así que quien pueda llegar directo a tu servidor le pasa por el costado. Y la misma Cloudflare dice que sus clientes «deben aplicar el parche de PHP incluso con las protecciones del WAF». Un filtro bloquea los ataques que reconoce. El parche elimina la falla.

La trampa del número de versión

Uno pensaría que basta con buscar «8.4.27» o «8.3.36». A veces sirve. A veces te engaña feo.

Las distribuciones de Linux muchas veces parchan la versión que ya entregan en vez de pasar a una nueva. El arreglo de Ubuntu para su versión 24.04, publicado el mismo día, es php8.3 versión 8.3.6-0ubuntu0.24.04.13. Está parchado, y dice «8.3.6». Ubuntu 22.04 incluso recibió un arreglo para PHP 8.1, una versión que el propio proyecto PHP ya no actualiza.

O sea, un número que parece viejo no prueba que estés expuesto, y un número que parece nuevo no prueba que estés a salvo. La única respuesta confiable la tiene quien lo instaló.

Lo que hicimos en nuestros servidores

En las primeras horas aplicamos una mitigación temporal del aviso de PHP y esperamos los paquetes con el parche. El servidor de descargas popular que usan muchos servidores Ubuntu para las versiones actuales de PHP estuvo devolviendo errores casi toda la tarde. Su mantenedor indicó un espejo alterno, y nuestros servidores quedaron en la versión corregida esa misma noche, probada primero en una copia del sitio.

Lo contamos porque «salió el parche» y «el parche está instalado» pueden estar a horas de distancia aunque alguien esté trabajando en eso. Si nadie está trabajando en eso, pueden estar a meses.

Qué preguntarle a tu hosting esta semana

1. «¿Ya aplicaron el parche de PHP contra CVE-2026-109618 y CVE-2026-109619, y en qué fecha?» Usa los números CVE. Convierten una pregunta vaga en una que se responde con sí o no.

2. «¿Qué versión de PHP usa mi sitio, y todavía tiene soporte?» Puedes ver la versión tú mismo en WordPress, en Herramientas, luego Salud del sitio, pestaña Información, sección Servidor. Si es 8.1 o anterior, pregunta cómo la están cubriendo, porque el proyecto PHP ya no lo hace.

3. «¿Reiniciaron PHP después de actualizar?» Un parche en el disco no hace nada hasta que se reinicia el PHP que está corriendo. A un buen hosting esta pregunta le va a parecer obvia. Está bien.

Si en uno o dos días no te dan una respuesta clara por escrito, esa es tu respuesta.

Por dónde empezar

Entra a tu panel de WordPress, revisa la versión de PHP en Salud del sitio y mándale a tu hosting las tres preguntas de arriba. Son diez minutos.

Después hazte la pregunta grande: ¿quién en tu empresa se habría enterado de esto si el boletín nunca hubiera llegado? Saber qué software usas, estar atento a los arreglos e instalarlos con un calendario es justamente lo que es la gestión de parches y vulnerabilidades. Es el mismo problema que una versión de Office que deja de recibir arreglos sin avisar, una capa más abajo. Si hoy nadie se encarga de eso, hablemos.

Fuentes: aviso de seguridad de PHP, Cloudflare, Ubuntu USN-8948-1, watchTowr. Las citas están traducidas del inglés.