EUVD-2026-76925
GHSA-jrp2-p3px-f5p5
Severity by source
AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:L
AV:N and AC:H reflect network MITM requirement; S:C because compromised firewall policy decisions corrupt downstream software supply chain beyond the firewall host itself; I:H for package substitution and policy bypass; C:L for passive traffic interception.
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
Lifecycle Timeline
5DescriptionCVE.org
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.
AnalysisAI
TLS certificate verification is disabled by default in Socket Firewall (socketdev/socket-registry-firewall) before version 2.0.0, enabling network-positioned attackers to conduct man-in-the-middle attacks against the firewall's outbound connections to both the Socket API and upstream package registries. When the api_ssl_verify and upstream_ssl_verify keys are omitted from socket.yml, the generated configuration explicitly sets both to false, causing the OpenResty/Lua HTTP client to accept any certificate - including self-signed and untrusted certificates - without chain validation. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires the attacker to occupy a man-in-the-middle network position between Socket Firewall and either the Socket API (api.socket.dev) or an upstream package registry such as the npm registry. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 8.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:L) is well-calibrated for this vulnerability. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Upgrade to Socket Firewall version 2.0.0, which changes the defaults for both api_ssl_verify and upstream_ssl_verify from false to true, enabling TLS certificate chain validation out of the box; the vendor confirms this is a breaking change for environments that use internal or private registries with self-signed or privately issued certificates, which will require importing the relevant CA bundle or explicitly disabling verification only for those connections. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, audit all Socket Firewall deployments to identify instances running versions before 2.0.0 and check socket.yml configuration files for presence of api_ssl_verify and upstream_ssl_verify keys. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
The ngx_http_parse_chunked function in http/ngx_http_parse.c in nginx 1.3.9 through 1.4.0 allows remote attackers to cau
A critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
nginx 0.8.41 through 1.4.3 and 1.5.x before 1.5.7 allows remote attackers to bypass intended restrictions via an unescap
An issue was discovered on GL.iNet devices before version 4.5.0. Rated critical severity (CVSS 9.8), this vulnerability
Nginx versions since 0.5.6 up to and including 1.13.2 are vulnerable to integer overflow vulnerability in nginx range fi
The resolver in nginx before 1.8.1 and 1.9.x before 1.9.10 allows remote attackers to cause a denial of service (invalid
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. Rated critical severity (CVSS 9.8
The STARTTLS implementation in mail/ngx_mail_smtp_handler.c in the SMTP proxy in nginx 1.5.x and 1.6.x before 1.6.1 and
Same weakness CWE-295 – Improper Certificate Validation
View allShare
External POC / Exploit Code
Leaving vuln.today