Una vulnerabilidad en PHP puede afectar a tu web aunque tengas actualizado el gestor de contenidos y la página funcione con normalidad. PHP se ejecuta en el servidor y participa en tareas como procesar formularios, gestionar sesiones o generar el contenido que recibe el navegador.
La alerta conocida como PHP2Shell afecta al propio entorno de ejecución de PHP. Bajo determinadas condiciones, permite ejecutar código remotamente sin disponer de una cuenta en la web. Por eso, la primera comprobación debe centrarse en la versión y los parches instalados en el alojamiento.
En esta guía encontrarás cómo comprobar tu situación, qué versiones corrigen los fallos y cómo organizar la actualización sin perder de vista el funcionamiento de tu negocio.
Si quieres que una empresa profesional se encargue de tu caso contacta con Indexeo
Vulnerabilidad PHP: qué ocurre y qué debes hacer ahora
PHP2Shell identifica dos vulnerabilidades: CVE-2026-109618 y CVE-2026-109619. Su explotación puede comprometer el proceso que atiende las peticiones web y, según sus permisos, facilitar el acceso a información o la modificación de archivos.
La alerta ha evolucionado desde su publicación. El Centro Canadiense de Ciberseguridad recoge, en su actualización del 27 de octubre, información sobre explotación activa y la inclusión de ambos fallos en el catálogo de vulnerabilidades explotadas de CISA.
Si gestionas una web, estas son las prioridades:
- Identificar qué versión de PHP utiliza.
- Confirmar con el hosting o el administrador si incorpora las correcciones.
- Aplicar la actualización adecuada y comprobar el resultado.
Si no administras el servidor, puedes empezar abriendo una solicitud al proveedor. Indica el dominio y los dos identificadores CVE para que la respuesta se refiera a estos fallos concretos.
Qué versiones de PHP están afectadas y cuáles corrigen PHP2Shell
En las ramas mantenidas, estas son las primeras versiones que incorporan las correcciones para los dos CVE iniciales:
| Rama de PHP | Versiones afectadas dentro de esa rama | Primera versión corregida |
|---|---|---|
| PHP 8.2 | Anteriores a 8.2.35 | 8.2.35 |
| PHP 8.3 | Anteriores a 8.3.36 | 8.3.36 |
| PHP 8.4 | Anteriores a 8.4.27 | 8.4.27 |
| PHP 8.5 | Anteriores a 8.5.12 | 8.5.12 |
La tabla identifica los parches de PHP2Shell. Para una instalación nueva o una actualización, comprueba también si existen versiones posteriores con otras correcciones.
Qué ocurre con PHP 7.4, 8.0, 8.1 y otras versiones antiguas
PHP 8.1 y las ramas anteriores han terminado su soporte regular. Sin embargo, debido a la gravedad de este incidente, el equipo de PHP ha proporcionado parches mínimos de código fuente para 7.4, 8.0 y 8.1.
Algunos distribuidores y proveedores de soporte prolongado también pueden ofrecer correcciones adaptadas a sus paquetes. Estas excepciones no restablecen el mantenimiento general de una rama obsoleta.
Si tu web depende de una versión antigua, pide al proveedor que confirme por escrito qué corrección ha aplicado. Después, planifica una migración compatible con tu aplicación para evitar depender de soluciones excepcionales.
Cómo interpretar una versión corregida por el proveedor
Una distribución puede incorporar un parche sin cambiar la numeración principal de PHP a la versión que aparece en la tabla. Por eso, una comprobación basada únicamente en el número visible puede resultar insuficiente.
Solicita la referencia del paquete instalado y el aviso de seguridad del proveedor que confirme la corrección de ambos CVE. Guarda esa información junto con la fecha de aplicación.
Cómo saber si tu web utiliza una versión vulnerable de PHP
La ruta de comprobación depende del acceso que tengas al alojamiento. Lo importante es identificar el PHP que ejecuta la web concreta que quieres revisar.
Consultar PHP desde WordPress
En el panel de administración, entra en:
Herramientas → Salud del sitio → Información → Servidor.
La información del servidor incluye la versión de PHP utilizada por esa instalación. Anota el número completo y compáralo con la tabla anterior.
Comprobar la versión desde el hosting
Accede a la configuración del dominio y localiza el apartado de PHP. Según el proveedor, puede aparecer como configuración de PHP, selector de versión o administración de PHP.
Si el panel solo muestra la rama —por ejemplo, «PHP 8.3»—, solicita al soporte la versión completa y el estado del parche.
Cuando tengas varios dominios o subdominios, revísalos por separado. Incluye las instalaciones antiguas y los entornos de pruebas que sigan accesibles.
Revisar un VPS, servidor dedicado o contenedor
El administrador debe comprobar tanto los paquetes instalados como los procesos que atienden las solicitudes.
El comando php -v permite consultar el PHP disponible en la terminal, pero ese resultado debe contrastarse con la configuración del servicio web: pueden coexistir varias instalaciones.
En sistemas con contenedores, incorpora a la revisión las imágenes desplegadas y las instancias en ejecución. Actualizar una imagen de referencia sin desplegarla no cambia el servicio que ya está funcionando.
¿Afecta a WordPress, WooCommerce, PrestaShop y otras aplicaciones?
Estas plataformas utilizan PHP, por lo que revisar únicamente sus actualizaciones no permite descartar la exposición del servidor.
Conviene distinguir tres componentes:
| Componente | Qué debes revisar |
|---|---|
| PHP | Versión, paquete instalado y correcciones del proveedor |
| CMS o aplicación | Compatibilidad con la versión de PHP elegida |
| Plugins, módulos y temas | Actualizaciones disponibles y requisitos técnicos |
Actualizar WordPress o un módulo de PrestaShop no sustituye al parche de PHP. A su vez, cambiar PHP exige comprobar que el conjunto de la aplicación sigue siendo compatible.
En una tienda online, presta especial atención a las integraciones de pago, los módulos de transporte y las conexiones con sistemas externos. Esos procesos deben formar parte de las pruebas de actualización.
Cómo solucionar la vulnerabilidad de PHP paso a paso
1. Identifica quién debe intervenir
En un hosting gestionado, el proveedor suele controlar los paquetes de PHP disponibles. El mantenimiento de la aplicación puede corresponder a otro equipo.
Aclara quién realizará cada tarea: actualización del servidor, ajustes de compatibilidad y validación de la web. Así evitarás que una parte dé por resuelto el trabajo de la otra.
2. Prepara una copia recuperable y revisa la compatibilidad
Antes del cambio, conserva una copia de los archivos, la base de datos y la configuración necesaria para recuperar el servicio. Comprueba cómo se restauraría.
Si necesitas cambiar de rama de PHP, revisa los requisitos del CMS y sus extensiones. Siempre que sea posible, prueba la migración en un entorno separado.
En una tienda con actividad, el plan de recuperación debe contemplar los pedidos y datos generados después de la copia. Restaurarla sin considerar ese intervalo puede provocar pérdidas de información.
3. Aplica el paquete corregido
Selecciona una versión mantenida y compatible que incorpore las correcciones. Cuando trabajes con paquetes del proveedor, sigue su procedimiento de actualización.
En un servidor propio, el administrador debe completar el despliegue y renovar los procesos necesarios para que ejecuten el software actualizado.
4. Comprueba las funciones esenciales
La validación debe cubrir las acciones que tus usuarios necesitan completar:
- Acceder a la web y al panel de administración.
- Enviar formularios y recibir sus notificaciones.
- Iniciar sesión y recuperar contraseñas.
- Subir archivos, si la aplicación lo permite.
- Completar compras y comprobar las confirmaciones.
- Ejecutar tareas programadas e integraciones.
Registra los errores encontrados y revisa los logs durante las pruebas. La apariencia de la página de inicio, por sí sola, no demuestra que todo funcione correctamente.
Qué hacer si no puedes actualizar PHP inmediatamente
Cuando existe una incompatibilidad o una dependencia que bloquea el cambio, el responsable técnico debe evaluar cómo reducir la exposición mientras prepara la corrección.
Los avisos de PHP describen medidas temporales para determinadas rutas de ataque. Su alcance es parcial: no convierten una instalación vulnerable en una instalación corregida. Algunos ajustes afectan al tratamiento de memoria y de solicitudes, por lo que requieren valorar sus consecuencias operativas.
Qué papel puede tener un WAF
Un cortafuegos de aplicaciones web puede formar parte de las medidas de protección, pero no debes asumir que tenerlo activado bloquea todas las variantes de un fallo.
Pregunta al proveedor qué cobertura ofrece para estos CVE y qué limitaciones reconoce. La decisión de aplazar una actualización no debería basarse únicamente en la presencia de un WAF.
Cuándo valorar el aislamiento temporal
Si no puedes aplicar el parche ni establecer medidas adecuadas con rapidez, considera restringir el acceso al servicio o retirarlo temporalmente de Internet. El NCSC incluye esta posibilidad entre las acciones de respuesta a la alerta.
Esta decisión debe coordinarse con el equipo responsable del negocio y acompañarse de un plan para recuperar el servicio.
Cómo comprobar que el parche de PHP está aplicado
La intervención debe terminar con evidencias del estado final. Puedes utilizar esta lista:
| Comprobación | Evidencia que conviene guardar |
|---|---|
| El paquete incorpora las correcciones | Versión completa y referencia del proveedor |
| El servicio utiliza el software actualizado | Comprobación sobre el entorno que atiende la web |
| Se ha revisado todo el alcance | Relación de dominios, servidores y contenedores |
| La aplicación funciona correctamente | Resultado de las pruebas funcionales |
| Existe trazabilidad del cambio | Fecha, responsable e incidencias detectadas |
Si el hosting ha realizado la actualización, solicita la confirmación para tus dominios. Una respuesta genérica sobre el mantenimiento de sus servidores puede no aclarar qué ocurre con cada instalación.
Qué hacer si sospechas que tu web ha sido comprometida
Una actualización cierra el fallo corregido, pero la investigación de una posible intrusión requiere trabajo adicional.
Entre las señales que conviene revisar están los archivos o cuentas inesperados, procesos desconocidos y conexiones salientes inusuales asociadas al servicio web. El Centro Canadiense de Ciberseguridad también recomienda examinar los registros de la aplicación, del servidor y de autenticación. Estos indicios requieren análisis; ninguno demuestra por sí solo un ataque mediante PHP2Shell.
Ante una sospecha fundada:
- Conserva los registros y las evidencias disponibles antes de modificar el entorno.
- Coordina la contención con el administrador del servidor.
- Investiga el alcance y los posibles mecanismos de persistencia.
- Recupera el servicio desde un estado verificado y revisa las credenciales que hayan podido quedar expuestas.
Evita limitar la respuesta a borrar un archivo sospechoso. Si no conoces el alcance del incidente, busca apoyo especializado para dirigir la investigación y la recuperación.
Detalles técnicos de PHP2Shell y avisos relacionados
CVE-2026-109618: corrupción asociada al agotamiento de memoria
Este fallo está relacionado con la gestión de errores por agotamiento de memoria. Una interrupción puede dejar datos de una solicitud en un estado incompleto que posteriormente se utiliza durante su cierre.
El aviso oficial describe ejecución remota demostrada en Apache mod_php y diferencias de exposición entre entornos. La configuración concreta influye en las condiciones de explotación.
CVE-2026-109619: estado interno reutilizado entre solicitudes
En este caso, un proceso puede conservar referencias a memoria de una solicitud que ya se ha liberado. Una petición posterior atendida por ese proceso puede utilizar esas referencias antes de reinicializarlas correctamente.
Las condiciones dependen del estado interno y de las operaciones implicadas. Ocultar los errores en pantalla no corrige este problema.
CVE-2026-115560: un aviso adicional sobre sesiones
El 23 de octubre, PHP publicó información sobre otro problema que requiere una combinación poco habitual: configurar un serializador de sesiones determinado, cambiarlo durante la ejecución y mantener habilitada la función de progreso de subida.
Para este escenario, PHP recomienda establecer session.upload_progress.enabled=0 hasta la actualización correspondiente. Las aplicaciones que nunca cambian el serializador durante la ejecución no están expuestas a ese vector concreto. Este aviso debe revisarse por separado de los dos CVE iniciales.
Cómo reducir el riesgo de futuras vulnerabilidades en PHP
Un mantenimiento organizado permite actuar con menos incertidumbre cuando aparece una alerta. (En Indexeo ofrecemos mantenimiento web profesional, contáctanos)
Mantén un inventario de aplicaciones, versiones y responsables. Incluye las fechas de fin de soporte y las dependencias que podrían dificultar una migración. Revisa también los entornos antiguos que ya no necesitas y retíralos cuando corresponda.
Define un procedimiento de actualización con copias recuperables, pruebas y verificación posterior. Suscríbete a los avisos de los proveedores que utilizas y establece quién debe evaluarlos.
El objetivo es que la siguiente intervención parta de información conocida: qué tienes instalado, quién lo mantiene y cómo comprobar que el cambio ha funcionado.
En Indexeo te ayudamos a revisar y actualizar tu web
Si no sabes qué versión utiliza tu página o te preocupa que una actualización afecte a tu tienda online, en Indexeo podemos ayudarte a revisar tu situación y planificar los siguientes pasos.
Podemos valorar las necesidades de tu web, identificar los aspectos de compatibilidad que conviene comprobar y coordinar las actuaciones con el proveedor de alojamiento. La prioridad es abordar la actualización teniendo en cuenta las funciones de las que depende tu negocio.
Contacta con Indexeo para que valoremos tu caso. Indícanos la dirección de tu web, la plataforma que utilizas y cualquier aviso recibido de tu hosting. Con esa información podremos orientar la revisión.
Preguntas frecuentes sobre la vulnerabilidad de PHP
¿Mi proveedor de hosting se encarga de solucionarla?
Depende del servicio contratado. Confirma si ha aplicado los parches a la instalación que utiliza tu dominio y quién debe resolver las posibles incompatibilidades de la aplicación.
¿Una web que funciona con normalidad puede estar afectada?
Sí. Que la web cargue y permita realizar operaciones no demuestra que el software esté corregido. Comprueba su versión y el estado de los parches.
¿Tener HTTPS protege frente a este fallo?
HTTPS protege la comunicación entre el navegador y el servidor. No sustituye las actualizaciones de seguridad del software que procesa las solicitudes.
¿Debo cambiar todas las contraseñas después de actualizar?
La actualización no demuestra por sí misma que haya habido una filtración. Si existen indicios de compromiso, evalúa qué credenciales pudieron quedar expuestas y coordina su renovación desde un entorno confiable.
¿Qué debe hacer un visitante de una web afectada?
El visitante no puede actualizar el PHP del servidor. Sigue las comunicaciones verificadas del servicio y accede a su web por los canales habituales antes de actuar sobre mensajes que soliciten cambios de contraseña o datos personales.
Fuentes y fecha de revisión
Información revisada el 29 de octubre de 2026. El estado de los avisos puede cambiar; consulta las fuentes oficiales antes de ejecutar una intervención.
