CVE-2026-49835

What it actually does

The flaw is a remotely triggerable denial-of-service condition in Sigstore Timestamp Authority prior to version 2.1.0. The HTTP metrics middleware records the raw request path and raw HTTP method as Prometheus label values before request routing or normalization. Because those labels are unbounded, an unauthenticated attacker can send many requests with unique paths or unusual methods, causing the application and potentially Prometheus to create a large number of permanent time-series entries. This high-cardinality metric growth can exhaust memory, increase CPU and storage pressure, destabilize metric scraping, and make the Timestamp Authority unavailable.

Why it matters to the business

If exploited, the timestamping service can become slow or unavailable, disrupting workflows that depend on trusted signing, provenance, or timestamp evidence. This can delay software release pipelines, artifact verification, compliance evidence generation, and other trust-chain operations. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, but internet-exposed timestamp services should still be prioritized because exploitation is unauthenticated and can be performed with simple HTTP traffic.

How an attack unfolds

An attacker first identifies an exposed Sigstore Timestamp Authority endpoint running a vulnerable version. They then send a large volume of HTTP requests using unique URL paths, such as randomized values appended to timestamp API paths, and may also vary HTTP method strings. The vulnerable middleware records each raw path and method as a distinct Prometheus label value before the application router rejects or handles the request. Each unique label combination creates a new time series that remains in memory. As the number of unique time series grows, memory consumption increases in the Timestamp Authority process and may also burden Prometheus during scraping. Eventually the service can experience degraded performance, failed scrapes, out-of-memory termination, or full denial of service.

How to fix it

Upgrade Sigstore Timestamp Authority to version 2.1.0 or later. The fixed release prevents unbounded metric cardinality caused by raw request path and method labels. If immediate upgrade is not possible, reduce exposure by placing the service behind authentication, network allowlists, rate limits, and request validation. Block or throttle requests with abnormal methods, excessive path entropy, or large volumes of unique 404 paths. Limit Prometheus scrape impact by applying metric relabeling or drop rules for high-cardinality labels where feasible, but treat this only as a mitigation because the vulnerable application can still consume memory before metrics are scraped. Monitor service memory, restart counts, 5xx rates, 404 rates, and Prometheus series cardinality until the upgrade is complete.

How to confirm the fix worked

Confirm the running Timestamp Authority version is 2.1.0 or later. Review container images, deployment manifests, package metadata, and release artifacts to ensure no vulnerable pre-2.1.0 build remains in use. After patching, send a small controlled set of requests with randomized paths and verify that exported metrics no longer create distinct permanent time series for each raw path or arbitrary method. Check Prometheus cardinality for request path and method labels before and after the fix. Validate that memory usage remains stable under benign high-variation request testing, and confirm ingress, WAF, or reverse-proxy controls reject or rate-limit abnormal request patterns.

Typical attack path

1. Discover an externally reachable Sigstore Timestamp Authority service.
2. Confirm the service accepts unauthenticated HTTP requests to timestamp-related paths or other routes.
3. Generate many requests with unique raw paths, for example by appending random UUID-like strings to an API path.
4. Optionally vary HTTP method names to create additional metric label combinations.
5. Cause the vulnerable metrics middleware to create unbounded Prometheus time-series labels for each unique path and method.
6. Drive memory and metric-cardinality growth until the service, container, node, or monitoring pipeline becomes unstable or unavailable.

How to detect it

Investigate whether the service has already been targeted by reviewing reverse-proxy, ingress, load balancer, application, and web server logs for bursts of unauthenticated requests with many unique paths, especially timestamp API paths containing random UUID-like suffixes. Look for unusual or invalid HTTP methods, high rates of 404 or 405 responses, increased request latency, and sudden growth in memory usage. In Prometheus, examine time-series cardinality for request path and method labels associated with the Timestamp Authority, looking for rapid growth, many one-off label values, and scrape failures. On hosts or containers, review OOM-kill events, restart loops, elevated memory, and degraded availability around the same time as suspicious request bursts. Because no specific threat actors or public exploitation are provided, focus detection on behavioral indicators rather than known attacker infrastructure.

• /api/v1/timestamp/
• GET /api/v1/timestamp/
• POST /api/v1/timestamp/
• 404
• 405
• out of memory
• OOMKilled
• Killed process
• container restarted
• context deadline exceeded
• prometheus scrape failed
• label name="path"
• label name="method"
• /api/v1/timestamp/[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}

What your security team should do

• Inventory all Sigstore Timestamp Authority deployments and identify any instances running versions earlier than 2.1.0.
• Upgrade vulnerable deployments to Sigstore Timestamp Authority 2.1.0 or later as the primary remediation.
• Restrict public access where possible using network controls, authentication, reverse proxies, or service mesh policy.
• Add rate limits and request validation for high-volume requests with unique paths or nonstandard HTTP methods.
• Monitor Prometheus series cardinality, application memory, container restarts, and HTTP 404/405 spikes for signs of attempted exploitation.
• Create detection rules for bursts of timestamp-service requests containing UUID-like or high-entropy path components.
• If exploitation is suspected, preserve application logs, reverse-proxy logs, Prometheus metadata, container restart history, and memory/OOM events for investigation.