EUVD-2026-41464
GHSA-22gx-ghv9-47gj
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L/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
Key grants network access with no per-user auth (PR:N) and full registry/command rights; scope changes (S:C) since one device's key controls the whole fleet and enables network pivot; availability impact only partial (A:L).
Primary rating from Vendor (hq).
CVSS VectorVendor: hq
Lifecycle Timeline
2DescriptionCVE.org
Gardyn devices expose a privileged iothubowner key. Access to this key will allow a malicious user to invoke an IoTHub Registry Manager function which returns connection information for all Gardyn Home Kit and Studio devices. Access to this key also allows a malicious user to execute arbitrary commands on a specific connected device and may allow the malicious user to pivot to other devices on the user's network.
AnalysisAI
Cloud takeover of Gardyn smart indoor garden devices is possible because a privileged Azure IoT Hub 'iothubowner' shared-access key is embedded in the product, letting a malicious actor query the IoT Hub Registry Manager to enumerate connection details for every Gardyn Home Kit and Studio device and then push arbitrary commands to a targeted unit. Because the key is service-level rather than per-device, one extracted credential compromises the entire fleet, and the attacker may pivot from a controlled device onto the victim's home or corporate LAN. This flaw was reported through CISA ICS-CERT (ICSA-26-183-03) and carries a CVSS 4.0 base score of 9.5, but no public exploit identified at time of analysis.
Technical ContextAI
The affected technology is Microsoft Azure IoT Hub, the cloud messaging backbone Gardyn uses to manage its consumer hydroponic 'Home Kit' and 'Studio' devices. Azure IoT Hub uses shared-access-policy keys with scoped permissions; the 'iothubowner' policy is the highest-privilege policy, granting full registry read/write and device management (RegistryRead/RegistryWrite/ServiceConnect/DeviceConnect). Exposing this key - the root cause captured by CWE-798 (Use of Hard-coded Credentials) - collapses the tenant's trust boundary because the credential is shared across the whole fleet rather than scoped per device. With it, an attacker calls the IoT Hub Registry Manager API to list all device identities and their connection strings, then uses ServiceConnect/DeviceConnect rights to invoke direct methods or send cloud-to-device messages that the on-device agent executes as commands.
RemediationAI
The fix is a vendor-side change: because the defect is a hard-coded/exposed service credential, the corrective action is Gardyn rotating and re-scoping the leaked iothubowner key and removing it from the device/app, so users should apply any firmware or app update Gardyn publishes and monitor https://mygardyn.com/security/ and CISA ICSA-26-183-03 (https://www.cisa.gov/news-events/ics-advisories/icsa-26-183-03) for the patched version - no exact fixed version is stated in the available data, so this is Patch available per vendor advisory rather than a confirmed release. As a network-side compensating control, place Gardyn devices on an isolated VLAN or guest network segment and block lateral traffic from them to trusted hosts to limit the described network-pivot risk (trade-off: may break local app discovery or integrations). Since the abused path is cloud-side, end users cannot directly revoke the key themselves; escalate to Gardyn support to confirm key rotation, and where feasible restrict or monitor outbound device connections to the Azure IoT Hub endpoint.
Same weakness CWE-798 – Use of Hard-coded Credentials
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today