How severe is GHSA-m2m6-cff5-3w7c?

GHSA-m2m6-cff5-3w7c has a CVSS score of 5.3/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-m2m6-cff5-3w7c?

GHSA-m2m6-cff5-3w7c affects the following packages: rwsdk (npm). Ecosystems affected: npm.

How do I fix GHSA-m2m6-cff5-3w7c?

Update rwsdk to 1.2.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m2m6-cff5-3w7c is resolved across your whole dependency graph.

How do I detect GHSA-m2m6-cff5-3w7c in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for rwsdk. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-m2m6-cff5-3w7c if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-m2m6-cff5-3w7c?

O3 pinpoints whether GHSA-m2m6-cff5-3w7c is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-m2m6-cff5-3w7c actively exploited in the wild?

No public exploit code has been indexed for GHSA-m2m6-cff5-3w7c yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-m2m6-cff5-3w7c published, and has it been updated?

GHSA-m2m6-cff5-3w7c was published on April 24, 2026 and was last updated on May 13, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 npm

GHSA-m2m6-cff5-3w7c

MEDIUM

GHSA-m2m6-cff5-3w7c is a medium-severity (CVSS 5.3) vulnerability in rwsdk. O3 Security confirms whether GHSA-m2m6-cff5-3w7c is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

RedwoodSDK has Same-site CSRF through lack of origin validation in its server actions

Also known asCVE-2026-42190

Published

Apr 24, 2026

Updated

May 13, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Real-World Exposure

1 pkg affected

📦rwsdk

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Server actions in rwsdk apply HTTP method enforcement but no origin validation. A request originating from a different origin that the browser treats as same-site can invoke a server action with the victim's session cookie attached.

Impact

An attacker who controls any origin the browser considers same-site with the deployed app can induce an authenticated victim's browser to invoke arbitrary server actions. The exposure depends on deployment shape:

Apps deployed on custom domains (for example app.example.com) are exposed whenever the attacker controls any sibling subdomain under the same registrable domain. Plausible vectors include subdomain takeover of stale DNS records pointing at third-party services, cross-site scripting on a sibling application, or content served from a user-content subdomain.
Apps deployed on platform-suffix domains on the Public Suffix List (*.workers.dev, *.pages.dev) are not exposed to the sibling-subdomain vector, because sibling subdomains under those suffixes are treated as cross-site.
In local development, localhost on any other port is treated as same-site with the app's dev server. A separate process running on the developer's machine can invoke server actions against the dev server.

The attacker cannot read action responses (mode: "no-cors" yields opaque responses). Impact is therefore limited to side effects of action invocation: writes, state changes, and any externally observable action the application performs in response.

Cross-site requests from unrelated origins (evil.com targeting app.com) are not affected because SameSite=Lax session cookies are not attached by default in that scenario.

Affected Configurations

Applications using rwsdk server actions (serverAction() or functions invoked via the RSC action protocol) in combination with cookie-based authentication. serverQuery() is not affected because it is designed to be idempotent and is invoked via GET.

Patch

The patched release enforces an Origin/Host match for non-GET action requests. Requests whose Origin header does not match the request's own origin are rejected with HTTP 403 unless the origin is listed in a new allowedOrigins configuration option.

No application code changes are required for apps that invoke server actions from their own origin. Apps that legitimately invoke server actions from another origin must add those origins to the allowedOrigins option on defineApp.

Credits

Reported by @mthx.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`rwsdk`	≥ 1.0.0-beta.50&&< 1.2.3	1.2.3

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for rwsdk. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update rwsdk to 1.2.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m2m6-cff5-3w7c is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-m2m6-cff5-3w7c is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-m2m6-cff5-3w7c. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary Server actions in `rwsdk` apply HTTP method enforcement but no origin validation. A request originating from a different origin that the browser treats as same-site can invoke a server action with the victim's session cookie attached. ### Impact An attacker who controls any origin the browser considers same-site with the deployed app can induce an authenticated victim's browser to invoke arbitrary server actions. The exposure depends on deployment shape: - Apps deployed on custom domains (for example `app.example.com`) are exposed whenever the attacker controls any sibling subd

O3 Security · Impact-Aware SCA

Is GHSA-m2m6-cff5-3w7c in your dependencies?

O3 detects GHSA-m2m6-cff5-3w7c across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works