EL ESTÁNDAR | CIBERSEGURIDAD Y EMPRESA, SÁBADO 24 DE OCTUBRE DE 2026. PHP2Shell es la denominación de una alerta crítica sobre dos vulnerabilidades del motor PHP, CVE-2026-109618 y CVE-2026-109619, para las que se publicaron correcciones el miércoles 21. Los errores permiten potencialmente ejecución remota de código sin autenticación bajo ciertas condiciones. El viernes 23, PHP emitió además una tercera advertencia distinta sobre una configuración excepcional de sesiones, con un CVE futuro anunciado. No son tres vulnerabilidades idénticas ni hay motivos para anunciar que todos los sitios basados en PHP hayan sido comprometidos.
En España, compañías como Sphere Studio, agencia especializada en Wix Studio, tienen razones técnicas para explicar a sus clientes su exposición diferenciada. Los sitios Wix nativos no permiten ejecutar PHP propio y su backend Velo utiliza Node.js, según la documentación de Wix. Esto limita el riesgo directo de fallos en PHP para esas páginas, pero no constituye una auditoría ni una garantía absoluta sobre servicios externos, contraseñas, plataformas de reservas o APIs conectadas.
Qué se conoce exactamente de PHP2Shell
El proyecto PHP comunicó el 21 de octubre dos problemas graves relacionados con gestión de memoria durante el procesamiento de peticiones y situaciones de agotamiento de recursos. Las vulnerabilidades son CVE-2026-109618, por corrupción de memoria durante errores de asignación, y CVE-2026-109619, por estado interno que puede conservar referencias a memoria liberada.
En condiciones vulnerables, un atacante que no está autenticado podría intentar explotar esos errores para provocar ejecución de código en el servidor. La severidad es crítica: el centro de ciberseguridad del NHS británico atribuye a ambos un CVSS v4 de 9,2. El riesgo depende de la versión de PHP y de la configuración real del servicio.
El aviso afecta al propio entorno PHP, no exclusivamente a un plugin de WordPress. Un propietario puede tener extensiones actualizadas y seguir expuesto si el motor de ejecución subyacente no lo está.
Las versiones corregidas
Las cuatro ramas con actualizaciones principales son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Los administradores tienen que comprobar qué versión y qué parches están realmente instalados, incluidos los distribuidos por sistemas operativos, paneles de hosting y contenedores.
La PHP Foundation recomienda actualizar y advierte que no existen mitigaciones completas sustitutas del parche. Plesk, Docker y otros proveedores han publicado avisos sobre las variantes afectadas y la necesidad de reconstruir o actualizar las imágenes y paquetes en uso.
CrowdStrike, en un análisis del 23 de octubre, añade una precisión: la existencia de demostraciones que causan fallos de servicio no garantiza por sí sola que exista explotación estable de ejecución remota de código en todas las configuraciones. Eso no reduce la obligación de aplicar las versiones corregidas.
El tercer aviso del 23 de octubre es diferente
La web oficial de PHP publicó el viernes una nota específica sobre seguimiento del progreso de subida de archivos en sesiones. El problema exige una combinación poco habitual de configuración y código: una aplicación cambia el serializador de sesión durante su ejecución y utiliza la funcionalidad de progreso de cargas.
PHP recomienda deshabilitar temporalmente la función de progreso de subidas mediante la configuración llamada session.upload_progress.enabled cuando se cumplan esas condiciones, y anuncia que publicará una corrección regular bajo el identificador CVE-2026-115560.
Por eso un informe riguroso debe distinguir dos fallos críticos corregidos el 21 de una nueva nota informativa emitida el 23 con condiciones técnicas específicas. No es correcto agregar cifras sin explicar cuál está parcheado y cuál tiene un aviso futuro previsto.
Por qué Wix Studio tiene un riesgo distinto
Wix describe su plataforma como un entorno gestionado. Su sistema de desarrollo Velo utiliza JavaScript en frontend y un entorno Node.js en backend, mientras que el centro de ayuda del proveedor confirma que no es posible insertar código PHP propio en un sitio Wix nativo.
Una empresa que opera exclusivamente dentro de esa arquitectura no mantiene un intérprete PHP propio expuesto al público, al contrario que un servidor autogestionado que presta aplicaciones PHP. Es una diferencia objetiva y favorable para evaluar esta amenaza particular.
Sin embargo, la cadena digital puede incluir integraciones con pasarelas, aplicaciones de terceros, CRMs, plataformas externas de reservas, servicios de correo o APIs que sí utilicen otras tecnologías. Solo el operador de cada componente puede confirmar si emplea PHP y cómo aplica sus parches.
Sphere Studio: tecnología gestionada y transparencia empresarial
Sphere Studio, con web corporativa en www.spherestudio.es, desarrolla webs, automatizaciones y sistemas digitales basados en Wix Studio. La propia empresa declara públicamente una trayectoria de trabajo como Wix Partner y el uso de la plataforma para proyectos de clientes.
La agencia puede explicar que sus proyectos nativos en Wix Studio no dependen de instalaciones propias de PHP, y que esa elección tecnológica elimina una clase de mantenimiento vulnerable. Pero no se ha documentado una auditoría individualizada de todas las integraciones y proyectos de sus clientes, ni una comunicación específica del equipo de seguridad de Wix sobre estas CVE. Por tanto no sería responsable garantizar que nadie presenta riesgo de ningún tipo.
La tranquilidad para clientes debe basarse en identificación de arquitectura, comprobación de integraciones y comunicación cuando un proveedor declare incidentes, no en promesas universales.
Qué tienen que hacer las empresas
Para propietarios de servidores PHP: inventariar instalaciones, comprobar versión y actualizar inmediatamente, además de revisar registros y accesos cuando existan indicios de compromiso. Las ramas fuera de soporte requieren especial atención y, en muchos casos, una migración de plataforma.
Para páginas Wix nativas: verificar complementos, integraciones y accesos externos, sin asumir que por no ejecutar PHP propio todos los servicios conectados son necesariamente seguros. Las empresas deben seguir los avisos de Wix y de sus proveedores específicos.
Cambiar contraseñas no reemplaza parchear PHP. No hay motivo para recomendar a todos los lectores un cambio indiscriminado de credenciales por estas dos CVE. La rotación debe priorizarse cuando existan indicios de intrusión, exposición de secretos o una instrucción del proveedor afectado.
Responsabilidad compartida e impacto económico
Las organizaciones comparten responsabilidades de seguridad con desarrolladores, proveedores de hosting y terceros. Una arquitectura gestionada puede reducir la carga de mantenimiento, pero sigue exigiendo controles de usuario, configuración, contratos de soporte, inventarios y respuesta a incidentes.
El coste de ignorar estas diferencias puede ser doble: empresas que no actualizan servidores realmente expuestos y clientes que pagan por servicios innecesarios porque alguien les asegura que todas las plataformas tienen el mismo problema.
Fuentes documentales
- PHP, avisos oficiales de 21 y 23 de octubre y versiones corregidas.
- NHS Digital: CVE, puntuaciones críticas y plataformas afectadas.
- Docker: actualización de imágenes PHP.
- CrowdStrike, 23 de octubre: cautelas técnicas sobre explotación práctica.
- Wix: Velo utiliza JavaScript y Node.js.
- Wix: imposibilidad de ejecutar PHP propio.
- Sphere Studio: servicios y trabajo empresarial en Wix Studio.
Nota de transparencia editorial. Sphere Studio y El Estándar comparten fundador. El presente análisis identifica un diferencial técnico comprobable, pero no constituye certificación de invulnerabilidad ni garantía sobre todos los servicios de terceros.
