CERT/CC VU#653116 | CISA Advisory ICSA-26-055-03 | All CVEs | Case Repository
| Field | Value |
|---|---|
| CVE | CVE-2025-1242 |
| ICSA | ICSA-26-055-03 |
| CVSS 3.1 | 9.1 (Critical) |
| Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| CWE | CWE-798 (Use of Hard-coded Credentials) |
| Researcher | Michael Groberman — Gr0m |
| Published | 2026-02-24 |
| Field | Value |
|---|---|
| Vendor | Gardyn |
| Product | Gardyn Home Kit 1.0, 2.0, 3.0, 4.0; Gardyn Studio 1.0, 2.0 |
| Component | Cloud API, mobile application, device firmware |
| Affected Versions | Firmware < master.622, Mobile App < 2.11.0, Cloud API < 2.12.2026 |
The Azure IoT Hub administrative credential (iothubowner shared access policy) is extractable through multiple vectors including unauthenticated API responses, mobile application reverse engineering, and device firmware analysis. This credential grants administrative control over the Gardyn IoT Hub, which architecturally manages all registered devices.
The iothubowner shared access policy is the highest-privilege credential in Azure IoT Hub. It grants:
| Permission | Description | Risk Level |
|---|---|---|
| RegistryRead | Read device registry (enumerate all devices) | HIGH |
| RegistryWrite | Modify device registry (add/delete devices) | CRITICAL |
| ServiceConnect | Send cloud-to-device messages | CRITICAL |
| DeviceConnect | Send device-to-cloud messages (impersonate any device) | CRITICAL |
| ServiceInvoke | Invoke direct methods on any device | CRITICAL |
Microsoft documentation states: "The iothubowner policy has all permissions and should be used with extreme caution. It is intended for backend service administration only and should NEVER be distributed to clients."
A single iothubowner connection string provides administrative access to the Gardyn IoT Hub.
The credential was exposed through multiple independent channels:
1. Unauthenticated API endpoint
An unauthenticated device provisioning endpoint returned the administrative credential to any caller. No authentication was required. The endpoint was accessible to anyone on the internet.
Request details removed — Specific endpoint paths, field names, and request structures have been removed from this public disclosure to reduce attacker enablement.
The administrative credential field was subsequently removed from this endpoint's response (partial fix), but the endpoint still returns device-level credentials without authentication.
2. Unauthenticated user enumeration endpoint
An unauthenticated user listing endpoint returned complete records for all 134,215 registered users. Every record included the administrative credential — 134,215 copies in a single API response.
Request details removed — Specific endpoint paths and field names have been removed from this public disclosure to reduce attacker enablement.
This endpoint also exposed sensitive PII for all users including full names, email addresses, phone numbers, partial payment card numbers, sequential user IDs (enabling IDOR), device IDs, and connection credentials.
Per CISA ICSA-26-055-03, this exposure path is remediated in the published fix versions.
3. Mobile application
The credential is embedded in the React Native application bundle (Hermes bytecode in index.android.bundle). It is also distributed via Firebase Remote Config, which logs credentials to Android logcat in debug builds.
4. Device firmware
The connection string is present in device firmware files under /usr/local/etc/gardyn/ and is logged to syslog in cleartext during initialization.
The credential has been exposed since at least May 2019 (6+ years based on API endpoint availability). The vendor migrated from an earlier IoT Hub ([REDACTED — IoT Hub name]) to the current hub ([REDACTED — IoT Hub name]) but reused the same shared access key, meaning anyone who captured the credential during the original exposure window retains access.
The vendor confirmed that no access logging existed on the affected endpoints, meaning the scope of unauthorized access during the 6+ year exposure window cannot be determined.
The vendor stated to CISA that no access logging existed on the affected endpoints during the exposure window. The vendor's public security page is at https://mygardyn.com/security/.
An attacker with the iothubowner credential can:
- Enumerate registered devices via IoT Hub registry queries
- Invoke direct methods on registered devices, including the
upgrade()method vulnerable to command injection (CVE-2025-29631) - Read and modify device twin configurations
- Send cloud-to-device messages
- Create or delete device registrations
- Access device telemetry data
Combined with CVE-2025-29631, this credential enables remote code execution as root on devices using the shared credentials (verified on researcher's own device).
This credential, combined with the IoT Hub hostname, allowed direct administrative access to the IoT Hub managing the affected Gardyn device fleet. The capabilities of an iothubowner credential are documented by Microsoft (see Impact above and the linked Azure documentation in References). CISA rated this CVE at CVSS 9.1 (Critical).
The other CVEs in ICSA-26-055-03 are documented as independent findings; this credential's exposure is a distinct issue from those vulnerabilities, although a single attacker holding multiple findings could combine them in some scenarios.
| Service | Purpose |
|---|---|
| Azure IoT Hub Device Provisioning Service (DPS) | Automated per-device credential provisioning with X.509 certificates |
| Scoped Shared Access Policies | Least-privilege access policies (e.g., device, service, registryRead) |
| Azure Monitor / IoT Hub Diagnostics | Access logging and anomaly detection for IoT Hub operations |
Microsoft's own documentation explicitly states: "The iothubowner policy has all permissions and should be used with extreme caution. It is intended for backend service administration only and should NEVER be distributed to clients."
Recommended mitigations for device owners:
- Isolate the Gardyn device on a dedicated VLAN or IoT network segment
- Monitor the device for unexpected network activity
- Do not place the device on networks containing sensitive systems
Recommended fix for the vendor:
- Immediately rotate the
iothubownershared access key - Remove the administrative credential from all API responses, mobile application code, and Firebase Remote Config
- Implement per-device scoped credentials using Azure IoT Hub Device Provisioning Service (DPS) with X.509 certificates
- Require authentication on all API endpoints that return device or hub credentials
- Audit IoT Hub access logs for unauthorized access during the exposure window
- Implement monitoring and alerting for anomalous IoT Hub administrative operations
| Date | Event |
|---|---|
| 2025-10-14 | Initial disclosure to vendor (researcher + consumer action — dual-capacity; the researcher disclosed as an affected Gardyn customer in addition to acting as the discovering researcher; see VU653116 standing note) |
| 2025-12-11 | Disclosure to CERT/CC (researcher + consumer action — dual-capacity; 58 days after initial vendor disclosure) |
| 2026-01-22 | iothubowner Azure IoT Hub administrative credential rotated (observable: previously distributed key stopped working) |
| 2026-02-24 | ICSA-26-055-03 published (initial) |
| 2026-04-02 | ICSA-26-055-03 Update A |
- CVE-2025-1242 — CVE Record
- ICSA-26-055-03
- CSAF JSON
- CWE-798: Use of Hard-coded Credentials
- Azure IoT Hub Shared Access Policies
Reported by Michael Groberman — Gr0m to CISA.