CVE-2026-53663

What it actually does

React Router v7 Framework Mode versions 7.12.0 through versions before 7.15.1 applied CSRF validation to POST requests but did not apply equivalent checks to PUT, PATCH, or DELETE requests. If an application exposes state-changing framework actions over those HTTP methods and relies on React Router’s built-in CSRF protection as the primary guard, a cross-site request could potentially modify server-side state without the user intentionally performing the action. The practical exploitability is limited because browsers commonly block the relevant cross-origin paths through CORS preflight behavior and SameSite cookie defaults, which is reflected in the low CVSS score, low EPSS score, absence from KEV, and no known mature public exploitation.

Why it matters to the business

The main business risk is unauthorized modification or deletion of user-accessible data in applications using affected React Router Framework Mode versions, especially where applications allow credentialed cross-origin requests or use permissive cookie/CORS settings. Operational impact is generally low, but affected internet-facing applications should still be updated because the flaw sits in a widely used web framework component and may be easier to exploit in applications with weakened browser-side protections.

How an attack unfolds

An attacker would first identify an application using React Router v7 Framework Mode in an affected version range and locate state-changing routes that accept PUT, PATCH, or DELETE. The attacker would then craft a malicious web page or link that attempts to cause a victim’s browser to send one of those requests while the victim is authenticated to the target application. If the application’s cookies are sent cross-site and the browser is allowed to make the request despite CORS preflight requirements, the missing CSRF check may allow the request to reach the application as if it were an intentional user action. Successful exploitation would typically result in low-integrity impact such as changing a setting, updating a record, or deleting user-accessible data, rather than code execution or data disclosure.

How to fix it

Upgrade React Router to version 7.15.1 or later. Treat affected versions as 7.12.0 through versions before 7.15.1 when used in v7 Framework Mode. If immediate upgrade is not possible, add explicit server-side CSRF validation for all state-changing methods, including POST, PUT, PATCH, and DELETE; require unpredictable CSRF tokens or equivalent origin-bound validation; reject unexpected Origin and Referer headers for state-changing requests; avoid credentialed wildcard CORS; and ensure cookies use appropriate SameSite settings, preferably Lax or Strict where application flows allow it.

How to confirm the fix worked

Confirm dependency manifests and lockfiles resolve React Router to 7.15.1 or later. Verify the application is not bundling or deploying an older transitive copy. Review routes/actions to ensure state-changing endpoints using PUT, PATCH, and DELETE require CSRF validation or equivalent origin checks. Test by sending cross-origin simulated PUT, PATCH, and DELETE requests without a valid CSRF token and confirm they are rejected. Also confirm CORS responses do not allow arbitrary origins with credentials and that authentication cookies are configured with appropriate SameSite attributes.

Typical attack path

1. Identify a React Router v7 Framework Mode application running version 7.12.0 or later but before 7.15.1.
2. Map application routes that perform state-changing actions using PUT, PATCH, or DELETE.
3. Create a malicious web page that triggers one of those HTTP methods against the target application.
4. Convince an authenticated user to visit the malicious page or interact with attacker-controlled content.
5. Rely on permissive CORS settings, cross-site cookies, or other weakened browser protections so the request is sent with the user’s credentials.
6. Cause the vulnerable route to process the request without the intended CSRF validation.
7. Modify or delete data within the permissions of the victim user.

How to detect it

Look for evidence of authenticated state-changing requests over PUT, PATCH, or DELETE that appear to originate from outside the application’s normal user interface. Useful sources include web server access logs, application request logs, WAF logs, reverse proxy logs, CDN logs, identity/session logs, and audit logs for changes or deletions. Prioritize events where the request method is PUT, PATCH, or DELETE; the Origin header is absent, null, or an untrusted domain; the Referer is external or missing; Fetch Metadata headers show cross-site context, such as Sec-Fetch-Site: cross-site; and the action resulted in a successful 2xx or 3xx response. Correlate these requests with user complaints, unexpected record updates, deletes, setting changes, or audit events occurring shortly after the user visited an external site. There are no known public exploit payloads or actor-specific indicators for this vulnerability, so detection should be behavior-based rather than signature-only.

What your security team should do

• Inventory applications using React Router v7 Framework Mode and identify versions 7.12.0 through before 7.15.1.
• Upgrade affected applications to React Router 7.15.1 or later during the next normal patch cycle, with higher priority for internet-facing applications handling sensitive or destructive user actions.
• Review CORS policies and remove credentialed access for untrusted origins, especially wildcard or origin-reflection configurations.
• Require CSRF protections consistently across POST, PUT, PATCH, and DELETE routes, not only POST.
• Harden authentication cookies with SameSite=Lax or SameSite=Strict where feasible and Secure/HttpOnly attributes.
• Search recent access logs for unusual authenticated PUT, PATCH, or DELETE requests with cross-site Origin, missing Referer, or unexpected browser Fetch Metadata headers.
• Because this is not KEV-listed, not associated with ransomware use, and has very low EPSS, prioritize remediation based on application exposure and business criticality rather than emergency response.