Vulnerabilidad de PHP: PHP2Shell y cómo proteger tu web

PHP2Shell es el nombre con el que se conocen dos vulnerabilidades críticas de PHP que pueden permitir ejecutar código en un servidor sin iniciar sesión. El equipo de PHP publicó las correcciones el 21 de octubre de 2026: PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12, según la rama instalada. Si tu web utiliza PHP, necesitas confirmar que el entorno que la sirve incorpora ambos parches.

La alerta afecta a la tecnología que ejecuta muchas webs, incluidas las desarrolladas con WordPress o PrestaShop. Tener WordPress actualizado no demuestra que PHP esté corregido, y una web que carga con normalidad también necesita revisión. Al mismo tiempo, utilizar una versión vulnerable no significa que alguien haya entrado en ella.

La información que sigue está contrastada a 22 de octubre de 2026. La referencia para comprobar nuevas instrucciones es el aviso oficial de seguridad de PHP, porque los detalles de una incidencia tan reciente pueden ampliarse.

Qué debes hacer si tienes una web

Antes de entrar en los detalles técnicos, estas son las decisiones que conviene resolver:

• Identifica quién mantiene PHP: puede ser tu proveedor de hosting, tu equipo de sistemas o una empresa que gestione el servidor.
• Pide confirmación del parche: necesitas la versión completa o el paquete corregido, la referencia a las dos vulnerabilidades y la fecha de aplicación.
• Comprueba todos los sitios: el dominio principal, los subdominios, las tiendas, las API y los entornos de pruebas accesibles desde internet pueden utilizar instalaciones distintas.
• Verifica que la web funciona después del cambio: una actualización no queda cerrada hasta comprobar las funciones que utiliza tu negocio.
• Si hay indicios de intrusión, abre además una investigación: actualizar PHP cierra la vulnerabilidad, pero no elimina por sí solo lo que un atacante hubiera dejado antes.

Si no puedes confirmar la corrección, no des el asunto por resuelto porque exista un firewall o porque alguien haya anunciado que está trabajando en ello. ENISA recomienda priorizar los sistemas expuestos a internet y valorar su aislamiento cuando no sea posible corregirlos inmediatamente. La decisión debe coordinarse con quien gestione el entorno para limitar tanto la exposición como la interrupción del servicio. Recomendaciones conjuntas de los organismos europeos.

Qué ha pasado con PHP en octubre de 2026

La alerta no corresponde a un plugin concreto ni a una sola empresa de alojamiento. Los problemas están en PHP, el componente que interpreta y ejecuta el código de muchas aplicaciones web. Por eso distintos proveedores y proyectos han tenido que actuar al mismo tiempo.

La cronología de la alerta

La PHP Foundation explica el origen y la coordinación de las correcciones. La secuencia ayuda a entender por qué se ha tratado como una emergencia:

• 2024: durante los trabajos derivados de una auditoría externa aparecieron indicios del problema relacionado con los errores por falta de memoria. Todavía no se había identificado una vía concreta que demostrara todo su impacto.
• Agosto y septiembre de 2026: nuevos informes de investigadores, con apoyo de herramientas de inteligencia artificial, mostraron formas de explotación y ampliaron el alcance conocido. La corrección pasó a ser prioritaria.
• 20 de octubre de 2026: PHP avisó de una publicación extraordinaria de seguridad para que los administradores prepararan la actualización.
• 21 de octubre de 2026: se publicaron las versiones corregidas y los detalles técnicos de las dos vulnerabilidades.
• 22 de octubre de 2026: la tarea para los responsables de las webs es comprobar el despliegue real de los parches y revisar la exposición previa, en lugar de quedarse en el anuncio de que existe una solución.

La circulación anticipada de los identificadores y después de algunos detalles alteró la divulgación coordinada. Según la Fundación, la publicación inicialmente prevista para el 22 se adelantó al 21 de octubre.

La participación de la IA importa porque ayudó a investigar y demostrar problemas complejos. No significa que todas las webs hayan sufrido un ataque de inteligencia artificial ni cambia la medida que necesita el propietario: corregir el software que está ejecutándose.

Por qué algunas webs han dejado de funcionar

Una interrupción durante esta alerta puede responder a situaciones diferentes: mantenimiento para instalar el parche, aislamiento preventivo, problemas al actualizar o un incidente de seguridad. Una caída no demuestra por sí sola un hackeo. Tampoco permite concluir que el proveedor esté actuando mal: restringir temporalmente un servicio puede formar parte de la contención.

Conviene pedir una explicación concreta: qué se ha suspendido, por qué, qué comprobación permitirá volver a abrirlo y qué servicio alternativo existe mientras tanto. Un aviso genérico de mantenimiento informa de la interrupción, pero no acredita el estado de seguridad del servidor.

¿Se han detectado ataques reales?

Sí existe evidencia de actividad maliciosa. AWS ha publicado observaciones de intentos de explotación en su infraestructura de detección, incluido un intento del 17 de octubre, anterior a la divulgación pública. Su análisis señala incertidumbre sobre el éxito de algunos intentos observados.

Hay que separar tres datos: una prueba de laboratorio demuestra que el ataque es posible; un intento indica actividad hostil; una intrusión confirmada requiere evidencias del sistema afectado. Ninguno de ellos permite calcular por sí solo cuántas webs han sido comprometidas en todo el mundo.

Qué es PHP y dónde está el problema dentro de una web

Cuando visitas una web dinámica, el navegador solicita una página al servidor. En muchos proyectos, PHP ejecuta las instrucciones necesarias para consultar contenido, comprobar una sesión o preparar la respuesta. El navegador recibe el resultado, normalmente HTML, y no necesita tener PHP instalado para verlo.

Por eso puedes usar PHP sin conocer su nombre. Si tienes una web con WordPress o una tienda con PrestaShop, hay una instalación de PHP detrás. También puede estar presente en un desarrollo a medida o en una herramienta que solo utilizas para gestionar la empresa.

Una forma práctica de entenderlo es distinguir las piezas:

• El hosting: es el entorno donde se aloja y ejecuta tu web.
• El servidor web: recibe las peticiones y las dirige al componente adecuado.
• PHP: interpreta el código de la aplicación.
• El CMS o la aplicación: organiza las funciones de la web, como WordPress, PrestaShop o un desarrollo propio.
• La base de datos: almacena la información que la aplicación necesita consultar o modificar.

PHP2Shell se corrige en el entorno de PHP. Actualizar la aplicación y mantener el servidor son tareas relacionadas, pero diferentes.

Si quieres profundizar en la relación entre el lenguaje y lo que muestra el navegador, puedes consultar nuestra guía sobre PHP y HTML. Para esta alerta, lo esencial es localizar quién administra PHP, aunque tú solo accedas al panel de contenidos.

Qué son las vulnerabilidades CVE-2026-109618 y CVE-2026-109619

Los códigos CVE identifican problemas de seguridad concretos. En este caso hay dos vulnerabilidades relacionadas, agrupadas popularmente bajo el nombre PHP2Shell. No es un virus que debas buscar con ese nombre en una carpeta.

Ambas tienen una puntuación 9,2 sobre 10 en CVSS v4.0, clasificada como crítica. Esa cifra describe la gravedad del problema bajo los criterios del sistema de evaluación; no significa que tu web tenga un 92 % de probabilidad de sufrir un ataque.

CVE-2026-109618: un error cuando PHP se queda sin memoria

PHP utiliza memoria para gestionar cada petición. El problema aparece cuando una falta de memoria interrumpe una operación y deja información interna a medio preparar. Al cerrar la petición, el programa puede tratar esa información incompleta como si fuera válida.

Una comparación útil es una ficha que se ha empezado a rellenar, pero que otro proceso interpreta como terminada. En un programa, ese error puede afectar al uso de la memoria y abrir una vía para ejecutar código.

El aviso técnico de CVE-2026-109618 confirma ejecución remota de código sin autenticación en Apache con mod_php, incluso antes de que empiece a ejecutarse el código de la aplicación. Otros entornos presentan condiciones diferentes y también requieren atención.

CVE-2026-109619: información de una petición que sobrevive más de lo debido

Los procesos que atienden las webs pueden reutilizarse para responder a varias peticiones. En esta segunda vulnerabilidad, un proceso puede conservar referencias a información de una petición anterior cuando la memoria que la contenía ya se ha liberado. Una operación posterior llega a utilizar esa referencia caducada.

A este tipo de problema se le llama uso de memoria después de liberarla, conocido también por el término inglés use-after-free. El aviso técnico de CVE-2026-109619 describe varias vías relacionadas con errores, configuración y estado de las sesiones. Su alcance depende del entorno y de las operaciones que la aplicación permita alcanzar. También se ha validado una vía en PHP-FPM que necesita determinadas operaciones de la aplicación; utilizar FPM no permite descartar el riesgo.

Qué significa ejecutar código sin autenticación

Significa que, bajo las condiciones de explotación, el atacante puede conseguir que el servidor ejecute instrucciones sin necesitar una cuenta de usuario de la web. Por eso una contraseña fuerte o la verificación en dos pasos, aunque siguen siendo necesarias para proteger los accesos, no corrigen estos fallos.

El código se ejecutaría con los permisos del proceso que atiende la web. Eso no equivale automáticamente a obtener todos los privilegios del servidor. El daño dependerá del aislamiento, los permisos de archivos, las credenciales accesibles y las conexiones que ese proceso pueda utilizar.

Qué webs y configuraciones pueden estar afectadas

La pregunta inicial no es si utilizas un tema concreto, sino si alguna parte de tu servicio ejecuta una versión de PHP sin corregir. El riesgo debe evaluarse en la instalación real, incluyendo su configuración y sus extensiones.

WordPress, WooCommerce y PrestaShop

WordPress puede verse afectado por el PHP que utiliza el servidor, aunque el núcleo, los plugins y el tema estén al día. WooCommerce funciona dentro de ese entorno y necesita la misma comprobación de infraestructura. WordPress ha aclarado que estos fallos no se solucionan con una actualización de WordPress.

En PrestaShop ocurre algo parecido. El proyecto ha publicado un aviso específico para las tiendas PrestaShop que remite a actualizar PHP o a utilizar paquetes corregidos por el proveedor. El cambio debe respetar la compatibilidad de la versión de la tienda y sus módulos: no todas las tiendas antiguas pueden saltar sin más a cualquier rama moderna de PHP.

Para un comercio electrónico hay una comprobación adicional: que el parche no haya interrumpido el carrito, los pagos, los pedidos o las conexiones con servicios externos. Que la portada cargue es solo una parte de la validación.

Drupal, Joomla, Magento y desarrollos a medida

El alcance tampoco termina en esos dos CMS. PHP forma parte de muchos otros proyectos. Los investigadores de Calif han publicado demostraciones en entornos controlados con distintas aplicaciones, y Wiz ha explicado el impacto de los fallos en el ecosistema PHP.

Una demostración sobre una aplicación concreta no implica que todos sus despliegues sean idénticos ni que todas sus webs estén comprometidas. Sí demuestra por qué no basta con decir que una aplicación está bien programada: el motor que la ejecuta también necesita mantenimiento.

Apache, PHP-FPM, LiteSpeed y otros modos de ejecución

Los nombres pueden resultar técnicos, pero ayudan a formular la pregunta correcta al hosting:

El modo de ejecución modifica las condiciones y las vías posibles. Para quien gestiona una web, la decisión sigue siendo comprobar el parche. Cambiar de nombre de servidor o asumir que otra configuración es segura no sustituye la corrección.

En una infraestructura con varios nodos, es decir, servidores o instancias que reparten el trabajo, hay que comprobarlos todos. Cada uno puede ejecutar una instalación distinta.

Qué ocurre con las webs estáticas y los servicios externos

Una web que solo sirve archivos estáticos y no ejecuta PHP no está expuesta a estos fallos a través de ese componente. Pero conviene comprobar también sus formularios, paneles, subdominios y servicios de apoyo. Una portada estática puede convivir con una aplicación PHP en el mismo proyecto.

Si utilizas un servicio completamente gestionado, corresponde al proveedor mantener su infraestructura. Por ejemplo, WordPress.com comunicó que sus sitios estaban protegidos frente a PHP2Shell. Esa afirmación se refiere a su plataforma: no debe trasladarse a cualquier WordPress alojado en otra empresa.

Qué versiones de PHP corrigen PHP2Shell

Estas son las primeras versiones publicadas por el proyecto PHP que incorporan las correcciones, dentro de las ramas indicadas:

Una versión posterior de la misma rama que incluya esas correcciones también puede resolver estos fallos. El número “PHP 8” es demasiado impreciso para comprobarlo. Tampoco debes comparar ramas como si fueran una sola secuencia: PHP 8.4.26 no queda corregido simplemente por ser numéricamente mayor que PHP 8.3.36.

Por qué un hosting puede mostrar un número anterior y estar parcheado

Algunos distribuidores trasladan una corrección a su paquete mantenido sin cambiar el número principal de PHP que ves en el panel. Esto se conoce como backport. Puede ser una corrección válida, pero necesita una referencia verificable: el aviso del proveedor, la revisión del paquete y la confirmación de que cubre las dos CVE.

Por tanto, un número anterior requiere investigar; no permite afirmar automáticamente ni que todo esté bien ni que el proveedor no haya actuado. PrestaShop también advierte de este matiz en su comunicación a las tiendas.

Qué hacer si utilizas PHP 8.1, 8.0, 7.4 o versiones más antiguas

PHP 8.1 y las ramas anteriores ya no tienen soporte general del proyecto PHP. La existencia de proveedores con mantenimiento extendido o de parches excepcionales no devuelve a esas ramas su soporte oficial completo.

Para esta emergencia se han facilitado backports mínimos de código para PHP 7.4, 8.0 y 8.1, pero aplicarlos y validarlos requiere capacidad técnica. No son una actualización automática para cualquier hosting. Pide al proveedor una respuesta documentada y prepara la migración a una rama compatible y mantenida.

El calendario oficial de soporte de PHP también importa después de la emergencia. PHP 8.2 llega al final de su soporte de seguridad el 31 de diciembre de 2026: corregir PHP2Shell ahora y planificar la evolución del entorno son dos tareas que pueden necesitar fechas distintas.

Cómo puede afectar a tu web y a tu negocio

Una vulnerabilidad de esta gravedad puede tener efectos sobre la confidencialidad, la integridad y la disponibilidad. Dicho de una forma más cercana: qué información puede leerse, qué puede cambiarse y si el servicio sigue funcionando.

Acceso a información y credenciales

Si un atacante consigue ejecutar código con los permisos de la web, podría acceder a archivos o servicios disponibles para ese proceso. Una configuración con credenciales de base de datos o claves de integración puede ampliar el alcance del incidente.

Además, Wiz ha demostrado lectura de memoria sensible sin conseguir previamente ejecución de código. Esa memoria puede contener contraseñas, tokens o claves de otras peticiones. Por tanto, el riesgo de exposición de información no se limita a los casos en que se logra ejecutar instrucciones. Investigación original sobre la lectura de memoria en PHP2Shell.

Eso no significa que todos los datos de todos los servidores estén accesibles. El aislamiento entre cuentas y los permisos limitados pueden reducir el daño. Tampoco conviene suponer que utilizar una pasarela externa garantiza que todo el comercio está intacto: hay que revisar qué parte de la compra y de los datos dependía de la web.

Modificación de páginas, formularios o redirecciones

Una intrusión puede utilizarse para alterar contenido, introducir enlaces fraudulentos o redirigir visitantes. El riesgo no se limita a que alguien cambie la portada de forma visible. También puede afectar a funciones menos evidentes, como un formulario o un archivo que se carga en algunas páginas.

Interrupciones y pérdida de operaciones

Los errores, la sobrecarga o las medidas de aislamiento pueden detener ventas y consultas. Por eso la respuesta necesita un responsable técnico y otro de negocio: alguien tiene que decidir qué servicios se suspenden, cómo se informa y qué funciones deben volver primero.

Un ejemplo hipotético: una tienda puede mostrar sus productos desde caché mientras el proceso de compra falla al llegar al servidor. Ver la página no equivale a comprobar que el servicio completo funciona.

Alcance entre varias webs

Si un servidor aloja varios proyectos, hay que revisar cómo están separados. Compartir máquina no demuestra que una intrusión se haya propagado entre todos ellos, pero justifica comprobar cuentas, permisos y recursos compartidos. El inventario del hosting debe permitir saber qué sitios utilizan cada instalación de PHP.

Cómo saber si tu web está afectada

Para responder bien hay que resolver tres preguntas: ¿utiliza PHP?, ¿qué instalación atiende sus peticiones?, ¿esa instalación incorpora las dos correcciones? Detectar la tecnología es solo el primer paso.

Comprobar la versión de PHP en WordPress

En el panel de WordPress puedes consultar Herramientas > Salud del sitio > Información > Servidor. Allí aparece la versión de PHP utilizada por ese sitio. Es una comprobación recomendada en el aviso oficial de WordPress.

Anota el número completo y contrástalo con la tabla anterior. Si el hosting aplica un backport, pide su referencia. No cambies la versión al azar desde el panel: primero confirma cuál es compatible con tu instalación y qué paquete incorpora el arreglo.

Si gestionas varios WordPress, repite la revisión para cada entorno. Una instalación nueva en un dominio no acredita el estado de una web antigua en otro subdominio.

Comprobarlo en el panel del hosting

Muchos paneles muestran la versión asignada a cada dominio y permiten seleccionar otra. La ubicación y el alcance de esas opciones varían según el proveedor. Revisa si el selector corresponde al dominio que quieres comprobar o a una configuración por defecto que otros sitios pueden sobrescribir.

En un alojamiento compartido, normalmente no administras los paquetes del sistema. Necesitas que el proveedor confirme qué ha instalado y qué entorno utiliza tu cuenta. En un VPS o servidor propio, la responsabilidad puede recaer en tu equipo de sistemas o en quien tenga contratado su mantenimiento.

Por qué una comprobación superficial puede engañarte

• La terminal puede usar otro PHP: el resultado de “php -v” no tiene por qué coincidir con el proceso que sirve la web.
• La caché puede ocultar el estado del servidor: una página guardada puede mostrarse sin ejecutar PHP en esa visita.
• Puede haber más de un nodo: actualizar una máquina no corrige las demás instancias de una infraestructura repartida.
• Los encabezados públicos son incompletos: pueden ocultarse, cambiarse o mostrar información que no acredita el paquete instalado.
• Un escáner puede tener alcance limitado: un resultado negativo no sustituye la confirmación del parche ni una investigación de intrusión.

Evita dejar una página pública de diagnóstico con información detallada del servidor. La comprobación debe realizarse desde los accesos de administración y retirarse cuando termine.

Qué pedir exactamente al proveedor de hosting

Puedes utilizar este texto para evitar respuestas demasiado generales:

Necesito confirmar el estado de mi web frente a PHP2Shell, CVE-2026-109618 y CVE-2026-109619. ¿Qué versión completa o revisión de paquete PHP atiende este dominio? ¿Incorpora las correcciones de ambas CVE? Por favor, indicad la referencia del aviso o del paquete, cuándo se desplegó y si se han renovado los procesos que servían la versión anterior. Confirmad también si quedan otros dominios, subdominios o nodos de mi servicio pendientes y si habéis detectado indicios que requieran investigar una intrusión.

Una respuesta útil identifica el entorno y el estado real. “Tenemos firewall”, “PHP 8 está activado” o “las actualizaciones son automáticas” no responden por sí solas a esas preguntas.

Cómo actualizar PHP con un proceso verificable

La corrección necesita actuar sobre el entorno del servidor. Según el contrato, lo hará el hosting, un equipo de sistemas o una empresa que gestione esa infraestructura. El propietario de la web debe asegurarse de que la tarea tiene responsable y de que existe una comprobación final.

La actualización y la investigación de una posible intrusión pueden avanzar en paralelo. Completar una no sustituye la otra.

Identificar el entorno completo

Haz una lista de los sitios y servicios que dependen de PHP. Incluye producción, pruebas accesibles desde internet, paneles, procesos auxiliares y contenedores. Señala para cada uno la versión, el responsable y la evidencia del parche.

Esta lista evita un error frecuente en las emergencias: resolver el dominio más visible y dejar una aplicación olvidada expuesta en otro lugar.

Preparar una copia recuperable y comprobar compatibilidad

Antes de cambiar el entorno, quien lo administre debe disponer de una copia de seguridad recuperable de los elementos necesarios y de una forma de restablecer el servicio. En un comercio electrónico, hay que considerar también los pedidos y cambios que se produzcan durante la intervención.

Actualizar dentro de una rama compatible puede ser diferente de migrar una aplicación antigua a otra rama de PHP. Si hace falta esa migración, conviene probar los componentes críticos en un entorno separado. Las pruebas deben acotarse para no prolongar innecesariamente una exposición crítica. Si el entorno no puede corregirse a tiempo, hay que resolver su contención.

Si ya existe sospecha de intrusión, conserva además las evidencias antes de sobrescribir archivos. Una copia hecha después del incidente puede contener la alteración y no debe darse por limpia.

Instalar el paquete corregido y activarlo realmente

La actualización debe proceder de la distribución o del proveedor que mantenga el entorno, o de una compilación gestionada con garantías técnicas. Descargar un paquete o cambiar la etiqueta de una imagen no demuestra que la web ya lo esté utilizando.

El administrador debe renovar o reiniciar los procesos necesarios según la arquitectura, comprobar los nodos activos y verificar la versión que atiende las peticiones web. En contenedores, esto implica desplegar la imagen corregida y comprobar las instancias que están ejecutándose.

Probar las funciones que generan negocio

La validación debe recorrer acciones reales, no solo abrir la portada:

• Acceso y sesiones: iniciar y cerrar sesión, áreas privadas y recuperación de contraseña.
• Formularios: envío, recepción y registro de las solicitudes.
• Comercio electrónico: carrito, cálculo del pedido, pago de prueba y confirmación.
• Archivos: funciones necesarias de carga, descarga o importación.
• Integraciones: conexiones con CRM, reservas, facturación u otros servicios.
• Tareas automáticas: procesos programados y trabajos en segundo plano.

Elige las pruebas que correspondan a tu web y evita operaciones que generen cobros o comunicaciones reales sin control. Registra qué se ha probado y qué queda pendiente.

Cerrar la intervención con evidencia

El cierre debería incluir la versión o revisión del paquete aplicada, el alcance de los entornos revisados, el momento de activación y el resultado de las pruebas. Si hubo una incidencia, debe existir un registro separado de lo investigado y de las medidas tomadas.

“Actualizado” debe significar corregido, activo y comprobado. Si una función falla, el equipo debe resolver su compatibilidad manteniendo la protección. Volver a una instalación vulnerable sin contención reabre el problema.

Qué protecciones ayudan y cuáles no sustituyen el parche

Las medidas de defensa pueden reducir exposición o daño. Su utilidad depende de dónde actúen y de qué tráfico o funciones cubran. Conviene conocer sus límites para no confundir una protección parcial con una corrección completa.

Firewall de aplicaciones y CDN

Un WAF es un firewall que analiza peticiones web y puede bloquear patrones sospechosos antes de que lleguen a la aplicación. Cloudflare ha comunicado el despliegue de protecciones específicas frente a PHP2Shell.

Para valorar esa protección en tu caso, confirma que el tráfico pasa por el servicio, que las reglas están activas y que no existen accesos alternativos al servidor de origen que las eludan. Una CDN puede acelerar contenidos sin que eso acredite una cobertura concreta de seguridad.

Las reglas pueden necesitar ajustes a medida que se conocen nuevas vías. El firewall complementa el parche; no elimina el fallo del PHP instalado.

Plugins de seguridad, contraseñas y certificado SSL

Un plugin puede ayudar con detección, accesos o integridad de archivos. Sin embargo, parte del riesgo conocido puede aparecer antes de que empiece el código de la aplicación. No instales un plugin esperando que reemplace una actualización de PHP.

Las contraseñas robustas y la autenticación en dos pasos protegen cuentas. Estas vulnerabilidades incluyen escenarios sin autenticación, por lo que esas medidas no bloquean por sí solas la vía descrita.

Lo mismo ocurre con HTTPS: el certificado SSL protege la conexión, pero no corrige errores del software del servidor. Una web puede tener HTTPS y utilizar un componente vulnerable.

Cambios temporales de configuración

Los avisos técnicos describen ajustes que reducen determinadas vías, como limitar peticiones o desactivar funciones concretas. No deben convertirse en una receta para copiar sin revisar el entorno.

Por ejemplo, desactivar session.upload_progress.enabled puede limitar una vía relacionada con sesiones, pero no cubre todo PHP2Shell. Del mismo modo, modificar los límites de memoria tiene consecuencias sobre el consumo de recursos y no garantiza que desaparezcan todos los fallos de asignación.

Quien administre el servidor debe valorar cada medida con las instrucciones de mitigación de PHP y comprobar sus efectos. Los cambios también pueden afectar a importaciones, formularios o cargas de archivos. Si se utiliza una mitigación temporal, debe quedar identificado qué reduce, qué deja pendiente y cuándo se aplicará el parche.

Copias de seguridad y aislamiento

Las copias sirven para recuperar información y servicio. No impiden que una instalación vulnerable reciba un ataque. Restaurar una copia sobre el mismo entorno sin corregir puede volver a dejar abierta la vía de entrada.

El aislamiento reduce la exposición mientras se resuelve el problema. Debe aplicarse al servicio vulnerable de una forma que realmente impida acceder a él. Una página de mantenimiento generada por la propia aplicación PHP no demuestra que el motor haya dejado de recibir peticiones.

Qué hacer si sospechas que alguien ha entrado en tu web

Si aparecen indicios de intrusión, la actualización es una parte de la respuesta. Hace falta determinar qué ocurrió, qué sigue comprometido y cómo recuperar un entorno fiable.

Señales que justifican investigar

Entre las señales que conviene revisar están los archivos o usuarios no reconocidos, cambios inesperados en páginas, redirecciones, avisos de malware, conexiones anómalas o fallos repetidos sin explicación. También puede haber alertas del hosting o de sus herramientas de detección.

Ninguna señal aislada atribuye el incidente a PHP2Shell. Un error de memoria puede tener otras causas y una alteración de la web puede proceder de otro componente o de una cuenta comprometida. La atribución necesita evidencias y una cronología.

Contener, conservar pruebas y recuperar

La guía de WordPress para sitios comprometidos ofrece una referencia para organizar la respuesta en ese CMS. El trabajo debe adaptarse al entorno, pero necesita resolver estas tareas:

• Contener el acceso: limitar el servicio afectado y evitar que el problema continúe mientras se investiga.
• Conservar evidencias: guardar registros, fechas y copias de los elementos relevantes antes de borrarlos o sustituirlos.
• Determinar el alcance: revisar archivos, cuentas, bases de datos, tareas programadas y conexiones que pudieran haber quedado alteradas.
• Cerrar las vías de entrada: corregir PHP y cualquier otro acceso o componente comprometido.
• Recuperar desde una base fiable: limpiar o reconstruir el entorno y verificar las copias utilizadas.
• Renovar los secretos afectados: cambiar credenciales, claves o sesiones cuando el análisis indique exposición, desde un entorno de administración seguro.
• Vigilar después de la reapertura: comprobar que no reaparecen cambios ni actividad anómala.

Evita ejecutar herramientas desconocidas que prometan comprobar PHP2Shell con un clic. Además de su fiabilidad, importa si alteran el sistema o envían información a terceros. La comprobación del parche puede hacerse sin lanzar una prueba de explotación contra la web.

Si hay datos personales afectados

Una vulnerabilidad pendiente no equivale automáticamente a una brecha de datos personales. Si el incidente ha ocasionado pérdida, alteración, destrucción o acceso no autorizado a esos datos, debe intervenir quien gestione su protección en la organización.

La AEPD explica cuándo procede notificar una brecha: depende del riesgo para los derechos y libertades de las personas. Cuando existe obligación de notificar a la autoridad competente, el plazo es de 72 horas desde que se tiene constancia de la brecha. Un riesgo alto puede exigir también informar a las personas afectadas. La valoración y la documentación deben hacerse sobre el incidente real, sin esperar a tener una explicación pública definitiva de la vulnerabilidad.

Cómo puede afectar PHP2Shell al SEO

Una web no pierde posiciones automáticamente por utilizar PHP ni por el nombre de una vulnerabilidad. El efecto sobre la búsqueda puede llegar por sus consecuencias: indisponibilidad, respuestas incorrectas, contenido alterado o avisos de seguridad.

Caídas y páginas de mantenimiento

Si la intervención requiere una parada breve, el equipo técnico debe servir una respuesta adecuada. El código HTTP 503 Service Unavailable expresa una indisponibilidad temporal; puede acompañarse de una indicación Retry-After. La documentación de HTTP 503 explica ese uso.

No conviene sustituir todas las URL por una página vacía que responda como si fuera contenido normal, ni borrar páginas o redirigir todo permanentemente por una intervención temporal. El control del acceso vulnerable debe seguir siendo efectivo: cuidar la respuesta HTTP no sustituye contener el servicio.

Google explica que los errores de servidor afectan al rastreo. Si persisten, pueden acabar afectando a la presencia de las páginas en el índice. Por eso hay que reducir la interrupción y verificar las respuestas tras reabrir, sin prometer que cualquier duración de mantenimiento será inocua.

Contenido hackeado y advertencias de seguridad

Si un atacante introduce páginas, enlaces o redirecciones fraudulentas, el problema puede llegar a los resultados de búsqueda y a las advertencias que ve el visitante. El informe de problemas de seguridad de Search Console ayuda a revisar los problemas detectados por Google y a solicitar una revisión después de resolverlos.

No basta con retirar el contenido visible de una sola página. Hay que solucionar el conjunto de alteraciones y su origen. Tampoco debe interpretarse un informe sin alertas como un análisis forense completo del servidor.

Qué revisar después de recuperar el servicio

La revisión de SEO técnico debe comprobar que las URL importantes vuelven a responder correctamente, que no se ha dejado una restricción de indexación de las pruebas y que se conservan los enlaces y las referencias canónicas previstas.

También conviene revisar las páginas nuevas desconocidas, las redirecciones, los sitemaps y los informes de Search Console. Si hubo tráfico o ventas anómalas, contrasta las fechas con los registros de la intervención. Una caída de analítica puede deberse a la interrupción o a cambios de medición; no demuestra por sí sola una pérdida de posicionamiento.

Actualizar PHP normalmente no exige cambiar el dominio ni las URL. Si además se decide cambiar de proveedor, esa migración necesita su propio plan, como explicamos en la guía para cambiar una web de hosting.

Quién debe encargarse de cada parte

El reparto depende del contrato. Una agencia puede mantener la aplicación sin administrar el servidor, y un hosting puede mantener PHP sin revisar todos los módulos de una tienda. La coordinación debe aclararse antes de dar por cerrada la incidencia.

No necesitas conocer cada detalle de PHP para coordinarlo. Necesitas una respuesta trazable sobre quién ha corregido el entorno, quién ha probado la web y quién está revisando cualquier indicio pendiente.

Lista de comprobación para dar la revisión por terminada

Puedes utilizar esta lista como cierre con tu proveedor y tu equipo:

• Inventario completo: se han incluido los sitios y servicios PHP accesibles, también los menos visibles.
• Corrección de ambas CVE: existe una versión o paquete que acredita los dos arreglos.
• Parche activo: los procesos y nodos en servicio utilizan la corrección.
• Compatibilidad revisada: no quedan errores importantes de la aplicación tras el cambio.
• Operaciones probadas: funcionan las acciones críticas de tu negocio.
• Copias recuperables: hay una base fiable para restaurar si fuera necesario.
• Exposición previa valorada: se han revisado los avisos y registros disponibles, con sus límites.
• Incidentes separados: si hubo indicios, la investigación no se ha cerrado solo porque PHP esté actualizado.
• Web pública comprobada: respuestas, accesos e indexación han vuelto al estado previsto.
• Siguiente mantenimiento definido: existe un plan para las ramas antiguas o próximas a terminar su soporte.

Conserva la confirmación del proveedor y el resultado de las pruebas. Servirán para responder a una nueva alerta y para evitar que una restauración o un despliegue posterior vuelva a introducir una versión sin corregir.

Otras dudas habituales sobre la vulnerabilidad de PHP

¿Puede afectar al ordenador de alguien que solo visita una web?

Estos fallos se producen en PHP del lado del servidor. El visitante no tiene que actualizar PHP en su ordenador para corregir la web que visita. Si un sitio ha sido alterado y distribuye contenido malicioso, puede existir un riesgo adicional para sus usuarios que deberá investigarse como parte del incidente.

¿Es la misma vulnerabilidad de PHP de 2024?

No. PHP2Shell corresponde a CVE-2026-109618 y CVE-2026-109619. CVE-2024-4577 es otro problema, con condiciones y correcciones diferentes. Una instalación que corrigió un fallo anterior sigue necesitando comprobar las actualizaciones posteriores. Puedes contrastar aquel caso en el aviso de CERT-EU sobre CVE-2024-4577.

¿Afecta solo a Linux o solo a Windows?

No debes descartar la revisión únicamente por el sistema operativo. Hay que comprobar la rama, el paquete y la forma de ejecutar PHP en tu entorno. La plataforma puede cambiar las condiciones técnicas, pero no sustituye el aviso de seguridad ni la confirmación del proveedor.

¿Tengo que cerrar mi web aunque ya esté corregida?

Una instalación corregida y verificada no necesita cerrarse automáticamente por esta noticia. La decisión puede ser diferente si quedan componentes pendientes, no se puede confirmar el parche o se investiga una intrusión. El criterio debe basarse en el estado del servicio, no solo en el titular.

¿Es necesario cambiar de lenguaje de programación?

La respuesta inmediata es corregir el entorno afectado. Cambiar de lenguaje sería un proyecto distinto, con costes, compatibilidades y riesgos propios. No resuelve por sí solo la gestión de una posible intrusión previa ni garantiza que la nueva tecnología no vaya a necesitar actualizaciones.

¿Cuánto tarda en solucionarse?

No hay un plazo único. Aplicar un paquete compatible en un entorno mantenido es diferente de migrar una aplicación antigua o investigar un compromiso. Pide hitos comprobables: contención, despliegue, pruebas y reapertura, en lugar de una promesa sin conocer la instalación.

Una web protegida necesita una revisión que llegue hasta el servidor

PHP2Shell deja una tarea concreta para cualquier empresa con una web: saber qué tecnología está ejecutándose, quién la mantiene y cómo se comprueba una corrección. El parche debe llegar al servidor y la validación debe llegar a las funciones que utilizan tus clientes.

Si necesitas revisar el entorno de tu proyecto, su compatibilidad o el mantenimiento de la aplicación, en COCO Solution podemos ayudarte a definir esa revisión desde nuestro equipo de desarrollo web. Cuéntanos qué web utilizas y qué te ha confirmado tu hosting para valorar el siguiente paso con información concreta.