¿Es seguro Internet tras la pesadilla de PHP? Lo que debes saber

Un día después de que dos errores en PHP hicieran que los gobiernos se apresuraran a desconectar sus sitios web, la solución ya está disponible, los atacantes están golpeando sin descanso, y mucha gente se pregunta lo mismo: ¿Puedo usar internet sin preocuparme, o debería esconderme debajo de la cama hasta la próxima semana?

La respuesta corta es que internet no se rompió, y para la mayoría de las personas el riesgo recae en los sitios web que visitan, no en sus propios teléfonos o computadoras portátiles. La respuesta larga tiene algunas advertencias que vale la pena conocer.

Repaso rápido: PHP es el software que se ejecuta entre bastidores en aproximadamente el 70% de los sitios web cuyo lenguaje del lado del servidor es conocido, y los dos errores, apodados PHP2Shell, permiten que un desconocido tome el control de un servidor vulnerable sin iniciar sesión.

¿Está solucionado?

Entonces, ¿está solucionada la explotación? Sí, en su mayor parte. PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 el miércoles, según sus notas de la versión. "No existen mitigaciones completas, actualizar es la única opción segura". Hasta el jueves, PHP no ha emitido ningún parche de seguimiento.

Sin embargo, una solución solo ayuda una vez que alguien la instala. PHP no se actualiza a sí mismo, por lo que cada empresa de alojamiento, departamento de TI y propietario individual de un sitio web tiene que aplicarla en sus propios servidores, y luego reiniciar el software para que surta efecto.

En otras palabras, la solución ya existe, pero eso no significa que los sitios que visitas estén necesariamente a salvo.

PHP 8.1 y versiones anteriores ya no reciben versiones oficiales, lo que convierte a los servidores más antiguos en el punto débil, aunque el equipo de seguridad de PHP publicó parches mínimos para 7.4, 8.0 y 8.1 para quienes compilan el software por sí mismos.

¿Alguien fue hackeado realmente?

Los atacantes ciertamente lo intentaron: el CEO de Cloudflare, Matthew Prince, dijo que su red registró miles de intentos de explotación en las 10 horas previas al anuncio, decenas de miles en los 45 minutos posteriores a él, cientos de miles en dos horas y millones desde entonces.

Amazon fue más allá, diciendo que sus servidores señuelo registraron un intento el 17 de octubre, cuatro días antes de que los fallos se hicieran públicos. "Sigue sin estar claro cómo el actor adquirió información de explotación antes de la divulgación", escribió el CISO de Amazon, CJ Moses, y añadió que PHP2Shell "ahora está siendo ampliamente explotado en la naturaleza".

Los gobiernos, sin embargo, no parecen haber experimentado ningún tipo de intrusión exitosa todavía. Thomas Caspers, vicepresidente de la agencia federal de ciberseguridad de Alemania, BSI, dijo que la agencia había visto ataques pero ningún uso exitoso de los fallos, y añadió: "Parece un poco más complicado de lo esperado explotarlo". El secretario jefe del Gabinete de Japón, Minoru Kihara, también dijo que no se habían confirmado ataques que explotaran los fallos.

Un intento es alguien sacudiendo el pomo de la puerta; una brecha es alguien entrando, así que ambas afirmaciones pueden ser ciertas a la vez. Millones de pomos sacudidos y cero intrusiones confirmadas son buenas noticias, pero las intrusiones tienden a descubrirse más tarde, no en tiempo real.

¿Por qué no se detectó esto antes?

En cierto modo, sí se detectó. En una entrada de blog publicada el miércoles, la PHP Foundation dijo que su trabajo de seguridad en 2024 "encontró los primeros signos del problema de OOM detrás de CVE-2026-109618", es decir, el error de falta de memoria en el centro de una de las dos fallas.

El equipo ideó "varios enfoques en competencia" para solucionarlo, pero "les costó elegir entre estos y temían las repercusiones de lanzar la opción equivocada", según la fundación. "Sin la financiación de la Foundation habría sido imposible que varias personas trabajaran en este problema a tiempo completo", añadió.

"No vamos a fingir lo contrario: el retraso fue un fallo estructural, causado tanto por el proceso de decisión del equipo de seguridad como por su falta de recursos", escribió la fundación, y añadió que su equipo de seguridad, que antes necesitaba consenso, ahora decidirá por mayoría. Para el software que ejecuta la mayor parte de la web, ese trabajo de seguridad "sigue dependiendo de un pequeño grupo de desarrolladores financiados por la fundación y de un poco de ayuda voluntaria", según la publicación.

¿Por qué algunos sitios web siguen caídos?

Porque aplicar los parches lleva tiempo, y "desconectarse" fue el consejo oficial para cualquiera que no pudiera parchear de inmediato. El Centro Nacional de Ciberseguridad del Reino Unido dijo a las organizaciones que consideraran "desconectar el sistema hasta que pueda mitigarse por completo".

La lista de sitios que se cayeron el miércoles se hizo larga rápidamente. Según TechRadar, incluía los servicios de Wikimedia, sitios web y aplicaciones de Orange en docenas de países, 32 servicios del gobierno del Reino Unido, hospitales neerlandeses y el proveedor federal de TI de Alemania, ITZBund.

La Oficina de Responsabilidad Presupuestaria del Reino Unido y el sitio web del ayuntamiento de Edimburgo ya habían vuelto el jueves. Otros, como el sitio neerlandés de denuncia anónima de delitos Meld Misdaad Anoniem, seguían desconectados el jueves por la mañana, según DutchNews.

¿Debería cambiar mis contraseñas?

No por esto, al menos no todavía. Hasta ahora no se ha vinculado ninguna brecha de datos confirmada a PHP2Shell, y cambiar todas las contraseñas hoy no ayudará si el servidor de un sitio sigue sin parchear.

Lo que sí ayuda es lo aburrido: contraseñas únicas para cada cuenta, la autenticación de dos factores activada y prestar atención si una empresa te envía un correo electrónico sobre una brecha en las próximas semanas. Si aparece una, cambia esa contraseña y cualquier cuenta en la que la hayas reutilizado.

Los propietarios de sitios web tienen más deberes, porque aplicar los parches cierra la puerta pero no te dice si alguien entró primero. La empresa de seguridad Tag1 aconseja buscar archivos PHP que no subiste, nuevas tareas programadas y nuevas cuentas, y rotar las contraseñas de bases de datos y las claves de API en cualquier servidor expuesto a internet que ejecutara una versión vulnerable.

¿Y las criptomonedas?

El fundador de Binance, Changpeng Zhao, tenía un breve consejo en X: "Llámenme paranoico, pero tengan mucho cuidado al visitar CUALQUIER sitio web en los próximos días".

Un servidor web hackeado puede mostrarte una versión falsa de un sitio real, y en el mundo cripto eso normalmente significa una página que te pide conectar tu billetera y aprobar una transacción que la vacía. Una red blockchain en sí misma puede estar bien; los sitios web que están delante de ella podrían no estarlo.

Durante los próximos días, verifica tres veces lo que estás firmando, guarda en marcadores los sitios que usas en lugar de hacer clic en enlaces, y usa una billetera de hardware si tienes una. Hasta ahora, ningún exchange de criptomonedas ha reportado públicamente una brecha vinculada a PHP2Shell.

Entonces, ¿es seguro?

Navegar por la web hoy es aproximadamente tan seguro como lo era la semana pasada, es decir, no del todo. La exposición real está en los servidores que no han sido parcheados, y la empresa de seguridad Mallory contó aproximadamente 884.000 hosts expuestos a internet que ejecutan versiones de PHP que no reciben corrección oficial.

El consejo de Amazon a los defensores es básicamente que esto no ha terminado. "Los defensores no deberían asumir que la fecha de divulgación pública es la fecha más temprana de explotación". Cualquier servidor que haya ejecutado una versión vulnerable desde al menos el 17 de octubre debería ser revisado, no solo parcheado.