CVE-2025-24358 - Critical CSRF Protection Bypass in gorilla/csrf (Go)

gorilla/csrf is a popular middleware library that prevents Cross Site Request Forgery (CSRF) attacks in Go web apps and services. If you’re using gorilla/csrf (prior to version 1.7.2), read carefully—your CSRF protection may not be working as you expect. This post explains CVE-2025-24358, how it happened, who is affected, and how it can be exploited, with code examples and references.

Executive Summary

- Vulnerability: gorilla/csrf fails to validate the Origin header and misinterprets the Referer header check due to a Go HTTP spec nuance.
- Consequence: Attackers with XSS on a related domain can bypass CSRF protection and make authenticated, state-changing requests.
- Status: Fixed in gorilla/csrf v1.7.2.
- Reference: Github Security Advisory

Verifying the Origin or Referer header to check the request source.

Best practice: Always check Origin/Referer, deny unsafe requests, and keep an up-to-date allowlist.

### What Went Wrong in gorilla/csrf

In vulnerable versions <1.7.2, the code attempts to check the Referer’s origin only for TLS requests (https), using Go's native request structure:

if r.URL.Scheme == "https" {
    // Validate Referer header
}

But in Go, r.URL.Scheme is always empty for server requests (see docs), so this block never runs.

Vulnerable Code Snippet

// This is equivalent pseudo from before the fix
func validateRequest(r *http.Request) error {
    if r.URL.Scheme == "https" {
        referer := r.Header.Get("Referer")
        // validate referer's scheme/host
        // ... CSRF check logic ...
    }
    // NO Origin header check at all!
}

Impact

If your application is using gorilla/csrf for CSRF protection and is on a version prior to 1.7.2, any user who controls a related subdomain or has XSS can send authenticated cross-origin form posts. For example:

Cookies are set for .example.com

If attacker gets XSS on evil.example.com, they can bypass CSRF verification (because no Referer/Origin check runs), and send POST requests to www.example.com as the user.

Exploit Details

Here’s a minimal working example and an outline of the attack flow.

Example Setup

#### Victim Server Using gorilla/csrf (<1.7.2)

package main

import (
    "net/http"
    "github.com/gorilla/csrf"
)

func main() {
    CSRF := csrf.Protect([]byte("very-secret-32-byte-key"))
    mux := http.NewServeMux()
    mux.HandleFunc("/transfer", func(w http.ResponseWriter, r *http.Request) {
        // Money transfer code, assumes CSRF protection
        w.Write([]byte("Money sent!"))
    })
    http.ListenAndServe(":808", CSRF(mux))
}

If attacker controls HTML/JS context (XSS or other means), they can do

<form action="https://victim.example.com/transfer"; method="POST" id="attackForm">
  <input name="amount" value="100" />
</form>
<script>
    document.getElementById('attackForm').submit();
</script>

No CSRF token is needed, and browser will send cookies because it's the same top-level domain.

Who is Affected

- Apps using gorilla/csrf < v1.7.2

Apps serving authenticated sessions (cookies) on shared subdomains or TLD

- Apps not validating Origin/Referer manually

If you host multiple subdomains for a brand, and any are vulnerable to XSS, ALL are at risk due to shared cookies and CSRF bypass.

# Fix

Upgrade gorilla/csrf to v1.7.2 or newer.
CVE Fix commit: github.com/gorilla/csrf@9ace52

Secure Version Example

import "github.com/gorilla/csrf"

func main() {
    CSRF := csrf.Protect(
        []byte("very-secret-key"),
        csrf.TrustedOrigins([]string{"https://www.example.com";}), // explicit whitelist!
    )
    // ...rest as before...
}

Defense-in-Depth: Additional Best Practices

- Set SameSite attribute for cookies (prefer Strict or Lax).
- Use Origin checks in your own middleware for sensitive POST/PUT/PATCH/DELETE.

Scan for XSS everywhere—XSS on any sibling subdomain can now mean access to all.

- Use subdomain isolation when possible (bank.example.com should not share cookies with blog.example.com).

More Info & References

- gorilla/csrf Advisory
- Original Fix PR
- Go net/http.Request: URL is never populated
- CSRF in Depth (OWASP)
- SameSite Cookies Explained

Summary Table

| Vulnerable Versions | Fixed In | Risk | Exploit Prerequisite |
|------------------------|------------|------------|----------------------------|
| < 1.7.2 | 1.7.2 | CRITICAL | XSS or subdomain access |

Conclusion

If you use gorilla/csrf, stop and check your version now. Upgrade to 1.7.2 or higher and make sure you are whitelisting trusted origins. Do not rely solely on library defaults—double-check your own Origin and Referer validation for peace of mind.

*This post is an original, plain-English breakdown of CVE-2025-24358 intended for Go web developers and security engineers. Direct linking and improvement appreciated!*

Timeline

Published on: 04/15/2025 19:16:07 UTC
Last modified on: 05/01/2025 11:15:53 UTC