# PHP2Shell y Log4Shell: qué tienen en común las vulnerabilidades > PHP2Shell y Log4Shell comparados: qué une las vulnerabilidades, en qué se diferencian y qué lecciones de 2021 pueden aprovechar hoy las empresas. Fuente: https://phpsos.de/es/blog/php2shell-und-log4shell/ Actualizado: 25/10/2026 Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6 **En resumen:** PHP2Shell y Log4Shell tienen en común que son vulnerabilidades críticas en un componente básico muy extendido, mediante las cuales los atacantes pueden ejecutar código sin autenticarse. Se diferencian en la visibilidad, la clasificación y la situación respecto a ataques conocidos. La lección más importante de Log4Shell sigue vigente: quien sabe dónde funciona el componente afectado actúa en horas en lugar de en semanas. ## Por qué la comparación aparece ahora en todas partes En diciembre de 2021, Log4Shell tuvo en vilo al mundo informático durante semanas. El BSI declaró entonces el nivel de alerta más alto, rojo. Casi cinco años después, en muchas publicaciones sobre PHP2Shell aparece el mismo nombre, a menudo con la pregunta: «¿Será otra vez tan grave?» La comparación es obvia y es útil si se hace bien. Muestra qué patrones se repiten y qué experiencias pueden aprovechar directamente las empresas hoy. Cómo clasifica el BSI la situación actual lo explica el artículo [Nivel de alerta naranja del BSI](https://phpsos.de/es/blog/bsi-warnstufe-orange-erklaert/). ## PHP2Shell y Log4Shell comparados directamente | Característica | Log4Shell (2021) | PHP2Shell (2026) | |---|---|---| | Software afectado | biblioteca Java Log4j | el propio entorno de ejecución de PHP | | Identificador | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 | | Puntuación | CVSS 10.0 (v3) | CVSS v4.0 9,2 | | Efecto | ejecución de código sin autenticación | ejecución de código sin autenticación | | Nivel de alerta del BSI | 4 / rojo | 3 / naranja | | Situación en el momento de la alerta | según los informes de entonces, compromisos conocidos | intentos de ataque informados; según el BSI, inicialmente sin ataques exitosos confirmados de forma generalizada | | Visibilidad | a menudo oculta en lo profundo de las aplicaciones | visible en el servidor, pero el nivel de parcheo es difícil de leer por los backports | | Avisos posteriores | varios CVE más en pocas semanas | aviso sobre CVE-2026-115560 el 23 de octubre | ## Qué tienen en común las dos vulnerabilidades **Un componente básico, innumerables aplicaciones.** Log4j estaba en software Java de todo tipo; PHP sostiene WordPress, Shopware, TYPO3 e innumerables desarrollos propios. En ambos casos no está afectado un producto, sino un cimiento. **No hace falta inicio de sesión.** Ambas vulnerabilidades permiten ejecutar código a distancia sin autenticación. Eso las hace atractivas para ataques automatizados. **El parche no es el final.** Con Log4Shell se vio que muchos sistemas ya habían sido atacados antes de la actualización. También con PHP2Shell vale: un parche no elimina el software malicioso introducido. Según los medios, el primer intento de ataque se observó ya el 17 de octubre. **Avisos posteriores.** Tras Log4Shell aparecieron en pocas semanas otros CVE sobre Log4j. En PHP llegó dos días después de los parches el aviso sobre CVE-2026-115560. Por qué son probables más avisos lo explica [Tras PHP2Shell: por qué son probables más avisos](https://phpsos.de/es/blog/weitere-php-meldungen/). ## Dónde cojea la comparación La mayor diferencia está en la visibilidad. Log4j estaba a menudo integrada como parte de una aplicación, a veces con varios niveles de anidamiento. Muchos administradores sencillamente no sabían que la usaban. PHP, en cambio, no es ningún secreto en un servidor web. A cambio, en PHP2Shell surge otra incertidumbre: las distribuciones y los proveedores de alojamiento aplican las correcciones como backport y el número de versión mostrado se mantiene. Se ve PHP, pero no de inmediato si está parcheado. Una segunda diferencia es el punto de partida de la actualización. En Log4Shell, con frecuencia los fabricantes de aplicaciones especializadas tenían que entregar primero versiones nuevas. En PHP2Shell hay actualizaciones disponibles para todas las ramas compatibles. Se complica con PHP 8.1 y anterior, para las que el proyecto PHP ya no publica actualizaciones oficiales. Una tercera diferencia afecta al lugar del ataque. En Log4Shell podía ser peligroso cualquier punto en el que una aplicación registrara entradas, incluidos sistemas internos que solo recibían datos de internet de forma indirecta. En PHP2Shell el centro es el servidor web, que recibe las peticiones directamente. Eso hace algo más manejable la búsqueda de sistemas afectados: primero todos los servicios PHP accesibles públicamente, después las aplicaciones internas. Por último, difiere la situación respecto a la explotación. Para Log4Shell circularon pronto herramientas de ataque sencillas y, según los informes de entonces, los compromisos ya se conocían en el momento de la alerta. En PHP2Shell, Cloudflare y Patchstack informan de intentos de ataque, watchTowr reprodujo una de las vulnerabilidades según sus propias indicaciones y el BSI, inicialmente, no comunicó ataques exitosos confirmados de forma generalizada. Eso puede cambiar. Pero es una razón por la que la comparación no sirve como pronóstico. > **Consejo:** > Aproveche en su propia casa las experiencias de Log4Shell: ¿qué listas, procedimientos y contactos ayudaron entonces? Mucho de ello puede reutilizarse directamente para PHP2Shell. ## Cinco lecciones de Log4Shell que ayudan hoy 1. **Inventario antes que parche:** quien tenía en 2021 una lista actual de sus sistemas fue más rápido. Hoy vale lo mismo. Una guía la ofrece el artículo [Inventario de todos los sitios web y servidores](https://phpsos.de/es/blog/inventar-websites-server/). 2. **Conocer las dependencias:** una lista de materiales de los componentes de software, abreviada SBOM, responde en minutos a la pregunta «¿dónde usamos esto?». Para las aplicaciones PHP ayuda mirar Composer, como describe [Revisar las dependencias de Composer](https://phpsos.de/es/ratgeber/composer-abhaengigkeiten-pruefen/). 3. **Conservar los registros:** tras Log4Shell muchas empresas no pudieron aclarar si estaban afectadas porque faltaban registros. La prensa especializada aconseja con PHP2Shell conservar los registros desde el 20 de octubre. 4. **Revisar a posteriori:** un parche no responde a lo que pasó antes. La búsqueda de indicios forma parte del proceso. 5. **Estar preparado para avisos posteriores:** la primera actualización rara vez es la última. Quien ha dejado bien establecida la vía de actualización la repite con rapidez. ## ¿Cómo ayuda PHP SOS en concreto? - **Inventario:** averiguamos dónde funciona PHP en su empresa, en qué versión y modo de ejecución. - **Parche y reinicio:** aplicamos las actualizaciones y acreditamos el estado de cada sistema. - **Revisión de indicios:** conservamos los registros y buscamos anomalías desde el 17 de octubre. - **Seguimiento permanente:** mantenemos sus sistemas bajo observación para que los avisos posteriores no vuelvan a empezar de cero. Cómo es la supervisión continua lo describe [Monitorización de seguridad para servidores web](https://phpsos.de/es/leistungen/security-monitoring/). ## Conclusión PHP2Shell no es Log4Shell, pero rima con ella. Ambas afectan a un cimiento, ambas requieren más que un parche. Las empresas que se llevaron de 2021 el inventario, la conservación de registros y las vías de actualización tienen hoy ventaja. Para todas las demás, ahora es el momento de ponerse al día. ## Preguntas frecuentes **¿Es PHP2Shell tan grave como Log4Shell?** Ambas son vulnerabilidades críticas en software muy extendido, mediante las cuales los atacantes pueden ejecutar código sin autenticarse. El BSI (Oficina Federal alemana para la Seguridad de la Información) clasificó Log4Shell en 2021 con rojo y PHP2Shell con naranja. Una diferencia importante: en Log4Shell, según los informes de entonces, ya se conocían compromisos en el momento de la alerta; en PHP2Shell, según el BSI, inicialmente no se conocían ataques exitosos confirmados de forma generalizada. **¿Qué fue Log4Shell?** Log4Shell fue una vulnerabilidad crítica de la biblioteca Java Log4j, conocida en diciembre de 2021 y registrada como CVE-2021-44228. Log4j estaba integrada como componente en muchísimas aplicaciones, con frecuencia sin que los administradores lo supieran. **¿Vendrán más vulnerabilidades después de PHP2Shell?** Es posible. Tras Log4Shell siguieron en pocas semanas otros CVE sobre Log4j. En PHP ya hubo el 23 de octubre un aviso sobre CVE-2026-115560, que solo actúa con una configuración inusual. Cuente con avisos posteriores. **¿Qué es un SBOM?** Una Software Bill of Materials es una lista de materiales de todos los componentes de software de los que consta una aplicación. Con ella, ante una vulnerabilidad nueva se puede determinar rápidamente dónde se usa el componente afectado. ## Fuentes - [BSI: Oficina Federal alemana para la Seguridad de la Información](https://www.bsi.bund.de/) - [php.net: avisos de seguridad](https://www.php.net/) - [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)