Summary
SGLang exposes a credential leakage issue where the /server_info endpoint returns API keys and SSL keyfile details when only the --admin-api-key is configured.
An attacker who can reach this endpoint may obtain sensitive credentials and reuse them to impersonate administrators or intercept secure communications.
Affected context
This vulnerability affects SGLang deployments that:
- Expose the
/server_infoendpoint over a network interface, and - Rely primarily on the
--admin-api-keyoption for administrative protection, and - Do not apply additional access controls or network segmentation around administrative APIs.
In such setups, server metadata responses may include API keys and SSL keyfile information instead of being strictly sanitized.
Exploit preconditions
- Attack surface: HTTP(S) access to the SGLang
/server_infoendpoint. - Required access: Ability to send requests to the administrative or diagnostic interface; may be unauthenticated or weakly protected if misconfigured.
- Trigger point: Requesting server metadata when only
--admin-api-keyis configured, causing sensitive fields to be returned in the response. - Why exploitation is possible: Sensitive secrets are stored and returned in clear form through an informational endpoint without adequate redaction or separation between operational diagnostics and credential material.
Why this happens
The underlying issue is that sensitive credential material (API keys and SSL keyfile information) is handled as regular metadata and exposed through an informational endpoint.
This aligns with CWE-522: Insufficiently Protected Credentials, where secrets are not properly shielded from disclosure in transit or at rest.
Instead of redacting or omitting secret values from the /server_info response, the implementation surfaces them to clients, collapsing the boundary between internal secret storage and external observability.
Potential impact
- Attackers may obtain administrative API keys and impersonate privileged users.
- Compromised SSL keyfile information could enable man-in-the-middle attacks or decryption of captured traffic.
- Unauthorized configuration changes, including model management and system tuning, could be performed.
- Broader environment compromise if reused credentials are valid across other services or environments.
General mitigation guidance
Mitigation generally focuses on separating sensitive credentials from diagnostic output and minimizing the exposure of administrative interfaces.
Common defensive patterns include:
- Ensuring server metadata endpoints never include raw secret values; instead, redact, tokenize, or omit sensitive fields.
- Applying strict authentication and authorization controls to any administrative or debug endpoints, independent of single API-key mechanisms.
- Limiting network exposure of admin APIs using firewall rules, private interfaces, or service meshes so only trusted operators can reach them.
- Using dedicated secret management mechanisms to store keys and certificates, avoiding their reflection in standard API responses.
- Designing APIs so that operational observability never requires direct access to credential material.
How teams detect issues like this
Organizations can detect similar issues by:
- Performing API response audits and security testing focused on metadata and diagnostic endpoints to check for leaked secrets.
- Using static analysis and code review checklists that flag any serialization of secret-bearing structures into HTTP responses or logs.
- Enforcing policies that all endpoints returning configuration or status information use explicit whitelisting of safe fields.
- Applying automated secret scanning tools against HTTP traces, logs, and configuration dumps to identify inadvertent disclosure of keys or certificates.
