Executive Summary

This vulnerability exists in SGLang version 0.5.10.post1, specifically in an unknown function within the file python/sglang/srt/lora/lora_manager.py, part of the Inference HTTP Endpoint component.

The issue arises from manipulation of the argument 'lora_path', which leads to a reachable assertion, meaning the program can be forced into an unexpected state or crash.

The attack exploiting this vulnerability can be launched remotely, but it requires a high level of complexity and is considered difficult to exploit.

A fix has been proposed via a pull request but has not yet been accepted.

Useful 0 Not Useful 0

Impact Analysis

Exploitation of this vulnerability can cause the affected software to reach an assertion failure, potentially leading to a crash or denial of service.

Since the attack can be launched remotely, it could disrupt the availability of the Inference HTTP Endpoint component.

However, the exploitability is difficult due to the high complexity required to successfully carry out the attack.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability causes a scheduler crash in the SGLang server leading to a complete loss of availability of the Inference HTTP Endpoint service.

This loss of availability could impact compliance with standards and regulations that require continuous availability and reliability of services, such as HIPAA which mandates availability of electronic protected health information, or GDPR which requires data processing systems to be resilient and available.

However, there is no direct information provided about data confidentiality or integrity breaches, so the impact on compliance is primarily related to availability requirements.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by observing the behavior of the SGLang server when handling concurrent requests involving LoRA adapters. Specifically, if the server crashes or becomes permanently unresponsive, it may be due to this vulnerability.

To reproduce or detect the issue, you can start the SGLang server with the parameter `--max-loras-per-batch N` set, then send concurrent requests that include N LoRA adapters plus at least one base-model request in the same scheduling round. If the server crashes with an assertion error in `lora_manager.fetch_new_loras()` and a SIGQUIT signal, this indicates the vulnerability is present.

Monitoring server logs for assertion failures and SIGQUIT signals related to `fetch_new_loras` can also help detect the issue.

• Start SGLang server with a per-batch LoRA cap: `sglang_server --max-loras-per-batch N`
• Send concurrent requests exceeding the LoRA batch limit (N LoRA adapters + 1 base-model request)
• Check server logs for assertion failures and SIGQUIT signals indicating scheduler crash

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation involves avoiding conditions that trigger the scheduler crash by not exceeding the `--max-loras-per-batch` limit in concurrent requests.

Until the official fix is accepted and deployed, you should limit the number of concurrent LoRA adapter requests to be at or below the configured batch limit to prevent the scheduler from admitting more LoRAs than allowed.

Applying the fix from the pending pull request, which properly enforces the max_loras_per_batch limit by counting all admitted LoRA requests, is the definitive solution once it is merged and released.

• Configure the server to use a conservative `--max-loras-per-batch` value and avoid sending concurrent requests that exceed this limit.
• Monitor server stability and logs for signs of scheduler crashes.
• Apply the patch from the pull request (PR #25078) once it is available in your SGLang version.

Useful 0 Not Useful 0