Preguntas frecuentes
Respuestas breves. Encontrará más detalle en las páginas de conocimiento enlazadas.
¿Qué es PHP2Shell?
PHP2Shell designa dos vulnerabilidades críticas en el propio PHP (CVE-2026-109618 y CVE-2026-109619, CVSS 9.2). Pueden permitir a los atacantes ejecutar código malicioso en el servidor sin autenticación. Hay parches desde el 21/10/2026.
¿Qué versiones de PHP son seguras?
Las correcciones están incluidas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Algunos proveedores de hosting y distribuciones incorporan backports sin cambiar el número de versión. Lo decisivo es el estado del paquete o la confirmación por escrito del proveedor.
¿Basta con actualizar WordPress o la tienda online?
No. La vulnerabilidad está en PHP, no en el CMS. Una actualización del CMS no la cierra. Y un parche de PHP no elimina el código malicioso que se haya introducido antes.
¿Con qué rapidez pueden ayudarnos?
Trabajamos en remoto y empezamos en cuanto disponemos de los accesos. Escríbanos por WhatsApp indicando el sistema, la versión de PHP y lo que ha observado. Así acordamos directamente cómo proceder.
¿Trabajan también para agencias y clientes de proveedores de hosting?
Sí. Trabajamos directamente para empresas, en segundo plano por encargo de agencias y en coordinación con su proveedor de hosting cuando es este quien gestiona el servidor.
¿Tenemos que notificar el incidente?
Si pueden verse afectados datos personales, el art. 33 del RGPD establece, por regla general, un plazo de notificación de 72 horas desde que se tiene conocimiento. Si es aplicable, debe aclararlo con su delegado de protección de datos. Nosotros aportamos la documentación técnica.
¿Es PHP2Shell una vulnerabilidad de WordPress?
No. Las vulnerabilidades están en PHP, es decir, en el lenguaje de programación sobre el que funcionan WordPress, Shopware, TYPO3 y muchos otros sistemas. Por eso, una actualización del CMS no las cierra. Lo decisivo es la versión de PHP en el servidor.
Como cliente de un proveedor de hosting, ¿tengo que hacer algo yo mismo?
En el hosting compartido, por lo general es el proveedor quien instala la actualización de PHP. Aun así, conviene que le confirme por escrito que la versión de PHP que usted utiliza ha sido parcheada y reiniciada. La actualización no responde a la pregunta de si antes del parche ocurrió algo.
¿De dónde viene el nombre PHP2Shell?
El nombre describe la consecuencia: a través de PHP, en el peor de los casos, un atacante puede obtener en el servidor una línea de comandos, es decir, una shell. Las denominaciones oficiales son los números CVE-2026-109618 y CVE-2026-109619.
¿Ha sido atacado mi sitio web si se ha desconectado de la red?
No necesariamente. Algunos proveedores desconectaron sitios web por precaución, como recomienda el BSI cuando una actualización no es posible de inmediato. Es una medida de protección y no una prueba de un ataque.
¿Basta con que mi proveedor de hosting haya actualizado PHP?
Puede bastar si el proveedor confirma por escrito el estado del paquete y se han reiniciado todos los procesos de PHP. El número de versión que se muestra no es una prueba por sí solo, porque las distribuciones incorporan backports. Además, un parche no responde a la pregunta de si el servidor ya había sido atacado antes.
¿Tiene que quedar mi sitio web fuera de línea para recibir la ayuda inmediata?
No necesariamente. El BSI recomienda desconectar temporalmente los servidores web de la red cuando la actualización no sea posible de inmediato. Si en su caso es necesario, lo decidimos juntos tras el inventario.
¿Protege una actualización de WordPress o de Shopware frente a PHP2Shell?
No. PHP2Shell está en el propio PHP, no en el CMS. Actualizar el CMS sigue siendo conveniente, pero no cierra esta vulnerabilidad.
¿Qué ocurre con PHP 8.1 o anteriores?
Para estas versiones el proyecto PHP ya no ofrece actualizaciones oficiales, solo backports mínimos de código fuente para 7.4, 8.0 y 8.1. Protegemos el servidor con medidas provisionales y planificamos con usted el paso a una versión con soporte.
¿Desde cuándo corren las 72 horas?
Según el art. 33 del RGPD, desde el momento en que el responsable ha tenido conocimiento de la violación. Cuándo debe entenderse así en el caso concreto es una valoración jurídica. Por eso documente con exactitud cuándo tuvo quién qué información.
¿Hay que notificar cada vulnerabilidad de seguridad?
No. Una vulnerabilidad por sí sola todavía no es una violación de la seguridad de los datos personales. La notificación puede ser obligatoria cuando hay indicios de que personas no autorizadas tuvieron o pudieron tener acceso a esos datos y de ello resulta un riesgo para los afectados.
¿Y si pasadas las 72 horas todavía no lo sé todo?
El art. 33, apartado 4, del RGPD permite facilitar la información por fases cuando no sea posible facilitarla toda al mismo tiempo. Una notificación tardía debe justificarse. Esperar a tener total claridad no es, por tanto, por lo general, motivo para dejar pasar el plazo.
¿Quién notifica si se vio afectado el proveedor de hosting?
Está obligado a notificar el responsable del tratamiento, es decir, por lo general la empresa que opera el sitio web. Un encargado del tratamiento, como el proveedor de hosting, debe informar sin dilación al responsable según el art. 33, apartado 2, del RGPD.
¿Dónde notifico una brecha de datos?
A la autoridad de control de protección de datos competente; para las empresas, normalmente la del Estado miembro (en Alemania, la del estado federado) en el que tienen su sede. La mayoría de las autoridades ofrecen formularios en línea para ello.
Cada hora cuenta. Escríbanos ahora.
Describa brevemente el sistema, la versión de PHP y lo que ha observado. Nos pondremos en contacto, aclararemos la situación y trabajaremos en remoto hasta que el incidente quede cerrado y documentado.