Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/gofiber/fiber/v2 >= 2.52.1, < 2.52.3
Fixed in
2.52.3· Vendor fix available
Issue
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…
Recommended action: Upgrade to 2.52.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The BalancerForward proxy helper in GoFiber uses Header.Add() instead of Header.Set() when injecting the X-Real-IP header. This appends the real client IP as a second header value rather than replacing any attacker-supplied value. Upstream servers that read the first X-Real-IP header (nginx, Express, most HTTP servers) use the attacker's spoofed IP for logging, rate limiting, and access control. Vulnerable Code File: middleware/proxy/proxy.go, lines 270-285 Data Flow 1. Attacker sends request with X-Real-IP: 10.0.0.1 (spoofed internal IP) 2. BalancerForward handler executes at line 282 3. c.Request().Header.Add("X-Real-IP", c.IP()) APPENDS the real IP as a second header 4. Upstream server receives: X-Real-IP: 10.0.0.1 AND X-Real-IP: <real-attacker-ip 5. Most HTTP servers (nginx, Node.js, Apache) read the FIRST value 6. Upstream uses 10.0.0.1 for all IP-dependent logic Impact - Rate limit bypass: IP-based rate limiting at the upstream uses the spoofed IP, allowing unlimited…
Recommended action: Upgrade to 2.52.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Description A Cross-Site Scripting (CWE-79) vulnerability in Go Fiber allows a remote attacker to inject arbitrary HTML/JavaScript by supplying Accept: text/html on any request whose handler passes attacker-influenced data to the AutoFormat() feature. This affects github.com/gofiber/fiber/v3 (DefaultRes.AutoFormat) through version 3.1.0 and github.com/gofiber/fiber/v2 (Ctx.Format) through version 2.52.12. The developer opts into content negotiation by calling AutoFormat(), but does not opt into raw HTML emission for a particular request; Fiber chooses that branch from attacker-controlled Accept. Five of the six branches of the same method already escape. JSON, XML, MsgPack, and CBOR all route through encoders that neutralize markup; the txt branch emits text/plain and cannot execute. The html branch is the sole outlier in a method whose name (AutoFormat) and symmetrical structure actively telegraph "safe, format-agnostic reply." Details The issue resides in res.go within…
Recommended action: Upgrade to 2.52.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A denial of service vulnerability exists in Fiber v2 and v3 that allows remote attackers to crash the application by sending requests to routes with more than 30 parameters. The vulnerability results from missing validation during route registration combined with an unbounded array write during request matching. Affected Versions - Fiber v3.0.0-rc.3 and earlier v3 releases - Fiber v2.52.10 and potentially all v2 releases (confirmed exploitable) - Both versions share the same vulnerable routing implementation Vulnerability Details Root Cause Both Fiber v2 and v3 define a fixed-size parameter array in ctx.go: The router.go register() function accepts routes without validating parameter count. When a request matches a route exceeding 30 parameters, the code in path.go performs an unbounded write: - v3: path.go:514 - v2: path.go:516 When paramsIterator = 30, this triggers: Attack Scenario 1. Application registers route with 30 parameters (e.g., via code or dynamic routing): 2. Attacker…
Recommended action: Upgrade to 2.52.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fiber v2 contains an internal vendored copy of gofiber/utils, and its functions UUIDv4() and UUID() inherit the same critical weakness described in the upstream advisory. On Go versions prior to 1.24, the underlying crypto/rand implementation can return an error if secure randomness cannot be obtained. In such cases, these Fiber v2 UUID functions silently fall back to generating predictable values — the all-zero UUID 00000000-0000-0000-0000-000000000000. On Go 1.24+, the language guarantees that crypto/rand no longer returns an error (it will block or panic instead), so this vulnerability primarily affects Fiber v2 users running Go 1.23 or earlier, which Fiber v2 officially supports. Because no error is returned by the Fiber v2 UUID functions, application code may unknowingly rely on predictable, repeated, or low-entropy identifiers in security-critical pathways. This is especially impactful because many Fiber v2 middleware components (session middleware, CSRF, rate limiting,…
Recommended action: Upgrade to 2.52.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using Fiber's Ctx.BodyParser to parse form data containing a large numeric key that represents a slice index (e.g., test.18446744073704), the application crashes due to an out-of-bounds slice allocation in the underlying schema decoder. The root cause is that the decoder attempts to allocate a slice of length idx + 1 without validating whether the index is within a safe or reasonable range. If idx is excessively large, this leads to an integer overflow or memory exhaustion, causing a panic or crash. Steps to Reproduce Create a POST request handler that accepts x-www-form-urlencoded data Run the server and send a POST request with a large numeric key in form data, such as: Relevant Code Snippet Within the decoder's decode method: The idx is not validated before use, leading to unsafe slice allocation for extremely large values. --- Impact - Application panic or crash on malicious or malformed input. - Potential denial of service (DoS) via memory exhaustion or server…
Recommended action: Upgrade to 2.52.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gofiber/fiber/v2 >= 2.52.6, < 2.52.7
Fixed in
2.52.7· Vendor fix available
Issue
When using the fiber.Ctx.BodyParser to parse into a struct with range values, a panic occurs when trying to parse a negative range index Details fiber.Ctx.BodyParser can map flat data to nested slices using key[idx]value syntax, however when idx is negative, it causes a panic instead of returning an error stating it cannot process the data. Since this data is user-provided, this could lead to denial of service for anyone relying on this fiber.Ctx.BodyParser functionality Reproducing Take a simple GoFiberV2 server which returns a JSON encoded version of the FormData Correct Behaviour Send a valid request such as: You recieve valid JSON Crashing behaviour Send an invalid request such as: The server panics and crashes Impact Anyone using fiber.Ctx.BodyParser can/will have their servers crashed when an invalid payload is sent
Recommended action: Upgrade to 2.52.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security vulnerability has been identified in the Fiber session middleware where a user can supply their own sessionid value, leading to the creation of a session with that key. Impact The identified vulnerability is a session middleware issue in GoFiber versions 2 and above. This vulnerability allows users to supply their own sessionid value, resulting in the creation of a session with that key. If a website relies on the mere presence of a session for security purposes, this can lead to significant security risks, including unauthorized access and session fixation attacks. All users utilizing GoFiber's session middleware in the affected versions are impacted. Patches The issue has been addressed in the latest patch. Users are strongly encouraged to upgrade to version 2.52.5 or higher to mitigate this vulnerability. Workarounds Users who are unable to upgrade immediately can apply the following workarounds to reduce the risk: 1. Validate Session IDs: Implement additional…
Recommended action: Upgrade to 2.52.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The CORS middleware allows for insecure configurations that could potentially expose the application to multiple CORS-related vulnerabilities. Specifically, it allows setting the Access-Control-Allow-Origin header to a wildcard ("") while also having the Access-Control-Allow-Credentials set to true, which goes against recommended security best practices. Impact The impact of this misconfiguration is high as it can lead to unauthorized access to sensitive user data and expose the system to various types of attacks listed in the PortSwigger article linked in the references. Proof of Concept The code in cors.go allows setting a wildcard in the AllowOrigins while having AllowCredentials set to true, which could lead to various vulnerabilities. Potential Solution Here is a potential solution to ensure the CORS configuration is secure: Workarounds For the meantime, users are advised to manually validate the CORS configurations in their implementation to ensure that they do not allow a…
Recommended action: Upgrade to 2.52.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to obtain tokens and forge malicious requests on behalf of a user. This can lead to unauthorized actions being taken on the user's behalf, potentially compromising the security and integrity of the application. Vulnerability Details The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified: 1. Lack of Token Association: The CSRF token was validated against tokens in storage but was not tied to the original requestor that generated it, allowing for token reuse. Remediation To remediate this vulnerability, it is recommended to take the following actions: 1. Update the Application: Upgrade the application to a fixed version with a patch for the vulnerability. 2. Implement Proper CSRF Protection: Review the updated documentation and ensure your application's CSRF protection mechanisms follow…
Recommended action: Upgrade to 2.50.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to inject arbitrary values and forge malicious requests on behalf of a user. This vulnerability can allow an attacker to inject arbitrary values without any authentication, or perform various malicious actions on behalf of an authenticated user, potentially compromising the security and integrity of the application. Vulnerability Details The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified: 1. Token Injection: For 'safe' methods, the token was extracted from the cookie and saved to storage without further validation or sanitization. 2. Lack of Token Association: The CSRF token was validated against tokens in storage but not associated with a session, nor by using a Double Submit Cookie Method, allowing for token reuse. Specific Go Packages Affected…
Recommended action: Upgrade to 2.50.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Olivier Poitrey Go CORS handler through 1.3.0 actively converts a wildcard CORS policy into reflecting an arbitrary Origin header value, which is incompatible with the CORS security design, and could lead to CORS misconfiguration security problems.
Recommended action: Upgrade to 2.43.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.