CVE-2026-81664 in OpenFaaS
Summary
by MITRE • 08/27/2026
The OpenFaaS gateway registers GET /system/telemetry in gateway/main.go and, when basic_auth is enabled, wraps each administrative /system/* handler in auth.DecorateWithBasicAuth. TelemetryHandler was left out of that wrap block from 0.27.11, which introduced the route, until 0.27.14, which added it. On an affected gateway the route therefore reaches the forwarding proxy with no credential check and returns whatever the configured provider serves for /system/telemetry, so any client that can reach the gateway port can read the provider's telemetry regardless of the basic_auth setting. The exposed content depends on the provider, and covers resource and invocation metrics for faasd and pod or cluster state for faas-netes.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability in OpenFaaS versions 0.27.11 through 0.27.13 stems from an incomplete implementation of authentication controls within the gateway component, specifically affecting administrative endpoints that require privileged access. The architecture of the OpenFaaS gateway relies on a middleware pattern where handlers for sensitive paths under the /system/ namespace are wrapped with basic authentication logic to ensure that only authorized users can interact with system-level functions. This security control was correctly applied to most administrative routes when basic_auth is enabled, creating a necessary barrier against unauthorized access. However, during the introduction of telemetry capabilities in version 0.27.11, the specific handler for GET /system/telemetry was inadvertently omitted from this authentication wrapping block. Consequently, while other system endpoints remained protected by credential checks, the telemetry endpoint bypassed these safeguards entirely until the issue was rectified in version 0.27.14.
From a technical perspective, this oversight results in an unauthenticated access vulnerability where any client capable of reaching the gateway port can retrieve sensitive operational data without providing valid credentials. The TelemetryHandler forwards requests to the configured telemetry provider and returns the response directly to the requester. Because no authentication middleware intercepts or validates these specific requests, the confidentiality of the returned data is compromised. This flaw effectively nullifies the security posture provided by basic_auth for this particular endpoint, allowing external actors who have network connectivity to the gateway service to extract internal metrics that should be restricted to administrators only.
The operational impact of this vulnerability involves the exposure of detailed resource and invocation metrics specific to the deployment environment. For instances running on faasd, attackers can access granular data regarding function execution frequency, latency, and resource consumption patterns. In Kubernetes-based deployments using faas-netes, the exposed telemetry includes pod status information and cluster state details. This leakage provides adversaries with valuable intelligence for reconnaissance purposes, enabling them to map out the infrastructure topology, identify active workloads, assess system load, and potentially plan further attacks based on observed performance characteristics or architectural weaknesses revealed by the metrics.
This vulnerability aligns with CWE-284, which describes Improper Access Control, as well as CWE-200, Exposure of Sensitive Information to an Unauthorized Actor. In terms of attack vectors, it corresponds to ATT&CK technique T1592, Gather Victim Host Information, specifically through the collection of software and hardware details that can aid in subsequent exploitation phases. To mitigate this risk, organizations must ensure they are running OpenFaaS version 0.27.14 or later, where the authentication wrapper has been correctly applied to all administrative system handlers including telemetry endpoints. Additionally, administrators should verify their gateway configurations to confirm that basic_auth is enabled and properly enforced across all sensitive routes, thereby preventing unauthorized retrieval of internal operational data even if similar coding oversights occur in future updates.