CVE-2026-55785 in free5GC
Summary
by MITRE • 08/29/2026
free5GC is an open-source implementation of the 5G core network. Prior to 1.4.5, the AUSF component performs cryptographic authentication comparisons in internal/sbi/processor/ue_authentication.go with ordinary equality helpers. Auth5gAkaComfirmRequestProcedure compares RES* and XRES* with strings.EqualFold and logs the expected XRES* value at INFO level before comparison. EapAuthComfirmRequestProcedure compares AT_MAC and XMAC with bytes.Equal and evaluates XRES == RES with ordinary string equality. These comparisons can return at mismatch-dependent times, although testing did not demonstrate a practical remote timing oracle because of HTTP/SBI timing noise. The INFO log exposes authentication material to operators, log collectors, sidecars, or processes able to read AUSF logs. This issue is fixed in version 1.4.5.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/29/2026
The vulnerability identified within the free5GC open-source implementation of the fifth-generation core network architecture stems from improper handling of cryptographic authentication data during user equipment verification procedures. Specifically, the Authentication Server Function component contains flaws in its Service-Based Interface processing logic located in the ue_authentication.go module. In versions prior to 1.4.5, the system utilizes standard equality comparison functions rather than constant-time algorithms when validating critical security tokens. This architectural choice introduces two distinct categories of risk: potential timing side-channel attacks and unauthorized information disclosure through log files. The AUSF is responsible for authenticating user equipment against the home subscriber server, a process that relies on comparing expected cryptographic responses with actual values provided by the device or network functions.
The first technical flaw involves the Auth5gAkaConfirmRequestProcedure function which compares the received RES value against the expected XRES value using strings.EqualFold. This standard string comparison method iterates through characters and returns immediately upon finding a mismatch, meaning the execution time varies depending on how many leading characters match before the discrepancy occurs. While testing indicated that practical exploitation as a remote timing oracle is difficult due to inherent HTTP and Service-Based Interface network latency noise masking subtle timing differences, the theoretical vulnerability remains present under controlled conditions or if an attacker can mitigate external jitter through sophisticated measurement techniques. This behavior aligns with CWE-208 which describes observable timing discrepancy in cryptographic operations that could potentially be exploited by a local or remote adversary to infer secret data such as authentication keys or tokens.
The second and more immediately exploitable flaw is found in the EapAuthConfirmRequestProcedure function where AT_MAC and XMAC are compared using bytes.Equal, and XRES is checked against RES using ordinary string equality. Similar to the previous case, these non-constant-time comparisons introduce timing variability based on input data. More critically, the Auth5gAkaConfirmRequestProcedure logs the expected XRES* value at the INFO level prior to performing the comparison. This logging practice results in the exposure of sensitive authentication material directly into system logs accessible by operators, log collection services, sidecar containers, or any process with read access to the AUSF log files. The disclosure of these cryptographic values undermines the confidentiality required for secure 5G network operations and represents a significant data leakage vulnerability classified under CWE-209 which involves the generation of error messages containing sensitive information that could be utilized by attackers to further compromise the system.
From an operational perspective, this vulnerability impacts the integrity and confidentiality of the authentication handshake between user equipment and the core network. If an attacker gains access to log storage or monitoring tools, they can extract XRES* values which are critical for verifying subscriber identity in 5G networks. This could facilitate offline brute-force attacks against these hashes if additional context is available, or potentially aid in impersonation attempts within environments where logging retention policies do not adequately protect such sensitive data. Furthermore, the timing side-channel risks, although mitigated by network noise in typical deployments, highlight a broader pattern of insecure cryptographic implementation practices that should be addressed to ensure robustness against advanced persistent threats capable of high-precision timing analysis.
To mitigate these issues, it is imperative to upgrade free5GC to version 1.4.5 or later where the comparison logic has been corrected and logging behavior adjusted. For systems unable to immediately patch, operators should implement strict access controls on log files containing authentication data, ensuring that only authorized security personnel with need-to-know basis can view them. Additionally, integrating cryptographic libraries that provide constant-time equality checks for all sensitive comparisons is recommended as a defense-in-depth measure against timing attacks. Aligning these practices with industry standards such as the OWASP Cryptographic Cheat Sheet and MITRE ATT&CK techniques related to credential access via log exploitation will significantly enhance the security posture of 5G core deployments. Regular audits of logging configurations are also advised to prevent accidental exposure of high-value cryptographic material in plaintext formats across all network functions.