Description

Onyx 4.6.6 fails to properly restrict access to custom tool credentials stored in custom_headers, allowing any authenticated user to read admin-defined API keys. Attackers with basic authentication can call GET /tool/{tool_id} or GET /tool endpoints to retrieve plaintext authorization headers and third-party API credentials, then use them to directly access upstream APIs.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-04T15:17:49.110Z",
  "pubdate": "2026-09-04T15:17:49.110Z",
  "executiveSummary": "Onyx 4.6.6 is susceptible to an unauthorized credential disclosure vulnerability, categorized as an Improper Access Control flaw.\nThe vulnerability resides in the application's handling of custom tool configurations, where sensitive API credentials stored within custom_headers are improperly exposed through standard API endpoints.\nAny authenticated user, regardless of their privilege level, can retrieve plaintext authorization headers and third-party API keys by querying specific endpoints.\nThis represents a critical security risk as it facilitates horizontal and vertical privilege escalation, allowing attackers to perform unauthorized actions on upstream systems utilizing the exposed credentials.\nExploitation requires the attacker to possess basic authentication credentials to access the internal API, but no elevated administrative privileges are necessary to perform the data exfiltration.\nSuccessful exploitation directly results in the compromise of external service integrations, potentially leading to unauthorized data access, system manipulation, or complete account takeovers of integrated third-party services.",
  "technicalDetails": "The root cause of this vulnerability is the inadequate implementation of authorization checks within the Onyx tool management module. Specifically, the backend fails to sanitize or mask sensitive data contained within the 'custom_headers' field when serializing tool configuration objects for API responses.\nThe vulnerable components include the GET /tool/{tool_id} and GET /tool endpoints, which are designed to return metadata regarding configured custom tools. In Onyx 4.6.6, these endpoints process the underlying tool configuration data structures without performing a secondary validation to verify if the requesting user possesses administrative permissions to view sensitive headers.\nThe attack flow proceeds as follows: First, a malicious actor authenticates to the Onyx instance using a low-privileged account. Second, the attacker interacts with the REST API by issuing a GET request to either the singular resource endpoint (GET /tool/{tool_id}) or the collection retrieval endpoint (GET /tool). Third, the application's backend retrieves the full configuration object, including the 'custom_headers' dictionary, from the database and returns it in the HTTP response body in plaintext format.\nBecause the 'custom_headers' field often contains sensitive information such as Authorization, Bearer tokens, or proprietary API keys used for upstream communication, the attacker captures these tokens directly from the response.\nOnce these credentials are obtained, the attacker can bypass Onyx entirely and interact directly with the upstream APIs using the leaked tokens. This effectively allows the attacker to impersonate the Onyx server, potentially exfiltrating sensitive data from integrated platforms or executing unauthorized commands on behalf of the service account.\nThe vulnerability is limited to the application layer and does not require local file system access or remote code execution to retrieve the keys, making it a high-impact information disclosure issue. The lack of granular attribute-level access control on the API response serialization is the fundamental technical deficiency enabling this exposure."
}