Description

HyperDX through 1.10.1 fails to enforce role-based access controls in team management endpoints, allowing any team member to perform administrative actions. Attackers can delete team members including owners, rotate API keys, and rename teams by sending requests to PATCH /team/apiKey, PATCH /team/name, and DELETE /team/member endpoints.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-28T20:20:19.067Z",
  "pubdate": "2026-08-28T20:20:19.067Z",
  "executiveSummary": "HyperDX versions through 1.10.1 suffer from a critical improper access control vulnerability within its team management module. The flaw stems from a failure to perform server-side authorization checks on sensitive administrative API endpoints. Consequently, any authenticated team member, regardless of their assigned role or permission level, can exercise elevated privileges typically reserved for account owners or administrators. The impact of this vulnerability is severe, as it permits unauthorized actors to manipulate core team configurations, compromise security credentials, and perform destructive actions, including the removal of administrative users. This effectively leads to a complete bypass of the security model defined for HyperDX teams. The vulnerability is exploitable by any valid user within a team, requiring no additional escalated permissions. Successful exploitation allows for the permanent alteration of team settings and account takeovers by rotating API keys or purging existing team owners, posing a significant risk to the integrity and confidentiality of the affected organization's telemetry data and management environment.",
  "technicalDetails": "The vulnerability originates from inadequate validation of user roles within the backend logic governing the HyperDX team management interface. Specifically, the application endpoints responsible for administrative team operations fail to enforce strict Role-Based Access Control (RBAC) mechanisms. When a request is processed by the backend, the system fails to verify whether the requester possesses the 'owner' or 'admin' privilege level before authorizing the requested operation.\nThe affected endpoints include, but are not limited to, PATCH /team/apiKey, PATCH /team/name, and DELETE /team/member. In a standard secure implementation, these endpoints should intercept the user's session identifier, correlate it with a database entry regarding team membership and roles, and deny requests that do not match an administrative privilege mapping. Instead, the current implementation blindly executes the requested mutation upon receipt of a valid authenticated request from any user associated with the target team.\nThe attack flow proceeds as follows: 1. An attacker obtains a legitimate session token by authenticating as a standard team member within a HyperDX instance. 2. The attacker identifies the target team's operational scope. 3. The attacker crafts an HTTP request targeting the vulnerable endpoints, such as sending a DELETE request to /team/member with the user ID of the team owner. 4. The server processes the request and executes the removal of the administrative account from the database. 5. Alternatively, by sending a PATCH request to /team/apiKey, the attacker can force the rotation of the team's API keys, potentially invalidating existing integrations or allowing the attacker to intercept new keys if they have access to the configuration logs. Because the backend assumes the requester is authorized based purely on their presence within the team context, the operation is permitted without challenge.\nThis vulnerability highlights a flaw in the application's authorization layer, likely resulting from a lack of server-side middleware to validate permissions for sensitive routes. The scope covers all versions of HyperDX up to and including 1.10.1. The lack of granular authorization essentially collapses the role hierarchy, turning every standard member into an administrative user with the ability to destroy the security posture of the team."
}