GHSA-mrvp-qgq4-c66g: 
JavaScript Schwachstellenanalyse und -minderung

Summary

The custom --osv-url private-address protection has a DNS time-of-check/time-of-use gap. validateOsvUrl() resolves and checks the hostname at startup, but the OSV transport later connects using that hostname and performs its own resolution. A changing DNS answer can therefore cause a connection to a private/reserved address even though validation accepted only public addresses and --allow-private-osv-url was not supplied.

Affected version / commit

• Package: npm cve-lite-cli.
• Confirmed by source review in the latest release, v1.40.0, and current main at 509e475957304c1728dbe7d605496c89d5c45ea7.
• Earlier versions have not been exhaustively assessed. No patched version is identified yet.
• The maintainer confirmed the lookup gap privately before requesting this report.

Relevant code

These links are pinned to the reviewed commit, and correct the earlier request-code line reference:

• Startup URL validation: performs dns.lookup(..., { all: true }) and checks all returned addresses.
• OSV batch request: constructs /v1/querybatch from the original base URL and uses fetch.
• OSV detail request: also requests the original hostname. The validated addresses are not bound to either connection. Redirects are already refused via redirect: "error"; this report concerns DNS rebinding, not redirect following.

Reproduction outline

This is a source-confirmed issue with a controlled reproduction plan; I have not run an end-to-end exploit against internal services or cloud metadata.

1. Use an isolated test project with at least one dependency, and a controlled hostname for the custom OSV endpoint.
2. Arrange for the startup resolver lookup to return only a public address.
3. Arrange for the later connection-time lookup for that same hostname to return a controlled private/loopback destination instead.
4. Invoke cve-lite <test-project> --osv-url https://<controlled-host> --no-cache without --allow-private-osv-url.
5. Observe that startup validation accepts the public answer while the network connection attempts the private destination. For a complete HTTP-request demonstration, use an isolated HTTPS server with a certificate valid for the original hostname and trusted by the test process. A deterministic regression test should control the resolver answers and assert the actual connection target, rather than merely mocking fetch. It should cover both batch and detail requests, later/retried connections, and the custom-CA transport.

Preconditions and impact limits

An attacker must control or compromise DNS for a custom endpoint that the user/CI has selected, or influence that endpoint setting. The scanner must have network reachability to the private destination. This is not triggered by the normal official OSV endpoint or by arbitrary lockfile contents alone. The bypass permits private/reserved connection attempts despite the address policy. Successfully sending application data or reading a response still depends on TLS trust and hostname verification, the destination protocol/service, and the fixed OSV request paths and methods. In particular, DNS rebinding alone does not establish access to ordinary HTTP-only cloud metadata services, bypass TLS certificate checks, or prove credential exfiltration. Final severity should be assessed against the project's threat model.

Suggested mitigation

Bind address validation to the connection: either pin a validated address for each connection or use a transport lookup/dispatcher that validates the resolved address and returns that exact address to the connector. A second standalone validation lookup immediately before fetch still leaves a race. Preserve the original hostname for TLS SNI/certificate verification and the HTTP Host header. Apply the protection to the default and custom-CA request paths and keep redirect refusal. Preserve the explicit --allow-private-osv-url opt-in for internal mirrors.

Disclosure

Reported privately under SECURITY.md. Please keep the report and fix private until a patched version is available. Reporter: @vianmangal. I would also like to contribute the fix in the advisory's temporary private fork.

Patches

Fixed in 1.41.0. Connections to a custom --osv-url now resolve the hostname at connection time, refuse the connection if any returned address is private or reserved (unless --allow-private-osv-url is set), and connect only to the addresses that were checked. Official OSV hosts are unchanged.

Workarounds

Use the default OSV endpoint, or point --osv-url only at a host whose DNS you control, until you can upgrade.