<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T10:00:56.501142+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-55785</id>
    <title>fkie_cve-2026-55785</title>
    <updated>2026-10-02T10:00:59.403904+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-55785"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-fp46-6vfw-gc9c</id>
    <title>GHSA-fp46-6vfw-gc9c — free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA</title>
    <updated>2026-10-02T10:00:59.404102+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/free5gc/ausf</p>
<p>### Summary</p>
<p>The AUSF component of free5GC compares authentication response values with normal Go equality helpers instead of constant-time cryptographic comparison functions.</p>
<p>Two authentication flows are affected in `internal/sbi/processor/ue_authentication.go`:</p>
<p>1. 5G-AKA confirmation compares `RES*` and `XRES*` with `strings.EqualFold()`.
2. EAP-AKA' confirmation compares `AT_MAC` with `bytes.Equal()` and compares `XRES` and `RES` with `==`.</p>
<p>These functions are not designed to be constant-time cryptographic comparators and may return earlier depending on the location of the first mismatch.</p>
<p>Additionally, the 5G-AKA confirmation path logs both the received `res*` and the expected `Xres*` at INFO level immediately before comparing them. The `XRES*` value is authentication material and should not be written to application logs.</p>
<p>The timing side channel was confirmed as a code issue, but practical exploitation over HTTP was not demonstrated in the lab because the comparator-level signal is much smaller than HTTP/SBI noise. The `XRES*` logging issue is directly observable in AUSF logs.</p>
<p>Confirmed on `github.com/free5gc/ausf` v1.4.4 and current main as of the May 2026 analysis.</p>
<p>### Details</p>
<p>#### 5G-AKA: `RES*` / `XRES*`</p>
<p>In `Auth5gAkaComfirmRequestProcedure()`, the AUSF logs both values and then compares them with `strings.EqualFold()`:</p>
<p>```go
// internal/sbi/processor/ue_authentication.go
logger.Auth5gAkaLog.Infof("res*: %x\nXres*: %x\n",
    updateConfirmationData.ResStar,…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-fp46-6vfw-gc9c"/>
  </entry>
</feed>
