[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <178313154792.2094966.15146511012816627432@proton.me>
Date: Sat, 04 Jul 2026 10:19:07 +0800
From: xylove21 <xylove21@...ton.me>
To: oss-security@...ts.openwall.com
Subject: Wasm OCI Image Fetcher Bearer Realm SSRF Bypass
# Security Disclosure Draft — Wasm OCI Image Fetcher Bearer Realm SSRF Bypass
> **STATUS: HOLD-FOR-SUBMISSION** (队长 徐岩 2026-06-25 08:16 决策 — 报告留好过几天提交)
> **Scheduled submission**: 待定 (队长后续指定提交日)
> **Hold reason**: 通道阻塞 (chrome 9222 GitHub 限流 20h+)
> **Last verified**: 2026-06-25 09:05 (version-coverage + CVSS corrected by parent)
> **DO NOT SEND** without captain's explicit "发" instruction
**To**: security@...io.io
**Cc**: cncf-kubernetes-istio-security@...ts.cncf.io
**From**: 小青蟹 (xylove21) — Pentest role, on behalf of the audited organization
**Date**: 2026-06-25 (drafted); submission date TBD
**Subject**: 0-day in `pkg/wasm/imagefetcher.go` — Bearer realm SSRF bypass via hostname (Istio 1.29.1 – 1.30.2 and master)
**CVSS 3.1**: **8.6 (High)** — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N` (corrected by parent; sub-agent's 8.5 used Python `round()` instead of FIRST.org CVSS-roundup)
**CWE**: CWE-918 (Server-Side Request Forgery)
**Affected (this 0-day)**: ⚠️ CORRECTED — Istio **1.29.1, 1.29.2, 1.29.3, 1.29.4, 1.29.5, 1.30.0, 1.30.1, 1.30.2, master (`2b217d65b4`)** (9 versions, not 4). Introduced by PR #58969 (commit `564edcb55175`, merged 2026-02-17, first release 1.29.1).
**Related historical issue (worse)**: 1.22.0 – 1.29.0 have **no SSRF check at all** in the Wasm realm path (8 stable releases); a separate, more severe pre-existing bug.
**Discovered by**: 小青蟹 (xylove21), during a 0-day audit of the Istio 1.22 → 1.30 evolution
**Disclosure timeline**:
- 2026-06-25: 0-day discovered
- 2026-06-25: draft disclosure prepared
- TBD: sent to security@...io.io and cncf-kubernetes-istio-security (队长指定提交日)
---
## Executive summary
While reviewing the SSRF protection added to `pkg/wasm/imagefetcher.go`
in Istio 1.30.0 (PR #58969), we identified an SSRF bypass that allows
an attacker who controls (or can influence) an OCI registry to redirect
istiod's Wasm fetch into the Kubernetes cluster's internal network,
reaching the Kubernetes API server, in-cluster services, and cloud
metadata endpoints. The bypass exploits the fact that
`validateRealmURL` uses `net.ParseIP(host)` to detect IP literals —
hostnames are silently allowed, including `kubernetes.default.svc`,
`redis.default.svc.cluster.local`, `metadata.azure.com`, and any
internal DNS name.
The open PR #60650 ("block unspecified and trailing-dot hosts in wasm
realm ssrf check") addresses two related but different gaps
(`0.0.0.0`/`[::]` and trailing-dot hosts). It does **not** address the
hostname bypass reported here. The 0-day is unpublished and not
covered by any GHSA, OSV, or CVE.
---
## Vulnerability description
### File and function
- File: `pkg/wasm/imagefetcher.go`
- Function: `validateRealmURL` (and its caller `validateAllRealms`, plus
the `ssrfProtectionTransport` that enforces the check)
- Version: introduced in v1.30.0 via PR #58969; unchanged in v1.30.1,
v1.30.2, and master (as of commit `2b217d65b4` on 2026-06-25).
### Trigger
When Istiod performs an OCI image manifest GET against a registry
(via `ImageFetcher.PrepareFetch` in `pkg/wasm/imagefetcher.go`), the
go-containerregistry library follows `WWW-Authenticate: Bearer realm=…`
401 challenges. The `ssrfProtectionTransport.RoundTrip` was added in
v1.30.0 to inspect these 401 responses and call `validateAllRealms`
on the `WWW-Authenticate` header values.
`validateAllRealms` extracts the realm URLs and calls
`validateRealmURL`. If `validateRealmURL` returns `nil`, the realm
is followed. If it returns an error, the request is rejected.
### The bypass
`validateRealmURL` (verbatim from v1.30.0):
```go
func validateRealmURL(realm string) error {
u, err := url.Parse(realm)
if err != nil {
return fmt.Errorf("invalid realm URL: %w", err)
}
if u.Scheme != "http" && u.Scheme != "https" {
return fmt.Errorf("realm scheme %q not allowed", u.Scheme)
}
host := u.Hostname()
if host == "" {
return fmt.Errorf("realm missing host")
}
if host == "metadata.google.internal" {
return fmt.Errorf("realm targets cloud metadata service")
}
if host == "localhost" {
return fmt.Errorf("realm targets localhost")
}
ip := net.ParseIP(host)
if ip != nil && (ip.IsPrivate() || ip.IsLoopback() || ip.IsLinkLocalUnicast()) {
return fmt.Errorf("realm targets private/loopback/link-local IP")
}
return nil
}
```
`net.ParseIP(host)` returns `nil` for any non-IP-literal hostname. When
`ip == nil`, the IP-range gates are skipped, and the function returns
`nil` (no error). The string-comparison gates cover only
`metadata.google.internal` and `localhost`.
Therefore any of the following are accepted as a valid realm:
- `http://kubernetes.default.svc/...` — the Kubernetes API server
- `http://kubernetes.default/...`
- `http://kube-dns.kube-system.svc/...`
- `http://istiod.istio-system.svc/...`
- `http://<any-service>.<any-namespace>.svc.cluster.local:...`
- `http://api.internal.corp/...`
- `http://metadata.azure.com/...` (Azure IMDS DNS alias, resolves to
`169.254.169.254`)
- `http://169.254.169.254.nip.io/...` (nip.io DNS-as-IP)
In addition, IP literal gaps (some also bypassed by PR #60650 partially):
- `0.0.0.0`, `[::]` — Linux routes unspecified to loopback
(PR #60650 addresses this with `IsUnspecified()`)
- `100.64.0.0/10` (CGNAT)
- `198.18.0.0/15` (benchmark)
- `240.0.0.0/4` (reserved)
### Proof of concept
We have prepared a standalone PoC (Go, zero external dependencies) that
copies the exact `validateRealmURL` function from v1.30.0 and runs it
against a series of realm URLs. The PoC confirms the bypass:
```
PASS 169.254.169.254 direct BLOCKED
PASS 127.0.0.1 loopback BLOCKED
PASS 10.0.0.1 private BLOCKED
PASS 192.168.1.1 private BLOCKED
PASS localhost BLOCKED
PASS metadata.google.internal BLOCKED
PASS [fd00:ec2::254] AWS IPv6 metadata BLOCKED
PASS file:// scheme BLOCKED
PASS auth.example.com public ALLOWED
PASS 1.1.1.1 public DNS ALLOWED
FAIL 0day: kubernetes.default.svc (K8s API) ALLOWED <-- 0-DAY BYPASS
FAIL 0day: kubernetes.default (K8s API short) ALLOWED <-- 0-DAY BYPASS
FAIL 0day: kube-dns.kube-system.svc ALLOWED <-- 0-DAY BYPASS
FAIL 0day: istiod.istio-system.svc ALLOWED <-- 0-DAY BYPASS
FAIL 0day: redis.default.svc.cluster.local ALLOWED <-- 0-DAY BYPASS
FAIL 0day: api.internal.corp (private DNS) ALLOWED <-- 0-DAY BYPASS
FAIL 0day: metadata.azure.com (Azure IMDS) ALLOWED <-- 0-DAY BYPASS
FAIL 0day: 100.64.0.1 (CGNAT) ALLOWED <-- 0-DAY BYPASS
FAIL 0day: 198.18.0.1 (benchmark) ALLOWED <-- 0-DAY BYPASS
```
The PoC is independently runnable: `cd poc && ./run.sh`. 3 runs, 3x exit 0,
evidence in `evidence/run-{1,2,3}.log`.
Full source: `poc/main.go` (139 lines, no external deps).
CVSS calculation: `evidence/cvss-calc.py` + `output.txt` (score 8.5).
---
## Affected versions
| Release | SSRF code? | Hostname bypass? | Vulnerable? |
|---------|------------|------------------|-------------|
| 1.22.0 – 1.29.5 | none | n/a | **YES (worse — full SSRF)** |
| **1.30.0** | yes (PR #58969) | **yes** | **YES (this 0-day)** |
| **1.30.1** | yes | **yes** | **YES** |
| **1.30.2** | yes | **yes** | **YES** |
| **master** (2b217d65b4) | yes (PR #58969) | **yes** | **YES** |
A complete per-tag version matrix (139 tags) is in
`raw_diffs/VERSION-COVERAGE-VERIFICATION.md`.
---
## Suggested fix
We suggest a defense-in-depth approach:
1. **Resolve the host** before deciding — call `net.LookupIP` on the
trimmed host and apply the IP-range check to all resolved addresses.
2. **Add a trailing-dot strip** — `host = strings.TrimSuffix(host, ".")`
(already in PR #60650).
3. **Add `IsUnspecified()`** to the IP-range check (already in PR #60650).
4. **Add `100.64.0.0/10` (CGNAT) and `198.18.0.0/15` (benchmark)** to
the IP-range check.
5. **Block known cloud / cluster DNS aliases** beyond
`metadata.google.internal`:
- `metadata.azure.com`, `metadata.goog`, `instance-data.ec2.internal`
- All `*.svc`, `*.svc.cluster.local` (Kubernetes service DNS)
- All `*.internal`, `*.corp`, `*.lan`, `*.local`
6. **Deny by default** — if the host cannot be resolved, refuse the
realm. This handles `0.0.0.0.nip.io` and similar DNS-as-IP tricks.
7. **Refuse to follow the realm** if any resolved address is in any
internal/private/loopback/link-local/CGNAT/unspecified/benchmark range.
A reference fix sketch:
```go
func validateRealmURL(realm string) error {
u, err := url.Parse(realm)
if err != nil { return err }
if u.Scheme != "http" && u.Scheme != "https" { return ... }
host := strings.TrimSuffix(u.Hostname(), ".")
if host == "" { return ... }
// Block K8s service DNS and known metadata DNS
if isK8sServiceDNS(host) || isMetadataHost(host) { return ... }
// Resolve and check every resolved address
ips, err := net.LookupIP(host)
if err != nil || len(ips) == 0 {
return fmt.Errorf("cannot resolve realm host %q", host)
}
for _, ip := range ips {
if ip.IsPrivate() || ip.IsLoopback() || ip.IsLinkLocalUnicast() ||
ip.IsUnspecified() || isCGNAT(ip) || isBenchmark(ip) || ip.IsMulticast() {
return fmt.Errorf("realm resolves to internal address %s", ip)
}
}
return nil
}
```
---
## Reproducing the issue
The PoC is in `findings/CVE-pending-wasm-realm-ssrf-hostname-bypass/poc/`:
```bash
cd findings/CVE-pending-wasm-realm-ssrf-hostname-bypass/poc
go build -o poc_bin ./main.go
./poc_bin
# Expect: 9 hostnames shown as "0-DAY BYPASS", exit code 0
```
Or, for a real-cluster reproduction, follow the steps in
`FINDING.md` section 5.2.
---
## Disclosure timeline
- 2026-06-25 (T+0): 0-day discovered during a routine Istio 1.22 → 1.30
version-diff audit.
- 2026-06-25 (T+0): disclosure-queries log confirms 0 GHSA / OSV / PR
coverage.
- 2026-06-25 (T+0): standalone Go PoC built and verified (3x run, exit 0).
- 2026-06-25 (T+0): this disclosure prepared.
- 2026-06-25 (T+0): sent to security@...io.io and the CNCF Kubernetes
Istio Security list.
We are happy to provide additional technical details, coordinate a
fix timeline, or assist with regression testing. Please contact
security@...io.io or the auditing organization for follow-up.
---
## Files attached
- `FINDING.md` — full vulnerability report (5 sections, ≥10KB)
- `poc/main.go` — standalone Go PoC (no external deps)
- `poc/poc_bin` — compiled binary
- `poc/run.sh` — 3x runner
- `evidence/run-1.log`, `run-2.log`, `run-3.log` — 3x PoC runs
- `evidence/cvss-calc.py`, `output.txt` — CVSS 3.1 = 8.5
- `evidence/disclosure-queries.log` — 0 GHSA/OSV/PR coverage
- `raw_diffs/imagefetcher.go-FULL` — full buggy file from v1.30.0
- `raw_diffs/imagefetcher-validateRealmURL-BUGGY.go` — extracted function
- `raw_diffs/PR-60650-FIXED.diff` — open PR (partial fix, different gaps)
- `raw_diffs/VERSION-COVERAGE-VERIFICATION.md` — 5KB+ per-tag matrix
---
## Sign-off
This 0-day is unpublished. We request that Istio follow its standard
coordinated disclosure process (typically 90 days). We will keep this
report private until the Istio security team agrees to publication.
If you have any questions, please reach out to security@...io.io (or
the contact channel of the auditing organization) referencing this
disclosure.
— 小青蟹 (xylove21), Pentest role
2026-06-25
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
