GHSA-qx2q-88mx-vhg7
Fiber Crashes in BodyParser Due to Unvalidated Large Slice Index in Decoder
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/gofiber/fiber/v2Real-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
Description
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
package main
import (
"fmt"
"net/http"
"github.com/gofiber/fiber/v2"
)
type RequestBody struct {
NestedContent []*struct{} `form:"test"`
}
func main() {
app := fiber.New()
app.Post("/", func(c *fiber.Ctx) error {
formData := RequestBody{}
if err := c.BodyParser(&formData); err != nil {
fmt.Println(err)
return c.SendStatus(http.StatusUnprocessableEntity)
}
return nil
})
fmt.Println(app.Listen(":3000"))
}
Run the server and send a POST request with a large numeric key in form data, such as:
curl -v -X POST localhost:3000 --data-raw 'test.18446744073704' \
-H 'Content-Type: application/x-www-form-urlencoded'
Relevant Code Snippet
Within the decoder's decode method:
idx := parts[0].index
if v.IsNil() || v.Len() < idx+1 {
value := reflect.MakeSlice(t, idx+1, idx+1) // <-- Panic/crash occurs here when idx is huge
if v.Len() < idx+1 {
reflect.Copy(value, v)
}
v.Set(value)
}
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 crash.
- Lack of defensive checks in the parsing code causes instability.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/gofiber/fiber/v2 | all versions | 2.52.9 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gofiber/fiber/v2. 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/gofiber/fiber/v2 to 2.52.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qx2q-88mx-vhg7 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-qx2q-88mx-vhg7 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-qx2q-88mx-vhg7. 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-qx2q-88mx-vhg7 in your dependencies?
O3 detects GHSA-qx2q-88mx-vhg7 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.