# Quién parchea qué: las capas de tu web que ningún plugin controla > PHP2Shell (CVE-2026-109618/109619) no se corrige actualizando el CMS. El mapa de las cuatro capas de tu web universitaria y quién parchea cada una. **URL:** https://griddo.io/journal/quien-parchea-php2shell-universidad/ **Language:** Español **Publicado:** 2026-10-27 **Actualizado:** 2026-10-27 **Autor:** Daniel Serrano **Etiquetas:** security, architecture --- ## Puntos Clave - **El fallo está en PHP, no en el CMS:** actualizar WordPress o Drupal no corrige un error del intérprete que los ejecuta. - **El mapa de cuatro capas:** aplicación, intérprete, servidor y código por petición — el responsable de cada una cambia según tu modelo de alojamiento. - **Seis preguntas para tu proveedor:** qué versión de PHP sirve cada site, quién la actualiza y qué se revisa después del parche. --- El 21 de octubre de 2026 PHP publicó parches para dos fallos críticos, CVE-2026-109618 y CVE-2026-109619, conocidos como PHP2Shell. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35, según [el aviso de seguridad de PHP](https://www.php.net/archive/2026.php). [El análisis de Wiz](https://wiz.io/blog/php2shell-php-rce) sitúa la gravedad hasta CVSS 9,2. Además, demostró ejecución remota de código sin autenticación en WordPress, Drupal y Joomla. Si diriges TI en una universidad, la pregunta útil es otra: qué capas tiene tu web y quién parchea cada una. ## Por qué actualizar el CMS no basta El fallo está en PHP, no en las aplicaciones. PHP es el intérprete que ejecuta el CMS. Actualizar el CMS no corrige un fallo del intérprete. Wiz lo resume así: aplicar la actualización de seguridad de PHP es la única corrección completa. Drupal coincide. Su [aviso PSA-2026-10-20](https://www.drupal.org/psa-2026-10-20) dice que actualizar a una versión de PHP con el parche es la única mitigación completa. El alcance es amplio. Según Wiz, casi todas las versiones de PHP sufren al menos uno de los fallos, hasta PHP 5.4. Según VirusTotal, citado por [el blog de Recorded Future](https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation), unos 5,1 millones de direcciones IP ejecutan PHP. Solo unos 1,1 millones declaran su versión. Es una cifra de exposición, no de sites vulnerables. Drupal añade un recordatorio de responsabilidad. Si tu host gestiona PHP, sigue sus comunicaciones para saber plazos y acciones. Y la seguridad de la plataforma de alojamiento sigue siendo del propietario del site. #### Qué se sabe de la explotación (a 27/10/2026) El 26 de octubre de 2026, [CISA añadió los dos fallos](https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog) a su catálogo de vulnerabilidades explotadas (KEV), que exige pruebas de explotación. Amazon identificó un intento del 17 de octubre de 2026, según [su blog de seguridad](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/). Cloudflare también veía intentos antes del parche, según [SecurityWeek](https://www.securityweek.com/php2shell-exploitation-started-days-before-patches/). El 24 de octubre, un investigador informó de que unos atacantes ejecutaron comandos en sus honeypots, configurados para favorecer el exploit. A 27 de octubre de 2026, ninguna fuente consultada informa de un ataque con éxito contra sistemas en producción. Este dato caduca rápido: fíjate en la fecha de actualización de este artículo. ## El mapa de capas: quién parchea qué Una web universitaria apila cuatro capas. El responsable de cada una cambia según cómo la alojes. | Capa | Autoalojado | Hosting gestionado o agencia | Griddo | |------|-------------|------------------------------|--------| | Aplicación (CMS y extensiones) | Tu equipo | Quien indique el contrato: confírmalo | La web pública se genera como HTML estático en el build | | Intérprete (PHP) | Tu equipo | Tu host, si gestiona PHP: pregúntale | Griddo no se ejecuta sobre PHP ni .NET. Backend en Node.js y TypeScript | | Servidor | Tu equipo | Tu host o tu agencia | HTML estático distribuido por una CDN global. El front se despliega en la infraestructura que elija la universidad | | Código por petición | Tu equipo | Quien gestione la aplicación | Griddo no usa SSR ni DSG. Arquitectura API-first y headless, sobre infraestructura serverless en el edge | Un plugin vive solo en la primera fila. Los fallos de PHP2Shell viven en la segunda. ## Paso 0: un registro de sites Antes de preguntar a nadie, necesitas saber qué sites tienes. Un registro con propietario, versión de PHP y nivel de riesgo de cada uno. La escala sorprende. [El blog de la Universidad de Edimburgo](https://blogs.ed.ac.uk/website-communications/2117-websites-and-counting-welcome-to-our-wild-west-web-estate/) contaba 2.117 sites el 16 de octubre de 2026. Es un censo anterior a PHP2Shell, pero muestra el tamaño que puede alcanzar un patrimonio web universitario. Sin registro no hay respuesta a la primera pregunta de abajo. Si gestionas muchos sites, nuestra guía sobre [multisite y gobernanza digital](/journal/gestion-multisite-universidades-gobernanza-web/) te sirve de punto de partida. #### Seis preguntas para tu host o proveedor 1. **¿Qué versión de PHP sirve cada site?** Las ramas corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Pide la versión exacta, site a site. 2. **¿Qué rama tiene soporte y qué plan hay para PHP 8.1 y anteriores?** Ya no reciben actualizaciones del proyecto PHP. Hay backports mínimos de código fuente para 7.4, 8.0 y 8.1; PHP remite a distribuciones y proveedores LTS. Pregunta cuál de esas vías usa tu proveedor. Para el coste de quedarse en una versión, lee [Version lock-in](/journal/mito-vendor-lockin-vs-realidad-version-lockin/). 3. **¿Quién instala el parche, cuándo y quién reinicia los procesos?** El aviso de PHP pide reiniciar los workers solo para las mitigaciones por configuración. Laravel Forge documenta que su actualización reinicia PHP-FPM; los procesos de larga duración lanzados desde CLI siguen con la versión antigua hasta reiniciarse. Pregunta a tu proveedor cómo lo resuelve. 4. **¿Qué inventario de sites tiene?** Compáralo con el tuyo. Cada diferencia es un site sin dueño claro. 5. **¿Se puede cortar el tráfico antes de PHP?** Pregunta si el CDN o el balanceador lo permiten mientras llega el parche. 6. **¿Qué se revisa tras parchear?** Amazon recomienda investigar como mínimo desde el 17 de octubre de 2026. Pide qué comprobaciones hará tu proveedor y qué evidencia te entregará. ## Qué hace Griddo El backend de Griddo usa Node.js y TypeScript. Griddo no se ejecuta sobre PHP ni .NET. Griddo opera con el modelo SSG. Genera HTML estático en el build y lo distribuye por una CDN global. No usa SSR ni DSG. Griddo declara el despliegue del front estático en AWS (S3 + CDN + WAF). La universidad elige dónde se despliega: Cloudflare Pages, Amazon S3 + CloudFront + WAF o autoalojado. La arquitectura es API-first y headless, desplegada en el edge sobre infraestructura serverless. En el modelo Griddo Cloud, Griddo gestiona toda la infraestructura AWS. El parcheo también cambia de manos según el modelo. En Enterprise, con contrato AWS propio de la universidad, Griddo gestiona despliegue, monitorización y parches. Nuestra documentación no detalla qué componentes cubre el parcheo: pide ese alcance por escrito. Si tienes varios sites, Griddo permite gestionarlos desde un único panel. Encaja con el paso 0: un solo lugar donde ver tus sites. Aun así, revisa cada capa de tu web. Escribimos sobre quién parchea una web universitaria desde julio de 2025. Para el contexto, empieza por [La Crisis de Vulnerabilidades del CMS](/journal/crisis-vulnerabilidades-cms-universidades/). Sigue con los [costes ocultos de mantener la web](/journal/costes-ocultos-de-wordpress-en-tu-universidad/) y con [CIOs y arquitectura serverless](/journal/cio-universidad-ventaja-competitiva/). ## El siguiente paso PHP2Shell se parchea en una capa que el CMS no controla. Pregunta a cada proveedor quién es responsable de la suya, y deja las respuestas por escrito. [Solicita una Revisión de Seguridad Arquitectónica](/demo/) ## Fuentes [Aviso de seguridad de PHP](https://www.php.net/archive/2026.php) | [Análisis de Wiz sobre PHP2Shell](https://wiz.io/blog/php2shell-php-rce) | [Aviso PSA-2026-10-20 de Drupal](https://www.drupal.org/psa-2026-10-20) | [Blog de Recorded Future](https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation) | [SecurityWeek](https://www.securityweek.com/php2shell-exploitation-started-days-before-patches/) | [Catálogo KEV de CISA](https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog) | [Blog de seguridad de Amazon](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) | [Blog de la Universidad de Edimburgo](https://blogs.ed.ac.uk/website-communications/2117-websites-and-counting-welcome-to-our-wild-west-web-estate/) --- ## Preguntas frecuentes ### ¿Qué es PHP2Shell? Es el nombre de dos fallos críticos de PHP, CVE-2026-109618 y CVE-2026-109619, corregidos el 21 de octubre de 2026. Wiz sitúa su gravedad hasta CVSS 9,2. ### ¿Basta con actualizar mi CMS? No. Actualizar el CMS no corrige un fallo del intérprete que lo ejecuta. Según Wiz y Drupal, hace falta actualizar PHP. ### ¿Se está explotando ya? Sí. El 26 de octubre de 2026, CISA añadió los dos fallos a su catálogo de vulnerabilidades explotadas conocidas (KEV). A 27 de octubre de 2026, ninguna fuente consultada informa de un ataque con éxito contra sistemas en producción. Este dato caduca rápido: revisa la fecha de actualización de este artículo. ### ¿Qué hago si un site usa PHP 8.1 o anterior? Esas versiones ya no reciben actualizaciones del proyecto PHP, aunque existen backports mínimos de código fuente. Consulta a tu proveedor o planifica el salto a una versión con soporte. ### ¿Cómo se genera la web pública en Griddo? Se genera como HTML estático en el build y se distribuye por una CDN global. Griddo no usa SSR ni DSG, y tampoco se ejecuta sobre PHP ni .NET. ### ¿Quién parchea en Griddo? Depende del modelo. En Enterprise, con contrato AWS propio de la universidad, Griddo gestiona despliegue, monitorización y parches. En Griddo Cloud, Griddo gestiona toda la infraestructura AWS. Pide por escrito qué componentes cubre el parcheo en tu caso. ### ¿Puedo gestionar todos mis sites desde un solo sitio? Sí. Griddo permite gestionar cualquier número de sites desde un único panel, aunque eso no sustituye revisar cada capa de tu infraestructura. --- *Generado desde [Quién parchea qué: las capas de tu web que ningún plugin controla](https://griddo.io/journal/quien-parchea-php2shell-universidad/)*