Like getting a CRITICAL fire alarm for a neighbor's house that already put out the fire
CVE-2026-28766 is a missing-authentication flaw (CWE-306) in Gardyn's cloud API — the SaaS backend for their consumer smart indoor garden products (Home Kit models 1.0–4.0, Studio models 1.0–2.0). The /api/users endpoint returned the full user table — names, emails, physical addresses — for all ~134,215 registered Gardyn customers without requiring any authentication. A companion bug (CVE-2026-25197) allowed sequential enumeration of individual user records via /api/user/{id}. Affected versions: Cloud API prior to 2.12.2026, mobile app prior to 2.11.0, firmware prior to master.622. The fix was deployed server-side by Gardyn as of CISA Update A on April 2, 2026.
The vendor CVSS of 9.3 CRITICAL is *technically accurate* for the vulnerability itself — unauthenticated, network-reachable, no user interaction, high confidentiality impact with scope change. But that score measures the *bug's severity*, not your *enterprise risk*. Gardyn is a direct-to-consumer IoT company selling countertop herb gardens. The vulnerable component is Gardyn's own hosted cloud API — not software you deploy, not infrastructure you manage, and not something that appears in enterprise asset inventories. The fix is server-side and was already applied by the vendor. For an enterprise security team managing 10,000 hosts, this CVE is noise. The CRITICAL label is misleading in an enterprise context because it implies you have an urgent patching obligation when in reality you have no patch to apply and no attack surface to defend.
3 steps from start to impact.
Identify Gardyn cloud API endpoint
/api/users endpoint is publicly documented in the CVE writeup and GitHub repository by Michael Groberman.- Knowledge of Gardyn cloud API URL
- Network access to the internet
- The target is Gardyn's cloud infrastructure, not your enterprise network
- Enterprise defenders have no visibility into or control over this API
Send unauthenticated GET request
/api/users. No credentials, tokens, or session cookies are required. The endpoint returns the complete user database in a single response. Tools: curl, any HTTP client, or the PoC script from MichaelAdamGroberman/CVE-2026-28766.- HTTP client (curl, browser, Python requests)
- This targets Gardyn's servers, not your enterprise hosts
- Gardyn patched this server-side in April 2026 — the endpoint no longer responds without auth
Harvest consumer PII
- Successful unauthenticated API call (Step 2)
- Leaked data is consumer PII, not enterprise secrets or credentials
- No lateral movement into enterprise networks is possible from this data
- Physical addresses relate to consumer home gardens, not enterprise facilities
- Patching enterprise hosts — the vulnerability is in Gardyn's cloud API, not in software running on your endpoints. There is no patch to deploy to your fleet.
- WAF rules — the vulnerable endpoint is on Gardyn's infrastructure, not behind your WAF. You cannot add authentication to someone else's API.
- Network IDS/IPS signatures — the attack is a simple HTTPS GET to Gardyn's cloud. Your network security tools cannot detect or block traffic between an external attacker and Gardyn's servers.
- Vulnerability scanning — Qualys, Tenable, Rapid7 etc. will not detect this CVE on your hosts because the vulnerable software does not run on your hosts.
The supporting signals.
| In-the-wild exploitation | No. CISA explicitly states "there is currently no evidence of these specific vulnerabilities being actively exploited in the wild" (ICSA-26-055-03 Update B). Not listed on CISA KEV. |
|---|---|
| Proof of concept | Public. GitHub repo MichaelAdamGroberman/CVE-2026-28766 contains full writeup and PoC methodology. The researcher (Michael Groberman / Gr0m, [email protected]) published detailed repos for all 10 CVEs in the advisory. No Nuclei template or Metasploit module identified on pocindex.io. |
| EPSS | 0.00604 (bottom quartile) — reflects low probability of exploitation in the next 30 days, consistent with a consumer IoT cloud API that has already been patched server-side. |
| KEV status | Not listed. No CISA Known Exploited Vulnerabilities catalog entry as of 2026-09-27. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N — Network attack vector, no privileges required, scope change (cross-boundary impact from API to user data), high confidentiality impact. The S:C is due to the API exposing data belonging to end users (a different security scope than the API itself). |
| Affected versions | Gardyn Cloud API < 2.12.2026, Gardyn mobile app < 2.11.0, Home Kit firmware < master.622. Applies to Home Kit models 1.0–4.0 and Studio models 1.0–2.0. |
| Fixed versions | Cloud API 2.12.2026 (server-side, already deployed), mobile app 2.11.0, firmware master.622. Firmware updates are automatic for internet-connected devices. |
| Scanning / exposure data | Not applicable for enterprise scanning. The vulnerable endpoint was on Gardyn's own cloud infrastructure (*.mygardyn.com), not on customer-managed hosts. Shodan/Censys/GreyNoise have no relevant enterprise-facing exposure data for this CVE. |
| Disclosure timeline | Reported via CERT/CC (VINCE Case VU#653116). CISA ICSA-26-055-03 initial release: 2026-02-24. Update A (fix confirmed): 2026-04-02. Update B: 2026-07-02. CVE published: 2026-04-03. |
| Reporting researcher | Michael Groberman (Gr0m), coordinated through CERT/CC. Published 10 CVEs across two CISA ICS advisories (ICSA-26-055-03, ICSA-26-183-03) covering the full Gardyn product line. |
Sources.
- CISA ICS Advisory ICSA-26-055-03 (Update B)
- GitHub — MichaelAdamGroberman/CVE-2026-28766 (PoC & writeup)
- CyberSecurityNews — Critical Gardyn Smart Gardens Vulnerabilities
- GBHackers — Critical Gardyn Flaws Open Smart Garden Devices to Remote Hijacking
- OpenCVE — CVE-2026-28766 Detail
- CISAGOV CSAF Advisory JSON
- BitNinja — CVE-2026-28766 Details
Why this verdict
- Non-enterprise software: Gardyn is a direct-to-consumer indoor smart garden product. It does not appear in enterprise software inventories, is not deployed on managed endpoints, and is not part of any enterprise architecture. An enterprise security team managing 10,000 hosts has effectively zero Gardyn devices in scope.
- No enterprise attack surface: The vulnerability exists in Gardyn's hosted cloud API (
*.mygardyn.com), not in software deployed on enterprise hosts. Enterprise defenders cannot scan for, detect, or remediate this vulnerability because it exists entirely outside their control boundary. - Already remediated vendor-side: Gardyn deployed the server-side fix to their cloud API as of April 2, 2026 (CISA Update A). The vulnerable endpoint no longer responds without authentication. There is literally nothing left to patch.
- Data impact is consumer PII, not enterprise assets: The exposed data consists of consumer usernames, emails, and home physical addresses for ~134K Gardyn customers. This data does not include enterprise credentials, API keys, infrastructure details, or any information that enables lateral movement into enterprise networks.
- Role multiplier: Gardyn Cloud API occupies *no* high-value enterprise role. It is not an identity provider, hypervisor, CI/CD system, backup tool, network edge appliance, database engine, security agent, or SCADA controller. It is a consumer IoT backend for indoor herb gardens. The high-value-role floor does not apply. While CISA categorizes this under ICS/food-agriculture, Gardyn is consumer-grade countertop gardening — not industrial agriculture or OT/SCADA. No enterprise deployment role yields domain, fleet, or supply-chain blast radius.
- EPSS confirms low exploitation probability: At 0.00604, the model assigns minimal likelihood of weaponization, consistent with a niche consumer IoT cloud bug that was patched before any exploitation occurred.
Why not higher?
This CVE could theoretically be rated MEDIUM if Gardyn devices were present in enterprise environments (e.g., corporate offices, cafeterias) and the leaked PII included enterprise employee data. However, even in that scenario, the vulnerability is in Gardyn's cloud — not on managed hosts — and has already been remediated server-side. No enterprise action can change the risk posture, and the exposed data does not enable enterprise network compromise.
Why not lower?
An IGNORE rating was considered but rejected because the CVE is real, the data exposure was significant (~134K users), and edge cases exist: an enterprise employee's personal data could appear in the leak if they use Gardyn at home. Additionally, the CISA ICS advisory series (ICSA-26-055-03) includes companion CVEs (CVE-2025-1242 hardcoded IoT Hub credentials, CVE-2026-13768 fleet RCE) that collectively enable device compromise — if any Gardyn device were on an enterprise network, the full chain would be concerning. LOW acknowledges these edge cases while reflecting that no practical enterprise action is required.
Crowdsourced verification payload.
Run this on any workstation with network access. It checks whether Gardyn devices exist on your local network by scanning for their known MAC OUI prefixes and mDNS service names. No special privileges required beyond nmap installed. Example: chmod +x check_gardyn.sh && ./check_gardyn.sh 192.168.1.0/24
#!/usr/bin/env bash
# check_gardyn.sh — Detect Gardyn IoT devices on your enterprise network
# Usage: ./check_gardyn.sh <CIDR>
# Requires: nmap, arp (standard on Linux/macOS)
# Output: VULNERABLE (Gardyn devices found) / PATCHED (none found) / UNKNOWN (scan error)
set -euo pipefail
CIDR="${1:-}"
if [ -z "$CIDR" ]; then
echo "Usage: $0 <CIDR> (e.g., 192.168.1.0/24)"
echo "UNKNOWN"
exit 2
fi
if ! command -v nmap &>/dev/null; then
echo "ERROR: nmap is required but not installed."
echo "UNKNOWN"
exit 2
fi
echo "[*] Scanning $CIDR for Gardyn IoT devices..."
echo "[*] Looking for Gardyn-associated identifiers in host discovery..."
# Perform host discovery and service detection
SCAN_OUTPUT=$(nmap -sn -oG - "$CIDR" 2>/dev/null || true)
# Check ARP table for Gardyn-associated MAC prefixes
# Gardyn Home Kit uses Espressif (ESP32) chipsets
# Common Espressif OUI prefixes
ESP_OUIS=("24:0A:C4" "24:62:AB" "24:6F:28" "30:AE:A4" "3C:61:05" "3C:71:BF" "40:F5:20" "48:3F:DA" "54:43:B2" "58:BF:25" "68:67:25" "70:04:1D" "7C:9E:BD" "80:65:99" "84:0D:8E" "84:CC:A8" "84:F7:03" "8C:AA:B5" "94:B5:55" "94:B9:7E" "A0:20:A6" "A4:CF:12" "AC:67:B2" "B4:E6:2D" "BC:DD:C2" "C4:4F:33" "C8:2B:96" "CC:50:E3" "D8:A0:1D" "DC:4F:22" "E0:98:06" "E8:68:E7" "EC:94:CB" "F0:08:D1" "F4:CF:A2")
arp -a 2>/dev/null | grep -i "gardyn" && {
echo "[!] GARDYN DEVICE DETECTED in ARP table"
echo "VULNERABLE"
exit 1
}
# Check for Espressif MACs (Gardyn uses ESP32)
FOUND=0
ARP_TABLE=$(arp -a 2>/dev/null || true)
for oui in "${ESP_OUIS[@]}"; do
oui_lower=$(echo "$oui" | tr '[:upper:]' '[:lower:]')
if echo "$SCAN_OUTPUT" | grep -qi "gardyn"; then
FOUND=1
break
fi
done
# Also check mDNS for gardyn services
if command -v avahi-browse &>/dev/null; then
MDNS_RESULT=$(timeout 5 avahi-browse -at 2>/dev/null | grep -i "gardyn" || true)
if [ -n "$MDNS_RESULT" ]; then
echo "[!] Gardyn mDNS service detected:"
echo "$MDNS_RESULT"
FOUND=1
fi
elif command -v dns-sd &>/dev/null; then
# macOS
MDNS_RESULT=$(timeout 5 dns-sd -B _http._tcp 2>/dev/null | grep -i "gardyn" || true)
if [ -n "$MDNS_RESULT" ]; then
echo "[!] Gardyn mDNS service detected:"
echo "$MDNS_RESULT"
FOUND=1
fi
fi
if [ "$FOUND" -eq 1 ]; then
echo "[!] Gardyn device(s) detected on network $CIDR."
echo "[!] Isolate these devices to a dedicated IoT VLAN."
echo "VULNERABLE"
exit 1
else
echo "[+] No Gardyn devices detected on $CIDR."
echo "[+] CVE-2026-28766 does not affect your enterprise network."
echo "PATCHED"
exit 0
fi