Fiber: CORS wildcard origins matched without a dot boundary, allowing credentialed cross-origin reads
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 2.52.3
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Fiber, a Go web framework, is affected when its CORS middleware is configured with a wildcard subdomain origin and credentials enabled. An attacker can use a domain that merely ends with the configured base domain to read authenticated responses from the application, exposing users' data to the attacker's page.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
Fiber is an Express inspired web framework written in Go. From 2.52.1 until 2.52.3, the CORS middleware's validateDomain wildcard matcher in middleware/cors/utils.go strips the scheme and checks only a host suffix without requiring a dot boundary. An application configured with a wildcard-subdomain AllowOrigins value and AllowCredentials enabled can reflect an unrelated attacker-controlled origin whose host merely ends with the configured base domain. A user who visits that origin can expose authenticated cross-origin responses to the attacker's page; empty-label origins and later comma-space parsing hardening are outside this advisory. This issue is fixed in version 2.52.3.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- gofiber fiber
From 2.52.1 · fixed in 2.52.3