Information Disclosure in vllm-orchestrator-gateway via Log Exposure

Executive Summary

This vulnerability exists in the vllm-orchestrator-gateway component where the production binary logs all incoming authorization headers and full chat payloads at the DEBUG level by default.

These logs include sensitive data such as bearer tokens, personally identifiable information (PII), credentials, and chat content, which are written to persistent logs accessible to any user with logging privileges.

The root cause is the hard-coded DEBUG logging level and the logging of full payloads and headers before any allow-list filtering is applied.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can lead to information disclosure by exposing sensitive data such as authorization tokens and chat content to unauthorized users who have logging access.

An attacker with access to these logs could harvest credentials and sensitive conversation content, potentially compromising user accounts and confidential information.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability involves logging sensitive information including personally identifiable information (PII) and secrets, which can lead to unauthorized disclosure.

Such exposure conflicts with compliance requirements in standards like GDPR and HIPAA that mandate protection of sensitive data and proper handling of PII.

Additionally, the vulnerability is related to CWE-532 (insertion of sensitive information into log files) and aligns with ASVS requirements V7.1.1 and V8.3.5, indicating it violates secure logging best practices.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by inspecting the logs generated by the vllm-orchestrator-gateway component for the presence of sensitive data such as Authorization header values (e.g., Bearer tokens) and full chat payloads containing personally identifiable information (PII). Since the logs are written to stdout and flow to the node journal and cluster logging stack in OpenShift environments, you can check these logs for sensitive information exposure.

Suggested commands to detect this vulnerability include searching the logs for Authorization headers or sensitive payloads. For example, you can use the following commands in an OpenShift or Kubernetes environment:

• kubectl logs <pod-name> | grep -i 'Authorization'
• journalctl -u <service-name> | grep -i 'Authorization'
• kubectl logs <pod-name> | grep -i 'Bearer'
• kubectl logs <pod-name> | grep -E 'chat payload|PII|personal'

These commands help identify if sensitive information is being logged, indicating the presence of the vulnerability.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include changing the default logging level of the vllm-orchestrator-gateway component from DEBUG to INFO or higher to prevent sensitive data from being logged.

Additionally, avoid logging Authorization headers and cookie values, and restrict logging of full payload bodies to explicit development modes only.

These changes can be configured via the RUST_LOG environment variable or equivalent configuration settings.

Furthermore, restrict access to logs by tightening RBAC permissions so that only authorized users can view logs containing potentially sensitive information.

Useful 0 Not Useful 0