PHP2Shell la falla crítica de PHP

PHP2Shell: la falla crítica de PHP, explicada — y cómo la atravesó Folder

El 21 de octubre de 2026, el equipo de seguridad de PHP publicó una actualización de emergencia para dos fallas críticas que permiten tomar el control de un servidor sin usuario ni contraseña. Folder estaba entre los sitios afectados. Ya está migrado y verificado, y acá te cuento qué pasó y qué hice.

Qué pasó

PHP es el lenguaje que hace funcionar buena parte de internet: cerca del 70% de los sitios cuyo software de servidor se puede identificar, según W3Techs. Ahí entran WordPress, Drupal, Joomla y Magento.

Esta semana se confirmaron dos vulnerabilidades en su núcleo, registradas como CVE-2026-109618 y CVE-2026-109619 y apodadas PHP2Shell. Según el propio equipo de PHP, ambas puntúan 9,2 sobre 10 en CVSS v4.0, la escala internacional de gravedad. Algunos reportes previos al aviso oficial hablaban de 10.

Lo vi primero en una nota de Infobae y lo contrasté con los avisos técnicos de CERT-EU, Qualys, Sansec y otros. La lista completa está al final.

Por qué es grave

La categoría técnica es ejecución remota de código sin autenticación. Es decir: un atacante puede hacer que el servidor ejecute sus propias instrucciones sin tener cuenta ni contraseña.

Es el tipo de falla más delicada porque no depende de que alguien cometa un error ni de que se roben credenciales. Quien lo logra puede hacer en el servidor lo mismo que haría el propio sitio: leer, modificar o borrar lo que ese sitio alcanza.

Qué puede hacer un atacante

Una imagen para entenderlo: no le robaron la llave de la casa, le dieron la voz del dueño, y la casa hace todo lo que esa voz ordene. Estos son los actos concretos, de lo más silencioso a lo más visible.

Robo silencioso. Es lo más común, porque el atacante prefiere que nadie se entere.

Copia la base de usuarios: nombres, correos y contraseñas cifradas. Después prueba esas contraseñas en Gmail, bancos o Instagram, porque mucha gente las repite.
Se lleva los archivos privados. En una plataforma como Folder serían obras inéditas o catálogos que el artista todavía no hizo públicos.
En una tienda online, inserta un código invisible en la página de pago que copia cada tarjeta que se carga, mientras la compra sigue funcionando normal. Ese ataque tiene nombre propio: Magecart.
Usar el servidor como herramienta.
Manda miles de correos de spam o phishing desde tu dominio. El dominio queda marcado como fuente de estafas y tus propios mails empiezan a caer en spam.
Lo pone a minar criptomonedas: el sitio se vuelve lento y la ganancia es del atacante.
Lo suma a una red de computadoras secuestradas que atacan a otros sitios.

Envenenar a los visitantes.

Redirige a quien entra hacia sitios de estafa o de descargas con virus.
Crea cientos de páginas ocultas con publicidad de casinos o farmacias para posicionarlas en Google con tu reputación. Google termina castigando el sitio o marcándolo como peligroso, y quien comparte su link ve una pantalla roja que dice "sitio engañoso".

Lo visible.

Reemplaza el portfolio de un artista por un mensaje del atacante.
Borra todo, o lo cifra y pide rescate.

La puerta trasera. Lo primero que suele hacer un atacante es dejar un archivo escondido para volver cuando quiera. Por eso actualizar no alcanza si ya entraron: el parche cierra la puerta, pero no echa al que ya está adentro. Por eso, después de actualizar, hay que revisar si aparecieron archivos PHP desconocidos.

Un servidor, varios sitios. Una misma cuenta de hosting puede alojar varios sitios. Si el servidor obedece a un extraño, entrar por uno puede abrirle la puerta a todos los demás.

Las dos fallas, sin jerga

CVE-2026-109618, memoria agotada. Si al servidor se le acaba la memoria a mitad de una operación, PHP deja los datos del pedido a medio preparar. Después, las rutinas de limpieza trabajan sobre ese estado inválido, y eso abre un camino para ejecutar código.
CVE-2026-109619, datos obsoletos. PHP sigue apuntando a información de un pedido cuando la memoria donde vivía ya fue liberada. Es como seguir una dirección anotada de una casa demolida: lo que encontrás ahí puede ser cualquier cosa. En la jerga se llama use-after-free.

Los análisis posteriores al parche señalan dos puertas de entrada: las subidas de archivos (pedidos multipart/form-data) y el manejo de sesiones, en particular las opciones session.upload_progress.enabled y session.use_strict_mode.

A quién afecta

A casi cualquier sitio en PHP, porque la falla está en el lenguaje y no en una aplicación puntual.

Versiones: todas las ramas desde PHP 5.4 en adelante, según Sansec. watchTowr habla de PHP 5, 7 y 8 completos.
Formas de ejecutar PHP: cualquier instalación que atienda pedidos web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
Aplicaciones: da igual si el sitio usa un framework, un CMS o código propio sin dependencias. Los investigadores confirmaron la explotación sin autenticación contra Magento 2.4.9 y otras diez aplicaciones PHP.

Versiones corregidas:

PHP 8.5: corregida en la 8.5.12. Soporte activo.
PHP 8.4: corregida en la 8.4.27. Soporte activo.
PHP 8.3: corregida en la 8.3.36. Solo seguridad.
PHP 8.2: corregida en la 8.2.35. Solo seguridad, hasta el 31/12/2026.
PHP 8.1 y anteriores: sin versión oficial. Fuera de soporte.

Para 7.4, 8.0 y 8.1 se publicaron parches mínimos de código fuente, pero no versiones oficiales. Después de actualizar hay que reiniciar PHP-FPM o el servidor web para que cargue el binario nuevo. En hosting compartido, la actualización depende del proveedor.

El tamaño del problema

Unos 884.000 servidores expuestos a internet corren versiones que no van a recibir parche, según Mallory a partir de un relevamiento en Shodan.
CybelAngel cuenta 2,24 millones de hosts PHP expuestos, el 59% en versiones sin arreglo previsto.
Según Censys, citado por Cybernews, solo el 14% de los sitios públicos de WordPress tiene la última actualización disponible.

Cómo se filtró

Dos grupos de investigación, Calif y Wiz Research, reportaron las fallas a PHP de forma independiente durante agosto. La divulgación coordinada estaba prevista para el jueves 22 de octubre.

El 20 de octubre, una publicación anónima en Hacker News, borrada después, reveló que las fallas existían y rompió el embargo. watchTowr confirmó que eran reales, PHP adelantó un aviso y CERT-EU y las agencias de ciberseguridad del Reino Unido y Australia emitieron alertas.

El 21 a las 04:43 (hora argentina), Cloudflare reportó los primeros ataques, antes de que existiera el parche. Entre las 10:35 y las 10:52, PHP publicó las versiones corregidas, unos minutos antes de lo anunciado.

Hay una razón extra para la urgencia: cuando sale un parche, comparar el código viejo con el nuevo es el atajo más rápido para entender cómo explotar la falla. Los servidores sin actualizar quedan más expuestos que antes del aviso, no menos.

Qué recomendaron los especialistas

Actualizar de inmediato a 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Un desarrollador del núcleo de PHP sostuvo que actualizar es la única mitigación real.
Si no se puede actualizar ya, contener el riesgo: poner el sitio detrás de un servicio con reglas de protección como Cloudflare, bloquear las subidas multipart/form-data en el servidor web, endurecer la configuración de sesiones, o dejar el sitio en solo lectura o desconectado, como recomendó CERT-EU.
Si se usa PHP 8.1 o anterior, migrar. No va a haber arreglo oficial.
Revisar después si hubo intrusiones. Los ataques empezaron antes de que existiera el parche.

Si tenés un sitio en PHP y no sabés qué versión corre, preguntale a tu proveedor de hosting.

Qué hice en Folder

Folder es una plataforma de portfolio y catálogo para artistas, escrita en PHP y JavaScript sin frameworks. Estaba afectada: la web corría PHP 8.2.34, y el arreglo para esa rama es 8.2.35. Que no use framework no la protegía, porque la falla está en el lenguaje. Además, el vector apuntaba justo a lo que Folder usa: subidas de archivos y sesiones son el corazón del panel donde los artistas cargan su obra.

Medí la versión real de la web, no la de la consola. La que muestra la consola puede ser otro binario. Usé una prueba temporal servida por la propia web, y la borré apenas la leí.
Migré de PHP 8.2 a 8.5, en lugar de solo parchar. La rama 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026: parcharla hoy era resolver el problema por dos meses. Elegí 8.5 por ser la de soporte más largo, y Folder siguió funcionando sin cambios de código.
Revisé la arquitectura, no solo la versión. Los datos de los usuarios viven fuera de la carpeta pública del servidor, así que no hay dirección web que llegue a ellos. Y los archivos se entregan leyéndolos, nunca ejecutándolos. Aunque alguien lograra colar un archivo ejecutable entre las subidas, el servidor nunca lo correría. Por eso no hizo falta agregar reglas extra: la separación ya estaba resuelta desde el diseño.
Audité las inclusiones dinámicas de código. La única con ruta variable resultó apuntar a un archivo fijo, generado por la propia aplicación.
Limpié código muerto. Encontré en la carpeta pública código huérfano de un proyecto anterior que ya no vive ahí, y lo borré. Código que nadie mantiene es superficie de ataque que nadie vigila.
Verifiqué que las herramientas internas no respondan desde afuera sin sesión. Todas pasaron la prueba.

Lo que me deja

La autenticación no protege contra fallas del lenguaje. Folder tiene un editor interno con doble autenticación. Eso defiende del robo de credenciales, pero una falla como esta actúa antes de que el código llegue a pedir la contraseña. Contra eso, el único arreglo es el parche.
La arquitectura es la defensa que no depende de enterarte a tiempo. Separar los datos de la carpeta pública no evita una falla en PHP, pero reduce lo que un atacante puede hacer con las subidas.
Parchar no es lo mismo que resolver. Subir a 8.2.35 cerraba la falla de hoy. Salir de 8.2 cierra también las de enero.
La versión de la consola y la de la web pueden ser distintas. Hay que medir la que realmente atiende a los usuarios.

Fuentes