Alerta mundial pone en riesgo a las Universidades

IRESUMEN

El Observatorio de Educación Superior por encargo de la Asociación Nacional de Universidades Públicas del Perú (ANUPP) ha realizado un Informe Técnico sobre la “Alerta Mundial ante el fallo crítico de PHP”.

En los últimos días se han conocido dos fallas críticas en PHP, uno de los lenguajes más utilizados para construir páginas y aplicaciones web. Las vulnerabilidades identificadas pueden permitir que un atacante remoto ejecute códigos en un servidor sin necesidad de contar previamente con usuario o contraseña. También pueden exponer información sensible almacenada temporalmente en la memoria del sistema (Betz & Popa, 2026).

El problema es relevante porque PHP está detrás de una parte importante de Internet y es utilizado directa o indirectamente por plataformas como WordPress, Drupal, Joomla, Laravel y otros sistemas de gestión de contenidos. El riesgo depende de la versión instalada, de la configuración del servidor y de las medidas de protección existentes (NHS England Digital, 2026).

El problema se agrava al reportarse intentos de uso de información sensible identificados incluso antes de hacerse público. Esto muestra que, en la actualidad, el tiempo entre la publicación de una vulnerabilidad y los primeros intentos de aprovecharla puede ser muy corto (Amazon Web Services, 2026).

En ciberseguridad, un sistema que aparentemente funciona con normalidad, pero que no recibe actualizaciones, puede convertirse rápidamente en un riesgo para la continuidad institucional y para la protección de la información.

IILa falla mundial en PHP y los problemas que esta ocasionando

II.1La falla mundial en PHP y los problemas que puede ocasionar en las Universidades del Perú

Para el presente informe se ha hecho una revisión sobre 95 universidades, entre públicas y privadas, incluyendo universidades que se encuentran en proceso de institucionalización; se usaron los datos y la arquitectura que son públicas, se evaluaron los 95 portales de estas universidades, sus campus virtuales, intranets, sistemas académicos, gestión documental, trámites y otros servicios. Se hizo una bitácora de observación estructura con los estigmas visibles como cabeceras del servidor, código de la página y las cookies.

Las limitaciones del informe son: el acceso solo a la “fachada” de los ecosistemas, en 28 sitios no se pudo identificar plenamente su tecnología y eso es una limitación para el informe, pero también que estas instituciones ocultan bien sus datos. Lo que se presentará a continuación es un diagnóstico general y no un examen particular a una universidad, tampoco exhibiremos los datos de ninguna universidad.

Nuestras limitaciones son el no poder reconocer la versión exacta de PHP de todos los sistemas; por lo tanto, la tabla siguiente es una evaluación de lo que es de acceso público y sobre ello las consecuencias que consideramos potenciales.

IIIEstado situacional de las Universidades en el Perú

Revisamos las páginas webs de 95 universidades peruanas, entre públicas y privadas, no probamos contraseñas, ni hemos penetrado la seguridad, solo recogimos información a la que se puede acceder con una auditoría de los datos abiertos.

III.1WordPress domina el mercado

Gráfico 1

Tecnología principal de los portales universitarios del Perú

WordPress aparece en 47 sitios. La razón, porque es barato, hay mucha gente que lo maneja y se instala en una tarde. El costo llega después, cuando nadie lleva el control de qué plugins hay instalados ni de cuándo se actualizaron por última vez.

III.2PHP está debajo de casi todo

Gráfico 2

Sitios con señales de PHP, directas o por el gestor que usan

Contando WordPress, Joomla, Drupal, Laravel y las páginas que simplemente se sirven con extensión .php, 65 de 95 sitios descansan sobre PHP. Es un lenguaje sólido cuando se mantiene al día, lo que falla casi siempre es el mantenimiento.

III.3Públicas y privadas, parecidas

Gráfico 3

Porcentaje de sitios con WordPress y con indicios de PHP, según el tipo de universidad

No encontramos una brecha grande entre públicas y privadas. Los dos grupos dependen de las mismas herramientas, y los dos tienen la misma tarea pendiente.

III.4Protecciones básicas: bien en lo primero, flojo en lo demás

Casi todas (94 de 95) cargan por HTTPS, que es lo mínimo y solo 15 tienen un firewall o CDN adelante, que filtra tráfico malicioso antes de que llegue al sitio; 33 muestran la versión de su servidor, un dato que no hace falta hacerlo público (regalar al instruso).

Gráfico 4

Señales de protección visibles en la portada.

IV¿Por qué las Universidades se encuentran vulnerables?

La tecnología avanza imparable y las nuevas generaciones han ingresado a una escalada de acceso a la información desde temprana edad, no es una situación de genialidad encontrar a un adolescente programando, creando aplicativos o incluso vulnerando sistemas de seguridad avanzados. Hasta hace algunos años vulnerar sistemas de seguridad significaba revisar miles de líneas de códigos en búsqueda de la falla y atacar, la imagen del experto especialista, casi genio ya no existe más; las herramientas de la inteligencia artificial han reducido las barreras, se pueden leer códigos en minutos y explotarlos en cuestión de minutos también.

El caso de PHP de esta semana lo muestra bien. Las fallas se hicieron públicas el 21 de octubre y el código de ataque, bautizado PHP2Shell, ya circula en la Darknet / DeepWeb. Algunas fuentes hablan de primeros intentos de explotación; otras dicen que todavía no se sabe qué tan extendidos están. Las dos fallas están en PHP mismo, no en un sitio concreto. Cualquier página hecha con WordPress, Drupal, Laravel o con un sistema propio en PHP queda expuesta hasta que se actualice.

VMedidas que han sido adoptadas a nivel internacional

El 21 de octubre de 2026 se difundieron actualizaciones destinadas a corregir estas vulnerabilidades, las medidas adoptadas internacionalmente frente a PHP2Shell pueden agruparse en tres niveles: corrección definitiva, mitigación temporal y contención/monitoreo. La conclusión común de PHP, AWS, Google Cloud, NSA y NHS es inequívoca: la única corrección completa para CVE-2026-109618 y CVE-2026-109619 es actualizar PHP a una versión corregida (PHP Group, 2026).

V.1Medidas que deberían adoptar las universidades peruanas

Ya fueron puestas en alerta por el Centro Nacional de Seguridad Digital (CNSD) de la Presidencia del Consejo de Ministros, quien emitió el 21 de octubre de 2026 una alerta específica sobre PHP2Shell, identificando las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 y advirtiendo que podían permitir ejecución remota de código, acceso no autorizado y compromiso de servidores vulnerables. También informó que ya existían intentos de explotación y que la publicación de pruebas técnicas incrementaba el riesgo de ataques masivos (CNSD, 2026).

La alerta peruana siguió básicamente el mismo enfoque de los organismos internacionales: parchar primero; si no es posible, reducir o eliminar temporalmente la exposición pública.

Y hoy con este Informe del Observatorio de Educación Superior tienen una hoja de ruta suficiente para actuar rápidamente ante cualquier inconveniente y sobre todo, sensibilizar y prevenir sobre la vulnerabilidad de nuestros sistemas de gestión.

Las universidades peruanas deberían tratar PHP2Shell como un incidente de riesgo institucional, no solo como un problema del área de informática. La prioridad inmediata es identificar qué sistemas usan PHP y corregirlos antes de que una vulnerabilidad técnica termine afectando matrícula, notas, pagos, datos personales o continuidad académica.

Las medidas que recomendaría son estas:

1. 1Inventariar todos los sistemas que usan PHP.
2. 2Actualizar inmediatamente a una versión corregida.
3. 3Migrar las versiones fuera de soporte.
4. 4Desconectar temporalmente los sistemas que no puedan corregirse.
5. 5Reiniciar efectivamente PHP después del parcheo.
6. 6Desactivar session.upload_progress.enabled mientras corresponda.
7. 7Aplicar WAF/CDN como segunda barrera, no como sustituto del parche.
8. 8Reducir temporalmente la superficie de ataque.
9. 9Revisar retrospectivamente los registros.
10. 10Segmentar los sistemas críticos.
11. 11Proteger las cuentas privilegiadas con MFA.
12. 12Verificar backups y recuperación.
13. 13Crear un equipo de respuesta a incidentes.
14. 14Preparar un protocolo de comunicación.
15. 15Incorporar ciberseguridad a la gobernanza universitaria.

VI¿Qué está en juego?

Un sitio de portada comprometido es una molestia. El problema real es lo que hay al lado: correos institucionales, datos de matrícula, notas, trámites y pagos de miles de estudiantes. Cuando el sitio público y los sistemas internos comparten servidor o credenciales, una falla en el primero abre la puerta al resto. Si ocurre, las consecuencias no son abstractas: se cae la matrícula o el examen de admisión en plena fecha, se filtran datos personales de estudiantes y docentes, y la universidad queda obligada a explicarlo ante la comunidad, ante SUNEDU y ante la autoridad de protección de datos personales. Reponerse cuesta mucho más que actualizar a tiempo.

Hay además un daño que se ve menos y dura más: la reputación. Una página institucional que redirige a sitios de apuestas o a estafas aparece en buscadores, y los estudiantes y postulantes la ven antes que cualquier comunicado.

VII¿Qué hacer?