CVE-2026-115289 in APM Server
Summary
by MITRE • 11/03/2026
Use of Multiple Resources with Duplicate Identifier (CWE-694) in APM Server can lead to information disclosure via a specially crafted agent configuration request. An authenticated APM agent could receive the central agent configuration that belongs to a different service until the cached configuration expires. A service could also run with central configuration settings, such as sampling settings, that were meant for a different service.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in the Application Performance Monitoring (APM) Server involves a critical flaw related to resource management and identifier handling, specifically categorized under CWE-694: Use of Multiple Resources with Duplicate Identifier. This security issue arises from improper validation or isolation mechanisms when processing agent configuration requests. In a typical APM architecture, agents report telemetry data to the server, which then returns centralized configuration settings such as sampling rates, span limits, and other operational parameters tailored to specific services. The flaw allows an authenticated APM agent associated with one service to inadvertently receive the central configuration intended for a different service. This misalignment occurs because the system fails to strictly bind the requested resource identifier to the correct context or cache entry, leading to cross-service data leakage during the retrieval process.
From a technical perspective, the root cause lies in how the APM Server manages its internal caching mechanism and request routing logic. When an agent sends a configuration request, it includes identifiers that map it to a specific service entity within the monitoring infrastructure. Due to the duplicate identifier issue or insufficient key uniqueness checks, the server may retrieve a cached configuration object associated with a different service ID. This error persists until the cache entry expires or is invalidated by subsequent updates. Consequently, the agent receives settings not designed for its operational context, creating an immediate discrepancy between expected and actual behavior. The vulnerability exploits the trust relationship inherent in authenticated API interactions, where valid credentials grant access to configuration endpoints without adequate secondary verification of resource ownership.
The operational impact of this flaw extends beyond simple information disclosure. While an attacker could potentially infer details about other services by analyzing the received configuration parameters, such as naming conventions or structural metadata, the more severe consequence involves functional integrity and security posture degradation. A service might begin operating with sampling settings intended for another application. For instance, if a high-traffic production service receives low-sampling configurations meant for a development environment, it may fail to capture critical error traces or performance bottlenecks, leading to blind spots in observability. Conversely, receiving overly aggressive sampling rates could result in excessive resource consumption and data storage costs. Furthermore, any configuration parameters that influence security controls, such as authentication requirements or encryption settings, if misapplied due to this flaw, could inadvertently weaken the service's defense mechanisms against external threats.
This vulnerability aligns with ATT&CK technique T1530: Data from Cloud Storage Object, as it involves accessing data stored in a centralized repository (the configuration cache) that belongs to another entity. It also reflects aspects of CWE-284: Improper Access Control, since the authenticated user or agent is able to access resources they are not authorized to view due to flawed identifier mapping. The lack of strict isolation between service contexts allows for unauthorized data retrieval and misconfiguration propagation within the monitoring ecosystem.
To mitigate this vulnerability, immediate actions should focus on strengthening input validation and resource binding logic within the APM Server codebase. Developers must ensure that every configuration request explicitly validates that the requesting agent's identity matches the owner of the requested configuration resource before returning any cached data. Implementing strict key uniqueness checks in the caching layer is essential to prevent duplicate identifiers from resolving to incorrect objects. Additionally, introducing short cache lifetimes or versioned cache keys can reduce the window of exposure for stale configurations. On the operational side, administrators should monitor for anomalies in agent behavior and configuration drift across services. Regular audits of APM server logs can help detect instances where agents receive unexpected configuration parameters, allowing for rapid incident response before significant misconfiguration impacts production stability or security posture.