{"id":"CVE-2026-55245","aliases":["EUVD-2026-67860","GHSA-w98g-5w9p-p3rc","GO-2026-6320","SUSE-SU-2026:23692-1","SUSE-SU-2026:23712-1","openSUSE-SU-2026:21812-1"],"status":"published","title":"Bifrost: SSRF deny-list incomplete: isPublicIP permits CGNAT, IPv6 6to4/NAT64, and site-local in FetchAndEncodeURL","description":"Bifrost is an enterprise AI gateway for routing requests to model providers. Prior to 1.5.17, the isPublicIP function in core/providers/utils/fetch.go, reached through FetchAndEncodeURL for Bedrock and Vertex image or document URLs, classifies Carrier-Grade NAT 100.64.0.0/10, IPv6 6to4 2002::/16, NAT64 64:ff9b::/96 and 64:ff9b:1::/48, and deprecated IPv6 site-local fec0::/10 addresses as public. A remote attacker who controls a multimodal request URL can make the gateway fetch internal services, including a cloud instance metadata endpoint encoded through 6to4 or NAT64. This issue is fixed in version 1.5.17.","severity":{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00611,"percentile":0.49581,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-918"],"published":"2026-08-28T18:24:16Z","modified":"2026-10-28T02:30:47Z","fixes":[{"ecosystem":"Go","package":"github.com/maximhq/bifrost/core","fixed_in":["1.5.17"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/maximhq/bifrost/core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.5.17"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/maximhq/bifrost/core","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.5.17"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/maximhq/bifrost/core","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.5.17"}]}]},{"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":"brokercap","product":"bifrost"},{"vendor":"maximhq","product":"bifrost"}],"references":[{"url":"https://github.com/maximhq/bifrost/security/advisories/GHSA-w98g-5w9p-p3rc","tags":["x_refsource_CONFIRM","exploit","advisory","web"]},{"url":"https://github.com/maximhq/bifrost/pull/4092","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/maximhq/bifrost/commit/54ec431fc5255ff42c36420d88549477e0b33d89","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/maximhq/bifrost/releases/tag/core/v1.5.17","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-w98g-5w9p-p3rc"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55245.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-55245","tags":["advisory"]},{"url":"https://github.com/maximhq/bifrost","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-55245","title":"Bifrost: SSRF deny-list incomplete: isPublicIP permits CGNAT, IPv6 6to4/NAT64, and site-local in FetchAndEncodeURL","description":"Bifrost is an enterprise AI gateway for routing requests to model providers. Prior to 1.5.17, the isPublicIP function in core/providers/utils/fetch.go, reached through FetchAndEncodeURL for Bedrock and Vertex image or document URLs, classifies Carrier-Grade NAT 100.64.0.0/10, IPv6 6to4 2002::/16, NAT64 64:ff9b::/96 and 64:ff9b:1::/48, and deprecated IPv6 site-local fec0::/10 addresses as public. A remote attacker who controls a multimodal request URL can make the gateway fetch internal services, including a cloud instance metadata endpoint encoded through 6to4 or NAT64. This issue is fixed in version 1.5.17.","status":"published","published":"2026-08-28T18:24:16.723Z","modified":"2026-08-28T19:54:10.966Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high","assessor":"cna"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:20:12.260247Z"}],"euvd":[{"id":"EUVD-2026-67860","description":"Bifrost is an enterprise AI gateway for routing requests to model providers. Prior to 1.5.17, the isPublicIP function in core/providers/utils/fetch.go, reached through FetchAndEncodeURL for Bedrock and Vertex image or document URLs, classifies Carrier-Grade NAT 100.64.0.0/10, IPv6 6to4 2002::/16, NAT64 64:ff9b::/96 and 64:ff9b:1::/48, and deprecated IPv6 site-local fec0::/10 addresses as public. A remote attacker who controls a multimodal request URL can make the gateway fetch internal services, including a cloud instance metadata endpoint encoded through 6to4 or NAT64. This issue is fixed in version 1.5.17.","status":"published","published":"2026-08-28T18:24:16Z","modified":"2026-08-28T19:54:10Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T18:01:22.342607Z"}],"ghsa":[{"id":"GHSA-w98g-5w9p-p3rc","title":"Bifrost's SSRF deny-list is incomplete: isPublicIP permits CGNAT, IPv6 6to4/NAT64, and site-local in FetchAndEncodeURL","description":"## Summary\n\n`isPublicIP` in `core/providers/utils/fetch.go` — the SSRF deny-list that gates `FetchAndEncodeURL` — does not reject several routable address ranges that map onto internal infrastructure. Carrier-Grade NAT (`100.64.0.0/10`, RFC 6598), IPv6 6to4 (`2002::/16`), NAT64 (`64:ff9b::/96` and `64:ff9b:1::/48`), and deprecated IPv6 site-local (`fec0::/10`) are all classified as public and permitted. An attacker who controls a multimodal image/document URL in a Bedrock or Vertex request body can drive the gateway to fetch internal services it should not reach — including the cloud instance-metadata endpoint via the 6to4 / NAT64 embeddings of `169.254.169.254`.\n\nThe rest of the fetch hardening is correct and is **not** part of this report: the dial-time `LookupIP` + pin to `ips[0]` closes the DNS-rebinding TOCTOU, `CheckRedirect` re-validates redirect targets, the scheme gate, the 25 MiB cap, and the 20 s timeout all work. This is purely a residual IP-classification gap in `isPublicIP`.\n\n## Affected component\n\n- File: `core/providers/utils/fetch.go`, function `isPublicIP` (lines 107-118), reached only through `FetchAndEncodeURL` (line 28).\n- Go module: `github.com/maximhq/bifrost/core`\n- Version: confirmed on the current `dev` HEAD `f415c144678bd4b411d74a1c1f85f18652833224` (`core/version` = `1.5.15`).\n\n## Vulnerable code\n\n```go\nfunc isPublicIP(ip net.IP) bool {\n\taddr, ok := netip.AddrFromSlice(ip)\n\tif !ok {\n\t\treturn false\n\t}\n\taddr = addr.Unmap()\n\tif addr.IsLoopback() || addr.IsPrivate() || addr.IsLinkLocalUnicast() || addr.IsLinkLocalMulticast() ||\n\t\taddr.IsMulticast() || addr.IsUnspecified() || addr.IsInterfaceLocalMulticast() {\n\t\treturn false\n\t}\n\treturn true\n}\n```\n\n`addr.IsPrivate()` covers only RFC 1918 + RFC 4193 (`fc00::/7`); it does **not** cover CGNAT `100.64.0.0/10`. `addr.Unmap()` only collapses the `::ffff:0:0/96` IPv4-mapped form, so 6to4 (`2002::/16`) and NAT64 (`64:ff9b::/96`, `64:ff9b:1::/48`) IPv6 representations of internal/link-local IPv4 are never reduced to their embedded address and slip past every check. `fec0::/10` (deprecated IPv6 site-local) is likewise not matched by any of the helpers used.\n\n## Attack surface / who can trigger it\n\n`FetchAndEncodeURL` is invoked from the multimodal request-handling path of two providers:\n\n- `core/providers/bedrock/utils.go:1073` (document `block.File.FileURL`), `:1187` (image URL via `convertImageToBedrockSource`)\n- `core/providers/vertex/vertex.go:402` (document `block.File.FileURL`)\n\nThese URLs come straight from the client's chat-completion request body (a remote image/document URL in a multimodal content block). `SanitizeImageURL` (`core/schemas/utils.go:180`) only checks the scheme and a non-empty host — it performs no address filtering — so `isPublicIP` is the sole network guard, and it is always on (no opt-out flag). On a multi-tenant or shared gateway deployment, any client able to send a request can choose the fetch target.\n\n## Impact\n\nServer-side request forgery from the gateway into internal address space that the deny-list intends to block:\n\n- **CGNAT `100.64.0.0/10`** — reachable anywhere the internal fabric uses RFC 6598 space (common in Kubernetes overlay networks and cloud NAT fabrics). Live on any such host with no extra preconditions.\n- **6to4 `2002:a9fe:a9fe::` and NAT64 `64:ff9b::a9fe:a9fe`** — both embed `169.254.169.254`, the cloud instance-metadata endpoint. On a dual-stack or NAT64-enabled host (the default on AWS/GCP IPv6-only subnets) these reach IMDS even though the direct `169.254.169.254` and `::ffff:169.254.169.254` forms are correctly blocked.\n- **`fec0::/10`** — deprecated site-local, still routed on some networks.\n\nCWE-918 (Server-Side Request Forgery). Self-discovered while reviewing IP-classification deny-lists; the missing dimensions match the classes accepted as HIGH in the canonical references below.\n\n## Proof of concept\n\nA test placed in-package (`core/providers/utils/`) drives the **real** `FetchAndEncodeURL` — real `http.Client`, real `Transport.DialContext`, real `isPublicIP` — and classifies each target by whether `isPublicIP` let it past the gate. A `blocked fetch to non-public address` error means the gate rejected it before any dial (safe); any other outcome means the gate permitted the dial to a forbidden range (SSRF reachable).\n\n```go\npackage utils\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"strings\"\n\t\"testing\"\n\t\"time\"\n)\n\nfunc TestSSRFGateDecision(t *testing.T) {\n\tcases := []struct{ name, url string }{\n\t\t{\"CGNAT-100.64\", \"http://100.64.1.1:9/\"},\n\t\t{\"CGNAT-100.127\", \"http://100.127.255.254:9/\"},\n\t\t{\"6to4-IMDS\", \"http://[2002:a9fe:a9fe::]:9/\"},\n\t\t{\"NAT64-IMDS\", \"http://[64:ff9b::a9fe:a9fe]:9/\"},\n\t\t{\"NAT64-local-IMDS\", \"http://[64:ff9b:1::a9fe:a9fe]:9/\"},\n\t\t{\"sitelocal-fec0\", \"http://[fec0::1]:9/\"},\n\t\t// controls (must be rejected at the gate):\n\t\t{\"CONTROL-direct-IMDS\", \"http://169.254.169.254:9/\"},\n\t\t{\"CONTROL-RFC1918\", \"http://10.0.0.1:9/\"},\n\t\t{\"CONTROL-loopback\", \"http://127.0.0.1:9/\"},\n\t\t{\"CONTROL-mapped-IMDS\", \"http://[::ffff:169.254.169.254]:9/\"},\n\t}\n\tfor _, c := range cases {\n\t\tctx, cancel := context.WithTimeout(context.Background(), 4*time.Second)\n\t\t_, _, err := FetchAndEncodeURL(ctx, c.url)\n\t\tcancel()\n\t\tgateBlocked := err != nil \u0026\u0026 strings.Contains(err.Error(), \"blocked fetch to non-public address\")\n\t\tfmt.Printf(\"%-22s gateBlock=%-6v %v\\n\", c.name, gateBlocked, err)\n\t}\n}\n```\n\nVerbatim output (`go test ./providers/utils/ -run TestSSRFGateDecision -v` against HEAD `f415c14`, Go 1.26.1):\n\n```\n=== bifrost FetchAndEncodeURL SSRF gate decision (REAL code path) ===\ntarget                 gateBlock  verbatim error / outcome\n----------------------------------------------------------------------------------------------------\nCGNAT-100.64           false      failed to fetch from \"http://100.64.1.1:9/\": Get \"http://100.64.1.1:9/\": context deadline exceeded\nCGNAT-100.127          false      failed to fetch from \"http://100.127.255.254:9/\": Get \"http://100.127.255.254:9/\": context deadline exceeded\n6to4-IMDS              false      failed to fetch from \"http://[2002:a9fe:a9fe::]:9/\": Get \"http://[2002:a9fe:a9fe::]:9/\": EOF\nNAT64-IMDS             false      failed to fetch from \"http://[64:ff9b::a9fe:a9fe]:9/\": Get \"http://[64:ff9b::a9fe:a9fe]:9/\": context deadline exceeded\nNAT64-local-IMDS       false      failed to fetch from \"http://[64:ff9b:1::a9fe:a9fe]:9/\": Get \"http://[64:ff9b:1::a9fe:a9fe]:9/\": context deadline exceeded\nsitelocal-fec0         false      failed to fetch from \"http://[fec0::1]:9/\": Get \"http://[fec0::1]:9/\": EOF\nCONTROL-direct-IMDS    true       failed to fetch from \"http://169.254.169.254:9/\": Get \"http://169.254.169.254:9/\": blocked fetch to non-public address 169.254.169.254\nCONTROL-RFC1918        true       failed to fetch from \"http://10.0.0.1:9/\": Get \"http://10.0.0.1:9/\": blocked fetch to non-public address 10.0.0.1\nCONTROL-loopback       true       failed to fetch from \"http://127.0.0.1:9/\": Get \"http://127.0.0.1:9/\": blocked fetch to non-public address 127.0.0.1\nCONTROL-mapped-IMDS    true       failed to fetch from \"http://[::ffff:169.254.169.254]:9/\": Get \"http://[::ffff:169.254.169.254]:9/\": blocked fetch to non-public address 169.254.169.254\n```\n\nReading the result: every control (direct IMDS, RFC 1918, loopback, IPv4-mapped IMDS) is rejected **at the gate** with `blocked fetch to non-public address` and no socket is ever opened. Every CGNAT / 6to4 / NAT64 / site-local target instead passes `isPublicIP` and proceeds to the network dial — observed as `context deadline exceeded` or `EOF` (a real connection attempt), never `blocked fetch to non-public address`. The `blocked` vs `dial-attempted` split isolates the `isPublicIP` classification defect precisely.\n\nA standalone re-check of the verbatim `isPublicIP` body confirms the classification directly (Go 1.26.1):\n\n```\n100.64.0.1             isPublicIP=true   (CGNAT — should be blocked)\n100.127.255.254        isPublicIP=true   (CGNAT)\n2002:a9fe:a9fe::       isPublicIP=true   (6to4 -\u003e 169.254.169.254)\n64:ff9b::a9fe:a9fe     isPublicIP=true   (NAT64 -\u003e 169.254.169.254)\n64:ff9b:1::a9fe:a9fe   isPublicIP=true   (NAT64 local-use -\u003e 169.254.169.254)\nfec0::1                isPublicIP=true   (deprecated site-local)\n169.254.169.254        isPublicIP=false  (direct IMDS — correctly blocked, control)\n::ffff:169.254.169.254 isPublicIP=false  (IPv4-mapped — correctly blocked, control)\n8.8.8.8                isPublicIP=true   (public — correctly allowed, control)\n```\n\n### Honest scope note\n\nThe test host used for verification has no CGNAT/NAT64 routing that returns to a local recorder, so I did not capture live instance-metadata bytes here — the connection lands on the upstream NAT or times out. The 6to4/NAT64 vectors require a dual-stack or NAT64-enabled host to reach IMDS, and the CGNAT vector requires the deployment's internal network to use `100.64.0.0/10`. These are the same routing preconditions the references below were accepted under. The defect demonstrated above is unconditional: `isPublicIP` permits the forbidden ranges on every host.\n\n## References (canonical dimension precedents)\n\n- CVE-2026-45741 / GHSA-86m8-88fq-xfxp — Gotenberg `IsPublicIP` IPv6 6to4 / NAT64 / site-local bypass; same Go `netip` + `Unmap` gap.\n- GHSA-5jh9-2h63-pw4q — CC-Tweaked NAT64 (`64:ff9b::/96`) bypass; their fix adds `isCarrierGradeNatAddress` (CGNAT) + NAT64 handling.\n\n## Suggested fix\n\nIn `isPublicIP`, after `Unmap()`:\n\n1. Reject CGNAT: `100.64.0.0/10` for IPv4 (and the `::ffff:100.64.0.0/106` mapped form is already handled by `Unmap`).\n2. For IPv6, extract any embedded IPv4 and re-run the classification on it: 6to4 (`2002::/16` -\u003e bytes 2-5), NAT64 well-known (`64:ff9b::/96`) and local-use (`64:ff9b:1::/48`) -\u003e low 32 bits. Then apply the same loopback/private/link-local/CGNAT checks to the extracted IPv4.\n3. Reject deprecated site-local `fec0::/10`.","status":"published","published":"2026-08-28T18:26:02Z","modified":"2026-08-28T18:26:04Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:41:08.084849Z"}],"nvd":[{"id":"CVE-2026-55245","description":"Bifrost is an enterprise AI gateway for routing requests to model providers. Prior to 1.5.17, the isPublicIP function in core/providers/utils/fetch.go, reached through FetchAndEncodeURL for Bedrock and Vertex image or document URLs, classifies Carrier-Grade NAT 100.64.0.0/10, IPv6 6to4 2002::/16, NAT64 64:ff9b::/96 and 64:ff9b:1::/48, and deprecated IPv6 site-local fec0::/10 addresses as public. A remote attacker who controls a multimodal request URL can make the gateway fetch internal services, including a cloud instance metadata endpoint encoded through 6to4 or NAT64. This issue is fixed in version 1.5.17.","status":"published","published":"2026-08-28T20:18:26.743Z","modified":"2026-09-09T21:09:13.08Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:12:42.366888Z"}],"osv":[{"id":"CVE-2026-55245","title":"Bifrost: SSRF deny-list incomplete: isPublicIP permits CGNAT, IPv6 6to4/NAT64, and site-local in FetchAndEncodeURL","description":"Bifrost is an enterprise AI gateway for routing requests to model providers. Prior to 1.5.17, the isPublicIP function in core/providers/utils/fetch.go, reached through FetchAndEncodeURL for Bedrock and Vertex image or document URLs, classifies Carrier-Grade NAT 100.64.0.0/10, IPv6 6to4 2002::/16, NAT64 64:ff9b::/96 and 64:ff9b:1::/48, and deprecated IPv6 site-local fec0::/10 addresses as public. A remote attacker who controls a multimodal request URL can make the gateway fetch internal services, including a cloud instance metadata endpoint encoded through 6to4 or NAT64. This issue is fixed in version 1.5.17.","status":"published","published":"2026-08-28T18:24:16.723Z","modified":"2026-10-28T02:30:47.783856555Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T15:45:11.22012Z"},{"id":"GHSA-w98g-5w9p-p3rc","title":"Bifrost's SSRF deny-list is incomplete: isPublicIP permits CGNAT, IPv6 6to4/NAT64, and site-local in FetchAndEncodeURL","description":"## Summary\n\n`isPublicIP` in `core/providers/utils/fetch.go` — the SSRF deny-list that gates `FetchAndEncodeURL` — does not reject several routable address ranges that map onto internal infrastructure. Carrier-Grade NAT (`100.64.0.0/10`, RFC 6598), IPv6 6to4 (`2002::/16`), NAT64 (`64:ff9b::/96` and `64:ff9b:1::/48`), and deprecated IPv6 site-local (`fec0::/10`) are all classified as public and permitted. An attacker who controls a multimodal image/document URL in a Bedrock or Vertex request body can drive the gateway to fetch internal services it should not reach — including the cloud instance-metadata endpoint via the 6to4 / NAT64 embeddings of `169.254.169.254`.\n\nThe rest of the fetch hardening is correct and is **not** part of this report: the dial-time `LookupIP` + pin to `ips[0]` closes the DNS-rebinding TOCTOU, `CheckRedirect` re-validates redirect targets, the scheme gate, the 25 MiB cap, and the 20 s timeout all work. This is purely a residual IP-classification gap in `isPublicIP`.\n\n## Affected component\n\n- File: `core/providers/utils/fetch.go`, function `isPublicIP` (lines 107-118), reached only through `FetchAndEncodeURL` (line 28).\n- Go module: `github.com/maximhq/bifrost/core`\n- Version: confirmed on the current `dev` HEAD `f415c144678bd4b411d74a1c1f85f18652833224` (`core/version` = `1.5.15`).\n\n## Vulnerable code\n\n```go\nfunc isPublicIP(ip net.IP) bool {\n\taddr, ok := netip.AddrFromSlice(ip)\n\tif !ok {\n\t\treturn false\n\t}\n\taddr = addr.Unmap()\n\tif addr.IsLoopback() || addr.IsPrivate() || addr.IsLinkLocalUnicast() || addr.IsLinkLocalMulticast() ||\n\t\taddr.IsMulticast() || addr.IsUnspecified() || addr.IsInterfaceLocalMulticast() {\n\t\treturn false\n\t}\n\treturn true\n}\n```\n\n`addr.IsPrivate()` covers only RFC 1918 + RFC 4193 (`fc00::/7`); it does **not** cover CGNAT `100.64.0.0/10`. `addr.Unmap()` only collapses the `::ffff:0:0/96` IPv4-mapped form, so 6to4 (`2002::/16`) and NAT64 (`64:ff9b::/96`, `64:ff9b:1::/48`) IPv6 representations of internal/link-local IPv4 are never reduced to their embedded address and slip past every check. `fec0::/10` (deprecated IPv6 site-local) is likewise not matched by any of the helpers used.\n\n## Attack surface / who can trigger it\n\n`FetchAndEncodeURL` is invoked from the multimodal request-handling path of two providers:\n\n- `core/providers/bedrock/utils.go:1073` (document `block.File.FileURL`), `:1187` (image URL via `convertImageToBedrockSource`)\n- `core/providers/vertex/vertex.go:402` (document `block.File.FileURL`)\n\nThese URLs come straight from the client's chat-completion request body (a remote image/document URL in a multimodal content block). `SanitizeImageURL` (`core/schemas/utils.go:180`) only checks the scheme and a non-empty host — it performs no address filtering — so `isPublicIP` is the sole network guard, and it is always on (no opt-out flag). On a multi-tenant or shared gateway deployment, any client able to send a request can choose the fetch target.\n\n## Impact\n\nServer-side request forgery from the gateway into internal address space that the deny-list intends to block:\n\n- **CGNAT `100.64.0.0/10`** — reachable anywhere the internal fabric uses RFC 6598 space (common in Kubernetes overlay networks and cloud NAT fabrics). Live on any such host with no extra preconditions.\n- **6to4 `2002:a9fe:a9fe::` and NAT64 `64:ff9b::a9fe:a9fe`** — both embed `169.254.169.254`, the cloud instance-metadata endpoint. On a dual-stack or NAT64-enabled host (the default on AWS/GCP IPv6-only subnets) these reach IMDS even though the direct `169.254.169.254` and `::ffff:169.254.169.254` forms are correctly blocked.\n- **`fec0::/10`** — deprecated site-local, still routed on some networks.\n\nCWE-918 (Server-Side Request Forgery). Self-discovered while reviewing IP-classification deny-lists; the missing dimensions match the classes accepted as HIGH in the canonical references below.\n\n## Proof of concept\n\nA test placed in-package (`core/providers/utils/`) drives the **real** `FetchAndEncodeURL` — real `http.Client`, real `Transport.DialContext`, real `isPublicIP` — and classifies each target by whether `isPublicIP` let it past the gate. A `blocked fetch to non-public address` error means the gate rejected it before any dial (safe); any other outcome means the gate permitted the dial to a forbidden range (SSRF reachable).\n\n```go\npackage utils\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"strings\"\n\t\"testing\"\n\t\"time\"\n)\n\nfunc TestSSRFGateDecision(t *testing.T) {\n\tcases := []struct{ name, url string }{\n\t\t{\"CGNAT-100.64\", \"http://100.64.1.1:9/\"},\n\t\t{\"CGNAT-100.127\", \"http://100.127.255.254:9/\"},\n\t\t{\"6to4-IMDS\", \"http://[2002:a9fe:a9fe::]:9/\"},\n\t\t{\"NAT64-IMDS\", \"http://[64:ff9b::a9fe:a9fe]:9/\"},\n\t\t{\"NAT64-local-IMDS\", \"http://[64:ff9b:1::a9fe:a9fe]:9/\"},\n\t\t{\"sitelocal-fec0\", \"http://[fec0::1]:9/\"},\n\t\t// controls (must be rejected at the gate):\n\t\t{\"CONTROL-direct-IMDS\", \"http://169.254.169.254:9/\"},\n\t\t{\"CONTROL-RFC1918\", \"http://10.0.0.1:9/\"},\n\t\t{\"CONTROL-loopback\", \"http://127.0.0.1:9/\"},\n\t\t{\"CONTROL-mapped-IMDS\", \"http://[::ffff:169.254.169.254]:9/\"},\n\t}\n\tfor _, c := range cases {\n\t\tctx, cancel := context.WithTimeout(context.Background(), 4*time.Second)\n\t\t_, _, err := FetchAndEncodeURL(ctx, c.url)\n\t\tcancel()\n\t\tgateBlocked := err != nil \u0026\u0026 strings.Contains(err.Error(), \"blocked fetch to non-public address\")\n\t\tfmt.Printf(\"%-22s gateBlock=%-6v %v\\n\", c.name, gateBlocked, err)\n\t}\n}\n```\n\nVerbatim output (`go test ./providers/utils/ -run TestSSRFGateDecision -v` against HEAD `f415c14`, Go 1.26.1):\n\n```\n=== bifrost FetchAndEncodeURL SSRF gate decision (REAL code path) ===\ntarget                 gateBlock  verbatim error / outcome\n----------------------------------------------------------------------------------------------------\nCGNAT-100.64           false      failed to fetch from \"http://100.64.1.1:9/\": Get \"http://100.64.1.1:9/\": context deadline exceeded\nCGNAT-100.127          false      failed to fetch from \"http://100.127.255.254:9/\": Get \"http://100.127.255.254:9/\": context deadline exceeded\n6to4-IMDS              false      failed to fetch from \"http://[2002:a9fe:a9fe::]:9/\": Get \"http://[2002:a9fe:a9fe::]:9/\": EOF\nNAT64-IMDS             false      failed to fetch from \"http://[64:ff9b::a9fe:a9fe]:9/\": Get \"http://[64:ff9b::a9fe:a9fe]:9/\": context deadline exceeded\nNAT64-local-IMDS       false      failed to fetch from \"http://[64:ff9b:1::a9fe:a9fe]:9/\": Get \"http://[64:ff9b:1::a9fe:a9fe]:9/\": context deadline exceeded\nsitelocal-fec0         false      failed to fetch from \"http://[fec0::1]:9/\": Get \"http://[fec0::1]:9/\": EOF\nCONTROL-direct-IMDS    true       failed to fetch from \"http://169.254.169.254:9/\": Get \"http://169.254.169.254:9/\": blocked fetch to non-public address 169.254.169.254\nCONTROL-RFC1918        true       failed to fetch from \"http://10.0.0.1:9/\": Get \"http://10.0.0.1:9/\": blocked fetch to non-public address 10.0.0.1\nCONTROL-loopback       true       failed to fetch from \"http://127.0.0.1:9/\": Get \"http://127.0.0.1:9/\": blocked fetch to non-public address 127.0.0.1\nCONTROL-mapped-IMDS    true       failed to fetch from \"http://[::ffff:169.254.169.254]:9/\": Get \"http://[::ffff:169.254.169.254]:9/\": blocked fetch to non-public address 169.254.169.254\n```\n\nReading the result: every control (direct IMDS, RFC 1918, loopback, IPv4-mapped IMDS) is rejected **at the gate** with `blocked fetch to non-public address` and no socket is ever opened. Every CGNAT / 6to4 / NAT64 / site-local target instead passes `isPublicIP` and proceeds to the network dial — observed as `context deadline exceeded` or `EOF` (a real connection attempt), never `blocked fetch to non-public address`. The `blocked` vs `dial-attempted` split isolates the `isPublicIP` classification defect precisely.\n\nA standalone re-check of the verbatim `isPublicIP` body confirms the classification directly (Go 1.26.1):\n\n```\n100.64.0.1             isPublicIP=true   (CGNAT — should be blocked)\n100.127.255.254        isPublicIP=true   (CGNAT)\n2002:a9fe:a9fe::       isPublicIP=true   (6to4 -\u003e 169.254.169.254)\n64:ff9b::a9fe:a9fe     isPublicIP=true   (NAT64 -\u003e 169.254.169.254)\n64:ff9b:1::a9fe:a9fe   isPublicIP=true   (NAT64 local-use -\u003e 169.254.169.254)\nfec0::1                isPublicIP=true   (deprecated site-local)\n169.254.169.254        isPublicIP=false  (direct IMDS — correctly blocked, control)\n::ffff:169.254.169.254 isPublicIP=false  (IPv4-mapped — correctly blocked, control)\n8.8.8.8                isPublicIP=true   (public — correctly allowed, control)\n```\n\n### Honest scope note\n\nThe test host used for verification has no CGNAT/NAT64 routing that returns to a local recorder, so I did not capture live instance-metadata bytes here — the connection lands on the upstream NAT or times out. The 6to4/NAT64 vectors require a dual-stack or NAT64-enabled host to reach IMDS, and the CGNAT vector requires the deployment's internal network to use `100.64.0.0/10`. These are the same routing preconditions the references below were accepted under. The defect demonstrated above is unconditional: `isPublicIP` permits the forbidden ranges on every host.\n\n## References (canonical dimension precedents)\n\n- CVE-2026-45741 / GHSA-86m8-88fq-xfxp — Gotenberg `IsPublicIP` IPv6 6to4 / NAT64 / site-local bypass; same Go `netip` + `Unmap` gap.\n- GHSA-5jh9-2h63-pw4q — CC-Tweaked NAT64 (`64:ff9b::/96`) bypass; their fix adds `isCarrierGradeNatAddress` (CGNAT) + NAT64 handling.\n\n## Suggested fix\n\nIn `isPublicIP`, after `Unmap()`:\n\n1. Reject CGNAT: `100.64.0.0/10` for IPv4 (and the `::ffff:100.64.0.0/106` mapped form is already handled by `Unmap`).\n2. For IPv6, extract any embedded IPv4 and re-run the classification on it: 6to4 (`2002::/16` -\u003e bytes 2-5), NAT64 well-known (`64:ff9b::/96`) and local-use (`64:ff9b:1::/48`) -\u003e low 32 bits. Then apply the same loopback/private/link-local/CGNAT checks to the extracted IPv4.\n3. Reject deprecated site-local `fec0::/10`.","status":"published","published":"2026-08-28T18:26:02Z","modified":"2026-09-02T19:55:46.494426956Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T15:46:58.401149Z"},{"id":"GO-2026-6320","title":"Bifrost's SSRF deny-list is incomplete: isPublicIP permits CGNAT, IPv6 6to4/NAT64, and site-local in FetchAndEncodeURL in github.com/maximhq/bifrost/core","description":"Bifrost's SSRF deny-list is incomplete: isPublicIP permits CGNAT, IPv6 6to4/NAT64, and site-local in FetchAndEncodeURL in github.com/maximhq/bifrost/core","status":"published","published":"2026-09-02T18:37:27Z","modified":"2026-09-02T19:45:12.632040616Z","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"}]}}