Vulnerabilidad en PHP:
tu web no se protege sola.

Tu web puede verse perfecta, cargar rápido y no dar ningún error, y aun así tener una puerta abierta. Eso fue lo que pasó el 21 de octubre de 2026, cuando el equipo de PHP publicó actualizaciones de emergencia para dos fallas críticas conocidas como PHP2Shell. Bajo ciertas condiciones, permiten que alguien ejecute código en el servidor donde vive tu página sin necesidad de iniciar sesión.

Si tu sitio usa PHP, toca revisar qué versión tiene, comprobar si está afectada y actualizar. Aquí va qué pasó, por qué pasa, qué riesgos hay y cómo mantener tu página protegida.

Qué pasó: dos fallas críticas y alertas en varios países

PHP es el lenguaje en el que corren páginas dinámicas, tiendas en línea y aplicaciones de empresa. Está debajo de WordPress, Joomla y Drupal, y de miles de desarrollos a medida. Las dos fallas están en el propio PHP, no en un plugin ni en una plataforma concreta, por eso una web puede estar expuesta aunque funcione perfecto.

Son CVE-2026-109618 y CVE-2026-109619, y las dos tienen una calificación de 9,2 sobre 10 (CVSS v4.0). Los parches salieron en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. La agencia de ciberseguridad de Estados Unidos (CISA) advirtió que afectan a las instalaciones de PHP que atienden peticiones web: Apache con mod_php, PHP-FPM, php-cgi, FrankenPHP y LiteSpeed.

El propio PHP avisó antes. El 20 de octubre, su equipo de seguridad anunció —en un mensaje que difundió la PHP Foundation en X— un lanzamiento de seguridad para el día siguiente a las 14:00 UTC, con «dos vulnerabilidades críticas, ambas CVSSv4 9.2». Pidió a los usuarios que se prepararan y advirtió que lo adelantaría si los detalles se hacían públicos. Según varios medios, se hicieron públicos antes de lo previsto.

La alarma llegó desde arriba. El mismo día del parche, la NSA escribió en X que todas las organizaciones que usan PHP debían prepararse y que, si no podían actualizar de inmediato, la recomendación era sacar el sistema de línea hasta mitigarlo del todo. Esa misma noche, la primera ministra de Japón, Sanae Takaichi, publicó en X una petición que el medio ITmedia calificó de inusual: revisar si los sitios públicos usan PHP, prepararse para aplicar el parche esa noche y, si era difícil hacerlo rápido, suspender temporalmente el sitio como medida válida para reducir el riesgo (traducción nuestra del japonés).

No fueron solo palabras. Según The Japan Times, el acceso público a parte de los sitios de los ministerios de Salud y Trabajo y de Finanzas se suspendió temporalmente, y también hubo bancos y empresas que apagaron sitios.

Y no fueron solo ellos dos. El mismo día, CISA pidió parchar de inmediato, empezando por lo que está expuesto a internet, y recomendó sacar de línea lo que no se pueda actualizar o siga en PHP 8.1 o anterior. El FBI aconsejó vigilar los servidores web por si procesos de PHP lanzan shells o descargan archivos, y el centro de ciberseguridad del Reino Unido (NCSC) pidió inventariar todas las instalaciones de PHP, no solo las viejas (según Newsweek y SecurityWeek). La agencia de ciberseguridad de Singapur emitió su propia alerta, el servicio de salud de Inglaterra otra (NHS England Digital) y el equipo de respuesta de las instituciones europeas, CERT-EU, también.

Entre las empresas, Cloudflare activó reglas de protección por defecto para todos sus clientes, gratuitos y de pago, y Amazon reportó un intento de ataque desde el 17 de octubre, cuatro días antes de la divulgación pública.

Los investigadores de Wiz compararon la falla con Heartbleed, el error de 2014 que sacudió a medio internet, y escribieron que está «entre las vulnerabilidades más graves descubiertas en PHP y, posiblemente, en la historia del software» (traducción nuestra). Y los ataques no esperaron: watchTowr reportó explotación real el 21 de octubre en sus sistemas trampa, y otros equipos ubican los primeros intentos desde el 17, cuatro días antes del parche.

Ahora, para no exagerar: el mismo watchTowr y Rapid7 señalan que la mayoría de los exploits públicos que circulan no logran ejecutar código de forma fiable: cada uno apunta a una combinación concreta de sistema operativo, versión de PHP y servidor web. Eso no es un alivio, es una ventana. Lo que hoy es artesanal mañana se vuelve automático.

Por qué pasa: un error viejo en el motor, y esta vez lo encontró una IA

Las dos fallas están en el motor de PHP, no en tu aplicación. Dicho sin jerga:

• CVE-2026-109618: cuando el servidor se queda sin memoria en un mal momento, PHP deja datos de la petición a medio inicializar, y al «limpiar» después trabaja sobre un estado inválido. Ahí se abre el camino para ejecutar código.
• CVE-2026-109619: PHP conserva referencias a datos de una petición cuya memoria ya fue liberada. Es lo que se llama use-after-free: usar algo que ya no está donde crees que está.

Son errores de manejo de memoria, de los más difíciles de ver en código que lleva años funcionando. Varias fuentes los describen como un error que llevaba cerca de una década dormido. Y lo que cambió esta vez es quién lo encontró: según Fortune y Wiz, fueron herramientas de IA. El crédito está en disputa entre varios equipos que dicen haberlo hallado por su cuenta, pero el dato de fondo no: una IA puede encontrar en semanas lo que a los humanos se les escapó durante años, y los atacantes tienen acceso a las mismas herramientas.

Para un negocio, esto se traduce en algo concreto: el tiempo entre «se descubre la falla» y «alguien la usa contra tu sitio» se está acortando. Esperar al fin de mes para actualizar dejó de ser una opción razonable.

Y una aclaración que evita un falso sentido de seguridad: tener WordPress en su última versión y los plugins al día no te protege de esto. La falla está debajo, en el lenguaje en el que corre todo lo demás. Wiz y la agencia Kyodo hablan de cerca de un 70 % de la web usando PHP, así que no es un problema de nicho.

Que tu web esté expuesta no significa que ya la atacaron

Una vulnerabilidad no es un ataque: es una condición que alguien podría aprovechar. Pero conviene saber qué hay en juego si lo logra:

• Acceso no autorizado al servidor. El atacante podría ejecutar instrucciones con los permisos del proceso vulnerable.
• Exposición de información. Archivos de configuración, credenciales, llaves o datos a los que tenga acceso ese proceso. Algunos análisis también advierten de datos temporales que quedan en la memoria de PHP.
• Cambios en tu página. Redirecciones, contenido que tú no publicaste o archivos maliciosos.
• Interrupción del servicio. Un ataque puede tumbar tu web y las aplicaciones alojadas en el mismo servidor.
• Costos para tu empresa. Recuperarse, perder la confianza de tus clientes y frenar procesos comerciales.

El alcance real depende de los permisos, la configuración y los sistemas conectados. Por eso, además de actualizar, hay que revisar que no haya señales de una intrusión previa.

Qué versión de PHP debes tener

Los parches salieron solo para las ramas que todavía reciben soporte. Si tu instalación es de una de ellas, debes llegar como mínimo a la versión de esta tabla:

Una versión anterior dentro de la misma rama, por ejemplo 8.3.35, está sin parchear.

Si tienes PHP 8.1 o anterior, no hay versión corregida oficial

Esas versiones también están afectadas y el proyecto dejó de mantenerlas, así que no hay una versión corregida oficial. El equipo de PHP sí publicó respaldos mínimos en código fuente para 7.4, 8.0 y 8.1, según Help Net Security, pensados para quien compila PHP por su cuenta; fuera de eso, depende de lo que alguna distribución de Linux o un proveedor de soporte extendido respalde. Si no compilas tu PHP, tu hosting es quien debe ofrecerte esa opción o ayudarte a migrar. Hay muchos sitios ahí, casi siempre por la misma razón: un plugin o un desarrollo a medida que «se rompe» al subir de versión, y nadie quiso pagar el arreglo. Parece ahorro y funciona como deuda. Esta semana llegó el cobro. Migrar cuesta una fracción de lo que cuesta limpiar un sitio comprometido.

Y PHP 8.2 se acaba pronto

Según la tabla oficial de versiones soportadas, la rama 8.2 solo recibe parches de seguridad hasta el 31 de diciembre de 2026. Si estás ahí, instala el parche de hoy y planea el salto a una rama más nueva antes de que se acabe el año.

Descarga solo de fuentes oficiales

Si administras tu propio servidor, usa la página oficial de descargas de PHP o el gestor de paquetes de tu sistema, y evita instaladores de páginas desconocidas. Si tu web está en un hosting compartido o administrado, normalmente no tienes que instalar nada: el proveedor lo hace desde su infraestructura. Lo que sí debes pedirle es que active una versión corregida en el entorno que realmente ejecuta tu web.

Cómo comprobar qué versión usa tu web, aunque no seas técnico

Si tu página usa WordPress

1. Entra al panel de WordPress.
2. Ve a Herramientas → Salud del sitio → Información.
3. Abre el apartado Servidor.
4. Busca la versión de PHP y compárala con la tabla de arriba.

La ruta puede cambiar un poco según el idioma o la versión de WordPress.

Si usas otro CMS o una web a medida

1. Entra al panel de tu hosting.
2. Busca una sección llamada PHP, «Configuración de PHP» o «Selector de PHP» (en cPanel, «Select PHP Version» o «MultiPHP Manager»).
3. Mira qué versión está asignada a tu dominio.
4. Si no encuentras el dato, pídele confirmación por escrito al proveedor o a quien te hizo el sitio.

Con servidor propio, php -v muestra la versión de la línea de comandos, que puede ser distinta de la que usa el servidor web. Comprueba también la del entorno que atiende las peticiones de tu página.

Cómo actualizar PHP sin romper tu web

Antes de tocar nada, haz una copia de seguridad guardada fuera del servidor y, si puedes, prueba el cambio en un entorno de pruebas. Comprueba que la versión elegida sea compatible con tu web, tus plugins, tus extensiones y tus dependencias. Si el servidor está expuesto, coordina una actualización urgente; no la pospongas por comodidad.

Con hosting administrado

1. Escribe al soporte técnico e indica que necesitas corregir CVE-2026-109618 y CVE-2026-109619.
2. Pide la actualización a una versión corregida y compatible.
3. Pide confirmación de que el cambio está activo para tu dominio y para todos sus entornos.
4. Comprueba que tu web, tus formularios y tus funciones sigan trabajando.

Con servidor propio

1. Identifica todas las aplicaciones y versiones de PHP instaladas.
2. Actualiza con el gestor de paquetes o el mecanismo oficial de tu sistema operativo.
3. Reinicia o recarga los servicios para activar el cambio. Instalar sin reiniciar no cuenta: el servidor sigue expuesto hasta que los procesos de PHP se reinician.
4. Verifica la versión efectiva del entorno web y revisa los registros de errores.

Si no tienes experiencia administrando servidores, lo más sensato es coordinar esto con tu proveedor o con un profesional técnico.

Si hoy no puedes actualizar

Haz lo que pidieron la NSA y Japón: reduce la exposición, por ejemplo poniendo el sitio en mantenimiento, y consulta con tu responsable técnico cómo aislar el servicio hasta aplicar el parche. Un cortafuegos web (WAF) ayuda, y Cloudflare activó reglas de protección por defecto antes de la divulgación pública, pero PHP mismo dice que ninguna configuración mitiga estas fallas por completo. Es un cinturón de emergencia, no el parche.

El segundo aviso, del 23 de octubre

Dos días después, PHP divulgó otra falla de ejecución remota. Según CERT-EU, afecta solo a aplicaciones configuradas de forma poco habitual y el proyecto la considera de bajo riesgo, así que no habrá versión de emergencia: lo que recomiendan es mitigar. Trend Micro y AWS la identifican como CVE-2026-115560, relacionada con el seguimiento de la carga de archivos en sesiones, y coinciden en que el ajuste temporal es desactivar esa función con session.upload_progress.enabled=0.

Casi ningún sitio de una pyme usa barras de progreso de subida basadas en sesiones, así que apagarlo no te quita nada. Pídeselo a quien administra el servidor mientras llega una corrección definitiva.

Cómo mantener tu web segura después del parche

PHP2Shell pasará. Dentro de unos meses habrá otro titular con otro nombre, y quien esté preparado lo leerá con calma. Lo que prepara no es una herramienta mágica, son costumbres aburridas.

Mantén todo actualizado

Revisa cada cierto tiempo la versión de PHP y su estado de soporte, el CMS, los temas, los plugins, los frameworks, el sistema operativo y las extensiones de terceros. Borra lo que no uses: un plugin desactivado sigue siendo código que alguien puede atacar. Y si un componente dejó de recibir soporte, busca una alternativa o planifica su reemplazo.

Protege los accesos

Contraseñas únicas y robustas, verificación en dos pasos para los administradores, y cada persona con su propio usuario y solo los permisos que necesita. Revisa también las cuentas administrativas, los accesos al hosting, las credenciales de la base de datos y los permisos de los archivos. En WordPress, el editor de archivos del panel se puede desactivar.

Haz copias que de verdad puedas recuperar

Guarda copias de los archivos y de la base de datos en un lugar separado del servidor principal, con una frecuencia que tenga sentido para tu negocio, y pruébalas restaurándolas. Una copia que nunca restauraste es una suposición, no una copia.

Cuida lo que recibe tu web

Si tu página deja subir documentos o imágenes, valida los tipos permitidos, limita los tamaños y evita que lo subido pueda ejecutarse como código: nada de PHP ejecutable en la carpeta de subidas. En formularios y aplicaciones, usa validaciones, consultas parametrizadas y permisos restringidos. Y no dejes un phpinfo() olvidado en producción: le regala al atacante el mapa del servidor.

Vigila

Un WAF, los límites de solicitudes, los registros de actividad y las alertas ayudan a detectar comportamientos raros. Complementan el mantenimiento; no convierten una versión vulnerable en una segura.

Si ya te atacaron: cómo parchar y limpiar de verdad

Si tu sitio estuvo expuesto, no des por hecho que todo está resuelto después de actualizar. La ausencia de señales tampoco prueba que estés limpio, porque quien ejecuta comandos como el usuario del servidor web puede hacerlo sin que nada se caiga. Estas son las pistas que los equipos de respuesta recomiendan revisar, empezando por el 17 de octubre:

• Archivos .php que no reconoces, sobre todo en carpetas de subidas, caché o temporales.
• Procesos del servidor web (php-fpm, apache) lanzando shells o descargando cosas con curl o wget.
• Tareas programadas (cron) nuevas, o usuarios administradores que nadie creó.
• Errores de «memoria agotada» en los registros y peticiones de tamaño anormal.
• Redirecciones raras, páginas en otro idioma en tu dominio o avisos de «sitio peligroso» en Google.

Circulan listas de direcciones IP atribuidas a los atacantes, pero los propios investigadores no coinciden entre sí y ninguna está confirmada. Úsalas como pista para buscar en tus registros, nunca como prueba. Si encuentras señales, este es el orden:

1. Contén y conserva. Pon el sitio en mantenimiento y guarda copia de los registros y de los archivos tal como están. Sirven para entender qué pasó.
2. Parcha primero. Actualiza PHP a una versión corregida y reinicia. Si no, limpias hoy y te vuelven a entrar mañana por la misma puerta.
3. Cambia todas las credenciales desde un equipo limpio: administradores, base de datos, FTP o SSH, llaves de API y, en WordPress, las claves secretas del archivo de configuración. La falla puede exponer memoria del servidor, donde viven esos secretos.
4. Prefiere restaurar sobre «limpiar a mano». Una copia anterior al 17 de octubre, más el núcleo y los plugins reinstalados desde su fuente oficial, es más seguro que cazar archivos infectados uno por uno.
5. Revisa lo que no se ve: usuarios, tareas programadas, el archivo .htaccess y el contenido de la base de datos, donde se suelen esconder enlaces y redirecciones.
6. Mira Google Search Console. Si el atacante inyectó spam, ahí aparece como problema de seguridad, y hay que pedir revisión cuando esté limpio.
7. Pide ayuda especializada si hay señales de intrusión: hace falta determinar el alcance y eliminar accesos que hayan quedado escondidos.

Si en ese servidor había datos personales de clientes, hay una obligación aparte. En Colombia, quien trata datos personales debe reportar los incidentes de seguridad a la Superintendencia de Industria y Comercio a través del Registro Nacional de Bases de Datos, dentro de los 15 días hábiles siguientes a que los detecta, según lo que publican varias firmas de abogados. Verifica el plazo vigente con la SIC o con tu abogado antes de actuar.

Una web publicada también necesita mantenimiento

Una página no termina el día que sale a internet. Con el tiempo salen versiones nuevas, cambian las tecnologías y se descubren vulnerabilidades. Mucha gente cree que el hosting «se encarga de eso», y muchas agencias entregan el sitio, cobran el último pago y desaparecen. Cuando un parche así sale un miércoles en la mañana, nadie en esa cadena tiene la obligación de avisarte, y en un hosting compartido barato puede que ni siquiera tengas permiso para subir de versión.

Antes de que haya un incidente, pregunta quién parcha tu sitio, cada cuánto y qué pasa si sale un aviso como este un viernes en la noche. Pídelo por escrito. Si no sabes qué versión de PHP usa tu página, quién la actualiza o cuándo se revisó su seguridad por última vez, empieza por ahí. Si la respuesta es «nadie», ya sabes cuál es el verdadero riesgo.

De dónde sale esta información

Todo lo de este artículo viene de fuentes que puedes abrir. Los mensajes en X están enlazados a su publicación original; las traducciones son nuestras.

• NSA Cyber en X y su comunicado.
• Sanae Takaichi en X y The Japan Times.
• Aviso previo del equipo de seguridad de PHP (difundido por la PHP Foundation en X), descargas oficiales y versiones soportadas.
• CISA, CERT-EU, NHS England Digital y la agencia de ciberseguridad de Singapur.
• Wiz, watchTowr y Rapid7.
• Google Cloud: cómo responder a PHP2Shell.
• SecurityWeek, Cloudflare y The Hacker News (reacción de las empresas y primeros intentos de ataque).
• Fortune, Newsweek y Techmeme (Cloudflare).
• Trend Micro y AWS (aviso del 23 de octubre).