DotVVM EUVD-2026-77700

Exploitable only when the application uses DotVVM's AuthorizeActionFilter as its authorization mechanism on commands, view models, or presenters (reflected in the CVSS 4.0 AT:P attack-requirement metric). For such apps there are no further limits: exploitation is remote, unauthenticated (PR:N), needs no user interaction (UI:N), and requires no special bypass technique - the filter silently allows all requests. Applications that instead use AuthorizeAttribute (the recommended workaround, which implements the same interfaces correctly) or another authorization filter are NOT affected. Affected versions: DotVVM < 4.2.11, 4.3.0-preview01 through < 4.3.15, and 5.0.0-preview01 through < 5.0.0-preview09-final.

Signals are internally consistent in pointing to a genuinely severe but not urgently-exploited flaw. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VC:H/VI:H/VA:H) and SSVC Technical Impact of 'total' both reflect that once triggered, an unauthenticated remote attacker gains full access to whatever the filter was supposed to protect - this is a total authorization failure (CWE-862), not a partial one, since AuthorizeActionFilter performs no check at all. However, exploitation is bounded by AT:P (attack requirement present): the target application must actually use AuthorizeActionFilter as its authorization mechanism, so the flaw is critical for affected apps but inert for those using AuthorizeAttribute or other filters. Real-world urgency signals are LOW and agree with each other: EPSS 0.44% (37th percentile), SSVC Exploitation:none and Automatable:no, no CISA KEV listing, and no public POC. This is therefore a high-impact, patch-promptly issue rather than an actively-exploited emergency - its danger is silent (no bypass technique is needed, so vulnerable apps may already be exposing endpoints without any attack signature) rather than mass-exploited. Note a data caveat: the commit diff supplied in the intelligence (1635245b) is a FileUpload authorization/token hardening change, NOT the AuthorizeActionFilter fix described in the advisory - verify the actual fix commit against the GHSA before drawing code-level conclusions.

A DotVVM application uses AuthorizeActionFilter to restrict a sensitive command, view model, or presenter to authorized users. Because the filter's interface implementations return completed tasks without performing any check, an unauthenticated remote attacker simply issues the normal request to the protected command/view model/presenter and it executes - no bypass, token forgery, or special technique is required. No public exploit code is identified at time of analysis, but exploitation is trivial for anyone who knows the endpoint exists.