CVE-2026-44902

What it actually does

This is an unauthenticated network denial-of-service flaw in the OpenTelemetry JavaScript Prometheus exporter before version 0.217.0. The exporter’s HTTP metrics listener, commonly exposed on 0.0.0.0:9464, does not safely handle malformed request URIs during URL parsing. A specially malformed HTTP request can trigger an uncaught TypeError in the Node.js process. Because the exception is not handled, the process terminates. If the Prometheus exporter runs inside the same Node.js process as the application, exploitation can crash the whole application, not only the metrics endpoint.

Why it matters to the business

An attacker who can reach the metrics endpoint can crash affected Node.js services with a single request, causing outages, failed health checks, dropped traffic, or repeated restart loops. The CVSS availability impact is high, but current public exploitation signals are limited: it is not in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a low EPSS score of 0.00455. Even so, the issue is operationally important because metrics endpoints are often unintentionally exposed and the attack requires no authentication or user interaction.

How an attack unfolds

An attacker first identifies a Node.js service exposing the OpenTelemetry JS Prometheus exporter, often by scanning for the default Prometheus exporter listener on TCP port 9464 or a metrics endpoint. If the vulnerable exporter version is in use, the attacker sends an HTTP request containing an invalid URI that reaches the exporter’s request handling path. The exporter attempts to parse the malformed URI without adequate error handling. URL parsing throws a TypeError, the exception remains uncaught, and Node.js terminates the process. If a supervisor, container orchestrator, or process manager restarts the service, the attacker can repeat the same request to keep the service unstable or unavailable.

How to fix it

Upgrade the OpenTelemetry JavaScript Prometheus exporter to version 0.217.0 or later. In Node.js package terms, review direct and transitive usage of the OpenTelemetry Prometheus exporter package, commonly @opentelemetry/exporter-prometheus, and ensure lockfiles resolve to a fixed version. Rebuild and redeploy affected services after dependency updates. As compensating controls, do not expose the metrics listener directly to the internet; bind it to localhost or a private interface where possible; restrict access with firewall rules, security groups, Kubernetes NetworkPolicies, service mesh policy, or reverse proxy allowlists; and permit only trusted Prometheus scrapers to connect. Process supervisors and automatic restarts can reduce downtime but do not fix the vulnerability because the same request can crash the process again.

How to confirm the fix worked

Confirm the deployed dependency version is 0.217.0 or later using package manager and lockfile checks such as npm ls, yarn why, pnpm list, package-lock.json, yarn.lock, or pnpm-lock.yaml review. Validate that running containers or build artifacts contain the fixed dependency rather than only updated source manifests. Confirm the metrics endpoint is not internet-exposed and is reachable only from intended monitoring systems. In a controlled non-production environment, send malformed HTTP requests to the metrics listener and verify the process remains running, logs a handled error or returns a safe HTTP error, and does not restart. Review orchestration telemetry to ensure restart counts do not increase during validation.

Typical attack path

1. Scan for exposed OpenTelemetry Prometheus exporter endpoints, especially TCP port 9464 or publicly reachable metrics paths.
2. Confirm the endpoint responds like a Prometheus metrics exporter or is associated with a Node.js OpenTelemetry deployment.
3. Send a malformed HTTP request with an invalid request URI to the metrics listener.
4. Trigger an uncaught TypeError during URL parsing in the vulnerable exporter.
5. Cause the Node.js process to terminate, taking down the metrics exporter and potentially the application process.
6. Optionally repeat requests after automatic restarts to create sustained denial of service.

How to detect it

To determine whether exploitation already occurred, correlate metrics endpoint access logs, reverse proxy logs, load balancer logs, container logs, process manager logs, and application stderr/stdout. Look for malformed HTTP request lines or unusual 400-series parsing errors targeting Prometheus metrics endpoints or TCP port 9464 immediately followed by Node.js termination, uncaught TypeError messages, container exits, pod restarts, systemd service restarts, PM2 restarts, or health-check failures. In Kubernetes, review pod restart counts, previous container logs, events, and termination reasons around suspicious requests. In systemd or VM deployments, review journald/syslog for Node.js stack traces and service restarts. In container platforms, inspect logs from the previous container instance because the crash may have rotated active logs. Because the vulnerability results in availability impact rather than code execution, strong evidence usually consists of a malformed request to the exporter followed within seconds by an uncaught URL parsing TypeError and process termination.

• TCP port 9464
• 0.0.0.0:9464
• @opentelemetry/exporter-prometheus
• PrometheusExporter
• TypeError [ERR_INVALID_URL]
• ERR_INVALID_URL
• Invalid URL
• uncaughtException
• Uncaught TypeError
• GET /metrics
• POST /metrics
• /metrics
• npm ls @opentelemetry/exporter-prometheus
• pnpm list @opentelemetry/exporter-prometheus
• yarn why @opentelemetry/exporter-prometheus

What your security team should do

• Prioritize upgrading OpenTelemetry JS Prometheus exporter deployments to 0.217.0 or later, especially services exposing port 9464 or any metrics endpoint outside a trusted monitoring network.
• Inventory Node.js services using OpenTelemetry metrics and identify direct or transitive dependencies on @opentelemetry/exporter-prometheus or related OpenTelemetry JS packages.
• Restrict network access to metrics endpoints so only approved Prometheus scrapers or monitoring infrastructure can connect.
• Search recent logs and runtime telemetry for unexplained Node.js process exits, uncaught TypeError crashes, and restart loops correlated with requests to metrics endpoints.
• Add SIEM detections for repeated malformed requests to metrics endpoints followed by process restarts or container restarts.
• Ensure dependency scanning policies flag OpenTelemetry JS Prometheus exporter versions earlier than 0.217.0.
• Where upgrades cannot be applied immediately, place the endpoint behind a proxy or firewall that rejects malformed request lines before they reach the Node.js exporter.