CVE-2026-119285: Fiber: CORS wildcard origins matched without a dot boundary, allowing credentialed cross-origin reads
Summary
In v2.52.1 and v2.52.2 the CORS middleware matched a wildcard origin such as https://.example.com by suffix only, without a dot boundary and without comparing the scheme. Any origin whose host ends with the base domain, for example https://evil-example.com or http://notexample.com, was reflected in Access-Control-Allow-Origin, together with Access-Control-Allow-Credentials: true when AllowCredentials is enabled.
v2.52.3 replaced the matcher (#2915) and is not affected. The report was filed against v2.52.15, where the dot boundary holds; see "Other versions" below.
Details
v2.52.1 introduced validateDomain in middleware/cors/utils.go (f0cd3b44, part of the fix for GHSA-fmg4-x8pw-hjhg). It strips scheme and port from both sides and then checks only the suffix, with trimmedPattern = "example.com", so the character before the suffix is never checked:
go if strings.HasPrefix(normalizedPattern, ".") { trimmedPattern := normalizedPattern[2:] if strings.HasSuffix(normalizedDomain, trimmedPattern) { if normalizedDomain != trimmedPattern { if strings.TrimSuffix(normalizedDomain, trimmedPattern) != "" { return true } } } }
v2.52.3 (1aac6f61, #2915) replaced it with a scheme-aware prefix/suffix split that keeps the leading dot in the suffix (.example.com).
Proof of concept
go app := fiber.New() app.Use(cors.New(cors.Config{ AllowOrigins: "https://.example.com", AllowCredentials: true, })) app.Get("/", func(c fiber.Ctx) error { return c.SendString("secret") })
Request with Origin: https://evil-example.com, as a GET and as a preflight (OPTIONS with Access-Control-Request-Method: GET):
| Version | https://evil-example.com | http://evil-example.com | |---|---|---| | v2.52.0 | not allowed | not allowed | | v2.52.1, v2.52.2 | reflected, Access-Control-Allow-Credentials: true | reflected, Access-Control-Allow-Credentials: true | | v2.52.3 to v2.52.16 | not allowed | not allowed |
Impact
An app that configures a wildcard-subdomain AllowOrigins with AllowCredentials: true lets any page on a domain that ends with the base domain (for example notexample.com for .example.com) read authenticated responses cross-origin. Fixed in v2.52.3; upgrade to the latest v2 release.
Other versions
All v2 releases before v2.52.16 also accepted origins with empty labels (https://.example.com, https://a..example.com), and v2.52.3 to v2.52.15 mis-parsed a wildcard entry after a comma and a space ("https://a.com, https://.example.com"). No registrable domain produces such an origin, so these are hardening rather than part of this advisory. They are fixed in v2.52.16 (#4792).
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/gofiber/fiber/v2to a version that resolves this vulnerability.Fixed in 2.52.3 - Upgrade
Upgrade
Fiberto a version that resolves this vulnerability.Fixed in v2.52.16
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using Fiber v2.52.1 or v2.52.2 are affected when their CORS configuration includes a wildcard origin such as https://*.example.com. The cross-origin credentialed-read impact additionally requires AllowCredentials to be enabled.
What does exploitation require?
An attacker needs to induce a user to interact with an attacker-controlled origin whose hostname merely ends in the configured base domain, such as https://evil-example.com. The vulnerable middleware can reflect that origin even when the scheme differs from the configured wildcard pattern.
How can I determine whether a service needs remediation?
Check whether the service uses Fiber v2.52.1 or v2.52.2 and review its CORS allowed-origin patterns for wildcard base domains. Confirm whether AllowCredentials is enabled, since that causes Access-Control-Allow-Credentials: true to be returned with the incorrectly reflected origin.
What should be done if an upgrade cannot happen immediately?
Remove wildcard allowed-origin patterns or disable AllowCredentials until the middleware can be updated. Fiber v2.52.3 replaced the affected matcher and is not affected.