En junio de 1995, un programador danés-canadiense llamado Rasmus Lerdorf publicó un mensaje en un foro de Usenet anunciando un conjunto de herramientas que había escrito, el objetivo era saber quién estaba mirando su hoja de vida en internet. Las llamó Personal Home Page Tools.
No era un proyecto para cambiar la web. Era un contador de visitas con formularios.
Lo que Lerdorf había hecho sin proponérselo era borrar una frontera. En ese entonces, para que una página hiciera cosas como —mostrar datos distintos a cada visitante, recibir un formulario, consultar una base de datos— había que escribir un programa aparte, en lenguajes más complejos, y hacer que el servidor lo ejecutara. PHP permitió escribir esa lógica dentro de la misma página.
La “P” de media internet
De aquel ejercicio salió, unos años después, el eslabón que sostiene una gran parte de lo que usamos todos los días. PHP es la “P” de LAMP —Linux, Apache, MySQL y PHP—, la combinación de software libre sobre la que se construyó la web comercial de los dos mil. Es el lenguaje con el que está escrito WordPress, que mueve una porción gigantesca de los sitios del mundo. Es el lenguaje de MediaWiki, el programa detrás de Wikipedia. Facebook se escribió en PHP durante sus primeros años, antes de construir su propio motor y su propio dialecto de PHP para aguantar la escala.
Según W3Techs, a 22 de octubre de 2026 PHP estaba en el 69,3 % de los sitios cuyo lenguaje de servidor se puede detectar. Aunque la cifra viene bajando, sigue siendo una cifra enorme, y sigue significando que si tu empresa tiene un sitio web, es muy probable que por debajo haya PHP.
El lenguaje más burlado de la programación
Despreciar PHP ha sido durante años un deporte entre programadores, lo que en el mundo del desarrollo se llama coloquialmente PHP-bashing. Su texto canónico es un ensayo de 2012 titulado PHP: a fractal of bad design —PHP, un fractal de mal diseño—, que todavía hoy se cita en cualquier discusión. Las críticas de fondo son reales y los propios programadores PHP las reconocen: una biblioteca de funciones heredada y poco coherente, decisiones viejas que no se pueden revertir sin romper media web, nombres y órdenes de parámetros que no siguen ninguna lógica.
Pero la mayor parte del desprecio no viene de ahí. Viene de que PHP era fácil de aprender y estaba en todas partes. Cualquiera con un hosting de cinco dólares podía subir un archivo y tener algo funcionando. Eso significó que una generación entera aprendiera a programar en PHP, y que gran parte de este código lo escribieron personas “inexpertas”.
La simetría es incómoda: lo que a PHP se le reprocha es exactamente la razón por la que la web se llenó de sitios e información. Si construir en internet hubiera requerido dominar un lenguaje complejo, internet en los dos mil hubiera sido bastante aburrido.
La broma envejeció mal. PHP 7, en 2015, llegó a ser el doble de rápido que su antecesor, trajo además declaraciones de tipo. En PHP 8 compilación al vuelo y una sintaxis nueva. Aunque para cálculo intensivo este lenguaje seguirá siendo más lento que Go o Rust, el PHP moderno no se parece en nada al que vio nacer la web.
Y entonces llegó el 21 de octubre
El martes 20 de octubre, sobre las 15:00 UTC, se filtraron en foros y redes los códigos de identificación de dos vulnerabilidades que todavía no eran públicas. El equipo de seguridad de PHP tenía la corrección programada para el día 22; al filtrarse, la adelantó al 21 y publicó el preaviso esa misma noche.
El 21 de octubre salieron cuatro versiones de golpe —8.5.12, 8.4.27, 8.3.36 y 8.2.35 — y un aviso que no se lee a menudo en php.net: “se recomienda encarecidamente a todos los usuarios de PHP que actualicen de inmediato“.
Las dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, permiten que un desconocido ejecute código dentro de tu servidor sin tener usuario ni contraseña, enviándole peticiones normales a tu sitio web. PHP las califica con un 9,2 sobre 10. Esto afecta a prácticamente todas las versiones de PHP en uso. El aviso oficial publica correcciones para las series 8.2 a 8.5; quien corra algo más viejo tiene que mirar aparte.
Wiz, una de las empresas que participó en el hallazgo, bautizó al conjunto PHP2Shell y con ese nombre circula la noticia.
“se ha observado explotación en estado salvaje desde el 21 de octubre“
Lo demás pasó en horas:
- Cloudflare ya estaba protegiendo, antes de que el fallo fuera público. Sus reglas de filtrado se aplicaron unas nueve horas antes del anuncio. Dice también que los atacantes empezaron a mutar el ataque para esquivarlas, y que el filtro es una medida adicional mientras se actualiza a la versión corregida.
- Los primeros intentos conocidos son anteriores al parche y a que el fallo fuera público. Patchstack registró a las 07:34 UTC del 21 de octubre los primeros avisos de explotación que le llegaron de sus socios de hosting y, horas después, con su propia telemetría, describió lo que veía como sondeo, sin evidencia firme de intrusiones. Amazon reportó un intento contra su red de señuelos el 17 de octubre, cuatro días antes de la divulgación.
- CISA, la NSA y el centro de ciberseguridad británico pidieron parcheo inmediato, cada uno con comunicado propio, y los tres recomendaron desconectar los sistemas que no se pudieran actualizar.
- En Europa hubo sitios de gobiernos, universidades y hospitales que se apagaron mientras actualizaban: Dinamarca, Finlandia, Francia y Países Bajos retiraron páginas de gobierno —en el caso neerlandés, servicios tan centrales como DigiD y MijnOverheid—, y en Alemania cayeron desde partes del portal de Berlín hasta la web del hospital universitario Charité y los servicios de TI de la Universidad Libre.
- Varios servicios de la industria se detuvieron por su cuenta: la plataforma de despliegue de Laravel pausó las publicaciones y otras herramientas se apagaron para actualizar.
Al cierre de este artículo el volumen de ataque es enorme y el daño confirmado hasta ahora, cero. Cloudflare contó miles de intentos en las diez horas previas a la divulgación, decenas de miles en los primeros cuarenta y cinco minutos, cientos de miles a las dos horas, y desde entonces habla de millones.
Hay explotación observada en el mundo real. watchTowr, que opera una red de señuelos repartida por internet para detectar esto, dice que “se ha observado explotación en estado salvaje desde el 21 de octubre” La firma Hadrian habla de explotación “a escala“. Y ya circulan herramientas públicas para aprovechar el fallo.
No hay ninguna víctima confirmada públicamente. El responsable de inteligencia de amenazas de watchTowr, Jake Knott, dijo: “Aunque nadie lo ha conseguido hasta la fecha, no esperamos que eso dure mucho“.
Lo que hizo el proyecto PHP, que es la parte que casi nadie está contando
Corrigieron las cuatro versiones con soporte el mismo día, y pasaron las correcciones a las distribuciones de Linux por adelantado, para que los paquetes estuvieran listos cuando se publicara el aviso.
Además corrigieron tres versiones ya abandonadas. PHP 7.4 y 8.0 llevan años sin recibir actualizaciones oficiales, y PHP 8.1 dejó de recibirlas el 31 de diciembre de 2025. El equipo de seguridad publicó igual la corrección para las tres.
Publicaron las medidas provisionales con su propia letra pequeña. El aviso explica qué configurar si no puedes actualizar hoy, y lo encabeza advirtiendo que la actualización es la solución completa y que las medidas provisionales solo reducen la exposición a rutas de ataque específicas.
Una debilidad de su propio ecosistema: también avisaron de un repositorio de paquetes muy usado, mantenido por voluntarios, que no iba a tener la actualización ese día.
Pero ¿cómo fueron encontradas estas vulnerabilidades? La raíz del fallo más grave ya se había visto en 2024, durante la primera auditoría externa de PHP en años: un desarrollador del núcleo encontró las primeras señales y el arreglo se quedó atascado. Dos años después, con el código auditado por inteligencia artificial, el problema salió por tres vías casi a la vez. El 11 de agosto de 2026, el investigador Ryan A., de la empresa Calif, reportó una ejecución de código sin condiciones previas —con la misma raíz de 2024— y OpenAI reportó esa misma causa el mismo día. El 24 de agosto, el equipo de investigación de Wiz aportó vectores de ataque adicionales, encontrados auditando el código fuente con Wiz Atlas, su sistema de investigación de vulnerabilidades, apoyado en los modelos Gemini 4 Argon y GPT-5.6 Sol. Los dos avisos oficiales acreditan como reportantes a investigadores de cuatro empresas distintas. Wiz, por su parte, agradece a Calif y a OpenAI su trabajo “en el descubrimiento, la coordinación y la verificación del parche”.
El mismo día del parche, la Fundación PHP publicó que aquella demora de 2024 fue “un fallo estructural, causado tanto por el proceso de decisión del equipo de seguridad como por su falta de recursos”. Las dos cosas son verdad: cuando la noticia se filtró antes de tiempo, cerraron en veintitrés horas; y llegaron dos años tarde.
No fue lo único de la semana, y ahí está la tendencia
Cuatro días antes, un investigador reportó que ocho certificados intermedios de una autoridad certificadora llamada eMudhra tenían claves privadas fáciles de recuperar. Un certificado intermedio no es el de un sitio web: es el que firma los certificados de los sitios, así que con su clave se pueden emitir certificados para cualquier dominio. Una clave privada es un número “imposible de adivinar”; en estos ocho casos los números eran tan pequeños —uno de ellos era solo el número 4— que cualquier persona con el certificado público podía deducirla.
La empresa revocó los certificados al día siguiente del reporte y los navegadores los bloquearon. eMudhra dice que ninguno se usó para emitir certificados a clientes y que el fallo estuvo en un procedimiento de manejo de claves, no en sus dispositivos de seguridad. Lo que nadie puede saber es qué pasó en los diecisiete meses que esas claves estuvieron expuestas antes de que alguien lo notara.
El mismo 21 de octubre, Node.js publicó sus propias actualizaciones de seguridad por fallos en cifrado, resolución de nombres y compresión.
Tres capas distintas de la infraestructura invisible de internet —el lenguaje que corre los sitios, el sistema que certifica su identidad, y el motor que corre en otra buena parte de la web— fallaron en la misma semana. Y el más grave de los tres salió de una auditoría asistida por inteligencia artificial.
Esa es la tendencia, y algo que va a seguir vigente de acá en adelante. El software que sostiene nuestras vidas está siendo revisado, pero también está quedando expuesto por vulnerabilidades que llevaban años ahí. La pregunta útil para cualquier empresa en internet pasó de ser “¿me tocará a mí?” a “¿cuánto tardo en enterarme y en reaccionar?”.
Qué hacer si tu empresa tiene un sitio web
- Pregunta qué versión de PHP corre tu sitio. Escríbele a quien te lo administra o a tu proveedor de hosting, con esa pregunta exacta. Si tienes WordPress y entras al panel, el camino es Herramientas → Salud del sitio → Información → Servidor.
- Compárala con estas cuatro: 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35. Si tu número es menor que el de su misma serie —por ejemplo 8.3.31 frente a 8.3.36— tu sitio está expuesto.
- Pide que actualicen, que reinicien y que te confirmen el número después. El reinicio no es un detalle: si el programa viejo sigue corriendo en memoria, la actualización no sirvió. Y “lo actualizamos” y “la versión cambió” son dos afirmaciones distintas; solo la segunda se puede comprobar.
- Si la versión es 8.1 o anterior. PHP ya no publica actualizaciones para esas series. Puede que la distribución de Linux de tu servidor sí tenga la corrección, si no, las opciones son más trabajosas y hay que planearlas.
Actualizar WordPress no arregla esto. Cloudflare lo dejó por escrito en su aviso a clientes: “Estas fallas están en el motor de PHP, así que actualizar el código del sitio o un plugin por sí solo no corrige estas vulnerabilidades. Los administradores necesitan actualizar el software de PHP que corre sus aplicaciones“.
Lo que todavía no se puede saber
Revisar registros buscando señales de intrusión es otro trabajo y no lo resuelve la actualización. Amazon detectó un intento contra sus señuelos el 17 de octubre y recomienda empezar a mirar los registros desde ahí.
Si tu proveedor actualizó hoy, cerró la puerta. Lo que no sabemos es si alguien pasó por ella antes.
Y la pregunta de fondo
Si para responder estos interrogantes tuviste que escribir a alguien y esperar, ahí hay algo que revisar: cuánto tardas en obtener una respuesta cuando la necesitas de inmediato.
Hace unos días publicamos un checklist de quince preguntas para evaluar la madurez digital de una empresa. Una de las cinco áreas que mira es justamente esa.
Y si quieres que alguien revise qué hay debajo de tu operación —qué corre, en qué versión, qué está expuesto y qué lleva años sin que nadie lo toque—, solicita una auditoría digital. Escríbenos.