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:

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

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):

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).