Vulnerabilidad de PHP: qué pasó en octubre de 2026 y cómo proteger tu sitio web

La vulnerabilidad de PHP de octubre de 2026, conocida como PHP2Shell, corresponde a dos fallas críticas (CVE-2026-109618 y CVE-2026-109619) que pueden permitir que una persona externa ejecute código en el servidor de un sitio web sin iniciar sesión ni conocer ninguna clave. PHP las corrigió el 21 de octubre, y para cualquier empresa la medida más importante es una sola: confirmar con tu proveedor de hosting o con tu equipo de desarrollo que el sitio funciona con una versión corregida (8.5.12, 8.4.27, 8.3.36 u 8.2.35, o una posterior).

Si tienes un sitio web, una tienda online, un sistema de reservas o cualquier aplicación hecha en PHP, esta noticia te concierne aunque nunca hayas oído hablar de ese lenguaje. En este artículo te explicamos, sin tecnicismos, qué ocurrió, a quién afecta, qué riesgos reales existen para un negocio y qué pasos conviene seguir esta misma semana.

Qué es PHP y por qué una falla en PHP puede afectar a tu negocio

PHP es un lenguaje de programación que trabaja «detrás de escena» en una gran cantidad de sitios y aplicaciones. Cuando alguien entra a una página, el servidor usa PHP para armar lo que la persona ve: mostrar productos, procesar un formulario, cargar una reserva o consultar una base de datos. Muchos «creadores de páginas» y gran parte de las tiendas online funcionan sobre esta tecnología.

Por eso este caso es distinto a la falla de un complemento o de una plantilla puntual. El problema no está en una aplicación específica, sino en el propio motor de PHP, es decir, en la pieza que ejecuta tu sitio. No es un fallo propio de WordPress ni de un plugin concreto, sino del entorno donde corren todos ellos.

Qué pasó: cronología de la vulnerabilidad de PHP

Entre el 20 y el 26 de octubre de 2026, PHP publicó correcciones de emergencia, organismos de seguridad de distintos países emitieron alertas y se reportaron intentos de ataque. Esta es la secuencia:

Una cifra da idea de la escala: según una instantánea de Censys citada por Fortinet el 22 de octubre, unos 36,7 millones de servicios conectados a internet informaban versiones de PHP posiblemente afectadas. No significa que todos estuvieran comprometidos, pero sí que el universo de sitios por revisar era muy amplio.

Effective Immediately, all organizations using PHP for their systems are advised to be prepared for an update addressing two critical vulnerabilities. PHP is widely used for web applications. These vulnerabilities often provide a direct path to the server's file system or…

— NSA Cyber (@NSACyber) October 21, 2026

Las dos fallas explicadas en palabras simples

Las dos vulnerabilidades ahora reciben el nombre colectivo de «PHP2Shell». Ambas tienen una puntuación de 9,2 sobre 10 en la escala CVSS v4.0, que es el estándar para medir la gravedad de una falla: por encima de 9 se considera crítica.

CVE-2026-109618: cuando el servidor se queda sin memoria

PHP tiene un límite de memoria para evitar que una petición consuma todos los recursos del servidor. Si una solicitud supera ese límite, PHP intenta detener su ejecución y finalizar el trabajo. Sin embargo, en determinadas circunstancias, no completaba correctamente todas las tareas de limpieza que debía realizar antes de continuar y dejaba datos internos a medio construir. Es como un cajero que, tras un corte de luz en plena operación, retoma el trabajo confiando en un comprobante que quedó a medio llenar.

CVE-2026-109619: restos de una visita anterior

La segunda falla tiene que ver con la información interna que sobrevive después de que la memoria que la respaldaba ya fue liberada. Para trabajar más rápido, PHP puede reutilizar los mismos procesos para atender diferentes solicitudes, en lugar de empezar desde cero cada vez. Es decir, la siguiente solicitud que atiende el mismo «trabajador» del servidor podría usar ese resto antes de que se reinicie. Piensa en una mesa de restaurante que no se limpió: el cliente siguiente se encuentra con la cuenta abierta del anterior y puede hacer cosas con ella.

Quién está en riesgo: versiones de PHP afectadas

El proyecto PHP indica que están en riesgo todas las instalaciones que atienden solicitudes web, sea cual sea la forma en que estén configuradas (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed). Considera el riesgo más alto en el caso de mod_php, una forma de instalar PHP dentro del servidor Apache, porque ahí se demostró un ataque que se dispara antes de que corra cualquier código de la aplicación.

Si tu sitio está en un hosting compartido, quien debe actualizar PHP es el proveedor, no tú. Eso no te exime de preguntar: pide por escrito qué versión corre tu sitio y desde cuándo. Si tienes un servidor propio o un VPS, la responsabilidad es tuya o de quien lo administra.

Además, hay un matiz que muchos pasan por alto: puedes verte afectado aunque tu sitio no esté hecho en PHP. Un comunicado conjunto de la Unión Europea advirtió que productos de terceros, como paneles de administración o aplicaciones internas, también pueden usar PHP sin que sea evidente.

¿Se está explotando esta vulnerabilidad de PHP?

Sí, hay actividad real, aunque con matices. watchTowr observó intentos de explotación desde el mismo 21 de octubre, y CISA incluyó CVE-2026-109618 en su catálogo de fallas explotadas. Otros investigadores han señalado que lograr una ejecución de código confiable puede ser más difícil de lo que se temía al principio, y que muchos de los códigos de ataque que circulan no funcionan. Un reporte indicó que algunos sí fueron validados contra instalaciones por defecto con mod_php, y no contra PHP-FPM.

La conclusión práctica no cambia: PHP insiste en que no existe una mitigación completa y que actualizar es la única opción segura. Que un ataque sea difícil no significa que sea imposible, y los atacantes automatizados no se cansan de probar.

Cómo puede afectar a tu negocio

Un servidor comprometido puede exponer datos de clientes, dejar el sitio fuera de línea o usarse para fines ajenos, sin importar el tamaño del negocio, porque los ataques automatizados buscan servidores vulnerables en masa. Si un atacante lograra ejecutar código en tu servidor, estos serían los riesgos más habituales:

• >Datos de clientes expuestos: nombres, correos, teléfonos y mensajes que llegan por formularios, reservas o pedidos.
• >Sitio modificado o fuera de línea: contenido alterado, redirecciones a otras páginas o caída total del servicio.
• >Uso de tu servidor para fines ajenos: envío de correo no deseado, alojamiento de contenido malicioso o ataques a terceros desde tu dominio.
• >Daño a la reputación y a Google: un sitio comprometido puede ser marcado como peligroso y perder visitas y confianza.
• >Obligaciones legales: proteger los datos personales que recolectas es una responsabilidad del negocio. Si quieres revisar ese frente, tenemos una guía de auditoría de datos personales y Ley 21.719 para tu página web.

Cómo protegerte: qué hacer paso a paso

Protegerte consiste en actualizar PHP a una versión corregida, reiniciar sus procesos y revisar si hubo intrusión. Como dueño o administrador del negocio, tú pides y verificas; los puntos técnicos los ejecuta tu proveedor o tu equipo de desarrollo.

1. Haz un inventario. Anota todos los sitios, tiendas, sistemas internos y paneles que tu empresa usa y que podrían correr PHP. Incluye los que casi nadie mira: el sitio antiguo, el micrositio de una campaña, la intranet.
2. Averigua la versión de PHP de cada uno. Si estás en hosting compartido, suele verse en el panel de control. Si no la encuentras, pídesela a tu proveedor por correo.
3. Actualiza a una versión corregida. Debe ser 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o posterior. En servidores con paquetes del sistema operativo, hay que instalar el paquete actualizado de la distribución.
4. Reinicia los procesos de PHP. Actualizar no basta si los procesos que ya estaban corriendo siguen con la versión anterior. Tu proveedor debe confirmarlo.
5. Verifica el resultado. Comprueba la versión que realmente usa el servidor web, que no siempre es la misma que muestra la línea de comandos del servidor.
6. Revisa si hubo señales de intrusión entre el 21 de octubre y el día en que actualizaste (más abajo te dejamos qué buscar).
7. Si usas PHP 8.1 o anterior, planifica la migración. Las ramas sin soporte no recibirán más correcciones oficiales.

Cómo saber qué versión de PHP usa tu sitio

Hay tres caminos simples. El primero es el panel de tu hosting, donde casi siempre aparece una sección llamada «versión de PHP» o «selector de PHP». El segundo es preguntárselo a la agencia o al desarrollador que hizo tu sitio. El tercero, para perfiles técnicos, es pedir que se revise la versión directamente en el servidor web. Lo importante es que la respuesta sea concreta: un número de versión y una fecha, no un «estamos al día».

¿No sabes si tu sitio quedó realmente protegido? Pide una demostración del servicio de auditoría web de Itechnova: revisamos contigo qué versión de PHP y qué software usa tu sitio, y te entregamos una lista priorizada de lo que conviene corregir primero.

Si no puedes actualizar hoy: medidas temporales y sus límites

El propio proyecto PHP publicó medidas que reducen la exposición a caminos de ataque específicos mientras se actualiza. Advierte expresamente que no hacen segura una instalación, así que solo sirven como parche de emergencia. Si las aplicas, que las configure una persona técnica:

• >Límite de memoria de PHP: fijar memory_limit=-1 de un modo que las aplicaciones no puedan cambiarlo, y verificar que ninguna configuración vuelva a imponer un límite.
• >Tamaño máximo de envíos: reducir post_max_size a 8 MB si el sitio no recibe archivos, o a 32 MB si necesita cargas. Mantener upload_max_filesize por debajo de ese valor.
• >Progreso de subida de archivos: desactivar con session.upload_progress.enabled=0 y reiniciar todos los procesos, desde la configuración del servidor y no desde el código de la aplicación.
• >PHP 8.5: establecer fatal_error_backtraces=0, lo que bloquea solo una de las rutas confirmadas.
• >Restringir el acceso: si un sistema no puede actualizarse, limitar su acceso desde internet mientras tanto.

Cada una de estas medidas cierra una puerta concreta, pero deja otras abiertas. Por eso la instrucción oficial es actualizar. El aviso completo de PHP está publicado en su archivo de noticias de 2026.

La tercera falla: CVE-2026-115560

El 23 de octubre, PHP informó de otro problema que podría permitir ejecución remota de código. La buena noticia es que exige una combinación poco habitual: la aplicación debe configurar un formato de sesiones y luego cambiarlo mientras funciona, y además debe tener activo el seguimiento del progreso de subida de archivos. Quien nunca modifica ese formato en tiempo de ejecución no queda expuesto por esa vía.

La mala noticia es que las versiones del 21 de octubre no lo corrigen. PHP decidió tratarlo en su ciclo normal de publicaciones y anunció que publicará el aviso completo junto con la corrección. Mientras tanto recomienda desactivar el seguimiento de progreso de subida (session.upload_progress.enabled=0). Si ya lo hiciste como medida del 21 de octubre, no necesitas hacer nada más para esta vía. Al 9 de noviembre, el archivo oficial de noticias de PHP no mostraba aún esa publicación, así que conviene revisar el sitio de PHP o consultarle a tu proveedor.

Señales de que algo anda mal en tu sitio

Ninguna de estas señales prueba por sí sola que alguien haya entrado, pero todas justifican una revisión técnica:

• >Archivos desconocidos con extensión .php en carpetas de imágenes, cargas o temporales.
• >Usuarios administradores nuevos que nadie creó.
• >Aumentos inexplicables en el uso del procesador o del tráfico del servidor.
• >Correos de spam enviados desde tu dominio o avisos de que tu dominio figura en listas de bloqueo.
• >Redirecciones raras al abrir tu sitio desde el celular o desde Google.
• >Advertencias de seguridad del navegador o de Google al visitar tu página.

Si detectas algo así, no borres nada de inmediato. Conserva los registros del servidor, informa a tu proveedor y cambia las claves de acceso desde un equipo que sepas limpio.

Qué preguntarle a tu proveedor de hosting o a tu agencia

Seis preguntas concretas bastan para saber si tu sitio quedó protegido. Sirven para cualquier negocio, tenga hosting compartido o servidor propio:

• >¿Qué versión de PHP corre cada uno de mis sitios y en qué fecha se actualizó?
• >¿Se reiniciaron los procesos después de actualizar?
• >¿Revisaron si hubo actividad sospechosa entre el 21 de octubre y la actualización?
• >¿Hay sistemas míos que usen versiones sin soporte? ¿Cuál es el plan para migrarlos?
• >¿Aplicaron la configuración recomendada por PHP para session.upload_progress.enabled?
• >¿Tengo respaldos recientes que se puedan restaurar? ¿Cuándo se probó la restauración por última vez?

Si tu respuesta a «¿quién administra mi servidor?» es «no sé», conviene empezar por ahí. Elegir bien dónde vive tu sitio también es parte de la seguridad, y en nuestra guía sobre qué es el hosting y cómo elegir el mejor repasamos los criterios básicos.

La lección de fondo: el mantenimiento no es opcional

Esta vulnerabilidad de PHP se resolverá con actualizaciones, pero deja una enseñanza que va más allá: un sitio web no es un folleto que se imprime una vez, sino un sistema que depende de software que cambia, se vuelve obsoleto y a veces falla. Cuando la falla es crítica, las empresas que conocen su inventario, tienen responsables claros y mantienen sus versiones al día reaccionan en horas. Las que no, descubren el problema cuando ya es tarde.

Una auditoría periódica ayuda justamente a eso: ordena el inventario, detecta software sin soporte, revisa accesos y configuraciones, y entrega una lista priorizada de lo que hay que corregir. Si quieres entender cómo funciona, puedes leer nuestro artículo sobre auditoría de sitio web y qué está fallando hoy.

Itechnova, agencia de desarrollo web con base en Chile, ofrece auditoría web para empresas que necesitan saber en qué estado está su sitio después de una falla como esta: identifica qué tecnología y qué versión de PHP usa cada sitio, detecta software sin soporte, revisa accesos y configuraciones, y entrega una lista priorizada de correcciones. Si prefieres que alguien lo revise por ti, puedes pedir una demostración del servicio de auditoría web de Itechnova.

Mientras tanto, si solo vas a hacer una cosa después de leer esto, que sea escribirle hoy a tu proveedor y pedirle la versión de PHP de tu sitio. Es una pregunta de un minuto que puede evitarte un problema muy caro.

Preguntas frecuentes sobre la vulnerabilidad de PHP

¿Cómo sé si mi sitio web está afectado por la vulnerabilidad de PHP?

Está en riesgo si funciona con PHP en una versión anterior a la corregida de su rama (8.5.12, 8.4.27, 8.3.36 u 8.2.35) o en una rama sin soporte, como 8.1 o anteriores. Lo más simple es revisar la versión en el panel de tu hosting o pedirla por escrito a tu proveedor, con número de versión y fecha de actualización.

¿Mi sitio hecho en WordPress está afectado?

WordPress funciona sobre PHP, así que depende de la versión de PHP del servidor donde esté alojado. La falla no está en WordPress, sino en PHP. Lo que debes confirmar con tu hosting es que PHP esté en una versión corregida.

¿Qué versión de PHP debo tener?

Como mínimo, 8.5.12, 8.4.27, 8.3.36 u 8.2.35, según la rama que uses, o una versión posterior. Las ramas 8.1 y anteriores ya no reciben correcciones oficiales, por lo que conviene migrar a una versión con soporte.

¿Actualizar PHP es suficiente?

Actualizar corrige las dos fallas principales y es el paso más importante. Aun así, si tu sitio estuvo expuesto antes de actualizar, conviene revisar si hubo actividad sospechosa, cambiar claves si hay dudas y confirmar que los procesos de PHP se reiniciaron.

¿Puedo verme afectado si mi sitio no usa PHP directamente?

Sí. Paneles de administración, aplicaciones internas y herramientas de terceros pueden usar PHP sin que sea evidente, como advirtió un comunicado conjunto de la Unión Europea. Por eso conviene hacer un inventario de todos los sistemas del negocio, incluidos el sitio antiguo, los micrositios y la intranet, y no solo del sitio principal.

¿Qué hago si todavía no puedo actualizar?

PHP publicó medidas temporales, como ajustar límites de memoria y de tamaño de envíos y desactivar el progreso de subida de archivos. Reducen la exposición a ciertas rutas de ataque, pero no hacen segura la instalación, así que actualizar sigue siendo la solución.