CVE-2026-55785: free5GC AUSF Information Disclosure Flaw

CVE-2026-55785 Overview

free5GC is an open-source implementation of the 5G core network. Versions prior to 1.4.5 contain a timing side-channel and information disclosure weakness in the Authentication Server Function (AUSF) component. The vulnerability resides in internal/sbi/processor/ue_authentication.go, where cryptographic authentication values are compared using non-constant-time helpers. Additionally, the AUSF logs the expected XRES* value at INFO level before performing the comparison, exposing authentication material to any party able to read AUSF logs. The issue is classified as [CWE-208] Observable Timing Discrepancy.

Critical Impact
Authentication material for 5G subscriber authentication (XRES*) is written to INFO-level logs and compared using non-constant-time functions, enabling potential information disclosure to operators, log collectors, and sidecar processes.

Affected Products

free5GC AUSF component prior to version 1.4.5
Deployments using Auth5gAkaComfirmRequestProcedure (5G-AKA authentication flow)
Deployments using EapAuthComfirmRequestProcedure (EAP-AKA' authentication flow)

Discovery Timeline

2026-08-28 - CVE-2026-55785 published to NVD
2026-08-31 - Last updated in NVD database

Technical Details for CVE-2026-55785

Vulnerability Analysis

The AUSF component performs cryptographic authentication comparisons using ordinary equality helpers rather than constant-time primitives. In Auth5gAkaComfirmRequestProcedure, the code compares RES* and XRES* values using strings.EqualFold. In EapAuthComfirmRequestProcedure, it compares AT_MAC and XMAC using bytes.Equal and evaluates XRES == RES with the standard string equality operator.

These comparisons can return in mismatch-dependent time, creating a theoretical timing oracle against authentication secrets. Testing did not demonstrate a practical remote timing oracle due to HTTP and Service-Based Interface (SBI) timing noise, but the weakness remains present in the code path.

A more direct exposure exists in the logging behavior. The AUSF writes the expected XRES* value to logs at INFO level prior to comparison. Any operator, centralized log collector, sidecar container, or process with access to AUSF logs can read the authentication material directly.

Root Cause

The root cause is twofold. First, authentication comparisons use non-constant-time functions from the Go standard library (strings.EqualFold, bytes.Equal, ==) rather than crypto/subtle.ConstantTimeCompare. Second, sensitive authentication values are emitted to structured logs before comparison completes, violating the principle that authentication secrets should never appear in log output.

Attack Vector

Remote timing exploitation is limited by SBI transport noise, and the CVSS vector reflects high attack complexity. The more practical exposure is passive: any actor with read access to AUSF logs, including SIEM ingestion pipelines, log-forwarding sidecars, or misconfigured file permissions, can harvest XRES* values. These values are part of the 5G Authentication and Key Agreement (AKA) flow and should be treated as confidential.

// Patch diff from internal/sbi/processor/ue_authentication.go
 package processor
 
 import (
-	"bytes"
 	"crypto/hmac"
 	"crypto/sha256"
+	"crypto/subtle"
 	"encoding/base64"
 	"encoding/binary"
 	"encoding/hex"

Source: free5gc/ausf commit 7a5a4aa1. The patch replaces bytes with crypto/subtle, enabling constant-time comparison via subtle.ConstantTimeCompare and removes the exposed log statement.

Detection Methods for CVE-2026-55785

Indicators of Compromise

AUSF INFO-level log entries containing XRES* values or fields labeled as expected authentication response material.
Unexpected external access, mounts, or forwarders reading from AUSF log paths or standard output streams.
Log entries from ue_authentication.go written by AUSF binaries built from source prior to v1.4.5.

Detection Strategies

Inventory all running AUSF instances and verify their build version against the free5GC v1.4.5 release tag.
Grep centralized log stores for authentication field names emitted by the AUSF authentication procedures.
Audit which service accounts, sidecars, and log-shipping DaemonSets have read access to AUSF pod logs in Kubernetes deployments.

Monitoring Recommendations

Alert on any process outside the expected observability stack accessing AUSF log files or container log streams.
Track configuration drift on AUSF log-level settings; enforce that INFO-level output does not contain authentication secrets after upgrade.
Review retention policies for historical AUSF logs and purge entries that may contain XRES* values.

How to Mitigate CVE-2026-55785

Immediate Actions Required

Upgrade the free5GC AUSF component to version 1.4.5 or later.
Rotate any subscriber authentication credentials that may have been exposed through historical AUSF logs.
Restrict read access to AUSF log destinations to the minimum set of operators and services.

Patch Information

The fix is included in free5GC AUSF release v1.4.5 via pull request #63 and commit 7a5a4aa1. See the GitHub Security Advisory GHSA-fp46-6vfw-gc9c for full details. The patch imports crypto/subtle and replaces equality helpers with constant-time comparison, and removes the INFO-level logging of expected authentication values.

Workarounds

Raise the AUSF minimum log level above INFO to suppress emission of XRES* values until the patched build is deployed.
Redact authentication fields at the log-forwarder tier before entries reach centralized storage.
Tighten file-system and container log permissions to restrict which sidecars and collectors can read AUSF output.

bash

# Example: pin free5GC AUSF to the patched release when building from source
git clone https://github.com/free5gc/ausf.git
cd ausf
git checkout v1.4.5
go build ./...