CVE-2025-47909: Go TrustedOrigins CSRF Vulnerability

CVE-2025-47909 Overview

CVE-2025-47909 is a Cross-Site Request Forgery (CSRF) protection bypass in the github.com/gorilla/csrf Go module. Hosts added to the TrustedOrigins allowlist implicitly accept requests from both their HTTPS and HTTP origins. A network attacker positioned between the client and an HTTP endpoint can leverage this to forge state-changing requests against an HTTPS application. The flaw is classified under CWE-346: Origin Validation Error.

Critical Impact
A network-positioned man-in-the-middle (MitM) attacker can perform CSRF attacks against applications using gorilla/csrf whenever a trusted origin host is reachable over plain HTTP.

Affected Products

github.com/gorilla/csrf Go module (all versions that ship the post-CVE-2025-24358 origin check)
Go web applications relying on TrustedOrigins for cross-origin allowlisting
Applications that have not migrated to net/http.CrossOriginProtection (introduced in Go 1.25)

Discovery Timeline

2025-08-29 - CVE-2025-47909 published to NVD
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-47909

Vulnerability Analysis

The defect lives in the origin validation logic that gorilla/csrf introduced to remediate CVE-2025-24358. That earlier fix compares the inbound Origin header against a synthetic URL built from the request host using sameOrigin. The comparison ignores the scheme component of the synthetic URL and matches only on host.

When an application calls TrustedOrigins with a host such as example.net, the library accepts requests originating from either https://example.net or http://example.net. This makes the allowlist scheme-agnostic in a way that is invisible to developers reading the configuration. The flaw weakens transport security guarantees by re-introducing a CSRF vector that the original patch was intended to close.

Root Cause

The root cause is improper origin validation. The library treats Origin headers as equivalent whenever their host matches a trusted entry, regardless of whether the request arrived over http:// or https://. Because HTTP origins are subject to network tampering, an attacker controlling traffic on the path to a trusted host can inject content that issues authenticated cross-origin requests to the protected HTTPS application.

Attack Vector

Consider an application hosted at https://example.com that adds example.net to its TrustedOrigins. A network attacker who can intercept plaintext traffic to example.net serves a malicious HTML page at http://example.net containing an auto-submitting form targeting https://example.com. The browser attaches the user's session cookies, the Origin header reads http://example.net, and gorilla/csrf accepts the request because the host matches the trusted entry. The attacker does not need to compromise the protected application or its TLS certificate — only an unrelated HTTP-reachable trusted host.

No public proof-of-concept is referenced in the Go vulnerability database entry at the time of writing.

Detection Methods for CVE-2025-47909

Indicators of Compromise

Inbound state-changing requests carrying an Origin header with scheme http:// whose host matches an entry in TrustedOrigins.
Unexpected POST, PUT, PATCH, or DELETE requests with Referer headers pointing at HTTP versions of trusted partner domains.
Application logs showing successful CSRF token validation for requests that originated from non-TLS contexts.

Detection Strategies

Audit application source for calls to csrf.TrustedOrigins and enumerate every host that is allowlisted.
Instrument middleware to log the full Origin and Referer headers on authenticated mutating requests, then alert on HTTP-scheme matches.
Run dependency scanners against go.mod to identify projects pinned to vulnerable github.com/gorilla/csrf releases as flagged by GO-2025-3884.

Monitoring Recommendations

Forward web server access logs to a centralized analytics pipeline and build queries that correlate Origin: http:// headers with sensitive endpoints.
Alert when a trusted-origin host begins serving content over HTTP, which expands the MitM attack surface.
Track govulncheck results in CI to catch new builds that still depend on vulnerable module versions.

How to Mitigate CVE-2025-47909

Immediate Actions Required

Inventory every Go service that imports github.com/gorilla/csrf and review its TrustedOrigins configuration.
Migrate to net/http.CrossOriginProtection in Go 1.25, which performs scheme-aware origin checks by default.
If migration to Go 1.25 is not feasible, switch to the maintained backport at filippo.io/csrf, or use the drop-in filippo.io/csrf/gorilla replacement for the existing API surface.

Patch Information

The upstream remediation guidance, published with the Go vulnerability report GO-2025-3884 and tracked in golang/vulndb issue #3884, is to stop relying on gorilla/csrf origin validation. Applications should adopt net/http.CrossOriginProtection, filippo.io/csrf, or filippo.io/csrf/gorilla. These replacements treat the request scheme as part of the origin and reject HTTP-origin submissions to HTTPS applications.

Workarounds

Remove entries from TrustedOrigins whose hosts are reachable over plain HTTP, or restrict the allowlist to first-party hosts that enforce HSTS preload.
Terminate the request at a reverse proxy that strips or rewrites Origin headers to enforce HTTPS-only cross-origin policy.
Require SameSite=Strict or SameSite=Lax cookies on session identifiers to reduce browser-initiated cross-origin exposure.

bash

# Replace vulnerable gorilla/csrf usage with the maintained backport
go get filippo.io/csrf@latest
go mod tidy

# Verify remediation with govulncheck
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...