CVE-2026-57581: DotVVM DOS Vulnerability

CVE-2026-57581 Overview

CVE-2026-57581 is a medium-severity vulnerability in DotVVM, an open source Model-View-ViewModel (MVVM) framework for .NET web applications. Applications configured with file upload storage accept files submitted directly to DotvvmFileUploadMiddleware without requiring the X-DotVVM-UploadToken header normally generated by the FileUpload component. Unauthenticated attackers can repeatedly submit files to fill application storage and trigger a denial-of-service condition. The flaw is categorized under improper restriction of uploaded file handling [CWE-434]. It is fixed in DotVVM versions 4.2.11, 4.3.15, and 5.0.0-preview09-final.

Critical Impact
Unauthenticated remote attackers can exhaust storage capacity on affected DotVVM applications through repeated file uploads, resulting in denial of service.

Affected Products

DotVVM versions prior to 4.2.11
DotVVM versions prior to 4.3.15
DotVVM 5.0.0 preview releases prior to 5.0.0-preview09-final

Discovery Timeline

2026-09-14 - CVE-2026-57581 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-57581

Vulnerability Analysis

DotVVM ships a built-in file upload pipeline consisting of the client-side FileUpload component and the server-side DotvvmFileUploadMiddleware. Under normal use, the component negotiates an X-DotVVM-UploadToken value that the middleware validates before persisting uploads to the configured storage backend. Prior to the patched releases, the middleware processed multipart requests even when no valid token accompanied the request. Any anonymous HTTP client that reached the upload endpoint could stream arbitrary files into storage.

Because DotVVM applications frequently expose the upload endpoint on the same host as the main application, the attack surface is broad. Repeated submissions consume disk space, inode counts, or object storage quotas, degrading application availability. The impact is confined to availability rather than confidentiality or integrity, since the uploaded content is not directly executed.

Root Cause

The middleware lacked enforcement of the anti-abuse token that the FileUpload component was designed to issue. Without this precondition, the storage-writing code path was reachable by any network client, regardless of authentication state. The fix introduces token validation inside the middleware and adds an AuthorizeFileUpload hook in DotvvmSecurityConfiguration to restrict which principals may upload.

Attack Vector

Exploitation requires only network access to a vulnerable DotVVM application with file upload storage configured. An attacker issues repeated multipart POST requests to the upload endpoint without supplying X-DotVVM-UploadToken. Each accepted request writes to the configured storage location until the volume is exhausted.

text

// Security patch in src/Framework/Core/Storage/UploadedFile.cs
// Adds token validation semantics to the file upload middleware
         public bool IsFileTypeAllowed { get; set; } = true;
 
-        /// <summary> If the file size is larger that the limit specified in <c>FileUpload.MaxFileSize</c>. Use with caution, the user may manipulate with this property. </summary>
+        /// <summary> Always true </summary>
+        // [Obsolete("this is always true")]
         public bool IsMaxSizeExceeded { get; set; } = false;

// Source: https://github.com/riganti/dotvvm/commit/6af982bbe3b00bdac00f1c0efe9365d52db642ef

text

// Security patch in src/Framework/Framework/Configuration/DotvvmSecurityConfiguration.cs
// Introduces AuthorizeFileUpload hook for additional upload restrictions
 using System.ComponentModel;
 using System.Linq;
 using System.Text.Json.Serialization;
+using System.Threading.Tasks;
+using DotVVM.Framework.Hosting;
 
 namespace DotVVM.Framework.Configuration
 {

// Source: https://github.com/riganti/dotvvm/commit/1635245b5eaf9ccf8e3536b9d8b1941819526585

Detection Methods for CVE-2026-57581

Indicators of Compromise

Bursts of multipart POST requests to the DotVVM file upload endpoint from a single source or distributed set of sources.
Multipart upload requests that omit the X-DotVVM-UploadToken header or supply invalid values.
Rapid growth in the configured file upload storage directory or object storage bucket.
Application errors indicating disk exhaustion, quota limits reached, or failed writes to the upload backend.

Detection Strategies

Correlate web server access logs with storage capacity metrics to identify upload volume anomalies over short intervals.
Alert on requests to DotvvmFileUploadMiddleware endpoints that lack the expected X-DotVVM-UploadToken header.
Baseline the ratio of authenticated to unauthenticated upload sessions and flag deviations.

Monitoring Recommendations

Instrument disk, inode, and object storage usage for hosts running DotVVM applications with alerting thresholds well below capacity.
Enable request logging on the reverse proxy or WAF fronting DotVVM to capture headers, source IPs, and payload sizes.
Retain upload middleware telemetry for post-incident analysis of source addresses and upload counts.

How to Mitigate CVE-2026-57581

Immediate Actions Required

Upgrade DotVVM to 4.2.11, 4.3.15, or 5.0.0-preview09-final depending on the release branch in use.
Configure DotvvmConfiguration.Security.AuthorizeFileUpload to restrict uploads to authenticated or specifically authorized users.
Rotate or purge unexpected files written to the upload storage location since the deployment of the vulnerable version.

Patch Information

Upstream fixes are delivered in the GitHub Release v4.3.15 and the GitHub Release v5.0.0-preview09, with the coordinated advisory published as GHSA-2rm3-333w-xvc4. The relevant commits are 1635245, 4fc26a8, and 6af982b.

Workarounds

Place a reverse proxy or WAF rule in front of the application that rejects upload requests missing a valid X-DotVVM-UploadToken header.
Enforce request rate limits and per-source upload quotas on the DotVVM upload endpoint.
Move file upload storage to a volume with hard quotas so an exhaustion event cannot impact the operating system or application binaries.

bash

# Configuration example: enforce authorization on DotVVM file uploads
# In Startup / DotvvmStartup where the DotvvmConfiguration is built:
#
# config.Security.AuthorizeFileUpload.Add(async (context) =>
# {
#     return context.HttpContext.User?.Identity?.IsAuthenticated == true;
# });