One Hard-Coded Cloud Key, an Entire Fleet of Gardens: CVE-2026-13768

Gardyn's internet-connected indoor gardens shipped with a privileged Azure IoT Hub key that any owner could pull off the device. That one key is a skeleton key to the whole fleet: enumerate every unit, run commands on a chosen device, and pivot onto the owner's home network. CISA published it in a Food and Agriculture advisory on July 2, and the researcher posted proof-of-concept repositories the next day.

What the vulnerability is

Gardyn builds consumer indoor gardens, the Gardyn Home Kit and the larger Gardyn Studio, that grow plants hydroponically and connect to a cloud service for scheduling, monitoring, and updates. That cloud service is built on Microsoft Azure IoT Hub, which is the fleet-management layer: it holds the device registry, ingests telemetry, and pushes commands and firmware down to each unit. Access to the hub is governed by shared access policy keys, and the most powerful of those is the iothubowner policy, which grants registry read and write plus full device management across the entire hub.

The flaw is that this owner-level key was exposed on the device itself, where an owner or anyone who gets hold of a unit can recover it. A key that should never leave the operator's trusted backend was instead sitting on every appliance. Once it is in an attacker's hands, the Azure control plane cannot tell the difference between the vendor and the attacker, because from the cloud's point of view they are presenting the same legitimate, all-powerful credential.

How the exploit works

With the iothubowner key, the attack is not a memory-corruption puzzle or a race condition. It is a series of ordinary, documented API calls made with a credential that was never meant to be public. CISA describes three capabilities that follow directly from holding the key.

First, fleet enumeration. The attacker invokes the IoT Hub Registry Manager, the same interface Gardyn's own backend uses, and it returns the connection information for every Gardyn Home Kit and Studio device registered to the hub. In one call the attacker turns a single stolen key into a directory of the whole customer base.

Second, device command execution. Azure IoT Hub is bidirectional by design: the cloud can send messages, direct methods, and desired-state changes down to any device. An attacker holding the owner key inherits that channel and can execute arbitrary commands on a specific connected device, which means taking over an individual customer's unit at will.

A credential that should have lived only in the vendor's backend was riding on every appliance, and that turns one stolen key into control of the entire fleet.

Third, lateral movement. A Gardyn unit is a networked Linux-class appliance sitting on a home or small-office network. Once an attacker can run commands on it, CISA notes the compromise may allow a pivot to other devices on the owner's network. The garden becomes a beachhead, and the interesting targets are whatever else shares that LAN.

Two companion issues in the same advisory round out the picture. CVE-2026-55726 (CVSS 5.3) is an Azure Blob Storage container of device logs that was publicly listable without authentication, a sensitive-information exposure that hands an attacker reconnaissance for free. CVE-2026-54477 (CVSS 5.4) is the admin panel shipping without standard security headers, which opens the door to clickjacking and cross-site scripting. Neither is as serious as the owner-key exposure, but together they show a backend that was not built with an attacker in mind.

Why this counts as critical infrastructure

We want to be honest about scale, because it matters for how you weigh this one. Gardyn is a consumer and prosumer product, not an industrial control system, and the advisory does not describe a threat to the bulk food supply. What earns it a place here is that CISA's own ICS-CERT team published it as a Food and Agriculture sector advisory, and that the failure mode is the archetype for connected-device fleets everywhere: an over-privileged cloud credential, extractable from the edge, that collapses the security of thousands of devices into the secrecy of one key.

Controlled-environment agriculture, vertical farms, hydroponic and greenhouse automation, is a growing slice of that sector, and it is being built on exactly this pattern of internet-connected appliances talking to a cloud fleet manager. The lesson from CVE-2026-13768 transfers cleanly upmarket. If a home-garden vendor can leak an iothubowner key to the edge, so can a commercial greenhouse platform or a building-automation vendor, and there the blast radius is not somebody's basil.

What we see from our sensors

We run a fleet of honeypots and edge decoys, so we checked our own data. We want to be precise about what we found, and what we did not.

We did not see CVE-2026-13768. We would not expect to. The core of this attack is cloud-side: an attacker takes a leaked key and calls Azure IoT Hub endpoints at *.azure-devices.net. That traffic goes to Microsoft's control plane, not to an internet-facing service our decoys impersonate, so there is no scan or login attempt against our sensors to catch.

What our sensors do capture, constantly, is the reconnaissance that this class of flaw feeds on. Our HTTP decoys and persona sidecars are hammered around the clock by scanners hunting for exactly the kind of secret Gardyn left exposed. In one recent multi-week sample, those decoys logged roughly 1,600 requests for /.env files, more than 200 for /.git/config, and dozens more reaching for /.aws/credentials, /.ssh directories, /var/run/secrets, /.git/credentials, and cloud-config artifacts with names like azureprofile.json, azure-pipelines.yml, and azure-blob.zip. None of it named Gardyn, and not one request carried a real Azure IoT Hub connection string. The point is the appetite. There is a large, automated population of scanners whose entire job is to find a leaked credential or key sitting somewhere it should not be, and a hard-coded iothubowner key on an internet-connected appliance is precisely the prize they are built to collect. A device that ships that key has to survive that traffic every single day.

What our decoys plausibly would see is the phase after a device is taken over, when a compromised appliance starts probing the network around it. A Gardyn unit running attacker commands and sweeping its local subnet looks, from a decoy on that subnet, like any other IoT device gone rogue, and that lateral scanning is exactly what edge decoys are placed to catch. We have no Gardyn-specific captures to report, and we are not going to imply otherwise.

How to fix or mitigate it

The good news is that the heaviest lifting here is on the vendor, and Gardyn has done it. The company states that its IoT Hub deployed infrastructure has been updated to fix the listed vulnerabilities, which for an exposed owner key means rotating and rescoping the credential so the leaked one no longer works. The fix is delivered through the cloud backend and through firmware, so most owners are covered automatically as long as their devices are online.

• Keep the devices online so they update. Gardyn pushes firmware automatically, so make sure each unit has working internet connectivity and let it pull master.627 or later. Update the Gardyn mobile app to the current version as well, and confirm the firmware version in the app.
• Segment IoT devices from everything that matters. This is the mitigation that would have blunted the worst of it. Put connected appliances on their own VLAN or guest network so that a device an attacker can run commands on cannot reach your computers, storage, or work devices. CISA's advisory makes the same point: minimize network exposure and isolate these devices from business networks.
• If you build cloud-managed devices, never ship an owner key to the edge. The root cause is a design choice. Devices should authenticate with per-device credentials or short-lived tokens scoped to their own identity, provisioned through a service like the Azure Device Provisioning Service, never with a hub-wide iothubowner key. Treat any shared, high-privilege key as something that lives only in your backend.
• Lock down the storage and the admin surfaces too. The companion CVEs are a reminder to set Azure Blob containers to private by default and to ship standard security headers on any admin panel. Free reconnaissance and a clickjackable console make every other bug easier to exploit.

Indicators and references