OWASP Coraza WAF has parser confusion which leads to wrong URI in `REQUEST_FILENAME`GHSA-q9f5-625g-xm39
MEDIUMFix: corazawaf/coraza@4722c9aGHSA-q9f5-625g-xm39 is a medium-severity (CVSS 5.4) CWE-706 vulnerability in github.com/jptosso/coraza-waf. A fix is available for github.com/jptosso/coraza-waf — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-q9f5-625g-xm39.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
github.com/jptosso/coraza-waf🐹github.com/corazawaf/coraza/v3Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
URLs starting with // are not parsed properly, and the request REQUEST_FILENAME variable contains a wrong value, leading to potential rules bypass.
Details
If a request is made on an URI starting with //, coraza will set a wrong value in REQUEST_FILENAME.
For example, if the URI //bar/uploads/foo.php?a=b is passed to coraza: , REQUEST_FILENAME will be set to /uploads/foo.php.
The root cause is the usage of url.Parse to parse the URI in ProcessURI.
url.Parse can parse both absolute URLs (starting with a scheme) or relative ones (just the path).
//bar/uploads/foo.php is a valid absolute URI (the scheme is empty), url.Parse will consider bar as the host and the path will be set to /uploads/foo.php.
PoC
package main
import (
"fmt"
"net/url"
"os"
"github.com/corazawaf/coraza/v3"
)
const testRule = `
SecDebugLogLevel 9
SecDebugLog /dev/stdout
SecRule REQUEST_FILENAME "@rx /bar/uploads/.*\.(h?ph(p|tm?l?|ar)|module|shtml)" "id:1,phase:1,deny"
`
func main() {
var testURL = "//bar/uploads/foo.php"
if os.Getenv("TEST_URL") != "" {
testURL = os.Getenv("TEST_URL")
}
fmt.Printf("Testing URL: %s\n", testURL)
config := coraza.NewWAFConfig().WithDirectives(testRule)
waf, err := coraza.NewWAF(config)
if err != nil {
panic(err)
}
tx := waf.NewTransaction()
tx.ProcessURI(testURL, "GET", "HTTP/1.1")
in := tx.ProcessRequestHeaders()
if in != nil {
fmt.Printf("%+v\n", in)
}
}
Impact
Potential bypass of rules using REQUEST_FILENAME.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/jptosso/coraza-waf | all versions | 3.3.3go get github.com/jptosso/coraza-waf@v3.3.3 |
| 🐹Go | github.com/corazawaf/coraza/v3 | all versions | 3.3.3go get github.com/corazawaf/coraza/v3@v3.3.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/jptosso/coraza-waf, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/jptosso/coraza-waf to 3.3.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q9f5-625g-xm39 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-q9f5-625g-xm39 in your dependencies?
Find it across Go, including transitive dependencies.