Vigilancia cibernética: las vulnerabilidades del otoño de 2026 que debe corregir ya

PHP, GitLab, OpenSSH, equipos expuestos: qué comprobar y cómo protegerse

A finales de octubre y principios de noviembre de 2026 se publicaron varias vulnerabilidades críticas que fueron explotadas en cuestión de horas. Estas son las que requieren una acción inmediata, lo que conviene comprobar y las buenas prácticas para protegerse.

Dos candados en una puerta antigua

Foto: «Couple of metallic padlocks on old door frame», Horia Varlan, licencia CC BY 2.0.

PHP: «php2shell», ejecución remota de código

El 21 de octubre, PHP corrigió dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, que permiten ejecutar código de forma remota. El CERT-FR emitió una alerta (CERTFR-2026-ALE-014) y ha detectado intentos de explotación; desde el 22 de octubre circulan pruebas de concepto.

  • Versiones corregidas: 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
  • Sin parche: las ramas 5.x, 7.x, 8.0.x y 8.1.x ya no reciben mantenimiento. Es necesario migrar.
  • Qué hacer: inventariar todos los sitios y aplicaciones en PHP, incluidos los gestionados por un proveedor, actualizarlos y buscar indicios de compromiso (archivos desconocidos, nuevas cuentas de administrador, conexiones salientes inusuales).

GitLab: una vulnerabilidad con puntuación de 10 sobre 10

El 21 de octubre, GitLab publicó parches para CVE-2026-110264: una ejecución remota de código sin autenticación, en determinadas condiciones, que afecta a todas las versiones autoalojadas de GitLab CE y EE desde la 7.0. Las instancias actualizadas el 12 de octubre siguen siendo vulnerables. GitLab no ofrece ninguna solución alternativa.

  • Versiones corregidas: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13.
  • Por qué es grave: una forja de software alberga los secretos de la integración continua y, por tanto, a menudo las claves de despliegue de los servidores de producción.
  • Qué hacer: hacer una copia de seguridad de la configuración y los secretos, actualizar y, si los registros muestran algún intento, rotar los tokens y las variables.

OpenSSH: «sshole», explotada en menos de nueve horas

El 5 de noviembre, OpenSSH 10.6p2 corrigió CVE-2026-123158 (alerta CERTFR-2026-ALE-015). En los sistemas Linux que utilizan la biblioteca musl sin PAM, con Alpine Linux a la cabeza, las cuentas sin una contraseña real pueden abrirse sin autenticación. Se detectó un primer intento de explotación menos de nueve horas después de su publicación.

  • Afectados: Alpine Linux y otros sistemas basados en musl (algunas imágenes Docker, OpenWrt, Buildroot, Yocto). Las distribuciones basadas en glibc y las que utilizan PAM no se ven afectadas.
  • Qué hacer: aplicar el parche y reiniciar sshd; de lo contrario, el programa antiguo seguirá aceptando conexiones. En su defecto, desactivar la autenticación por contraseña.

Equipos expuestos: pasarelas de acceso y objetos conectados

Cables de red etiquetados conectados a un conmutador

Foto: «Switch!», andrewfhart, licencia CC BY-SA 2.0.

Siguen abiertas tres alertas del CERT-FR sobre equipos situados en el perímetro de la red:

  • Ivanti Connect Secure (CERTFR-2026-ALE-013): tres vulnerabilidades explotadas activamente. En caso de duda, aislar el equipo, conservar los registros y buscar movimientos laterales en la red.
  • Citrix NetScaler ADC y Gateway (CERTFR-2026-ALE-011): varias vulnerabilidades, una de ellas explotada.
  • Controladores remotos de instalaciones de refrigeración (CERTFR-2026-ALE-012): numerosos controladores Danfoss AK-SC y AK-SM, Copeland y Dixell xweb accesibles desde Internet han sido comprometidos. El recordatorio del CERT-FR vale para cualquier objeto conectado: «exponer una interfaz de gestión en Internet es contrario a las buenas prácticas». El acceso debe realizarse a través de una VPN o una red protegida, con el firmware actualizado y las contraseñas cambiadas.

Cinco buenas prácticas para esta semana

  1. Mantener el inventario de todo lo que está expuesto en Internet, incluidos los proveedores.
  2. Actualizar en los días siguientes a una alerta y reiniciar los servicios afectados.
  3. No exponer nunca una interfaz de administración: VPN o red protegida.
  4. Tras un parche aplicado con retraso, buscar indicios de compromiso y rotar los secretos.
  5. Probar las cuentas compartidas como lo haría un usuario malintencionado.

Fuentes: alertas del CERT-FR, avisos de los fabricantes (PHP, GitLab, OpenSSH). ¿Tiene alguna pregunta sobre su exposición? contact@cybelia-cloud.fr.

Geoiko, la consultoría en IA socia de Cybelia Cloud
El gemelo digital de la empresa, al que preguntar para transmitir su saber hacer