Desde el 20 de octubre de 2026, la alerta PHP2Shell exige una verificación inmediata en sitios PrestaShop, WordPress y WooCommerce. No se trata de un módulo o tema concreto: afecta al núcleo de PHP, la capa que ejecuta su tienda día a día.
Lo que cambia la prioridad es sencillo: las dos vulnerabilidades están catalogadas como críticas, con riesgo de ejecución remota de código sin autenticación y fuga de memoria que puede exponer secretos aplicativos. Si su sitio corre en una rama PHP vulnerable, esperar al siguiente mantenimiento le deja innecesariamente en riesgo.
En este artículo verá quiénes están afectados, cómo comprobar la versión real de PHP usada por su sitio, qué hacer según su alojamiento y qué planificar si su tienda sigue atascada en una rama antigua.
PHP2Shell: lo publicado y por qué la alerta es inmediata
Al 23 de octubre de 2026, la información útil ya es suficiente para actuar. Los parches están publicados y, el 22 de octubre de 2026, el CERT-FR ya señalaba pruebas de concepto conocidas. Para un responsable de e‑commerce, el reflejo correcto es simple: comprobar la exposición, corregir y luego verificar el estado de la tienda.
La cronología a recordar desde el 20 de octubre de 2026
El 20 de octubre de 2026, PHP anunció una publicación de seguridad inminente para dos vulnerabilidades críticas. Los detalles se filtraron antes del fin del embargo. Los parches oficiales se publicaron el 21 de octubre de 2026 a las 16:00, hora de París, con las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
El punto útil para usted: si su sitio no utiliza al menos una de estas versiones corregidas, o un paquete del proveedor con backport explícito, debe considerarse expuesto. PHP recuerda también que la actualización sigue siendo la única opción segura: aviso de seguridad PHP y versiones corregidas.
Las dos fallas en una frase clara
PHP2Shell agrupa aquí dos fallos del núcleo de PHP: CVE-2026-109618, ligada a una corrupción por un desbordamiento de memoria al finalizar una petición, y CVE-2026-109619, relacionada con un estado global de petición que puede reutilizarse en la siguiente en el mismo proceso, con use-after-free y fuga de memoria.
Ambas tienen una puntuación de 9,2 en CVSS v4.0. Dicho de otro modo: no es una alerta teórica. Al 22 de octubre de 2026, el CERT-FR ya reportaba pruebas de concepto conocidas.
La gravedad es realmente crítica para una tienda online
Para una tienda, la cuestión no es solo si el servidor puede caer. La verdadera pregunta es qué puede alcanzar un atacante antes de que lo detecte. En ese aspecto, el nivel de riesgo es alto.
Ejecución remota de código sin autenticación: qué implica
PHP indica que ambas fallas pueden permitir ejecución remota de código sin autenticación. Eso significa que un atacante no necesita cuenta de cliente, acceso al back-office ni un módulo ya comprometido para intentar explotarlas. Si el motor PHP que atiende las peticiones es vulnerable, la superficie de exposición existe a nivel del tratamiento de las solicitudes HTTP.
Cloudflare notificó tráfico de ataque desde la divulgación pública, lo que confirma que el asunto pasó con rapidez de alerta a intentos reales a vigilar: análisis de Cloudflare sobre las protecciones desplegadas contra PHP2Shell. Eso no prueba campañas específicas contra PrestaShop, WordPress o WooCommerce en particular, y conviene ser preciso en ese punto.
Fuga de memoria: por qué pueden verse comprometidos contraseñas, tokens y claves API
El aviso GHSA-6wmf-4rv5-p3rp describe un estado global de petición que puede sobrevivir en un worker y ser reutilizado por la siguiente petición en el mismo proceso. El resultado posible: use-after-free, fuga de memoria y, potencialmente, RCE. El otro aviso, GHSA-w8hw-w9fx-j79w, trata una corrupción ligada a un desbordamiento de memoria al final de la petición.
Para un comerciante, la consecuencia práctica es clara: secretos aplicativos presentes en memoria pueden quedar expuestos. Esto puede afectar contraseñas, tokens y claves API. Una tienda puede seguir aparentemente operativa y, sin embargo, mantener un riesgo serio en pagos, conectores, área de cliente o administración. El mecanismo de CVE-2026-109619 está descrito en el aviso oficial: advisory en GitHub sobre RCE por stale global state.
Quién está afectado según su versión PHP y su alojamiento
La buena metodología es situarse primero en dos ejes: su rama PHP y el modo de ejecución. Es ese dúo el que determina la urgencia y el tipo de actuación.
Las ramas PHP a considerar como expuestas
Las ramas oficialmente corregidas son 8.2, 8.3, 8.4 y 8.5 a partir de las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Todas las versiones anteriores en esas ramas están afectadas.
Las ramas 5.x, 7.x, 8.0 y 8.1 también deben considerarse en riesgo. Para 8.1 y versiones anteriores ya no existe soporte upstream. Pueden existir backports por proveedores para 7.4, 8.0 y 8.1, pero son limitados. No hay anuncios para 7.4. El error frecuente es creer que una rama todavía disponible en el panel de alojamiento es necesariamente segura. No es un criterio suficiente.
Por qué Apache mod_php y PHP-FPM deben tratarse con prioridad
Qualys recomienda tratar Apache mod_php como el caso más urgente. PHP-FPM también está implicado, al igual que php-cgi, FrankenPHP y LiteSpeed. Si no sabe cómo se ejecuta PHP en su sitio, parta de la base de que debe comprobarlo sin demora y luego confirmar con su proveedor o servicio de infogestión.
Un punto práctico: una tienda que responde no es una tienda protegida. El riesgo ataca al motor PHP en sí. Qualys detalla este punto y recuerda que un paquete del sistema o del proveedor puede incluir el parche sin mostrar exactamente el número de versión upstream esperado: evaluación del riesgo PHP2Shell por Qualys.
El caso particular del alojamiento compartido
En hosting compartido, el proveedor puede haber parcheado sus clústeres rápidamente, pero eso no exime de comprobar la rama PHP seleccionada en su panel de cliente. Puede tener un proveedor reactivo y, aun así, mantener el sitio expuesto si permanece en una rama antigua como 8.1 o anteriores.
Cómo comprobar la versión real de PHP usada por su sitio
Es el paso más simple y, sin embargo, donde muchos fallan. La trampa clásica es mirar la versión en la línea de comandos o en un contrato de alojamiento y pensar que el sitio web la utiliza.
PrestaShop: dónde verificar en el back-office
En PrestaShop, compruebe primero en Parámetros avanzados > Información. Ahí verá la versión de PHP que la tienda reporta realmente. Haga esta verificación antes de tocar nada y repítala después de la intervención.
Si su sitio muestra una versión anterior a 8.2.35, 8.3.36, 8.4.27 o 8.5.12 en una rama aún soportada, la acción es clara: actualización inmediata. Si está en 8.1, 8.0 o 7.x, además verifique si su proveedor anuncia un backport. Sin esa confirmación, considere la tienda en riesgo.
WordPress y WooCommerce: la ruta más segura
En WordPress y WooCommerce, vaya a Herramientas > Estado del sitio. Es la vía más simple para ver la versión PHP usada por el sitio web. Tampoco confíe primero en lo que el servidor debería usar: verifique lo que WordPress ve realmente.
En entornos con varios sitios o varios pools, dos aplicaciones en el mismo servidor pueden no usar la misma configuración PHP. Es un error frecuente en VPS y servidores dedicados tras cambios parciales.
Por qué la versión CLI puede engañar
El comando php -v en SSH puede diferir de la versión realmente usada por el sitio web. Puede leer una versión tranquilizadora en la línea de comandos mientras el front funciona con otra pila.
Otro caso habitual: un paquete del sistema u ofrecido por el proveedor incorpora el parche sin reflejar el número de versión upstream. En VPS, dedicado o alojamiento gestionado, la buena práctica es cruzar tres cosas: la versión vista por el CMS, la versión de los paquetes y el comunicado del proveedor.
Qué hacer ahora, en el orden correcto
El orden correcto evita dos errores comunes: parchear a medias o reiniciar demasiado tarde. Aquí la secuencia útil para un sitio en producción.
Actualizar PHP o seleccionar la rama adecuada en el panel de alojamiento
Primer reflejo: aplique la versión corregida si está disponible. En hosting compartido, eso puede significar seleccionar la rama correcta en el panel. En VPS o dedicado, significa actualizar los paquetes que administra su distribución o su proveedor.
Si es comerciante PrestaShop y la tienda ya es sensible en disponibilidad, prevea en paralelo una intervención de urgencia en PrestaShop si el cambio de rama rompe el front, el back-office o el túnel. Y si desea reducir el riesgo de cortes en futuros incidentes técnicos, tenga a mano los controles que evitan que una avería deje su tienda fuera.
Reiniciar PHP-FPM o Apache tras la actualización
En un VPS o servidor dedicado, la actualización no basta si los procesos afectados no se reinician. Hay que reiniciar PHP-FPM o Apache según el modo de ejecución real del sitio. El reinicio forma parte de las acciones a prever también tras una mitigación temporal.
Error frecuente: actualizar un paquete, comprobar rápidamente el sitio y olvidar que hay workers en memoria que siguen usando el estado anterior. En una vulnerabilidad que afecta procesos y memoria, ese detalle cuenta.
Por qué un WAF o una mitigación temporal no son suficientes
PHP indica que no existe una mitigación completa y que la actualización es la única opción segura. Los atajos provisionales tienen utilidad, pero no corrigen PHP. Los oficialmente citados son session.upload_progress.enabled=0 para reducir el perímetro de CVE-2026-109619, bloquear peticiones multipart innecesarias, fatal_error_backtraces=0 en 8.5 y, por supuesto, reiniciar los procesos PHP. El aviso GHSA añade que pm.max_requests=1 puede reducir el riesgo si el rendimiento no es prioritario.
Un WAF puede ayudar a ganar tiempo. Cloudflare ha desplegado protecciones por defecto para sus clientes WAF. Pero un filtrado no elimina la vulnerabilidad del motor PHP. Si la rama sigue expuesta, usted mantiene un riesgo residual.
Si su tienda está bloqueada en PHP 7.x u 8.1, inicie ya un proyecto planificado
Es el caso más incómodo. En urgencia, lo que se busca es reducir el riesgo. En la práctica, una tienda antigua no siempre sube de versión PHP sin causar roturas. Por eso debe tratarse como un proyecto serio, no como un simple clic en un panel.
Por qué la actualización rompe a veces una tienda antigua
Cuando una tienda permanece en 7.x o 8.1, la causa habitual son compatibilidades rotas: módulos incompatibles, tema antiguo, overrides frágiles, conectores sin mantenimiento. Mientras eso no se solucione, seguirá dependiendo de una rama que ya no ofrece las mismas garantías de soporte.
En PrestaShop suele ser el momento de revisar los componentes más riesgosos y de detectar un módulo PrestaShop mal codificado antes de mantenerlo en producción. La ganancia no es solo compatibilidad: también reduce el riesgo en próximas actualizaciones.
Qué comprobaciones hacer si ya sospecha una compromisión
Tras parchear, la ausencia de error visible no prueba la ausencia de compromiso. Si su rama PHP estuvo expuesta, haga revisar los logs HTTP y PHP, confirme el modo de ejecución real y evalúe la posible exposición de contraseñas, tokens y claves API presentes en el servidor.
El criterio de decisión es simple: si no puede descartar la exposición de secretos aplicativos, planifique su rotación en el perímetro afectado. Esperar a un síntoma evidente no es buena práctica en un asunto de fuga de memoria.
Cuándo pasar de un parche inmediato a un proyecto de compatibilidad planificado
Si actualizar PHP rompe el sitio, el funnel o la administración, vuelva a modo proyecto una vez contenida la urgencia. Hay que listar incompatibilidades, decidir qué se corrige rápido y qué debe reemplazarse, y luego probar la actualización en un entorno separado antes de volver a producción.
Si su tienda PrestaShop está bloqueada en una rama antigua de PHP, puedo intervenir en soporte PrestaShop puntual o mensual para planificar la subida de versión y asegurar la mantenimiento mensual de una tienda PrestaShop. Diagnóstico gratuito, respuesta en 24 h, presupuesto en 24 h laborables.
Preguntas frecuentes
¿Mi sitio PrestaShop, WordPress o WooCommerce está afectado si yo nunca toco el código PHP directamente?
Sí, potencialmente. PHP2Shell afecta al núcleo de PHP, no solo al código personalizado. Si su sitio ejecuta una rama PHP expuesta, el riesgo existe incluso sin desarrollos propios recientes. El reflejo correcto es comprobar la versión PHP realmente usada por el sitio y confirmar si está corregida o si su proveedor ha publicado un backport documentado.
¿Cómo comprobar la versión real de PHP que usa mi sitio, y no solo la mostrada en la línea de comandos?
En PrestaShop, mire Parámetros avanzados > Información. En WordPress y WooCommerce, vaya a Herramientas > Estado del sitio. Es más fiable para el sitio web que solo ejecutar php -v. En VPS o dedicado, la versión CLI puede diferir del front; cruce la versión vista en el CMS, los paquetes instalados y el comunicado del proveedor.
¿Mi proveedor de hosting compartido ya habrá corregido la falla, o debo actuar yo desde el panel?
Ambas cosas importan. Un hosting compartido puede haber aplicado parches o protecciones en sus clústeres, pero la rama PHP seleccionada para su sitio sigue siendo responsabilidad suya revisar. Si su panel aún mantiene la tienda en 8.1 o una rama más antigua, no suponga que todo está resuelto. Controle la versión usada por el sitio y la comunicación oficial del proveedor.
¿Basta una regla WAF o desactivar session.upload_progress, o debo actualizar PHP igualmente?
Debe actualizar PHP. Los avisos oficiales indican que la actualización es la única opción segura. Un WAF puede reducir el riesgo de forma inmediata y session.upload_progress.enabled=0 puede limitar parte del perímetro de CVE-2026-109619, pero son medidas temporales e incompletas. Sirven para ganar tiempo, no para corregir el motor PHP.
Estoy aún en PHP 8.1, 8.0 o 7.x: ¿sigo siendo vulnerable y existe un parche disponible?
Debe considerar esas ramas en riesgo hasta que un parche o un backport del proveedor se confirme explícitamente. Para 8.1 y versiones anteriores no hay soporte upstream. Pueden existir backports por proveedores para 7.4, 8.0 y 8.1, pero son limitados. En 7.4 no hay anuncios. En una tienda antigua, la dificultad real suele ser la compatibilidad de módulos, tema y conectores.
¿Qué signos simples deben hacerme sospechar una compromisión antes o después del parche?
Todo comportamiento inusual en una tienda expuesta merece revisión, pero la ausencia de síntoma visible no basta para tranquilizar. En PHP2Shell hay riesgo de fuga de memoria. Si su sitio estuvo en una rama vulnerable, haga revisar logs HTTP y PHP, el modo de ejecución real y la posible exposición de contraseñas, tokens y claves API. Si persiste la duda, planifique la rotación de secretos afectados.