PHP2Shell explicado: quién debe parchear tu sitio web y cómo hacerlo

El 21 de octubre de 2026 se reveló una falla de seguridad crítica en PHP, el lenguaje de programación detrás de aproximadamente tres de cada cuatro sitios web. Sitios gubernamentales de los Países Bajos, Francia y Canadá se desconectaron por precaución, y la agencia surcoreana KISA (Korea Internet & Security Agency) publicó una guía de respuesta urgente. La comunidad de seguridad la llama PHP2Shell.

La buena noticia: los parches ya están disponibles y la mayoría de los grandes proveedores de hosting ya los aplicaron. El problema es que quién parchea tu sitio depende por completo de cómo está alojado. Esta guía explica quién debe actuar ahora mismo, qué parches existen y cómo respondieron los principales proveedores de hosting.

Puntos clave

• PHP2Shell son dos fallas críticas de ejecución remota de código en el propio PHP (CVSS 9.2) que se pueden explotar sin iniciar sesión.
• Actualizar WordPress o los plugins no lo soluciona. Hay que parchear PHP.
• Las versiones parcheadas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35 o posteriores. PHP 8.1 y anteriores no tienen versión oficial.
• En hosting compartido o administrado, tu proveedor parchea PHP, pero debes verificarlo. En un VPS o servidor dedicado, debes parchearlo tú y reiniciar PHP.
• Una tercera falla (CVE-2026-115560) tiene una solución temporal: session.upload_progress.enabled = 0.

¿Qué es PHP2Shell?

PHP2Shell es el nombre que reciben dos vulnerabilidades de ejecución remota de código (RCE) encontradas en el núcleo de PHP.

• CVE-2026-109618: una falla de corrupción de memoria que se activa abusando de situaciones de falta de memoria
• CVE-2026-109619: una falla que reutiliza un estado global ya liberado

Ambas tienen una gravedad de CVSS 9.2 sobre 10, y lo más preocupante es que se pueden explotar sin iniciar sesión y sin una cuenta. Las fallas están en el propio procesamiento de solicitudes de PHP, no en WordPress ni en un plugin, así que el ataque funciona antes de que el código de tu sitio llegue a ejecutarse. Mantener WordPress totalmente actualizado no sirve de nada si PHP no está parcheado.

Se cree que prácticamente todas las versiones de PHP desde la 5.4 están afectadas y, según W3Techs, alrededor del 75 % de los sitios web con un lenguaje de servidor conocido usan PHP. Las fallas las descubrieron las empresas de seguridad Calif y Wiz durante un análisis con modelos de IA (OpenAI GPT-5.6 Sol y Google Gemini 4 Argon) y las reportaron al equipo de PHP en agosto. Los detalles se filtraron mientras se preparaban los parches, lo que adelantó la divulgación un día. Los intentos de ataque reales comenzaron el mismo día de la divulgación y Cloudflare reportó millones de ellos. Todavía no se ha confirmado ninguna intrusión exitosa a gran escala, pero las herramientas de ataque siguen mejorando, así que «todavía no nos han atacado» no es motivo para relajarse.

Luego, el 23 de octubre, se reveló una tercera falla relacionada, CVE-2026-115560. Solo funciona con ciertas combinaciones de configuración, por lo que el equipo de PHP recomienda una solución temporal en lugar de un parche de emergencia. Los detalles están más abajo, en la sección de parches.

¿Quién debe actuar?

Todo se reduce a una pregunta: «¿Quién administra PHP en mi sitio?» La respuesta determina lo que tienes que hacer.

¿Qué parches están disponibles?

Parches oficiales (21 de octubre de 2026)

Si administras tu propio servidor, lo habitual es actualizar con los paquetes de tu distribución. Ubuntu, Debian, AlmaLinux, Amazon Linux y otras ya publicaron paquetes parcheados.

# Ejemplo para Debian / Ubuntu
sudo apt update
sudo apt upgrade php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm

Si no reinicias, el parche no se aplica. Si actualizas los paquetes pero no reinicias PHP-FPM o Apache, el PHP antiguo que sigue cargado en memoria continúa procesando las solicitudes. La guía de KISA advierte sobre esto de forma explícita. Si usas el repositorio Remi en un sistema de la familia CentOS, ten en cuenta que Remi no tenía actualización el día de la divulgación, así que considera los paquetes por defecto de tu distribución o compilar PHP tú mismo.

PHP 8.1 o anterior: backports

PHP 8.1, 8.0 y 7.4 ya no tienen soporte, por lo que no hay versiones oficiales con parche. Aun así, tienes opciones.

• El equipo de PHP publicó parches mínimos de código fuente (backports) para 7.4, 8.0 y 8.1. Puedes aplicarlos si compilas PHP tú mismo.
• Los paquetes para Ubuntu y Debian del repositorio de Ondřej Surý incluyen backports de la 5.6 a la 8.1.
• Algunos proveedores (Hostinger, 20i, xCloud y otros) publicaron sus propias compilaciones parcheadas, incluidas versiones antiguas. Primero comprueba si tu proveedor ofrece un backport.

Eso sí, los backports son solo una solución provisional. Es un buen momento para pasar a PHP 8.3 o posterior.

Tercera falla CVE-2026-115560: solución temporal hasta el parche

La tercera falla, revelada el 23 de octubre, está relacionada con la función de progreso de subida de sesión (session upload progress) de PHP. Es difícil de activar con configuraciones típicas, así que no hay parche de emergencia. La corrección llegará en la próxima versión regular. Mientras tanto, la solución oficial es un solo ajuste:

; Añadir a php.ini o a la configuración del pool de PHP-FPM y reiniciar PHP
session.upload_progress.enabled = 0

A menos que tu sitio muestre una barra de progreso de subida, no pierdes casi nada. Como muestra la tabla de proveedores más abajo, los grandes proveedores ya desactivaron esta opción a nivel de servidor.

Mitigaciones temporales antes de parchear (no son una solución completa)

• Desactivar session.upload_progress: lo mismo que arriba. Bloquea una vía de ataque conocida de CVE-2026-109619.
• Reglas WAF de Cloudflare: Cloudflare aplicó reglas de emergencia a todos los planes, incluido el gratuito, justo antes de la divulgación. Pero la propia Cloudflare dice que es «una protección temporal, no un sustituto del parche», y ya se han visto intentos de evadirla.
• Reglas de firewall de tu proveedor: herramientas como ModSecurity bloquean patrones de ataque delante del servidor. Te dan tiempo, pero no resuelven el problema de fondo.

La postura oficial del equipo de PHP es clara: «No existe una mitigación completa. Actualizar es la única opción segura.»

Cómo respondieron los principales proveedores de hosting

Por suerte, los proveedores conocidos actuaron rápido. Abajo está el estado de cada empresa según sus anuncios oficiales. El patrón común: primero bloquear los ataques con reglas de firewall y ajustes, y luego desplegar el parche en todos los servidores en cuanto se publicó.

El estado de cada proveedor sigue cambiando, así que si el tuyo no aparece o no sabes en qué punto está, revisa directamente su página de estado y sus anuncios. Dicho al revés: si tu proveedor se ha quedado callado sin publicar ningún anuncio, eso ya es una señal de alerta.

Cómo revisar tu sitio (3 minutos)

1. Revisa tu versión de PHP: en WordPress, ve a Herramientas → Salud del sitio → Información → Servidor y mira la versión de PHP.
2. Compárala con las versiones parcheadas: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 o posterior significa que estás parcheado.
3. No asumas que un número más bajo significa que estás expuesto: algunos proveedores, como Hostinger, mantienen el número de versión y parchean la compilación. En ese caso, la prueba es si la Build Date en PHP Info de tu panel de hosting es del 21 de octubre de 2026 o posterior.
4. Con PHP 8.1 o anterior: revisa los anuncios de tu proveedor o pregúntale si ofrece un backport. Si no lo ofrece, programa una actualización.
5. En un VPS o servidor dedicado: ejecuta php -v en la terminal y asegúrate de que coincide con el PHP que realmente usa tu servidor web (según phpinfo). Es común que convivan varias versiones de PHP en un mismo servidor.

Parchear no es el final: revisiones posteriores

Un parche solo bloquea los ataques futuros. Si tu sitio fue comprometido antes de parchearlo, el parche no lo deshace. Como los detalles se filtraron antes del parche y los ataques empezaron antes de la divulgación, KISA recomienda lo siguiente:

• Revisa los registros: busca solicitudes sospechosas en los registros del servidor web y de PHP, incluido el periodo anterior al parche.
• Busca web shells: revisa si hay archivos PHP creados o modificados recientemente, cuentas de administrador desconocidas o tareas cron que no reconoces.
• Cambia las credenciales: en los servidores que estuvieron expuestos, cambia las contraseñas de la base de datos, las claves API y las contraseñas de administrador.
• Asegura tus copias de seguridad: guarda fuera del servidor copias de seguridad probadas y restaurables de antes y después del parche.
• Si encuentras señales de una intrusión, no reinicies el servidor (perderías la evidencia en memoria). Corta el acceso a la red y repórtalo a un profesional.

Lista de verificación final

• Confirma la versión de PHP de tu sitio y quién administra PHP
• Verifica que tienes una versión parcheada (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) o que la fecha de compilación es del 21 de octubre o posterior
• En un VPS o servidor dedicado, actualiza PHP tú mismo y reinicia siempre el servicio de PHP
• Con PHP 8.1 o anterior, comprueba si hay un backport y planifica la actualización a 8.3 o posterior
• Desactiva session.upload_progress por la tercera falla (o confirma que tu proveedor lo hizo)
• Revisa los registros y busca web shells del periodo anterior al parche
• Incluye en tu inventario los sitios de prueba, staging y eventos olvidados

Preguntas frecuentes

¿Actualizar WordPress me protege de PHP2Shell?

No. Las fallas están en el propio PHP, no en WordPress ni en los plugins. Solo una compilación de PHP parcheada protege tu sitio.

Tengo hosting compartido. ¿Tengo que hacer algo?

Normalmente tu proveedor parchea PHP por ti, pero verifícalo. Comprueba que tu versión de PHP está parcheada o que la fecha de compilación de PHP es del 21 de octubre de 2026 o posterior.

¿Basta con Cloudflare para mantener mi sitio seguro?

No. Las reglas WAF de Cloudflare son una protección temporal y ya se han visto intentos de evadirlas. Tu servidor de origen sigue necesitando el parche de PHP.

¿Afecta a plataformas que no usan PHP, como Wix?

No. PHP2Shell es una falla de PHP en el servidor, así que las plataformas que no funcionan con PHP, como Wix, y los sitios estáticos no están afectados.

¿Necesitas ayuda?

Si administras varios sitios o no estás seguro de si tu proveedor ya aplicó el parche, contacta con We Design Orange. Te ayudamos con todo: desde revisar la versión y la compilación de PHP de cada sitio hasta parchear tu VPS, buscar señales de intrusión y probar tu sitio después de actualizar PHP.

Este artículo resume información pública al 23 de octubre de 2026. Es información técnica, no una evaluación de seguridad ni asesoría legal. El estado de cada proveedor se basa en sus anuncios oficiales y puede cambiar. Si sospechas de una intrusión, contacta con una empresa de seguridad o con el equipo de respuesta a emergencias informáticas (CERT) de tu país.