CVE-2026-71262: IoTSharp Auth Bypass Vulnerability

CVE-2026-71262 Overview

CVE-2026-71262 affects the BlobStorageController.cs component of IoTSharp, an open-source IoT platform built on ASP.NET Core. The controller omits the [Authorize] attribute that other controllers in the application enforce, and Startup.cs does not configure a global authorization FallbackPolicy. Unauthenticated remote attackers can reach the Upload, Download, List, Modify, and Delete endpoints. The same endpoints pass user-controlled path and filename parameters to file operations without sanitization, enabling path traversal that reads, writes, modifies, and deletes files outside the intended blob storage directory.

Critical Impact
Unauthenticated attackers can achieve remote code execution by uploading a webshell to a web-accessible directory through the exposed blob storage endpoints.

Affected Products

IoTSharp (open-source IoT platform)
IoTSharp/Controllers/BlobStorageController.cs
Deployments using the default Startup.cs without a global authorization fallback policy

Discovery Timeline

2026-08-05 - CVE-2026-71262 published to NVD
2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-71262

Vulnerability Analysis

The vulnerability combines two defects into a single unauthenticated remote code execution primitive. First, BlobStorageController is missing the [Authorize] attribute that guards other controllers such as DevicesController, CustomersController, and TenantsController. Second, Startup.cs does not register a global FallbackPolicy that would apply authorization to controllers lacking explicit attributes. The result is that every action on the blob controller is anonymously reachable over the network.

Once an attacker reaches these endpoints, the controller uses the path and filename request parameters directly in calls such as _blob.WriteFileAsync($"{path}/{formFile.FileName}", ...). There is no canonicalization, no allow-list, and no check that the resolved path stays within the blob root. This is a classic missing-authentication flaw ([CWE-306]) chained with path traversal.

Root Cause

The root cause is inconsistent access control enforcement in the ASP.NET Core pipeline. Authorization is applied per controller through the [Authorize] attribute rather than centrally, and BlobStorageController was not decorated with it. Without a FallbackPolicy requiring an authenticated user, the framework treats the controller as anonymous. Compounding this, file paths are constructed through string interpolation over untrusted input.

Attack Vector

An attacker sends HTTP requests directly to the blob endpoints without any credentials or session. By supplying traversal sequences such as ../../wwwroot in the path parameter and a filename ending in .aspx, .ashx, or .cshtml, the attacker writes a webshell into the web-served directory. Subsequent HTTP requests to that file execute attacker-controlled code in the application's process context. The same primitive supports arbitrary file read, overwrite of configuration files, and deletion of application binaries.

See the BlobStorageController source and the IoTSharp project repository for the affected code.

Detection Methods for CVE-2026-71262

Indicators of Compromise

HTTP requests to /api/BlobStorage/* endpoints from unauthenticated clients or unexpected source addresses
Request bodies or query strings containing ../, ..\, URL-encoded %2e%2e%2f, or absolute paths in path/filename parameters
New or modified files with server-executable extensions (.aspx, .ashx, .cshtml, .dll) inside wwwroot or application binary directories
Child processes spawned by the IoTSharp application process (for example cmd.exe, powershell.exe, /bin/sh) following blob upload activity

Detection Strategies

Inspect web server and application logs for anonymous POST/PUT/DELETE traffic to blob storage routes and correlate with file system writes outside the configured blob root.
Enable file integrity monitoring on wwwroot, application binary directories, and configuration paths to catch webshell drops and configuration tampering.
Deploy WAF rules that block traversal sequences and non-alphanumeric characters in path and filename parameters on IoTSharp endpoints.

Monitoring Recommendations

Alert on process lineage where the IoTSharp dotnet process spawns interactive shells or scripting hosts.
Track authentication telemetry to identify endpoints receiving traffic without corresponding auth events, which highlights unprotected controllers.
Baseline outbound network connections from the IoTSharp host and flag deviations that suggest post-exploitation command-and-control.

How to Mitigate CVE-2026-71262

Immediate Actions Required

Restrict network access to IoTSharp management and API endpoints to trusted networks until a patched build is deployed.
Add the [Authorize] attribute to BlobStorageController and rebuild the application from source.
Audit all controllers in the project for missing authorization attributes and register a global authorization FallbackPolicy in Startup.cs that requires an authenticated user by default.
Review wwwroot and application directories for unexpected files created since the service was first exposed.

Patch Information

No vendor advisory or fixed version was listed in the NVD entry at publication. Track the IoTSharp repository for a patched release. Until an official fix ships, apply the source-level changes described above and rebuild.

Workarounds

Place IoTSharp behind a reverse proxy that enforces authentication and blocks the /api/BlobStorage/* routes for unauthenticated clients.
Add a WAF rule set that rejects requests to blob endpoints containing .., backslashes, or path separators in the path and filename parameters.
Run the IoTSharp process under a least-privileged account with no write permission to wwwroot or binary directories, reducing the impact of a successful traversal write.

bash

# Example ASP.NET Core global authorization fallback in Startup.cs
# services.AddAuthorization(options =>
# {
#     options.FallbackPolicy = new AuthorizationPolicyBuilder()
#         .RequireAuthenticatedUser()
#         .Build();
# });