Impulsando la Experiencia del Día del Socio de Eroski con Servicios Web y Streaming Online
julio 4, 2024
Las vulnerabilidades de PHP conocidas como PHP2Shell permiten ejecutar código en un servidor sin usuario ni contraseña. Afectan a las webs y tiendas online que funcionan con PHP, como WordPress, WooCommerce o PrestaShop, y se corrigen actualizando PHP, no el CMS. En Innotu hemos actualizado servidores propios y de clientes: te contamos qué versiones lo corrigen y qué hacer según dónde esté alojada tu web.
En este artículo
- ¿Qué es PHP2Shell y por qué es tan grave?
- ¿Qué versiones de PHP corrigen estas vulnerabilidades?
- ¿Afecta a WordPress, WooCommerce y PrestaShop?
- ¿Cómo saber si tu web está afectada?
- ¿Cómo actualizar PHP según dónde esté alojada tu web?
- ¿Qué medidas temporales hay si no puedes actualizar todavía?
- CVE-2026-115560: la tercera vulnerabilidad, aún sin parche
- ¿Cómo prepararte para las próximas vulnerabilidades de PHP?
- Preguntas frecuentes
¿Qué es PHP2Shell y por qué es tan grave?
PHP2Shell es el nombre de dos vulnerabilidades críticas del intérprete de PHP, CVE-2026-109618 y CVE-2026-109619. Ambas tienen una puntuación de 9.2 sobre 10 en CVSS v4.0 y permiten que un atacante sin autenticar ejecute código de forma remota en el servidor. El fallo está en PHP, no en tu aplicación, así que afecta aunque tu código esté al día.
CVE-2026-109618 y CVE-2026-109619, explicadas sin tecnicismos
- CVE-2026-109618: cuando falla una reserva de memoria, PHP deja datos no válidos que luego procesa su rutina de limpieza.
- CVE-2026-109619: un proceso de PHP puede reutilizar el estado que dejó una petición anterior.
En los dos casos, quien envía una petición manipulada puede acabar ejecutando comandos con los permisos del servidor web. Afecta a todas las formas habituales de servir PHP: Apache con mod_php, PHP-FPM, php-cgi, FrankenPHP y LiteSpeed.
¿Se están explotando ya?
Sí. Amazon detectó un intento de explotación el 17 de octubre, cuatro días antes de que se hicieran públicas, y Cloudflare vio pasar los intentos de decenas de miles a millones en menos de un día tras la divulgación. La agencia estadounidense CISA las añadió el 26 de octubre a su catálogo de vulnerabilidades explotadas.
En España, INCIBE emitió una alerta de importancia crítica y el CCN-CERT publicó la alerta AL 11/26 el 21 de octubre. En Innotu estamos suscritos a las notificaciones de INCIBE y fue su aviso el que puso en marcha nuestra revisión de servidores. Si gestionas webs, suscribirte a esos avisos es la forma más sencilla de enterarte a tiempo.
¿Qué versiones de PHP corrigen estas vulnerabilidades?
El 21 de octubre de 2026, el proyecto PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen las dos vulnerabilidades. Si tu servidor tiene una versión igual o superior dentro de su rama, está protegido frente a PHP2Shell. Las ramas 8.1 y anteriores no reciben versión oficial corregida.
| Rama de PHP | Versión corregida | Estado de soporte |
|---|---|---|
| 8.5 | 8.5.12 | Con soporte |
| 8.4 | 8.4.27 | Con soporte |
| 8.3 | 8.3.36 | Con soporte |
| 8.2 | 8.2.35 | Fin de soporte el 31 de diciembre de 2026 |
| 8.1 y anteriores | Sin versión oficial | Sin soporte del proyecto PHP |
Fuente: aviso de seguridad de php.net.
¿Qué pasa si tu web usa PHP 8.1 o anterior?
No hay versión oficial. El proyecto PHP ha publicado ajustes mínimos del código fuente para 7.4, 8.0 y 8.1, y muchas distribuciones de Linux y proveedores de hosting ofrecen paquetes ya corregidos. Lo primero es confirmar con tu proveedor si tu PHP lleva esa corrección. A medio plazo, la salida segura es subir a una rama con soporte.
No es un caso aislado: según las estadísticas de WordPress.org del 22 de octubre, el 35,8 % de las webs WordPress funcionan con PHP 8.1 o anterior.
¿Afecta a WordPress, WooCommerce y PrestaShop?
Sí, porque los tres se ejecutan sobre PHP. Los investigadores de Wiz demostraron la ejecución remota de código sin autenticación contra WordPress, Drupal y Joomla. La corrección no depende del CMS: hay que actualizar PHP en el servidor. Una tienda WooCommerce o PrestaShop con todos sus módulos al día sigue expuesta si su PHP no está parcheado.
Por qué actualizar el CMS o los plugins no es suficiente
WordPress ha confirmado que no necesita ni prepara ninguna actualización para corregir estos fallos. Los plugins y módulos de seguridad tampoco protegen: el ataque se produce mientras PHP lee la petición, antes de que carguen WordPress, PrestaShop o cualquier extensión. Desconfía de cualquier plugin o fragmento de código que prometa «arreglar» PHP2Shell.
Si tu web es un desarrollo web en WordPress o una tienda con WooCommerce, lo que tienes que revisar es la versión de PHP de tu alojamiento.
El caso de PrestaShop 8: atado a PHP 8.1
Es el escenario más delicado. PrestaShop 1.7.8 funciona con PHP 7.1 a 7.4, y PrestaShop 8.0 a 8.2 con PHP 7.2 a 8.1: ninguna de esas ramas de PHP tiene versión oficial corregida. PrestaShop 9 ya admite de PHP 8.1 a 8.5, así que, para muchas tiendas, pasar a un PHP con soporte implica migrar antes a PrestaShop 9.
Nuestra experiencia
Hemos tenido que decidir tienda por tienda:
- Donde la tienda estaba preparada, la hemos migrado a PrestaShop 9 y subido PHP a una versión corregida.
- Donde la migración no podía hacerse de inmediato, hemos aplicado las medidas temporales del aviso (límite de memoria fijado en el servidor y reglas de cortafuegos de aplicación) mientras planificamos la actualización.
Es el mismo orden que recomienda PrestaShop: asegurar primero un PHP corregido o mitigado, porque una migración de versión mayor no debe hacerse con prisas.
¿Qué frena la migración a PrestaShop 9? En nuestra experiencia, sobre todo dos cosas:
- Integraciones con ERP: suelen ser desarrollos específicos y hay que probarlos a fondo antes de cambiar de versión.
- Módulos de pago sin actualizar: son críticos para el negocio y no siempre tienen versión compatible. En algunos casos los adaptamos nosotros mismos.
Si tu tienda está en esta situación, en Innotu trabajamos tiendas online con PrestaShop y podemos valorar contigo la migración.
¿Cómo saber si tu web está afectada?
Tu web está afectada si funciona con una versión de PHP anterior a la corregida de su rama, o con PHP 8.1 o anterior sin un paquete parcheado de tu proveedor. Comprobarlo lleva pocos minutos, y después conviene revisar si hubo actividad sospechosa antes de actualizar.
- Mira tu versión de PHP. En WordPress, en Herramientas → Salud del sitio → Información → Servidor. En PrestaShop, en Parámetros avanzados → Información. En Plesk, en el panel del dominio, junto al icono de PHP.
- Compárala con la tabla de versiones corregidas.
- Si tienes hosting gestionado, pide confirmación por escrito de que el parche está aplicado en tu dominio y de que se han reiniciado los procesos de PHP.
- Revisa si hubo actividad sospechosa antes de parchear. La actualización cierra la puerta, pero no deshace un acceso previo.
Para descartar intrusiones, en los servidores que gestionamos hemos combinado tres revisiones:
- Registros (logs) del servidor web y de PHP, buscando peticiones anómalas y procesos inesperados lanzados por PHP.
- Antivirus de servidor tipo Imunify, para detectar ficheros maliciosos o webshells.
- Revisión manual de archivos, centrada en ficheros PHP modificados recientemente o creados en carpetas de subida.
¿Cómo actualizar PHP según dónde esté alojada tu web?
Quién actualiza PHP depende del tipo de alojamiento: en un hosting compartido lo hace el proveedor; en un VPS o servidor dedicado, quien lo administra; en contenedores, hay que reconstruir la imagen. En todos los casos, después de actualizar hay que reiniciar los procesos de PHP para que el cambio surta efecto.
| Tipo de alojamiento | Quién actualiza PHP | Qué debes comprobar |
|---|---|---|
| Hosting compartido | El proveedor | Versión de PHP en tu panel y confirmación del proveedor |
| VPS con Plesk o cPanel | Tú o tu equipo técnico | Versión de PHP del panel actualizada y PHP-FPM reiniciado |
| VPS o servidor sin panel | Tú o tu equipo técnico | Paquetes del sistema actualizados a mano y servicios reiniciados |
| Servidor dedicado gestionado por el cliente | Su equipo de sistemas | Coordinación previa: ventana de actualización y pruebas posteriores |
| Contenedores Docker o Kubernetes con PHP | Quien mantiene la imagen | Reconstruir con la imagen base corregida y volver a desplegar; reiniciar no basta |
| Productos de terceros que incluyen PHP | El fabricante | Avisos de seguridad del fabricante |
Así lo hemos aplicado
- Nuestro VPS con Plesk y los VPS de clientes con Plesk: actualización de PHP desde el panel y reinicio de procesos.
- VPS de clientes sin panel: actualizaciones manuales de los paquetes de PHP.
- Hosting compartido de distintos clientes en proveedores como Hostalia, OVH o Dinahosting: revisión de la versión de PHP de cada web y comprobación de que el proveedor había aplicado el parche.
- Servidores dedicados de clientes: coordinación con sus equipos para actualizar y probar sin cortar el servicio.
Si trabajas con Docker o Kubernetes y tus contenedores usan imágenes de PHP, revisa también las imágenes antiguas que sigan desplegadas en entornos de pruebas o preproducción.
¿Qué medidas temporales hay si no puedes actualizar todavía?
Hay mitigaciones que reducen el riesgo mientras preparas la actualización, pero ninguna lo elimina. Úsalas solo como puente y pruébalas antes en un entorno de pruebas.
Importante: un desarrollador del núcleo de PHP advirtió de que ninguna mitigación bloquea por completo los ataques y de que el parche oficial es la única defensa permanente.
Las recomendadas en el aviso de PHP son:
- Para CVE-2026-109618: fijar
memory_limit=-1de forma que la aplicación no pueda cambiarlo, por ejemplo conphp_admin_valueen el pool de PHP-FPM o en la configuración de Apache. Esto elimina el límite de memoria por proceso, así que vigila el consumo del servidor. - Para CVE-2026-109619: poner
session.upload_progress.enabled=0y reiniciar todos los procesos; en PHP 8.5, además,fatal_error_backtraces=0. - Cortafuegos de aplicación (WAF) en el CDN, el proxy o el servidor, con reglas que filtren los patrones de ataque conocidos.
Es la combinación que hemos usado en las tiendas PrestaShop 8 que no podían migrar de inmediato, siempre con la migración ya planificada.
CVE-2026-115560: la tercera vulnerabilidad, aún sin parche
El 23 de octubre, PHP publicó un aviso sobre CVE-2026-115560, una vulnerabilidad de ejecución remota de código que solo afecta a aplicaciones con una configuración poco habitual y que el proyecto considera un riesgo improbable. Las versiones del 21 de octubre no la corrigen. No se ha informado de ataques que la exploten.
La vulnerabilidad aparece por una combinación poco frecuente entre la serialización de sesiones y el progreso de subida de sesión de PHP. PHP la corregirá en su próxima actualización ordinaria y, hasta entonces, recomienda desactivar el progreso de subida (session.upload_progress.enabled=0). Si ya lo desactivaste para CVE-2026-109619, mantén esa configuración.
¿Cómo prepararte para las próximas vulnerabilidades de PHP?
La mejor protección es no llegar tarde a la siguiente: saber qué versión de PHP tiene cada web, mantenerla en una rama con soporte y tener un procedimiento de actualización ya probado. Con eso, una alerta como PHP2Shell se resuelve en horas; sin eso, obliga a improvisar migraciones con prisa.
- Haz inventario. Anota qué versión de PHP tiene cada web, tienda o aplicación, dónde está alojada y quién la mantiene.
- No des por hecho que tu hosting te cubre. En un VPS o en un servidor dedicado, actualizar PHP no es tarea del proveedor. Incluso en hosting compartido, pide confirmación.
- Vigila el calendario de soporte. PHP 8.2 tiene parche, pero deja de recibir actualizaciones de seguridad el 31 de diciembre de 2026. Si estás en 8.2, planifica ya el salto a 8.3 o superior.
- No acumules versiones de retraso en el CMS. Una tienda en PrestaShop 8 o una web WordPress con plugins abandonados limita las versiones de PHP que puedes usar.
- Prueba antes en un entorno de pruebas. Subir de versión de PHP puede romper plugins, módulos o integraciones antiguas.
- Suscríbete a los avisos de INCIBE. Son gratuitos y te avisan de alertas críticas como esta.
- Aprovecha la actualización. Las versiones recientes de PHP suelen rendir mejor; puedes combinarla con una optimización de velocidad web (WPO).
Preguntas frecuentes
¿Basta con actualizar WordPress o PrestaShop para protegerme de PHP2Shell?
No. El fallo está en PHP, el software que ejecuta el CMS en el servidor. Actualizar el CMS, el tema o los módulos es buena práctica, pero no corrige estas vulnerabilidades.
¿Cómo sé si mi hosting ya ha actualizado PHP?
Comprueba la versión de PHP en tu panel o en la información del sistema de tu CMS y compárala con las versiones corregidas: 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Si tienes hosting gestionado, pide confirmación por escrito.
¿Un plugin de seguridad me protege de PHP2Shell?
No. El ataque ocurre antes de que se carguen el CMS y sus plugins. Un cortafuegos externo puede filtrar parte de las peticiones, pero no sustituye al parche.
Mi tienda está en PrestaShop 8, ¿qué hago?
Pregunta a tu hosting si tu PHP lleva un paquete parcheado y aplica las medidas temporales mientras tanto. A medio plazo, lo recomendable es migrar a PrestaShop 9 para poder usar una versión de PHP con soporte.
¿Me han podido atacar antes de actualizar?
Es posible, porque hubo intentos de explotación antes de la divulgación. Después de parchear, revisa registros, ficheros modificados y pasa un antivirus de servidor, o pide a tu equipo técnico que lo haga.
¿Tu web o tu tienda online sigue en una versión de PHP sin soporte, o no sabes en cuál está?
Revisamos contigo qué versión usa, quién debe actualizarla y qué opciones tienes si tu CMS no admite una versión con soporte.
Si prefieres escribirnos, contacta con nosotros.
Fuentes
- Aviso de seguridad de PHP, 21 de octubre de 2026
- Aviso de INCIBE-CERT: múltiples vulnerabilidades en PHP
- Alerta CCN-CERT AL 11/26: actualización inmediata de vulnerabilidad crítica en PHP
- Alerta de CISA sobre las vulnerabilidades críticas de PHP
- Comunicado de PrestaShop: Critical PHP security updates (21/10/2026)
