PHP2Shell, día 2: explotación cuatro días antes del aviso y un voluntario a cargo del parche

PHP2Shell, día 2: explotación cuatro días antes del aviso y un voluntario a cargo del parche

Escucha este artículo en audio (1:58 min, resumen del artículo original)

📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.

PHP2Shell, día 2: explotación cuatro días antes del aviso y un voluntario a cargo del parche

Esta semana un desarrollador apareció en HackerNews con un hilo de perdones consecutivos: había avisado antes de tiempo sobre los RCE críticos de PHP y resultó romper, sin saberlo, el embargo de divulgación coordinada de los CVE-2026-109618 y CVE-2026-109619. Su versión: su contacto le aseguró que no existía embargo, y el contacto de su contacto le dijo exactamente lo mismo. Cuando la cosa explotó, escribió «tomo toda la responsabilidad» y asumió las consecuencias sobre el calendario de disclosure.

Mi lectura es distinta de la suya. Si nadie te informó que existía una restricción, no la rompiste: alguien más arriba en la cadena perdió el dato, y el problema es de proceso, no de persona. En el hilo lo dijeron todos con más elegancia que yo: un embargo no obliga a nadie que ni siquiera está dentro del juego. Y el post-mortem tiene que ser sin culpa, porque si la gente se avergüenza, deja de reportar, y ahí comienzan los desastres de verdad. Asumir el castigo por un error administrativo ajeno es generoso, pero ensombrece la autopsia.

El aviso llegó cuatro días tarde

Mientras eso pasaba, el blog de seguridad de Amazon soltó el dato incómodo: su red de honeypots MadPot registró un intento de explotación de PHP2Shell el 17 de octubre, cuatro días antes de la divulgación pública. El atacante venía de una infraestructura de anonimización, así que alguien tenía el exploit antes del 21 de octubre a las 14:00 UTC, cuando recién se levantó el embargo. Ese mismo día del release ya circulaban exploits de prueba contra sus sensores desde las 02:00 UTC: doce horas antes del parche oficial. Hoy el tema ya es explotación masiva en la calle.

Ninguna de las dos vulnerabilidades vive en tu código. Está en el motor, en lo que pasa cuando una request se muere a media inicialización y el código de limpieza confía en memoria que nunca se llenó. El bug puede activarse con una request sola, antes de que tu aplicación tenga la oportunidad de decir que no: así de simple es el «sin autenticación» del CVSS 9.2. Eso sí, una precisión necesaria: los PoCs públicos funcionan para combinaciones específicas de sistema, versión y servidor web, así que «el 70% de la web vulnerable» es titular, no diagnóstico.

El voluntario invisible

La parte que más me impactó salió en The Atlantic: el tipo que permitió que medio internet parchara a tiempo, Ondřej Surý, hace ese trabajo como voluntario. En su pega es director de ingeniería de DNS en ISC; el empaquetado de PHP que usan media Debian, media Ubuntu y servicios como Laravel Forge es una changa que financia con donaciones modestas. Cuando el release de emergencia tuvo que acelerarse, fue una de las pocas personas de las que dependió que los sysadmins del mundo tuviéramos binarios listos en horas. El día del parche los sitios andaban abajo justamente por eso: gobiernos de Alemania y Finlandia, hospitales y hasta 4chan bajaron para aplicar el fix.

La fundación PHP, para su crédito, fue honesta sobre la otra mitad del fiasco: el arreglo se venía arrastrando desde una auditoría de 2024 y se estancó por parches alternativos en competencia. Su frase textual fue brutal: llamaron al retraso un «fallo estructural» del proceso de seguridad y su falta de recursos. Eso es más valioso que cualquier post-mortem de corporación con abogados de por medio.

Lo que me llevo de la semana

Yo pasé por esto del lado del sysadmin. Ese mismo día 21 actualicé PHP en mis paneles vía CLI: php83 a la 8.3.36 y php82 a la 8.2.35, verificando con php -v, porque los binarios del panel no siempre traen las versiones parchadas al minuto. Tres conclusiones: los SLA de parchado se miden ahora en horas, no en días; la fecha de divulgación NO es la fecha de primera explotación; y no confíes solo en firmas por CVE, porque la primera oleada llega antes de que existan. Y si todavía corres Apache con mod_php, eres el caso más frágil de todos: PHP-FPM mata al worker cuando la startup falla, mod_php insiste en limpiar de todos modos.

Fuente del tema: The Man Who Saved the Internet Yesterday, de The Atlantic.

Fuente de inspiración: The Man Who Saved the Internet Yesterday (The Atlantic)

Comentarios

Aún no hay comentarios. ¿Por qué no comienzas el debate?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *