This is a hidden side door that only matters if you also built a public hallway to it
CVE-2026-28798 is an SSRF-style proxy abuse in ZimaOS's /v1/sys/proxy endpoint that can turn the web UI into a bounce point toward localhost-only services. The NVD description says versions *prior to 1.5.3* are affected; the GitHub advisory metadata says <=1.5.0, so defenders should treat *all 1.5.x before 1.5.3 as suspect* until the vendor clarifies the range. The exploit condition that matters is not just 'network reachable' but *Internet reachable through a Cloudflare Tunnel*.
The vendor's CRITICAL 9.0 label is too high for enterprise prioritization because the prerequisite chain is unusually restrictive: niche product, intentional remote publishing, and a Cloudflare Tunnel-backed exposure pattern. If that condition exists, the bug is ugly because it strips away localhost trust boundaries and may expose admin APIs or sensitive local services without auth; but most real deployments never satisfy the exposure prerequisite, which is why this lands as HIGH, not CRITICAL.
4 steps from start to impact.
Find an Internet-published ZimaOS instance
localhost service behind cloudflared, so the target can be reachable without a public origin IP. Commodity recon is enough here; the hard part is simply finding a target population that chose this exposure model.- ZimaOS is deployed at all
- The admin/web interface is reachable from the Internet
- A Cloudflare Tunnel or equivalent published-hostname pattern is in use
- ZimaOS is a niche NAS/home-server OS, not a mainstream enterprise platform
- Many deployments stay LAN-only
- Cloudflare Tunnel hides the origin IP, reducing straightforward Shodan-style census quality
Abuse /v1/sys/proxy with the vendor-supplied Exploit.py PoC
Exploit.py, showing the issue is already weaponized at least to proof-of-concept level. The attacker sends crafted requests to the proxy endpoint so the ZimaOS UI makes backend requests on the attacker's behalf. This converts an external web request into local service access.- Unauthenticated access to the published ZimaOS web interface
- Vulnerable build still in place
- The proxy path must be exposed as part of the reachable UI surface
- Some reverse-proxy rules, Access policies, or auth gates in front of the hostname may block direct anonymous access
/v1/sys/proxy; WAF/API gateway logs can catch unusual target parameters. Most vuln scanners will flag the CVE only if they understand the exposure prerequisite and can exercise the endpoint.Pivot into localhost-only services
127.0.0.1, the attacker can enumerate internal-only HTTP services, service banners, and admin APIs that were never meant to face the Internet. The GitHub advisory explicitly calls out internal endpoints such as user management and device configuration. In practice, the vulnerability is an auth-boundary collapse, not just a generic SSRF curiosity.- Interesting local services exist on the ZimaOS host
- Those services trust localhost or lack their own strong auth
- Impact depends heavily on what is listening locally on that specific box
- Some internal services may still enforce independent authentication or CSRF/session checks
Translate internal access into real damage
- Valuable data or powerful localhost APIs are present
- No compensating access controls sit in front of the published hostname
- No public evidence here of broad in-the-wild chaining to full takeover
- Blast radius is host-local rather than a universal domain-wide compromise primitive
The supporting signals.
| In-the-wild status | No authoritative evidence found of active exploitation as of 2026-05-31; not in CISA KEV. |
|---|---|
| Proof-of-concept availability | Yes. The vendor GitHub advisory links a PoC attachment named Exploit.py and a demo video, which lowers attacker effort for exposed targets. |
| EPSS | 0.08% EPSS, about 24th percentile in the latest public mirror data; threat pressure is currently low. |
| KEV status | Not listed in the CISA KEV catalog. |
| CVSS vector reality check | Vendor/CNA vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H. The important downward pressure is the hidden prerequisite behind AC:H: the product must be intentionally exposed through a Cloudflare Tunnel. |
| Affected versions | NVD says versions prior to 1.5.3. The GitHub advisory metadata says <=1.5.0. Treat all builds below 1.5.3 as suspect until the vendor reconciles the discrepancy. |
| Fixed version | Patched in ZimaOS 1.5.3. |
| Exposure/scanning note | Cloudflare states Tunnel publishes a public hostname that proxies to a private service behind cloudflared; that means origin-IP-based scanning undercounts exposure and DNS/Tunnel inventory matters more than Shodan counts. |
| Disclosure timeline | GitHub advisory published 2026-03-31; CVE/NVD published 2026-04-03; NVD enrichment updated 2026-04-13. |
| Reporter | GitHub advisory credits DrDark1999 as reporter. |
noisgate verdict.
The decisive factor is the exposure prerequisite: this bug is only meaningfully exploitable when a vulnerable ZimaOS instance is intentionally published to the Internet through a Cloudflare Tunnel. That sharply reduces the reachable population, but any matching host loses its localhost trust boundary and can expose sensitive internal APIs without authentication.
Why this verdict
- Downgrade for reachability friction: exploitation is not 'any Internet host'; it requires a ZimaOS deployment that is *deliberately* exposed through a Cloudflare Tunnel, which is a major population reducer.
- Still unauthenticated remote on exposed systems: once that edge case exists, the attacker needs no account and can drive the proxy endpoint directly from the Internet.
- PoC exists, but pressure is low: vendor-linked
Exploit.pylowers attacker effort, yet EPSS is only 0.08% and there is no KEV or confirmed campaign evidence. - Niche product matters: ZimaOS is a specialized NAS/home-server OS, not a broad enterprise platform with huge exposed census numbers.
- Blast radius is host-local, not automatically estate-wide: the vulnerability compromises localhost trust on the appliance, but impact depends on what internal services are present and how much they trust loopback.
Why not higher?
This is not a clean Internet-wide pre-auth exploit against a commonly exposed enterprise product. The Cloudflare Tunnel prerequisite effectively implies a consciously published appliance, which narrows both victim population and exploit reliability. There is also no authoritative evidence of widespread exploitation or KEV inclusion.
Why not lower?
For the subset of hosts that *are* exposed this way, the bug is nasty: unauthenticated remote access can punch through to internal-only services and admin APIs. The presence of a vendor-linked PoC means defenders should assume exposed systems are testable by adversaries now, not hypothetically later.
What to do — in priority order.
- Unpublish the ZimaOS UI — Remove the public hostname or disable the Cloudflare Tunnel route that exposes the ZimaOS web interface. This is the fastest risk kill-switch and, for a HIGH verdict, should be deployed within 30 days unless business need forces external access.
- Put Cloudflare Access in front — Require identity-aware access controls on any published hostname so anonymous traffic never reaches
/v1/sys/proxy. If remote access must remain, deploy this compensating gate within 30 days. - Block the proxy path upstream — Add a WAF/reverse-proxy rule that denies requests to
/v1/sys/proxyfrom untrusted clients. This is a practical temporary barrier when you cannot remove external publishing immediately; deploy within 30 days. - Restrict admin reach to VPN-only — Move management access behind WireGuard/Tailscale/VPN instead of direct public hostname exposure. This removes the Internet attacker position entirely and should be implemented within 30 days if patch rollout lags.
- Review localhost-trusting services — Inventory services bound to
127.0.0.1on the appliance and identify any admin endpoints that trust loopback implicitly. This contains post-exploit blast radius and should be completed within 30 days.
- Relying on origin-IP cloaking alone does not help; Cloudflare Tunnel can still publish a reachable public hostname that carries the exploit traffic.
- Perimeter port scans of public IP space are insufficient because Tunnel-backed exposure may not present a routable origin IP to discover.
- MFA on unrelated downstream apps does not fix the broken trust boundary if localhost APIs behind the proxy do not enforce their own auth.
Crowdsourced verification payload.
Run this on the ZimaOS target host over local shell or SSH. Invoke with sudo bash ./check-zimaos-cve-2026-28798.sh; root is recommended so the script can inspect processes and common config paths. It checks the local ZimaOS version and whether cloudflared appears present/running, then prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env bash
# check-zimaos-cve-2026-28798.sh
# Detect likely exposure state for CVE-2026-28798 on ZimaOS.
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
set -u
TARGET_FIXED="1.5.3"
verlt() {
# returns 0 if $1 < $2
[ "$1" = "$2" ] && return 1
local first
first=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
[ "$first" = "$1" ]
}
get_version() {
local v=""
if [ -r /etc/os-release ]; then
v=$(awk -F= '/^VERSION_ID=/{gsub(/"/,"",$2); print $2}' /etc/os-release | head -n1)
fi
if [ -z "$v" ] && [ -r /etc/issue ]; then
v=$(grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' /etc/issue | head -n1)
fi
if [ -z "$v" ] && command -v zimaos >/dev/null 2>&1; then
v=$(zimaos --version 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)
fi
printf '%s' "$v"
}
cloudflared_present=false
cloudflared_running=false
cloudflared_config=false
if command -v cloudflared >/dev/null 2>&1; then
cloudflared_present=true
fi
if pgrep -fa cloudflared >/dev/null 2>&1; then
cloudflared_running=true
fi
for p in \
/etc/cloudflared/config.yml \
/etc/cloudflared/config.yaml \
/root/.cloudflared/config.yml \
/root/.cloudflared/config.yaml \
/home/*/.cloudflared/config.yml \
/home/*/.cloudflared/config.yaml
do
if [ -e "$p" ]; then
cloudflared_config=true
break
fi
done
version=$(get_version)
if [ -z "$version" ]; then
echo "UNKNOWN - could not determine ZimaOS version; cloudflared_present=$cloudflared_present cloudflared_running=$cloudflared_running cloudflared_config=$cloudflared_config"
exit 2
fi
if verlt "$version" "$TARGET_FIXED"; then
if [ "$cloudflared_running" = true ] || [ "$cloudflared_config" = true ] || [ "$cloudflared_present" = true ]; then
echo "VULNERABLE - ZimaOS version $version is older than $TARGET_FIXED and cloudflared appears present/running/configured"
exit 1
else
echo "UNKNOWN - ZimaOS version $version is older than $TARGET_FIXED but no local cloudflared evidence was found; verify remote publishing manually"
exit 2
fi
else
echo "PATCHED - ZimaOS version $version is >= $TARGET_FIXED"
exit 0
fi
If you remember one thing.
/v1/sys/proxy; the noisgate remediation SLA is ≤180 days to get every affected host to 1.5.3 or later. If you confirm a public hostname is live today, do not wait for the full window—treat that subset as urgent and close exposure first, then patch.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.