gssproxy EUVD-2026-109941

Exploitation requires local access to the host and the ability to connect to the gssproxy daemon's Unix domain socket - i.e. any local user account; it does not require GSS/application-level authentication, and the malicious GSSX_INIT_SEC_CONTEXT request simply omits the target_name field. There is no remote vector (AV:L) and no user interaction. Impact is limited to availability of gssproxy itself, but is amplified because the daemon does not auto-restart, so recovery needs manual administrator action; the practical blast radius is confined to hosts running gssproxy in Kerberized configurations (e.g. serving Kerberized NFS or IdM). Hosts where gssproxy is not deployed or not running are not exposed.

This is a genuine but moderate-priority issue, correctly rated medium (CVSS 5.5). The CVSS vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H is internally consistent with a local, low-complexity, availability-only denial of service: the only impact is A:H (daemon crash), with no confidentiality or integrity effect, and the scope is unchanged. Note a tension between signals: the description states the request 'requires no authentication,' while the CVSS carries PR:L - these reconcile because reaching the gssproxy Unix socket still requires a local user account (any local user, authenticated to the host, but no further GSS/application credential), so PR:L reflects the need for local presence rather than an application-layer credential; the 'no authentication' phrasing refers to the GSSX protocol message itself. No EPSS score, KEV entry, or PoC/exploit reference is present in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The vuln.today decision label is 'this_month,' consistent with a local-only availability bug rather than an emergency. Real-world risk is bounded by the local-access requirement and the absence of confidentiality/integrity impact, but the persistent nature (daemon does not auto-restart) raises operational severity in Kerberized environments where dependent services such as NFS and IdM fail until manual intervention.

A local user with any shell account on an affected RHEL or OpenShift host connects to the gssproxy Unix socket and sends a crafted GSSX_INIT_SEC_CONTEXT request that omits the target_name field, causing the daemon to dereference a NULL pointer and crash. Because gssproxy does not automatically restart, dependent services such as Kerberized NFS and IdM remain broken until an administrator manually intervenes. No public exploit identified at time of analysis; the attack requires only local socket access and no application-level authentication.