CVE-2026-77354

{"id": "CVE-2026-77354", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-77354", "role": "CISA Coordinator", "options": [{"exploitation": "poc"}, {"automatable": "yes"}, {"technicalImpact": "partial"}], "version": "2.0.3", "timestamp": "2026-08-25T19:15:10.388384Z"}}], "cvssMetricV40": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 8.7, "Automatable": "NOT_DEFINED", "attackVector": "NETWORK", "baseSeverity": "HIGH", "valueDensity": "NOT_DEFINED", "vectorString": "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", "exploitMaturity": "NOT_DEFINED", "providerUrgency": "NOT_DEFINED", "userInteraction": "NONE", "attackComplexity": "LOW", "attackRequirements": "NONE", "privilegesRequired": "NONE", "subIntegrityImpact": "NONE", "vulnIntegrityImpact": "NONE", "integrityRequirement": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "HIGH", "availabilityRequirement": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "subConfidentialityImpact": "NONE", "vulnConfidentialityImpact": "NONE", "confidentialityRequirement": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "vulnerabilityResponseEffort": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED"}}]}, "affected": [{"source": "security-advisories@github.com", "affectedData": [{"vendor": "getkin", "product": "kin-openapi", "versions": [{"status": "affected", "version": ">= 0.124.0, < 0.142.0"}]}]}], "published": "2026-08-21T21:17:07.130", "references": [{"url": "https://github.com/getkin/kin-openapi/commit/1223a0f215d2cf9beb2d9eb9ea2649d001c21388", "source": "security-advisories@github.com"}, {"url": "https://github.com/getkin/kin-openapi/pull/923", "source": "security-advisories@github.com"}, {"url": "https://github.com/getkin/kin-openapi/releases/tag/v0.142.0", "source": "security-advisories@github.com"}, {"url": "https://github.com/getkin/kin-openapi/security/advisories/GHSA-xhj3-7xw9-vr34", "source": "security-advisories@github.com"}], "vulnStatus": "Deferred", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-400"}, {"lang": "en", "value": "CWE-789"}]}], "descriptions": [{"lang": "en", "value": "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."}, {"lang": "es", "value": "kin-openapi es un proyecto Go para manejar archivos OpenAPI. Desde la versi\u00f3n 0.124.0 hasta la 0.142.0, openapi3filter.sliceMapToSlice en openapi3filter/req_resp_decoder.go convierte \u00edndices dispersos controlados por el atacante de un par\u00e1metro de consulta deepObject en un slice denso, asignando entradas desde cero hasta el \u00edndice m\u00e1s grande proporcionado, despu\u00e9s de lo cual buildResObj crea otro slice de la misma longitud. Esta asignaci\u00f3n ocurre antes de la validaci\u00f3n del esquema, por lo que maxItems no la previene. Un cliente no autenticado puede enviar una peque\u00f1a consulta como param[items][50000000]=x a un endpoint cuyo esquema deepObject contiene un array, forzando una asignaci\u00f3n de memoria heap de varios gigabytes y causando una terminaci\u00f3n por OOM (Out Of Memory) o un bucle de reinicio. Otras codificaciones de cuerpo de solicitud y par\u00e1metros con estilo que no producen \u00edndices enteros entre corchetes no se ven afectados. Este problema se corrige en la versi\u00f3n 0.142.0."}], "lastModified": "2026-10-12T16:10:00.220", "sourceIdentifier": "security-advisories@github.com"}