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. El análisis de Wiz 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 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, 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.

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 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 te sirve de punto de partida.

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. Sigue con los costes ocultos de mantener la web y con CIOs y arquitectura serverless.

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