GitHub Enterprise Server EUVD-2026-116583

Exploitation requires a valid account on the target GitHub Enterprise Server with SSH access to the Git service (babeld); the attacker must be able to complete an SSH connection and then re-key to a signature algorithm whose digest is longer than the one babeld used to size the session identifier. The condition is therefore authenticated and specific to the SSH host-key possession-proof path in babeld, not reachable by a fully anonymous remote attacker. Limiting factors: the account/SSH-access prerequisite (PR:L) bounds the attacker population to those with existing access, and only 'a limited amount' of adjacent process memory is recoverable (VC:L), so each attempt yields a bounded confidentiality leak with no integrity or availability impact. All GHES releases prior to 3.23 are affected; instances already on 3.22.3, 3.21.8, 3.20.10, 3.19.14 or later are not.

This is a medium-severity information-disclosure issue, not a top-priority emergency, and the signals are internally consistent. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 5.3 and shows network reach with low attack complexity, but it also requires low privileges (PR:L) - the description confirms the attacker must already have an account and SSH access to the GitHub Enterprise Server instance. Impact is limited to confidentiality (VC:L), with no integrity or availability effect, matching the CWE-125 out-of-bounds read that leaks only 'a limited amount' of adjacent process memory. No EPSS score was provided, there is no CISA KEV listing, and no public exploit is referenced; the vuln.today decision label is 'this_month', which is a patch-on-normal-cadence priority rather than act_now or emergency. The flaw was found and reported through the GitHub Bug Bounty program, consistent with a researcher-discovered bug rather than observed in-the-wild abuse. Net: a genuine but bounded issue - an authenticated-user memory leak on an enterprise appliance - that merits scheduled patching, not crisis response. Note the data gap: no EPSS and no KEV status were supplied as positive signals, so exploitation likelihood cannot be quantified from the input beyond the absence of any exploit reference.

An attacker who already holds a valid account with SSH access to a GitHub Enterprise Server instance connects to the Git service (babeld) and, during the SSH host-key possession proof, renegotiates (re-keys) to a signature algorithm whose hash is longer than the one babeld used to size the session identifier buffer. Because babeld sizes the identifier by the current digest length rather than its own, adjacent process memory beyond the intended buffer is included in the signed data and returned to the client, where a limited amount of that memory can be recovered. No public exploit code is referenced in the available data.