CVE-2026-111629 in IoTSharp
Summary
by MITRE • 10/16/2026
IoTSharp through 3.6.1 contains an insecure direct object reference vulnerability that allows any authenticated user to read other tenants' data because Customers and Devices API handlers do not scope queries to the caller's tenant. Attackers can self-register through the anonymous AccountController.Create endpoint and supply other tenants' GUIDs to read customer contact details, device inventories and device attribute telemetry.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in IoTSharp versions up to 3.6.1 represents a critical failure in access control mechanisms, specifically classified as an Insecure Direct Object Reference or IDOR according to the Common Weakness Enumeration standard CWE-639. This flaw stems from a fundamental architectural oversight where the application logic fails to validate that the requesting user has authorization for the specific resources being accessed. The core technical deficiency lies within the API handlers responsible for managing Customers and Devices, which process requests based solely on provided identifiers without cross-referencing them against the authenticated session's tenant context. Consequently, the system treats any valid authentication token as sufficient permission to access data associated with arbitrary object IDs, regardless of whether those objects belong to the user or their designated organization.
From an operational perspective, this vulnerability allows for a severe breach of multi-tenancy isolation principles that are essential in Software-as-a-Service environments like IoTSharp. An attacker can exploit this by first creating an account through the anonymous AccountController.Create endpoint, thereby obtaining valid authentication credentials without needing prior access to any specific tenant data. Once authenticated, the attacker can manipulate API parameters to supply Globally Unique Identifiers associated with other tenants. Because the backend logic does not enforce scoping queries to the caller's tenant ID, it returns sensitive information such as customer contact details, comprehensive device inventories, and real-time telemetry attributes belonging to unrelated organizations. This effectively bypasses logical access controls and exposes proprietary operational data that should remain strictly isolated within individual tenant boundaries.
The impact of this vulnerability extends beyond simple data leakage, potentially facilitating further attacks through the ATT&CK framework technique T1078, Valid Accounts, as well as T1530, Data from Cloud Storage Objects if telemetry is stored externally. The exposure of customer contact information and device inventories can lead to significant reputational damage for affected tenants and potential regulatory violations under data protection laws such as GDPR or CCPA due to the unauthorized disclosure of personally identifiable information. Furthermore, access to device attribute telemetry may reveal sensitive operational parameters that could be used by adversaries to map network topologies or identify specific industrial control systems for targeted exploitation in subsequent attack phases.
Mitigation strategies must prioritize immediate patching to version 3.6.2 or later where this issue has been addressed through stricter input validation and authorization checks. Developers should implement a defense-in-depth approach by ensuring that all API endpoints enforce tenant-scoped queries at the database level, not just within application logic. This involves explicitly joining query results with user-tenant mapping tables to verify ownership before returning data. Additionally, implementing comprehensive logging of access attempts for resources outside the authenticated user's scope can aid in detecting exploitation activities and refining future security controls. Regular penetration testing focusing on logical flaws and IDOR vulnerabilities is recommended to ensure that multi-tenancy boundaries remain robust against evolving attack techniques.