Waku's RSC request dispatcher invokes server actions without validating the request's "Origin" (or "Sec-Fetch-Site") header. A cross-origin web attacker can therefore cause a victim browser to issue an authenticated "POST" to a registered server action endpoint using a CORS-safelisted content type ("text/plain"), which does not trigger a preflight. Any state-mutating server action that the application exposes via "'use server'" can be invoked with the victim's cookies attached. A working proof-of-concept demonstrates the vulnerability against waku 1.0.0-beta.0 dev server: a cross-origin POST with "Content-Type: text/plain" invokes a registered "'use server'" action and returns HTTP 200 with an RSC stream response. The same defect affects the progressive-enhancement (no-JavaScript) server action path: a cross-origin HTML form auto-submitting "multipart/form-data" reaches the dispatch through a second unguarded branch of the request handler, dynamically confirmed on 2026-05-17. Both branches were confirmed exploitable from opaque-origin contexts (sandboxed iframes, "file://" navigation, browser extension pages), which send "Origin: null" — a value no Origin guard exists to reject. This is the same vulnerability class previously disclosed for Next.js Server Actions (GHSA-mq59-m269-xvcx); waku's implementation is broader in that no Origin check exists at all in the default request handler.