{"id":"CVE-2026-55785","aliases":["EUVD-2026-68017","GHSA-fp46-6vfw-gc9c","GO-2026-6328","SUSE-SU-2026:23692-1","SUSE-SU-2026:23712-1","openSUSE-SU-2026:21812-1"],"status":"published","title":"free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA","description":"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.","severity":{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00445,"percentile":0.39133,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-208","CWE-385","CWE-532"],"published":"2026-08-28T22:25:06Z","modified":"2026-10-28T02:30:29Z","fixes":[{"ecosystem":"Go","package":"github.com/free5gc/ausf","fixed_in":["1.4.5"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/free5gc/ausf","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.4.5"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/free5gc/ausf","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.4.5"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/free5gc/ausf","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.4.5"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39}],"products":[{"vendor":"free5gc","product":"free5gc"}],"references":[{"url":"https://github.com/free5gc/free5gc/security/advisories/GHSA-fp46-6vfw-gc9c","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/free5gc/ausf/pull/63","tags":["x_refsource_MISC","fix"]},{"url":"https://github.com/free5gc/ausf/commit/7a5a4aa1ec6cd0e1febebf333911c3104968edf0","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/free5gc/ausf/releases/tag/v1.4.5","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-fp46-6vfw-gc9c"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55785.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-55785","tags":["advisory"]},{"url":"https://github.com/free5gc/free5gc","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623692-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-20909","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-22547","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-24690","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25712","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25718","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26232","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26247","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26307","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27657","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27878","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-28705","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54746","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54754","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54755","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54766","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55064","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55065","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55066","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55067","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55068","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55108","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55245","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55484","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55569","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55588","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55621","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55622","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55678","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55761","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55763","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55764","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55784","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55785","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55834","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55873","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55874","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56854","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56855","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-78662","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623712-1/","tags":["advisory"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-55785","title":"free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA","description":"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.","status":"published","published":"2026-08-28T22:25:06.814Z","modified":"2026-08-31T18:53:29.062Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"low","assessor":"cna"}],"cwes":["CWE-208","CWE-385","CWE-532"],"updated_at":"2026-11-02T14:20:11.925815Z"}],"euvd":[{"id":"EUVD-2026-68017","description":"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.","status":"published","published":"2026-08-28T22:25:06Z","modified":"2026-08-31T18:53:29Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"low"}],"updated_at":"2026-11-02T18:01:19.818565Z"}],"ghsa":[{"id":"GHSA-fp46-6vfw-gc9c","title":"free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA","description":"### Summary\n\nThe AUSF component of free5GC compares authentication response values with normal Go equality helpers instead of constant-time cryptographic comparison functions.\n\nTwo authentication flows are affected in `internal/sbi/processor/ue_authentication.go`:\n\n1. 5G-AKA confirmation compares `RES*` and `XRES*` with `strings.EqualFold()`.\n2. EAP-AKA' confirmation compares `AT_MAC` with `bytes.Equal()` and compares `XRES` and `RES` with `==`.\n\nThese functions are not designed to be constant-time cryptographic comparators and may return earlier depending on the location of the first mismatch.\n\nAdditionally, 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.\n\nThe 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.\n\nConfirmed on `github.com/free5gc/ausf` v1.4.4 and current main as of the May 2026 analysis.\n\n### Details\n\n#### 5G-AKA: `RES*` / `XRES*`\n\nIn `Auth5gAkaComfirmRequestProcedure()`, the AUSF logs both values and then compares them with `strings.EqualFold()`:\n\n```go\n// internal/sbi/processor/ue_authentication.go\nlogger.Auth5gAkaLog.Infof(\"res*: %x\\nXres*: %x\\n\",\n    updateConfirmationData.ResStar, ausfCurrentContext.XresStar)\n\nif strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar) {\n    ausfCurrentContext.AuthStatus = models.AusfUeAuthenticationAuthResult_SUCCESS\n    confirmDataRsp.AuthResult = models.AusfUeAuthenticationAuthResult_SUCCESS\n    success = true\n    logger.Auth5gAkaLog.Infoln(\"5G AKA confirmation succeeded\")\n    // ...\n}\n```\n\nFor hexadecimal ASCII strings, `strings.EqualFold()` performs a character comparison that can terminate when a mismatch is found. It is not a constant-time comparison primitive.\n\nThe line immediately before the comparison is more directly exploitable: it writes `XresStar` to INFO logs. Any operator, compromised sidecar, log collector, SIEM user, or local process with access to AUSF logs can read the expected response value for authentication attempts.\n\n#### EAP-AKA': `AT_MAC`, `XMAC`, `XRES`, and `RES`\n\nIn `EapAuthComfirmRequestProcedure()`, the AUSF computes the expected MAC and compares it with the received `AT_MAC` using `bytes.Equal()`:\n\n```go\nK_autStr := ausfCurrentContext.K_aut\nK_aut, _ := hex.DecodeString(K_autStr)\nXMAC := CalculateAtMAC(K_aut, decodeEapAkaPrimePkt.MACInput)\nMAC := decodeEapAkaPrimePkt.Attributes[ausf_context.AT_MAC_ATTRIBUTE].Value\nXRES := ausfCurrentContext.XRES\nRES := hex.EncodeToString(decodeEapAkaPrimePkt.Attributes[ausf_context.AT_RES_ATTRIBUTE].Value)\n\nif !bytes.Equal(MAC, XMAC) {\n    eapOK = false\n    eapErrStr = \"EAP-AKA' integrity check fail\"\n} else if XRES == RES {\n    logger.AuthELog.Infoln(\"Correct RES value, EAP-AKA' auth succeed\")\n    // ...\n}\n```\n\n`bytes.Equal()` is not specified as a constant-time cryptographic comparison. The subsequent `XRES == RES` string comparison is also not constant-time. The correct primitive for comparing authentication tags and secret response values in Go is `crypto/subtle.ConstantTimeCompare`, after validating and normalizing input length and encoding.\n\nThe EAP-AKA' case is harder to exploit remotely than the 5G-AKA case because the `XRES == RES` comparison is reached only if `AT_MAC` is valid. Producing a valid `AT_MAC` requires session-specific `K_aut`.\n\n### Evidence\n\n#### Static evidence\n\nStatic analysis confirmed:\n\n- `strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar)` in the 5G-AKA confirmation path.\n- `logger.Auth5gAkaLog.Infof(\"res*: %x\\nXres*: %x\\n\", ...)` immediately before the comparison.\n- `bytes.Equal(MAC, XMAC)` in the EAP-AKA' confirmation path.\n- `XRES == RES` in the EAP-AKA' confirmation path.\n- `crypto/subtle` is absent from the AUSF authentication processor code.\n\nInternal evidence:\n\n```text\nhallazgos/finding10-hres-timing/evidencia/20260526-090151-static-analysis/\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-094642-static-analysis/\n```\n\n#### 5G-AKA timing and logging evidence\n\nA timing PoC sent 500 iterations per condition over loopback HTTP/SBI:\n\n```text\nCondition A: mismatch near the start\nCondition B: mismatch in the middle\nCondition C: mismatch near the end\nCondition D: full match\n```\n\nThe comparator-position signal was not distinguishable from HTTP noise:\n\n```text\nDelta C-A: approximately -1.5 us\n2-sigma noise threshold: approximately 557 us\nResult: SIGNAL NOT CLEAR\n```\n\nThis is consistent with the expected signal-to-noise ratio: the comparator-level timing difference is in the nanosecond range, while the HTTP/SBI path adds hundreds of microseconds of variance.\n\nThe same lab run confirmed that AUSF logs include `XresStar` in plaintext at INFO level. This does not require statistical inference.\n\nInternal evidence:\n\n```text\nhallazgos/finding10-hres-timing/evidencia/20260526-093558-timing-poc/\n```\n\n#### EAP-AKA' timing evidence\n\nA timing PoC sent 500 iterations per condition against the EAP-AKA' confirmation path:\n\n```text\nA: first MAC byte incorrect\nB: first 8 MAC bytes correct\nC: MAC correct, XRES incorrect\nD: MAC correct, XRES correct\n```\n\nObserved medians were all around 464-467 us, and the HTTP-level timing signal was not detectable:\n\n```text\nA: 466.6 us\nB: 466.5 us\nC: 464.2 us\nD: 464.2 us\nDelta D-A: approximately -2.4 us\n2-sigma noise threshold: approximately 716 us\nResult: SIGNAL NOT CLEAR\n```\n\nThis confirms the expected practical limitation of a remote HTTP timing attack.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-103822-timing-poc/\n```\n\n#### Local CPU benchmark for `bytes.Equal()`\n\nA direct Go microbenchmark without HTTP overhead measured `bytes.Equal()` for 16-byte values. The raw benchmark data showed a monotonic increase as more leading bytes matched. The median delta from `N=0` matching bytes to `N=15` matching bytes was roughly 0.31 ns, or more than 20%.\n\nThis confirms that the local comparator is not position-independent at CPU level, even though the signal is too small to exploit remotely over HTTP in normal conditions.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-104842-cpu-benchmark/\n```\n\n#### Uprobe path confirmation\n\nLinux uprobes on the live AUSF process confirmed that requests reach the relevant comparison paths:\n\n- MAC comparison path is hit for both failing and successful EAP-AKA' attempts.\n- XRES comparison path is hit only when MAC verification passes.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-053510-ebpf-uprobe/\n```\n\n### Impact\n\nThere are two impact classes.\n\n#### Sensitive value in logs\n\nThe 5G-AKA path logs `XRES*`, the expected response value, at INFO level. In deployments where AUSF logs are collected centrally or are readable by lower-privileged operators, infrastructure agents, compromised containers, or log-processing systems, this exposes authentication material that should remain internal to the authentication procedure.\n\nThe exact exploitability depends on whether the attacker can correlate log access with an active authentication context and submit the confirmation before the context is consumed or failed. Regardless, writing `XRES*` to application logs is an unsafe handling of authentication material.\n\n#### Timing side channel / cryptographic hardening issue\n\nThe non-constant-time comparisons are real code issues and should be fixed, but we did not demonstrate a practical remote timing oracle over HTTP/SBI. The measured comparator signal is too small relative to HTTP noise in the lab.\n\nThe risk is higher in environments where an attacker has a lower-noise measurement point, local co-residency, kernel tracing capabilities, or another side channel that can observe the comparison more directly.\n\n### Suggested remediation\n\n1. Remove `XRES*`, `RES*`, `XRES`, `RES`, `K_aut`, `AT_MAC`, and derived authentication material from INFO logs. If logging is necessary, log only metadata such as the authentication context ID, SUPI/SUCI in redacted form, result, and failure class.\n\n2. Replace `strings.EqualFold()` and string `==` comparisons for authentication values with constant-time comparisons.\n\n3. Normalize encodings before comparison. For hex-encoded values, decode both inputs first, validate expected lengths, and then compare fixed-size byte slices.\n\nExample for 5G-AKA:\n\n```go\nresStar, err1 := hex.DecodeString(updateConfirmationData.ResStar)\nxresStar, err2 := hex.DecodeString(ausfCurrentContext.XresStar)\n\nif err1 == nil \u0026\u0026 err2 == nil \u0026\u0026\n    len(resStar) == len(xresStar) \u0026\u0026\n    subtle.ConstantTimeCompare(resStar, xresStar) == 1 {\n    // success\n} else {\n    // failure\n}\n```\n\nExample for EAP-AKA' MAC:\n\n```go\nif len(MAC) != len(XMAC) || subtle.ConstantTimeCompare(MAC, XMAC) != 1 {\n    eapOK = false\n    eapErrStr = \"EAP-AKA' integrity check fail\"\n}\n```\n\nExample for EAP-AKA' XRES:\n\n```go\nres, err1 := hex.DecodeString(RES)\nxres, err2 := hex.DecodeString(XRES)\n\nif err1 == nil \u0026\u0026 err2 == nil \u0026\u0026\n    len(res) == len(xres) \u0026\u0026\n    subtle.ConstantTimeCompare(res, xres) == 1 {\n    // success\n}\n```\n\n4. Add unit tests that ensure authentication values are not written to logs.\n\n5. Consider avoiding a second UDM notification call in the 5G-AKA failure path if the first failure notification already reports the result. In the lab, failure performed two UDM calls while success performed one; this creates a coarse success/failure timing difference, although that result is already visible through the API response.\n\n### Prior art / non-duplication note\n\nKnown recent free5GC AUSF issues such as CVE-2026-33063 concern different failure modes and code paths. This report concerns cryptographic comparison and logging behavior in `internal/sbi/processor/ue_authentication.go`.","status":"published","published":"2026-08-28T22:26:16Z","modified":"2026-08-28T22:26:16Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"low"}],"cwes":["CWE-208","CWE-385","CWE-532"],"updated_at":"2026-11-02T14:41:08.084849Z"}],"nvd":[{"id":"CVE-2026-55785","description":"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.","status":"published","published":"2026-08-28T23:17:07.697Z","modified":"2026-09-08T21:11:31.703Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"low","assessor":"secondary"}],"cwes":["CWE-208","CWE-385","CWE-532"],"updated_at":"2026-11-02T14:12:42.366888Z"}],"osv":[{"id":"CVE-2026-55785","title":"free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA","description":"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.","status":"published","published":"2026-08-28T22:25:06.814Z","modified":"2026-10-28T02:30:29.158896688Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"low"}],"cwes":["CWE-208","CWE-385","CWE-532"],"updated_at":"2026-11-02T15:45:11.609219Z"},{"id":"GHSA-fp46-6vfw-gc9c","title":"free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA","description":"### Summary\n\nThe AUSF component of free5GC compares authentication response values with normal Go equality helpers instead of constant-time cryptographic comparison functions.\n\nTwo authentication flows are affected in `internal/sbi/processor/ue_authentication.go`:\n\n1. 5G-AKA confirmation compares `RES*` and `XRES*` with `strings.EqualFold()`.\n2. EAP-AKA' confirmation compares `AT_MAC` with `bytes.Equal()` and compares `XRES` and `RES` with `==`.\n\nThese functions are not designed to be constant-time cryptographic comparators and may return earlier depending on the location of the first mismatch.\n\nAdditionally, 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.\n\nThe 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.\n\nConfirmed on `github.com/free5gc/ausf` v1.4.4 and current main as of the May 2026 analysis.\n\n### Details\n\n#### 5G-AKA: `RES*` / `XRES*`\n\nIn `Auth5gAkaComfirmRequestProcedure()`, the AUSF logs both values and then compares them with `strings.EqualFold()`:\n\n```go\n// internal/sbi/processor/ue_authentication.go\nlogger.Auth5gAkaLog.Infof(\"res*: %x\\nXres*: %x\\n\",\n    updateConfirmationData.ResStar, ausfCurrentContext.XresStar)\n\nif strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar) {\n    ausfCurrentContext.AuthStatus = models.AusfUeAuthenticationAuthResult_SUCCESS\n    confirmDataRsp.AuthResult = models.AusfUeAuthenticationAuthResult_SUCCESS\n    success = true\n    logger.Auth5gAkaLog.Infoln(\"5G AKA confirmation succeeded\")\n    // ...\n}\n```\n\nFor hexadecimal ASCII strings, `strings.EqualFold()` performs a character comparison that can terminate when a mismatch is found. It is not a constant-time comparison primitive.\n\nThe line immediately before the comparison is more directly exploitable: it writes `XresStar` to INFO logs. Any operator, compromised sidecar, log collector, SIEM user, or local process with access to AUSF logs can read the expected response value for authentication attempts.\n\n#### EAP-AKA': `AT_MAC`, `XMAC`, `XRES`, and `RES`\n\nIn `EapAuthComfirmRequestProcedure()`, the AUSF computes the expected MAC and compares it with the received `AT_MAC` using `bytes.Equal()`:\n\n```go\nK_autStr := ausfCurrentContext.K_aut\nK_aut, _ := hex.DecodeString(K_autStr)\nXMAC := CalculateAtMAC(K_aut, decodeEapAkaPrimePkt.MACInput)\nMAC := decodeEapAkaPrimePkt.Attributes[ausf_context.AT_MAC_ATTRIBUTE].Value\nXRES := ausfCurrentContext.XRES\nRES := hex.EncodeToString(decodeEapAkaPrimePkt.Attributes[ausf_context.AT_RES_ATTRIBUTE].Value)\n\nif !bytes.Equal(MAC, XMAC) {\n    eapOK = false\n    eapErrStr = \"EAP-AKA' integrity check fail\"\n} else if XRES == RES {\n    logger.AuthELog.Infoln(\"Correct RES value, EAP-AKA' auth succeed\")\n    // ...\n}\n```\n\n`bytes.Equal()` is not specified as a constant-time cryptographic comparison. The subsequent `XRES == RES` string comparison is also not constant-time. The correct primitive for comparing authentication tags and secret response values in Go is `crypto/subtle.ConstantTimeCompare`, after validating and normalizing input length and encoding.\n\nThe EAP-AKA' case is harder to exploit remotely than the 5G-AKA case because the `XRES == RES` comparison is reached only if `AT_MAC` is valid. Producing a valid `AT_MAC` requires session-specific `K_aut`.\n\n### Evidence\n\n#### Static evidence\n\nStatic analysis confirmed:\n\n- `strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar)` in the 5G-AKA confirmation path.\n- `logger.Auth5gAkaLog.Infof(\"res*: %x\\nXres*: %x\\n\", ...)` immediately before the comparison.\n- `bytes.Equal(MAC, XMAC)` in the EAP-AKA' confirmation path.\n- `XRES == RES` in the EAP-AKA' confirmation path.\n- `crypto/subtle` is absent from the AUSF authentication processor code.\n\nInternal evidence:\n\n```text\nhallazgos/finding10-hres-timing/evidencia/20260526-090151-static-analysis/\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-094642-static-analysis/\n```\n\n#### 5G-AKA timing and logging evidence\n\nA timing PoC sent 500 iterations per condition over loopback HTTP/SBI:\n\n```text\nCondition A: mismatch near the start\nCondition B: mismatch in the middle\nCondition C: mismatch near the end\nCondition D: full match\n```\n\nThe comparator-position signal was not distinguishable from HTTP noise:\n\n```text\nDelta C-A: approximately -1.5 us\n2-sigma noise threshold: approximately 557 us\nResult: SIGNAL NOT CLEAR\n```\n\nThis is consistent with the expected signal-to-noise ratio: the comparator-level timing difference is in the nanosecond range, while the HTTP/SBI path adds hundreds of microseconds of variance.\n\nThe same lab run confirmed that AUSF logs include `XresStar` in plaintext at INFO level. This does not require statistical inference.\n\nInternal evidence:\n\n```text\nhallazgos/finding10-hres-timing/evidencia/20260526-093558-timing-poc/\n```\n\n#### EAP-AKA' timing evidence\n\nA timing PoC sent 500 iterations per condition against the EAP-AKA' confirmation path:\n\n```text\nA: first MAC byte incorrect\nB: first 8 MAC bytes correct\nC: MAC correct, XRES incorrect\nD: MAC correct, XRES correct\n```\n\nObserved medians were all around 464-467 us, and the HTTP-level timing signal was not detectable:\n\n```text\nA: 466.6 us\nB: 466.5 us\nC: 464.2 us\nD: 464.2 us\nDelta D-A: approximately -2.4 us\n2-sigma noise threshold: approximately 716 us\nResult: SIGNAL NOT CLEAR\n```\n\nThis confirms the expected practical limitation of a remote HTTP timing attack.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-103822-timing-poc/\n```\n\n#### Local CPU benchmark for `bytes.Equal()`\n\nA direct Go microbenchmark without HTTP overhead measured `bytes.Equal()` for 16-byte values. The raw benchmark data showed a monotonic increase as more leading bytes matched. The median delta from `N=0` matching bytes to `N=15` matching bytes was roughly 0.31 ns, or more than 20%.\n\nThis confirms that the local comparator is not position-independent at CPU level, even though the signal is too small to exploit remotely over HTTP in normal conditions.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-104842-cpu-benchmark/\n```\n\n#### Uprobe path confirmation\n\nLinux uprobes on the live AUSF process confirmed that requests reach the relevant comparison paths:\n\n- MAC comparison path is hit for both failing and successful EAP-AKA' attempts.\n- XRES comparison path is hit only when MAC verification passes.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-053510-ebpf-uprobe/\n```\n\n### Impact\n\nThere are two impact classes.\n\n#### Sensitive value in logs\n\nThe 5G-AKA path logs `XRES*`, the expected response value, at INFO level. In deployments where AUSF logs are collected centrally or are readable by lower-privileged operators, infrastructure agents, compromised containers, or log-processing systems, this exposes authentication material that should remain internal to the authentication procedure.\n\nThe exact exploitability depends on whether the attacker can correlate log access with an active authentication context and submit the confirmation before the context is consumed or failed. Regardless, writing `XRES*` to application logs is an unsafe handling of authentication material.\n\n#### Timing side channel / cryptographic hardening issue\n\nThe non-constant-time comparisons are real code issues and should be fixed, but we did not demonstrate a practical remote timing oracle over HTTP/SBI. The measured comparator signal is too small relative to HTTP noise in the lab.\n\nThe risk is higher in environments where an attacker has a lower-noise measurement point, local co-residency, kernel tracing capabilities, or another side channel that can observe the comparison more directly.\n\n### Suggested remediation\n\n1. Remove `XRES*`, `RES*`, `XRES`, `RES`, `K_aut`, `AT_MAC`, and derived authentication material from INFO logs. If logging is necessary, log only metadata such as the authentication context ID, SUPI/SUCI in redacted form, result, and failure class.\n\n2. Replace `strings.EqualFold()` and string `==` comparisons for authentication values with constant-time comparisons.\n\n3. Normalize encodings before comparison. For hex-encoded values, decode both inputs first, validate expected lengths, and then compare fixed-size byte slices.\n\nExample for 5G-AKA:\n\n```go\nresStar, err1 := hex.DecodeString(updateConfirmationData.ResStar)\nxresStar, err2 := hex.DecodeString(ausfCurrentContext.XresStar)\n\nif err1 == nil \u0026\u0026 err2 == nil \u0026\u0026\n    len(resStar) == len(xresStar) \u0026\u0026\n    subtle.ConstantTimeCompare(resStar, xresStar) == 1 {\n    // success\n} else {\n    // failure\n}\n```\n\nExample for EAP-AKA' MAC:\n\n```go\nif len(MAC) != len(XMAC) || subtle.ConstantTimeCompare(MAC, XMAC) != 1 {\n    eapOK = false\n    eapErrStr = \"EAP-AKA' integrity check fail\"\n}\n```\n\nExample for EAP-AKA' XRES:\n\n```go\nres, err1 := hex.DecodeString(RES)\nxres, err2 := hex.DecodeString(XRES)\n\nif err1 == nil \u0026\u0026 err2 == nil \u0026\u0026\n    len(res) == len(xres) \u0026\u0026\n    subtle.ConstantTimeCompare(res, xres) == 1 {\n    // success\n}\n```\n\n4. Add unit tests that ensure authentication values are not written to logs.\n\n5. Consider avoiding a second UDM notification call in the 5G-AKA failure path if the first failure notification already reports the result. In the lab, failure performed two UDM calls while success performed one; this creates a coarse success/failure timing difference, although that result is already visible through the API response.\n\n### Prior art / non-duplication note\n\nKnown recent free5GC AUSF issues such as CVE-2026-33063 concern different failure modes and code paths. This report concerns cryptographic comparison and logging behavior in `internal/sbi/processor/ue_authentication.go`.","status":"published","published":"2026-08-28T22:26:16Z","modified":"2026-09-02T19:55:42.818084205Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","level":"low"}],"cwes":["CWE-208","CWE-385","CWE-532"],"updated_at":"2026-11-02T15:46:46.760785Z"},{"id":"GO-2026-6328","title":"free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA in github.com/free5gc/ausf","description":"free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA in github.com/free5gc/ausf","status":"published","published":"2026-09-02T18:37:27Z","modified":"2026-09-02T19:45:14.13501115Z","updated_at":"2026-11-02T15:47:03.11707Z"},{"id":"openSUSE-SU-2026:21812-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:52:09Z","modified":"2026-09-10T18:23:18.964541257Z","updated_at":"2026-11-02T16:58:42.426393Z"},{"id":"SUSE-SU-2026:23692-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.31116925Z","updated_at":"2026-11-02T15:54:03.991985Z"},{"id":"SUSE-SU-2026:23712-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.805639295Z","updated_at":"2026-11-02T15:54:03.991985Z"}]}}