CVE-2026-73423 in Astro
Summary
by MITRE • 08/12/2026
Astro is a web framework for content-driven websites. From 7.0.0 until 7.0.6, the composable astro/hono pipeline installs security.checkOrigin only through the middleware() primitive, while actions() and pages() can dispatch to user code independently. Mounting actions() before middleware(), as in the examples/advanced-routing example and Cloudflare Hono documentation, allows cross-origin form-encoded action requests to execute before the origin check, and using pages() without middleware() drops the check for on-demand endpoints and pages. The flaw enables blind write-only cross-site request forgery using the victim's cookies against ActionHandler.handle and PagesHandler.handleWithErrorFallback when manifest.checkOrigin is enabled; the attacker can trigger a state-mutating action or endpoint handler but cannot read the cross-origin response. The default non-composable astro() pipeline is not affected. This issue is fixed in version 7.0.6.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/12/2026
The vulnerability exists within Astro web framework versions 7.0.0 through 7.0.6, specifically affecting the composable astro/hono pipeline implementation that handles security.checkOrigin validation. This flaw stems from an inconsistent application of origin checking mechanisms where middleware() primitive properly enforces security.checkOrigin while actions() and pages() can execute user code independently without such validation. The architectural inconsistency creates a window of opportunity for attackers to exploit cross-origin requests before proper origin verification occurs, particularly when mounting actions() before middleware() as demonstrated in examples/advanced-routing and Cloudflare Hono documentation patterns.
The technical implementation flaw resides in the pipeline's execution order and security validation logic where form-encoded cross-origin requests can traverse the action handler before the origin check is enforced. When actions() are mounted prior to middleware(), the security.checkOrigin validation occurs too late in the request processing chain, allowing malicious requests to be dispatched to ActionHandler.handle and PagesHandler.handleWithErrorFallback with victim cookies already present. This creates a blind write-only cross-site request forgery condition where attackers can trigger state-mutating operations against legitimate endpoints but cannot observe or read the responses from these cross-origin interactions.
The operational impact of this vulnerability is significant as it enables attackers to perform unauthorized modifications to application state through victim sessions without requiring any direct user interaction beyond the initial cross-origin request. The flaw specifically affects scenarios where manifest.checkOrigin is enabled, providing a mechanism for attackers to manipulate application data or execute unintended operations against endpoints that should be protected from cross-origin access. However, the vulnerability is limited to write-only operations as the attacker cannot read response data from cross-origin requests, which constrains the potential information disclosure but still allows for state modification attacks.
Security mitigation requires updating to Astro framework version 7.0.6 which resolves this inconsistency in security validation implementation. Organizations should also review their application routing patterns to ensure actions() and pages() are not mounted before middleware() when security.checkOrigin is enabled, and consider implementing additional security controls such as CSRF tokens for critical state-mutating operations. The vulnerability aligns with CWE-352 Cross-Site Request Forgery and follows ATT&CK technique T1203 Exploitation for Client Execution patterns where attackers leverage legitimate application functionality to perform unauthorized operations through victim sessions.
The default non-composable astro() pipeline remains unaffected by this issue, indicating the problem is specifically within the composable astro/hono integration path. This distinction suggests that the vulnerability is not inherent to the framework itself but rather emerges from specific implementation choices in the composable pipeline architecture. Security practitioners should monitor for similar patterns in custom middleware implementations and ensure consistent security validation across all application entry points regardless of execution order or routing configuration.