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.

# 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 ./...