Dotvvm
Monthly
Missing authorization in DotVVM's AuthorizeActionFilter causes any ASP.NET web application that relies on that filter to grant unauthenticated remote access to protected commands, view models, and presenters - the filter performs no check at all, so no bypass technique is required. All DotVVM releases before 4.2.11, the 4.3.0-preview01 through 4.3.15 range, and 5.0.0-preview01 through 5.0.0-preview09-final are affected; the vendor rates this critical (CVSS 4.0 base 9.2, independently assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H with high confidentiality, integrity, and availability impact). Exploitation applies only where AuthorizeActionFilter is actually wired up (CVSS 4.0 AT:P expresses that attack requirement), and no public exploit code and no confirmed active exploitation were identified at time of analysis, with EPSS at just 0.44% (37th percentile).
A regular-expression denial-of-service (ReDoS) flaw in DotVVM's routing engine (DotvvmRoute.IsMatch / DotvvmRouteParser.RouteRegex) lets a remote requester send a long, near-matching URL path and force excessive regex backtracking, tying up a worker thread for roughly one second per request. Only applications that declare routes with multiple unconstrained parameters inside a single path segment (e.g. "edit/{a}-{b}-{c}/done") are exposed; fully constrained or slash-separated routes are unaffected. The issue is fixed in DotVVM 4.2.11, 4.3.15 and 5.0.0-preview09-final, which apply a one-second regex timeout and then permanently switch the route to the .NET non-backtracking engine (or return HTTP 503 on runtimes older than .NET 8). There is no CISA KEV entry and no public exploit code identified at time of analysis, and CISA's SSVC assessment rates Exploitation as none and Automatable as no.
Unrestricted file upload in DotVVM before 4.2.11, 4.3.15, and 5.0.0-preview09-final lets unauthenticated remote users push arbitrary files into the application's configured upload storage by posting directly to DotvvmFileUploadMiddleware without a valid X-DotVVM-UploadToken, enabling repeated uploads that exhaust disk space and cause denial of service. The flaw stems from the middleware storing files without verifying a per-render cryptographic token or applying the previously client-supplied type/size constraints server-side. No CISA KEV listing or public exploit code was identified at time of analysis; the vendor has released fixes and adds an optional AuthorizeFileUpload authorization hook.
Missing authorization in DotVVM's AuthorizeActionFilter causes any ASP.NET web application that relies on that filter to grant unauthenticated remote access to protected commands, view models, and presenters - the filter performs no check at all, so no bypass technique is required. All DotVVM releases before 4.2.11, the 4.3.0-preview01 through 4.3.15 range, and 5.0.0-preview01 through 5.0.0-preview09-final are affected; the vendor rates this critical (CVSS 4.0 base 9.2, independently assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H with high confidentiality, integrity, and availability impact). Exploitation applies only where AuthorizeActionFilter is actually wired up (CVSS 4.0 AT:P expresses that attack requirement), and no public exploit code and no confirmed active exploitation were identified at time of analysis, with EPSS at just 0.44% (37th percentile).
A regular-expression denial-of-service (ReDoS) flaw in DotVVM's routing engine (DotvvmRoute.IsMatch / DotvvmRouteParser.RouteRegex) lets a remote requester send a long, near-matching URL path and force excessive regex backtracking, tying up a worker thread for roughly one second per request. Only applications that declare routes with multiple unconstrained parameters inside a single path segment (e.g. "edit/{a}-{b}-{c}/done") are exposed; fully constrained or slash-separated routes are unaffected. The issue is fixed in DotVVM 4.2.11, 4.3.15 and 5.0.0-preview09-final, which apply a one-second regex timeout and then permanently switch the route to the .NET non-backtracking engine (or return HTTP 503 on runtimes older than .NET 8). There is no CISA KEV entry and no public exploit code identified at time of analysis, and CISA's SSVC assessment rates Exploitation as none and Automatable as no.
Unrestricted file upload in DotVVM before 4.2.11, 4.3.15, and 5.0.0-preview09-final lets unauthenticated remote users push arbitrary files into the application's configured upload storage by posting directly to DotvvmFileUploadMiddleware without a valid X-DotVVM-UploadToken, enabling repeated uploads that exhaust disk space and cause denial of service. The flaw stems from the middleware storing files without verifying a per-render cryptographic token or applying the previously client-supplied type/size constraints server-side. No CISA KEV listing or public exploit code was identified at time of analysis; the vendor has released fixes and adds an optional AuthorizeFileUpload authorization hook.