CVE-2026-107840 in yopass
Summary
by MITRE • 10/09/2026
yopass is a service for securely sharing secrets, passwords, and files. Prior to version 14.7.0, the Prometheus metrics middleware in pkg/server/server.go uses the attacker-controlled r.Method value directly as the method label for yopass_http_requests_total and yopass_http_request_duration_seconds. Because the catch-all route accepts arbitrary HTTP method tokens, an unauthenticated remote attacker can submit many unique methods and create metric series that the Prometheus registry never evicts. The resulting monotonic memory growth can OOM-kill the process, while the expanding registry also degrades /metrics scrape latency and can blind monitoring. This issue is fixed in version 14.7.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in yopass versions prior to 14.7.0 represents a significant resource exhaustion risk stemming from improper handling of HTTP method labels within the Prometheus metrics middleware. Yopass functions as a secure service for sharing secrets, passwords, and files, relying on robust monitoring infrastructure via Prometheus to track performance and usage patterns. The core technical flaw resides in pkg/server/server.go, where the application directly incorporates the attacker-controlled r.Method value into the label set for two critical time-series metrics: yopass_http_requests_total and yopass_http_request_duration_seconds. In a standard secure implementation, HTTP methods should be restricted to a predefined whitelist of valid verbs such as GET, POST, PUT, DELETE, etc., ensuring that metric labels remain finite and manageable. However, the catch-all route in this version accepts arbitrary HTTP method tokens without validation or sanitization.
This lack of input validation allows an unauthenticated remote attacker to exploit the system by submitting a high volume of requests using unique and non-standard HTTP methods. Because Prometheus metrics are designed as time-series data points indexed by their label combinations, each new unique HTTP method creates a distinct metric series in the registry. The Prometheus client library does not automatically evict these series based on cardinality limits unless explicitly configured to do so, which was not the case here. Consequently, every request with a novel method string results in permanent memory allocation for that specific time-series identifier. This leads to monotonic and unbounded memory growth within the application process as the registry expands indefinitely.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition through out-of-memory errors. As the number of unique metric series increases, the Go runtime consumes increasing amounts of heap memory to store these label-value pairs. Eventually, the process exceeds its available memory allocation and triggers an Out-Of-Memory (OOM) kill event by the operating system or container orchestrator, causing yopass to crash and become unavailable. Beyond immediate service disruption, the expanding registry significantly degrades performance even before a full crash occurs. The overhead of managing thousands or millions of metric series increases latency for scraping /metrics endpoints, which can blind monitoring systems that rely on timely data collection. This degradation affects observability capabilities, making it difficult to detect other anomalies or assess system health during an active attack.
From a classification perspective, this vulnerability aligns with CWE-770: Allocation of Resources Without Limits or Throttling, as the application fails to limit the resources consumed by untrusted input. It also relates to CWE-284: Improper Access Control, specifically regarding the failure to restrict access to internal monitoring mechanisms based on valid operational parameters. In terms of the MITRE ATT&CK framework, this behavior is characteristic of T1496: Resource Hijacking, where an attacker consumes system resources to degrade service availability or cause a denial-of-service condition. The attack vector is remote and unauthenticated, allowing any external actor with network access to initiate the resource exhaustion without prior credentials.
The recommended mitigation for organizations running affected versions is to upgrade yopass immediately to version 14.7.0 or later, where this issue has been resolved by implementing proper validation of HTTP methods before they are used as metric labels. For environments that cannot patch immediately due to operational constraints, temporary mitigations should include deploying a Web Application Firewall (WAF) in front of the yopass instance to filter out non-standard HTTP methods and restrict allowed verbs to standard values such as GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, and CONNECT. Additionally, configuring Prometheus scrape intervals with appropriate timeouts can help mitigate some performance degradation but does not address the underlying memory leak caused by unbounded cardinality growth. Long-term architectural improvements should involve implementing metric label cardinality limits within the application code or using a metrics aggregation layer that enforces strict labeling policies to prevent similar issues in other services.