← Volver a artículos
Seguridad· 2 min de lectura

CVE-2026-4747: un fallo sin autenticar en RPCSEC_GSS abre la puerta a RCE con privilegios de kernel en FreeBSD

El 26 de marzo de 2026 el proyecto FreeBSD publicó el aviso FreeBSD-SA-26:08.rpcsec_gss, que corrige un fallo de gravedad crítica en la implementación de RPCSEC_GSS. El problema (CVE-2026-4747) afecta sobre todo a servidores NFS que usan autenticación Kerberos, y lo más serio es que un cliente malicioso puede explotarlo sin haberse autenticado antes.

Qué falla exactamente

RPCSEC_GSS es el mecanismo que da integridad y cifrado a las llamadas RPC, y es la base de NFS con seguridad Kerberos (sec=krb5, krb5i, krb5p). Cada paquete de datos RPCSEC_GSS se valida con una rutina que comprueba una firma incluida en el propio paquete. Para hacerlo, esa rutina copia una parte del paquete a un buffer en la pila. El error está justo ahí: no se comprueba que el buffer sea lo bastante grande antes de copiar. Un cliente que envíe un paquete preparado para ello provoca un desbordamiento de pila.

Un stack overflow en contexto de kernel no es un simple cuelgue. Según el aviso, puede derivar en ejecución remota de código con privilegios de kernel en el servidor NFS. En el espacio de usuario, los servidores RPC enlazados con librpcsec_gss quedan igualmente expuestos a explotación remota desde cualquier cliente.

A quién afecta

El fallo está presente en todas las versiones soportadas de FreeBSD:

  • FreeBSD 15.0-RELEASE y stable/15
  • FreeBSD 14.3 y 14.4, además de stable/14
  • FreeBSD 13.5-RELEASE y stable/13

Los componentes vulnerables son el módulo de kernel kgssapi.ko (la implementación de RPCSEC_GSS) y la biblioteca de espacio de usuario librpcsec_gss. Si tienes un servidor NFS con autenticación Kerberos y el módulo cargado, estás en el grupo de riesgo directo. Lo mismo vale para cualquier servidor RPC propio que enlace con librpcsec_gss.

Que no haga falta autenticación cambia mucho el cálculo de riesgo. No hablamos de un usuario ya con acceso al sistema, sino de alguien que pueda alcanzar el puerto del servicio por la red.

Cómo mitigarlo

La vía buena es actualizar. FreeBSD aplicó las correcciones el 26 de marzo de 2026 en todas las ramas soportadas, tanto stable como las releng correspondientes (releng/15.0, releng/14.4, releng/14.3 y releng/13.5). El procedimiento habitual sirve aquí: aplica el parche con freebsd-update, o recompila el kernel y librpcsec_gss desde las ramas corregidas si gestionas el sistema desde fuentes. Después hay que reiniciar para que el kernel nuevo entre en uso.

Si no puedes parchear de inmediato y no usas NFS con Kerberos, descargar el módulo kgssapi.ko reduce la superficie expuesta en el lado del kernel. Aun así, mientras el servicio siga accesible desde redes no confiables el riesgo persiste, así que conviene limitar el acceso a los puertos de NFS y RPC con el cortafuegos mientras instalas el parche definitivo.

Si gestionas FreeBSD en producción, este es de los que se aplican sin esperar a la siguiente ventana de mantenimiento. Puedes consultar más detalles en la ficha de FreeBSD.

Fuente