CVE-2025-47909

What it actually does

TrustedOrigins configuration implicitly trusts both HTTP and HTTPS origins for a given host, bypassing Origin header same-origin checks and enabling network attackers to submit cross-origin forms from the HTTP variant of a trusted host.

Why it matters to the business

Attackers on the local network can trigger unauthorized state-changing actions on behalf of authenticated users, potentially leading to data exposure, account manipulation, or other application-specific impacts until the configuration is corrected.

How an attack unfolds

A network-positioned attacker observes an application that lists a host in TrustedOrigins, registers the matching HTTP origin, serves a malicious form from that HTTP origin, and causes a victim browser to submit it to the HTTPS application endpoint, defeating the post-CVE-2025-24358 synthetic-URL check because only the host component is validated.

How to fix it

Migrate applications to net/http.CrossOriginProtection introduced in Go 1.25. When that is unavailable, adopt the backported module at filippo.io/csrf or the gorilla/csrf drop-in replacement at filippo.io/csrf/gorilla. Audit all TrustedOrigins lists and remove entries that are no longer required.

How to confirm the fix worked

Review source code and configuration for use of TrustedOrigins, confirm that only scheme-aware cross-origin protection is active, and test that HTTP origins of listed hosts are rejected while HTTPS origins continue to function as intended.

Typical attack path

1. Identify an application that configures TrustedOrigins with a host name
2. Position as a network MitM or compromised HTTP site for that host
3. Craft and host a form targeting the HTTPS application endpoint
4. Induce an authenticated victim to load and submit the form
5. Bypass Origin validation and perform the CSRF action

How to detect it

Search application and web-server logs for POST or state-changing requests whose Origin header contains an HTTP scheme for a host listed in TrustedOrigins; correlate with authentication events and look for form submissions lacking expected Referer or Origin values.

What your security team should do

• Prioritize migration to net/http.CrossOriginProtection or the filippo.io/csrf module within the next sprint
• Scan codebases for TrustedOrigins usage and document required hosts
• Add static-analysis rules to flag continued use of the vulnerable pattern
• Monitor EPSS and KEV updates given the 424 days since publication