CVE-2026-55785: Non-Constant-Time Cryptographic Comparison and Sensitive Information Leakage in free5GC AUSF

The free5GC Authentication Server Function (AUSF) acts as the authority verifying that a connecting User Equipment (UE) has computed a valid response vector corresponding to the home network's expectations. These protocol sequences operate under either 5G-AKA or EAP-AKA' profiles, as defined by 3GPP standards. The vulnerability resides inside the processor package of the SBI handling layer, specifically in the file internal/sbi/processor/ue_authentication.go.

By leveraging standard, non-constant-time comparison primitives, the AUSF introduces side-channel vulnerabilities during the verification of the cryptographic parameters RES*, XRES*, AT_MAC, and XMAC. Furthermore, the code prints the plaintext expected validation strings into standard system output at the INFO logging level.

This flaw exposes the 5G core's subscriber credential management mechanisms. This combination of structural flaws introduces two separate risk vectors: a timing-discrepancy vector under specific noise-free topologies, and a high-exposure diagnostic logging vector across all cloud environments.

The application's structural weakness stems from two independent coding errors in the validation of network challenge responses. Under 3GPP specifications, the AUSF generates expected authorization response challenges (XRES* or XRES) and expects the client to present a corresponding RES* or RES parameter calculated from its subscriber identity module.

First, during 5G-AKA validation, the AUSF invokes Go's native strings.EqualFold string equality wrapper to compare user responses against the internal expected vector. The execution flow of strings.EqualFold processes strings byte-by-byte and returns immediately upon discovering a mismatch. Because of this short-circuit logic, the total execution elapsed duration varies predictably depending on how many leading bytes of the client's guess match the correct token.

Second, the validation path for EAP-AKA' relies on standard bytes.Equal logic and the normal comparison operator == to validate cryptographic hash blocks. This implementation behaves exactly like the string comparison functions, introducing a covert timing channel. Compounding this risk, the developer included verbose logging statements that export the master confirmation vector (XresStar) to standard logs. This output is evaluated prior to validation, exposing credential strings to container orchestrators, sidecars, or syslog listeners.

The patch implemented in free5GC commit 7a5a4aa1ec6cd0e1febebf333911c3104968edf0 introduces constant-time evaluation and removes diagnostic leaks. In the vulnerable code, the Auth5gAkaComfirmRequestProcedure processes verification as follows:

// VULNERABLE CODE (Pre-v1.4.5)
logger.Auth5gAkaLog.Infof("res*: %x\nXres*: %x\n", updateConfirmationData.ResStar, ausfCurrentContext.XresStar)
if strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar) {
    // Authentication success
}

The fix addresses this by replacing the non-constant comparisons with secure comparison algorithms and deleting the logger instructions:

// PATCHED CODE (v1.4.5)
if constantTimeHexEqual(updateConfirmationData.ResStar, ausfCurrentContext.XresStar) {
    // Authentication success
}

The patch defines two custom validation wrappers to enforce uniform execution paths across different variable types:

func constantTimeHexEqual(a, b string) bool {
	aBytes, err := hex.DecodeString(a)
	if err != nil {
		return false
	}
	bBytes, err := hex.DecodeString(b)
	if err != nil {
		return false
	}
	return constantTimeEqual(aBytes, bBytes)
}
 
func constantTimeEqual(a, b []byte) bool {
	return len(a) == len(b) && subtle.ConstantTimeCompare(a, b) == 1
}

By calling subtle.ConstantTimeCompare, the process executes a bitwise comparison across the entire length of both byte arrays, eliminating any variation in timing. While the conditional length check (len(a) == len(b)) technically short-circuits, 5G authentication parameters are fixed in size, rendering the resulting timing variance useless to adversaries.

The vulnerability presents two practical attack paths based on configuration and target environment constraints. These are split between a static local timing evaluation and a direct credential harvest via diagnostic systems.

Attack Path 1: Log-Harvesting Exploitation

An attacker targeting the cloud-native infrastructure exploits the logging weakness directly. If the attacker has compromised a co-resident pod, a telemetry collection system, or a local log aggregator, they query the stream for XresStar. Armed with the correct vector, they submit authentication confirmation requests using the stolen value, authenticating successfully as the targeted subscriber without performing any mathematical or cryptographic calculations.

Attack Path 2: Local Timing Analysis

An attacker attempts a side-channel attack targeting co-resident container systems where virtualization limits network jitter. The adversary initiates repetitive authentication procedures while tracking system processing latency at nanosecond-scale precision. By performing a character-by-character brute force, the adversary identifies longer processing windows indicating a correct prefix match. This allows complete recovery of validation keys over several million requests.

The impact of CVE-2026-55785 is concentrated on the confidentiality of 5G subscriber sessions. While rated as CVSS 3.7 (Low) due to the high complexity required to exploit timing vectors over live internet routing infrastructure, the practical severity increases to High in shared-tenant cloud platforms.

If the plaintext logger statements are active, any operator or adjacent software system capable of reading log containers or standard output streams can obtain active authentication challenges. This completely compromises authentication token confidentiality, allowing rogue hardware or emulation scripts to spoof subscriber identities. This compromises the non-repudiation guarantees of the 5G Service-Based Architecture.