← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-28798 · CWE-918 · Disclosed 2026-04-03

ZimaOS is a fork of CasaOS

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Serious if you exposed ZimaOS through Cloudflare Tunnel; otherwise this is a narrow edge-case, not a fleet-wide fire."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find an Internet-published ZimaOS instance

The attacker first needs a ZimaOS web UI that has been deliberately published externally. Per Cloudflare's docs, a Tunnel can proxy a public hostname to a private 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: External attack-surface tools may miss these because Tunnel fronting publishes a hostname rather than a routable origin IP. Asset inventory and DNS/Tunnel config reviews are more reliable than scanner-only discovery.
STEP 02

Abuse /v1/sys/proxy with the vendor-supplied Exploit.py PoC

The GitHub advisory includes a PoC attachment named 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.
Conditions required:
  • Unauthenticated access to the published ZimaOS web interface
  • Vulnerable build still in place
Where this breaks in practice:
  • 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
Detection/coverage: Web logs should show requests to /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.
STEP 03

Pivot into localhost-only services

Once the proxy can reach 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.
Conditions required:
  • Interesting local services exist on the ZimaOS host
  • Those services trust localhost or lack their own strong auth
Where this breaks in practice:
  • Impact depends heavily on what is listening locally on that specific box
  • Some internal services may still enforce independent authentication or CSRF/session checks
Detection/coverage: Look for localhost-targeting requests generated by the ZimaOS UI service, unexpected access to internal admin endpoints, and anomalous loopback traffic from the web process.
STEP 04

Translate internal access into real damage

The practical end state is unauthorized access to admin functions, sensitive config, tokens, or service metadata; worst-case impact depends on what those local APIs can do. The public advisory does not prove turnkey RCE by itself, so defenders should resist inflating this into instant box compromise everywhere. Still, on an Internet-published appliance, unauthorized internal API reach is enough to justify urgent action.
Conditions required:
  • Valuable data or powerful localhost APIs are present
  • No compensating access controls sit in front of the published hostname
Where this breaks in practice:
  • 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
Detection/coverage: Follow-on impact shows up as unexpected config reads/changes, new sessions, token use, or abnormal admin API calls from the web tier.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo authoritative evidence found of active exploitation as of 2026-05-31; not in CISA KEV.
Proof-of-concept availabilityYes. The vendor GitHub advisory links a PoC attachment named Exploit.py and a demo video, which lowers attacker effort for exposed targets.
EPSS0.08% EPSS, about 24th percentile in the latest public mirror data; threat pressure is currently low.
KEV statusNot listed in the CISA KEV catalog.
CVSS vector reality checkVendor/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 versionsNVD 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 versionPatched in ZimaOS 1.5.3.
Exposure/scanning noteCloudflare 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 timelineGitHub advisory published 2026-03-31; CVE/NVD published 2026-04-03; NVD enrichment updated 2026-04-13.
ReporterGitHub advisory credits DrDark1999 as reporter.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (7.3/10)

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.

HIGH Patch version and core vulnerability description
MEDIUM Real-world blast radius on an exposed host
MEDIUM Affected-version range because NVD and GHSA metadata conflict

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.py lowers 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. Block the proxy path upstream — Add a WAF/reverse-proxy rule that denies requests to /v1/sys/proxy from untrusted clients. This is a practical temporary barrier when you cannot remove external publishing immediately; deploy within 30 days.
  4. 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.
  5. Review localhost-trusting services — Inventory services bound to 127.0.0.1 on the appliance and identify any admin endpoints that trust loopback implicitly. This contains post-exploit blast radius and should be completed within 30 days.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, query your asset inventory for any ZimaOS hosts and immediately separate the handful that publish their web UI through Cloudflare Tunnel from the ones that are LAN-only. For this HIGH verdict, the noisgate mitigation SLA is ≤30 days: by then, either remove external publishing, put Cloudflare Access in front, or block /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

  1. NVD CVE-2026-28798
  2. GitHub advisory GHSA-vqqj-f979-8c8m
  3. ZimaOS 1.5.3 release
  4. ZimaOS repository
  5. Cloudflare Tunnel published applications
  6. CISA Known Exploited Vulnerabilities catalog
  7. FIRST EPSS overview
  8. CVEFind EPSS mirror for CVE-2026-28798
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.