El 21 de octubre PHP publicó parches de emergencia para dos fallas críticas que dejan a cualquiera ejecutar su propio código en tu servidor. PHP mueve siete de cada diez sitios de internet. Ese mismo día, Finlandia desconectó sitios de gobierno.
Si tu sitio está en WordPress, en un hosting compartido o en cualquier cosa que haya armado alguien "en PHP", esto te toca. Y lo más probable es que nadie te haya avisado.
Qué pasó
Las fallas se registraron como CVE-2026-109618 y CVE-2026-109619, con una severidad de 9.2 sobre 10. Las dos son de *ejecución remota de código*: quien las explota no se roba un dato suelto, toma el control del servidor. La prensa de seguridad las bautizó PHP2Shell.
Según los investigadores de Wiz, que participaron en el hallazgo, todas las versiones de PHP publicadas en la última década tienen al menos una de las dos: desde PHP 5.4 en adelante. Wiz coordinó la divulgación con el equipo de PHP antes de hacerla pública.
Por qué el alcance es tan grande
PHP está en cerca del 70% de los sitios cuyo lenguaje se puede identificar, según W3Techs. Las estimaciones hechas con los sondeos de Netcraft hablan de unos 200 millones de sitios activos en internet. Haz la cuenta: hablamos de más de cien millones de sitios.
Y no son sólo blogs viejos. PHP corre WordPress, que corre una buena parte de las tiendas, portafolios y páginas de negocio que existen. Como lo resumió Wiz: PHP vive en nubes, en proveedores de hosting, en CDNs y en millones de servidores que administra cada quien por su cuenta.
La mitad nunca va a recibir el arreglo
Ésta es la parte que convierte una mala semana en un problema de años. Sólo PHP 8.2 o más reciente recibe el parche. Todo lo anterior ya no tiene soporte, así que nadie va a publicar una corrección para esas versiones.
Según Cisco, cerca de la mitad de las instalaciones de PHP expuestas a internet corre una de esas versiones. Para ellas no hay "actualiza y listo": la única salida es cambiar de versión, con todo lo que eso rompe en un sitio que nadie ha tocado en años.
Gobiernos, empresas, y un ataque armado en menos de una hora
La reacción fue inmediata. Finlandia desconectó sitios de gobierno, el parlamento de Países Bajos desconectó el suyo, y Nintendo apagó servicios mientras parchaba. No fue pánico: fue lo responsable, porque la ventana para hacerlo con calma ya no existe.
De acuerdo con The Record, armar un ataque funcional con ayuda de inteligencia artificial tomó menos de una hora. Antes, entre la publicación de una falla y su explotación masiva había días. Ahora, quien publica un sitio y no se entera de la noticia esa misma mañana ya llegó tarde.
Cómo saber si tu sitio corre PHP, y qué versión
No necesitas ser programador. Prueba en este orden:
- Si es WordPress, sí corre PHP. En el panel ve a Herramientas → Salud del sitio → Información → Servidor: ahí dice la versión exacta.
- Si tienes hosting compartido (cPanel, Plesk o similar), busca una opción como "Seleccionar versión de PHP" o "PHP Manager". La versión activa aparece ahí mismo.
- Si no sabes cómo está hecho, abre una terminal y corre
curl -I https://tusitio.com. Si en la respuesta apareceX-Powered-By: PHP/7.4, ése es tu número. (Si no aparece, no descarta nada: muchos servidores lo ocultan.) - Si alguien más te lo hizo, pregúntale una sola cosa: "¿qué versión de PHP corre mi sitio?". Si no lo sabe, ésa también es una respuesta.
Y una advertencia: si para averiguarlo alguien sube un archivo phpinfo.php, que lo borre al terminar. Ese archivo le cuenta a cualquiera exactamente qué tienes instalado, y es de lo primero que buscan los escáneres automáticos.
Qué hacer hoy, según lo que encontraste
- 8.2 o más reciente: actualiza a la versión corregida de tu rama hoy. En un hosting administrado suele ser un botón; si no lo ves, escribe a soporte y pregunta si ya lo aplicaron.
- Menor a 8.2: no hay parche para ti. Sube de versión — primero en una copia del sitio, porque plugins y temas viejos se rompen — y mientras tanto desactiva todo lo que no uses.
- Un sitio que sólo muestra información (un portafolio, una landing, la página de un negocio): pregúntate si necesita PHP. Muchos WordPress de cinco páginas se pueden exportar como sitio estático, y un sitio estático no tiene un servidor de aplicación que tomar.
- En cualquier caso: respaldo completo antes de tocar nada, y cambia las contraseñas del panel y de la base de datos si tu versión estuvo expuesta.
La misma semana: «roten todos sus secretos»
Sin relación con PHP, esa misma semana Railway, una plataforma de despliegue, pidió a todos sus usuarios rotar sus variables de entorno, llaves de API y credenciales tras un acceso no autorizado a donde las guardaban. Según su propia divulgación, del contenido de algunas se llevaron la versión descifrada, y pausó los despliegues mientras lo contenía.
Y según su página de estado, entre que lo detectaron y que avisaron a sus clientes pasaron casi quince horas. Contenerlo bien toma tiempo, y no es nuestro lugar juzgar cómo lo manejaron. Pero el dato deja una pregunta que vale para cualquier plataforma, incluida la tuya:
Ningún sistema es invulnerable. Lo que sí eliges es cuánto expones, y qué tan rápido te enteras cuando algo sale mal. Si guardas llaves en una plataforma, ten a mano cómo rotarlas todas en una tarde: algún día te lo van a pedir. Aquí explicamos qué llaves importan y cómo rotarlas.
Qué hace FluentOps, y qué no
FluentOps no corre PHP: ni la plataforma, ni lo que publicas en ella. Un proyecto PHP no se construye. Así que PHP2Shell, en particular, no tiene por dónde entrar. Pero la lección de la semana es más amplia que una falla, así que esto es lo que hacemos en general:
- Tus secretos se guardan cifrados (AES-256-GCM) y viajan cifrados. Siempre.
- Cada despliegue se revisa antes de salir: llaves escritas en el código, archivos
.envy de credenciales, código fuente expuesto (*source maps*, la carpeta.git) y dependencias con fallas conocidas. Los.envy los README no se publican; lo demás se te señala con el archivo donde está. - Cada sitio se vigila. Si un sitio publicado empieza a servir un archivo sensible, te escribimos con lo que hay que arreglar. La revisión es periódica, no instantánea: preferimos decirlo así a prometerte un "al momento" que no es cierto.
- Quien llega a probar puertas se bloquea en el borde, antes de tocar tu sitio: los escaneos que buscan
/.env,/wp-login.phpo/.git/configse cortan solos, con caducidad.
Nada de eso reemplaza tener tu propio respaldo o usar contraseñas distintas en cada servicio. Pero sí quita de tu lista lo que nadie debería tener que revisar a mano la mañana en que sale la noticia.