{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-90651", "assignerOrgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca", "state": "PUBLISHED", "assignerShortName": "mitre", "dateReserved": "2026-09-12T23:55:40.704Z", "datePublished": "2026-09-12T23:55:41.065Z", "dateUpdated": "2026-09-12T23:55:41.065Z"}, "containers": {"cna": {"affected": [{"collectionURL": "https://hub.docker.com", "defaultStatus": "unaffected", "modules": ["registry mode; outbound TLS to Socket API and upstream package registries (OpenResty/Lua HTTP client)"], "packageName": "socketdev/socket-registry-firewall", "product": "Socket Firewall", "vendor": "Socket", "versions": [{"lessThan": "2.0.0", "status": "affected", "version": "0", "versionType": "semver"}]}], "descriptions": [{"lang": "en", "value": "Socket Firewall (socketdev/socket-registry-firewall) in registry mode before 2.0.0 does not verify upstream TLS certificates by default. When the api_ssl_verify and upstream_ssl_verify configuration keys are omitted from socket.yml, the generated configuration sets SOCKET_API_SSL_VERIFY='false' and UPSTREAM_SSL_VERIFY='false', and the OpenResty/Lua HTTP client used for outbound requests accepts any certificate, including self-signed and otherwise untrusted certificates, without validating the chain. An attacker positioned to intercept traffic between Socket Firewall and the Socket API or an upstream package registry can present a crafted certificate and modify responses in transit, including substituting malicious package content or altering the allow/block decisions the firewall enforces. Setting api_ssl_verify: true and upstream_ssl_verify: true enables verification; however, in versions before 1.1.334, the generated nginx configuration did not emit lua_ssl_trusted_certificate, and thus verification could not be used successfully without manually patching the generated configuration. Version 2.0.0 changes the default for both settings to true."}], "metrics": [{"cvssV3_1": {"attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 8.1, "baseSeverity": "HIGH", "confidentialityImpact": "LOW", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "CHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:L", "version": "3.1"}, "format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "problemTypes": [{"descriptions": [{"cweId": "CWE-295", "description": "CWE-295 Improper Certificate Validation", "lang": "en", "type": "CWE"}]}], "providerMetadata": {"orgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca", "shortName": "mitre", "dateUpdated": "2026-09-12T23:55:41.065Z"}, "references": [{"url": "https://github.com/SocketDev/socket-registry-firewall/releases/tag/v2.0.0"}, {"url": "https://docs.socket.dev/docs/registry-mode-configuration-reference"}], "solutions": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<span style=\"background-color: rgb(252, 252, 251)\">Upgrade to Socket Firewall 2.0.0 or later, where api_ssl_verify and upstream_ssl_verify default to true. Deployments that terminate TLS on an internal proxy or use a private CA must supply that CA via api_ssl_ca_cert / upstream_ssl_ca_cert, or explicitly disable verification for those connections.</span><br>"}], "value": "Upgrade to Socket Firewall 2.0.0 or later, where api_ssl_verify and upstream_ssl_verify default to true. Deployments that terminate TLS on an internal proxy or use a private CA must supply that CA via api_ssl_ca_cert / upstream_ssl_ca_cert, or explicitly disable verification for those connections."}], "workarounds": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<span style=\"background-color: rgb(252, 252, 251)\">On versions 1.1.334 through 1.1.x, explicitly set api_ssl_verify: true and upstream_ssl_verify: true in socket.yml. On versions before 1.1.334 this setting alone is not sufficient, because the generated nginx configuration omits lua_ssl_trusted_certificate; operators had to patch the generated configuration to inject lua_ssl_trusted_certificate and lua_ssl_verify_depth.</span><br>"}], "value": "On versions 1.1.334 through 1.1.x, explicitly set api_ssl_verify: true and upstream_ssl_verify: true in socket.yml. On versions before 1.1.334 this setting alone is not sufficient, because the generated nginx configuration omits lua_ssl_trusted_certificate; operators had to patch the generated configuration to inject lua_ssl_trusted_certificate and lua_ssl_verify_depth."}], "x_generator": {"engine": "CVE-Request-form 0.0.1"}}}}

{}

{"affected": [{"affectedData": [{"collectionURL": "https://hub.docker.com", "defaultStatus": "unaffected", "modules": ["registry mode; outbound TLS to Socket API and upstream package registries (OpenResty/Lua HTTP client)"], "packageName": "socketdev/socket-registry-firewall", "product": "Socket Firewall", "vendor": "Socket", "versions": [{"lessThan": "2.0.0", "status": "affected", "version": "0", "versionType": "semver"}]}], "source": "cve@mitre.org"}], "cveTags": [], "descriptions": [{"lang": "en", "value": "Socket Firewall (socketdev/socket-registry-firewall) in registry mode before 2.0.0 does not verify upstream TLS certificates by default. When the api_ssl_verify and upstream_ssl_verify configuration keys are omitted from socket.yml, the generated configuration sets SOCKET_API_SSL_VERIFY='false' and UPSTREAM_SSL_VERIFY='false', and the OpenResty/Lua HTTP client used for outbound requests accepts any certificate, including self-signed and otherwise untrusted certificates, without validating the chain. An attacker positioned to intercept traffic between Socket Firewall and the Socket API or an upstream package registry can present a crafted certificate and modify responses in transit, including substituting malicious package content or altering the allow/block decisions the firewall enforces. Setting api_ssl_verify: true and upstream_ssl_verify: true enables verification; however, in versions before 1.1.334, the generated nginx configuration did not emit lua_ssl_trusted_certificate, and thus verification could not be used successfully without manually patching the generated configuration. Version 2.0.0 changes the default for both settings to true."}], "id": "CVE-2026-90651", "lastModified": "2026-09-13T00:17:07.203", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 8.1, "baseSeverity": "HIGH", "confidentialityImpact": "LOW", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "CHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:L", "version": "3.1"}, "exploitabilityScore": 2.2, "impactScore": 5.3, "source": "cve@mitre.org", "type": "Secondary"}]}, "published": "2026-09-13T00:17:07.203", "references": [{"source": "cve@mitre.org", "url": "https://docs.socket.dev/docs/registry-mode-configuration-reference"}, {"source": "cve@mitre.org", "url": "https://github.com/SocketDev/socket-registry-firewall/releases/tag/v2.0.0"}], "sourceIdentifier": "cve@mitre.org", "vulnStatus": "Received", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-295"}], "source": "cve@mitre.org", "type": "Primary"}]}

{}

{}