testkube-enterprise-api-1.18.1_linux_arm64

digest	sha256:bc201ad99f0be9fa372cf5f5a5069adef607f39c203420a70acce9b7082c16d0
vulnerabilities
platform	linux/arm64
size	56 MB
packages	290

github.com/gofiber/fiber/v2 2.52.6 (golang) pkg:golang/github.com/gofiber/fiber@2.52.6#v2 Memory Allocation with Excessive Size Value Affected range <=2.52.8 Fixed version 2.52.9 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.055% EPSS Percentile 17th percentile 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. Improper Validation of Array Index Affected range >=2.52.6 <2.52.7 Fixed version 2.52.7 CVSS Score 7.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P EPSS Score 0.081% EPSS Percentile 24th percentile Description Summary 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 package main import ( "encoding/json" "fmt" "net/http" "github.com/gofiber/fiber/v2" ) type RequestBody struct { NestedContent []*struct { Value string `form:"value"` } `form:"nested-content"` } 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) } c.Set("Content-Type", "application/json") s, _ := json.Marshal(formData) return c.SendString(string(s)) }) fmt.Println(app.Listen(":3000")) } Correct Behaviour Send a valid request such as: curl --location 'localhost:3000' \ --form 'nested-content[0].value="Foo"' \ --form 'nested-content[1].value="Bar"' You recieve valid JSON {"NestedContent":[{"Value":"Foo"},{"Value":"Bar"}]} Crashing behaviour Send an invalid request such as: curl --location 'localhost:3000' \ --form 'nested-content[-1].value="Foo"' The server panics and crashes panic: reflect: slice index out of range goroutine 8 [running]: reflect.Value.Index({0x738000?, 0xc000010858?, 0x0?}, 0x738000?) /usr/lib/go-1.24/src/reflect/value.go:1418 +0x167 github.com/gofiber/fiber/v2/internal/schema.(*Decoder).decode(0xc00002c570, {0x75d420?, 0xc000010858?, 0x7ff424822108?}, {0xc00001c498, 0x17}, {0xc00014e2d0, 0x2, 0x2}, {0xc00002c710, ...}) [...] Impact Anyone using fiber.Ctx.BodyParser can/will have their servers crashed when an invalid payload is sent

github.com/golang-jwt/jwt/v5 5.2.1 (golang) pkg:golang/github.com/golang-jwt/jwt@5.2.1#v5 Asymmetric Resource Consumption (Amplification) Affected range >=5.0.0-rc.1 <5.2.2 Fixed version 5.2.2 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.029% EPSS Percentile 6th percentile Description Summary Function parse.ParseUnverified currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods. As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification) Details See parse.ParseUnverified Impact Excessive memory allocation

gopkg.in/square/go-jose.v2 2.6.0 (golang) pkg:golang/gopkg.in/square/go-jose.v2@2.6.0 Improper Handling of Highly Compressed Data (Data Amplification) Affected range <=2.6.0 Fixed version Not Fixed CVSS Score 4.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L EPSS Score 0.247% EPSS Percentile 48th percentile Description Impact An attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting. Patches The problem is fixed in the following packages and versions: github.com/go-jose/go-jose/v4 version 4.0.1 github.com/go-jose/go-jose/v3 version 3.0.3 gopkg.in/go-jose/go-jose.v2 version 2.6.3 The problem will not be fixed in the following package because the package is archived: gopkg.in/square/go-jose.v2

github.com/docker/docker 28.2.2+incompatible (golang) pkg:golang/github.com/docker/docker@28.2.2%2Bincompatible Missing Initialization of Resource Affected range >=28.2.0 <28.3.3 Fixed version 28.3.3 CVSS Score 5.1 CVSS Vector CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N EPSS Score 0.008% EPSS Percentile 0th percentile Description Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as moby/moby is commonly referred to as Docker, or Docker Engine. Firewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks. Impact The iptables rules created by Docker are removed when firewalld is reloaded using, for example "firewall-cmd --reload", "killall -HUP firewalld", or "systemctl reload firewalld". When that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that prevent packets arriving on a host interface from reaching container addresses are not re-created. Once these rules have been removed, a remote host configured with a route to a Docker bridge network can access published ports, even when those ports were only published to a loopback address. Unpublished ports remain inaccessible. For example, following a firewalld reload on a Docker host with address 192.168.0.10 and a bridge network with subnet 172.17.0.0/16, running the following command on another host in the local network will give it access to published ports on container addresses in that network: ip route add 172.17.0.0/16 via 192.168.0.10. Containers running in networks created with --internal or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload. Where Docker Engine is not running in the host's network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop. Patches Moby releases older than 28.2.0 are not affected. A fix is available in moby release 28.3.3. Workarounds After reloading firewalld, either: Restart the docker daemon, Re-create bridge networks, or Use rootless mode. References https://firewalld.org/ https://firewalld.org/documentation/howto/reload-firewalld.html

github.com/cloudflare/circl 1.5.0 (golang) pkg:golang/github.com/cloudflare/circl@1.5.0 Improper Input Validation Affected range <1.6.1 Fixed version 1.6.1 CVSS Score 3.7 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N EPSS Score 0.022% EPSS Percentile 4th percentile Description Impact The CIRCL implementation of FourQ fails to validate user-supplied low-order points during Diffie-Hellman key exchange, potentially allowing attackers to force the identity point and compromise session security. Moreover, there is an incorrect point validation in ScalarMult can lead to incorrect results in the isEqual function and if a point is on the curve. Patches Version 1.6.1 (https://github.com/cloudflare/circl/tree/v1.6.1) mitigates the identified issues. We acknowledge Alon Livne (Botanica Software Labs) for the reported findings. OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <1.6.1 Fixed version 1.6.1 Description The CIRCL implementation of FourQ fails to validate user-supplied low-order points during Diffie-Hellman key exchange, potentially allowing attackers to force the identity point and compromise session security. Moreover, there is an incorrect point validation in ScalarMult can lead to incorrect results in the isEqual function and if a point is on the curve.