CVE-2026-77776

{"id": "CVE-2026-77776", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-77776", "role": "CISA Coordinator", "options": [{"exploitation": "none"}, {"automatable": "yes"}, {"technicalImpact": "total"}], "version": "2.0.3", "timestamp": "2026-08-21T21:18:54.351966Z"}}], "cvssMetricV31": [{"type": "Secondary", "source": "disclosure@vulncheck.com", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 9.1, "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}, "impactScore": 5.2, "exploitabilityScore": 3.9}], "cvssMetricV40": [{"type": "Secondary", "source": "disclosure@vulncheck.com", "cvssData": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 9.3, "Automatable": "NOT_DEFINED", "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/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": "HIGH", "integrityRequirement": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "NONE", "availabilityRequirement": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "subConfidentialityImpact": "NONE", "vulnConfidentialityImpact": "HIGH", "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": "disclosure@vulncheck.com", "affectedData": [{"repo": "https://github.com/headroomlabs-ai/headroom", "vendor": "Headroom Labs", "product": "Headroom", "versions": [{"status": "affected", "version": "0", "lessThan": "0.36.1", "versionType": "semver"}, {"status": "unaffected", "version": "0.36.1", "versionType": "semver"}], "packageURL": "pkg:pypi/headroom-ai", "packageName": "headroom-ai", "programFiles": ["headroom/proxy/handlers/openai.py", "headroom/proxy/memory_handler.py", "headroom/memory/easy.py"], "collectionURL": "https://pypi.org", "defaultStatus": "unaffected"}]}], "published": "2026-08-21T12:16:36.967", "references": [{"url": "https://github.com/headroomlabs-ai/headroom", "source": "disclosure@vulncheck.com"}, {"url": "https://github.com/headroomlabs-ai/headroom/blob/v0.29.0/headroom/proxy/handlers/openai.py", "source": "disclosure@vulncheck.com"}, {"url": "https://github.com/headroomlabs-ai/headroom/blob/v0.36.1/headroom/proxy/identity.py", "source": "disclosure@vulncheck.com"}, {"url": "https://github.com/headroomlabs-ai/headroom/pull/2207", "source": "disclosure@vulncheck.com"}, {"url": "https://www.vulncheck.com/advisories/headroom-proxy-treats-the-client-supplied-x-headroom-user-id-header-as-an-authenticated-identity", "source": "disclosure@vulncheck.com"}], "vulnStatus": "Deferred", "weaknesses": [{"type": "Secondary", "source": "disclosure@vulncheck.com", "description": [{"lang": "en", "value": "CWE-639"}]}], "descriptions": [{"lang": "en", "value": "Headroom's LLM proxy derives the memory owner from the x-headroom-user-id request header. The header is read directly at several points in headroom/proxy/handlers/openai.py, including the chat completion and websocket paths, and nothing binds the value to the caller. A client can therefore name another user's identifier and read or write that user's stored LLM memory. The fix introduces a single resolve_memory_identity seam in headroom/proxy/identity.py that honors the header only for loopback or allowlisted callers and otherwise binds the identity to the proxy-token fingerprint or the operating system user. The pip console script binds 127.0.0.1 by default, but the reference docker-compose.yml ships --host 0.0.0.0 with published ports and no required HEADROOM_PROXY_TOKEN, which the server itself warns about at startup, so a deployment following the shipped compose exposes the affected data-plane routes to the network without authentication."}, {"lang": "es", "value": "El proxy LLM de Headroom deriva el propietario de la memoria del encabezado de solicitud x-headroom-user-id. El encabezado se lee directamente en varios puntos en headroom/proxy/handlers/openai.py, incluyendo las rutas de completado de chat y websocket, y nada vincula el valor al llamador. Un cliente puede, por lo tanto, nombrar el identificador de otro usuario y leer o escribir la memoria LLM almacenada de ese usuario. La soluci\u00f3n introduce una \u00fanica costura resolve_memory_identity en headroom/proxy/identity.py que respeta el encabezado solo para llamadores de loopback o en lista blanca y de lo contrario vincula la identidad a la huella digital del token de proxy o al usuario del sistema operativo. El script de consola pip enlaza 127.0.0.1 por defecto, pero el docker-compose.yml de referencia se env\u00eda con --host 0.0.0.0 con puertos publicados y sin HEADROOM_PROXY_TOKEN requerido, sobre lo cual el propio servidor advierte al inicio, por lo que un despliegue siguiendo el compose enviado expone las rutas del plano de datos afectadas a la red sin autenticaci\u00f3n."}], "lastModified": "2026-10-15T19:10:00.173", "sourceIdentifier": "disclosure@vulncheck.com"}