GHSA-v78c-4p63-2j6c

What it actually does

The vulnerable versions of the npm package moment-timezone transmit or retrieve sensitive project resources over cleartext HTTP rather than HTTPS. At a technical level, this creates an opportunity for a network-positioned attacker to observe or modify data in transit, including downloaded timezone data or related package resources, because transport confidentiality and integrity are not enforced. The issue is categorized as a cryptographic weakness: the primary problem is not broken application logic, but the use of an insecure transport channel for sensitive information.

Why it matters to the business

Applications or build pipelines that depend on affected versions of moment-timezone may be exposed to network interception or tampering risks, especially when dependencies are installed or resources are fetched over untrusted networks. The most likely business consequences are loss of confidence in dependency integrity, possible exposure of sensitive metadata, and supply-chain risk if cleartext traffic is modified in transit. This advisory is not listed in CISA KEV, has no known exploit maturity in the provided data, and was published over three years ago, so remediation should be treated as routine dependency hygiene unless the package is used in sensitive, regulated, or high-assurance environments.

How an attack unfolds

An attacker must be positioned where they can observe or interfere with network traffic between the system using moment-timezone and the remote resource being accessed over HTTP. The attacker monitors for cleartext requests associated with vulnerable package behavior, reads any exposed data, and may attempt to tamper with responses if the client accepts them without independent integrity validation. Successful exploitation depends on network placement, vulnerable package usage, and whether the affected code path is exercised in the application or build process.

How to fix it

Upgrade moment-timezone to version 0.5.35 or later. For npm-based projects, update package.json and the lockfile, then rebuild and redeploy affected applications. Where transitive dependencies bring in moment-timezone, update the parent dependency or use package manager override/resolution mechanisms to force a fixed version. As a defense-in-depth measure, require HTTPS for dependency and resource retrieval, block cleartext HTTP egress where feasible, use package-lock.json/yarn.lock/pnpm-lock.yaml integrity protections, and route dependency installation through a trusted internal package mirror that enforces TLS.

How to confirm the fix worked

Confirm that all deployed applications, build images, and dependency lockfiles resolve moment-timezone to 0.5.35 or later. Run package inventory commands such as `npm ls moment-timezone`, software composition analysis, or SBOM scanning across repositories and container images. Validate that dependency installation and application runtime traffic do not initiate cleartext HTTP requests associated with moment-timezone resources. In CI/CD, fail builds that resolve vulnerable versions or allow insecure dependency downloads.

Typical attack path

1. Identify an application, build system, or dependency tree using an affected version of moment-timezone before 0.5.35.
2. Gain a network position capable of observing or modifying traffic, such as a compromised local network, proxy path, Wi-Fi network, or upstream routing point.
3. Wait for the vulnerable package behavior to make cleartext HTTP requests for sensitive resources or data.
4. Capture sensitive information visible in the unencrypted request or response.
5. Optionally modify the cleartext response in transit if the consuming process does not enforce integrity checks.
6. Leverage exposed or tampered data for follow-on reconnaissance, application manipulation, or supply-chain compromise attempts.

How to detect it

To assess whether this was already exploited, review network, proxy, firewall, DNS, EDR, and CI/CD build logs for cleartext HTTP activity from systems that install or run affected versions of moment-timezone. Focus on build agents, developer workstations, containers, and application servers where npm install or dependency bootstrap activity occurred. Look for outbound HTTP requests involving moment-timezone, timezone data resources, npm package retrieval, or unusual non-TLS traffic during dependency installation. Because this issue is network-position dependent and does not create a distinctive host artifact by itself, absence of logs may make retrospective confirmation difficult. Investigate any cases where HTTP responses were served by unexpected hosts, proxies, captive portals, internal interception devices, or IPs inconsistent with normal package/resource sources.

• moment-timezone
• GET http://
• POST http://
• http://registry.npmjs.org/
• http://unpkg.com/moment-timezone
• http://momentjs.com
• latest.json
• packed/latest.json
• moment-timezone-with-data
• moment-timezone-with-data-10-year-range
• node_modules/moment-timezone

What your security team should do

• Inventory all repositories, container images, and build environments for moment-timezone versions earlier than 0.5.35.
• Upgrade direct dependencies to moment-timezone 0.5.35 or later and use npm overrides/resolutions for transitive dependency exposure where necessary.
• Regenerate and commit lockfiles after upgrade, then rebuild and redeploy affected artifacts.
• Add SCA or dependency scanning rules to prevent reintroduction of vulnerable versions.
• Monitor proxy, DNS, and network logs for cleartext HTTP requests related to moment-timezone or timezone data retrieval.
• Restrict outbound cleartext HTTP from build and production environments where operationally feasible.
• Use trusted package registries or internal mirrors that enforce TLS and package integrity verification.