Summary
InternLM LMDeploy contains an unauthenticated unsafe deserialization vulnerability in the /update_weights endpoint. A remote attacker may submit crafted pickled data that is deserialized without validation, allowing operating system commands to execute with the privileges of the API server process.
InternLM LMDeploy contains an unauthenticated unsafe deserialization vulnerability in the /update_weights endpoint. A remote attacker may submit crafted pickled data that is deserialized without validation, allowing operating system commands to execute with the privileges of the API server process.
Affected context
The vulnerability affects LMDeploy deployments using the API server and exposing the /update_weights endpoint. It becomes risky when the endpoint is reachable by untrusted network clients and accepts serialized tensor data that is processed with ForkingPickler.loads without strict validation or an equivalent trust boundary. The reported affected release range is LMDeploy 0.9.0 through 0.18.0.
The vulnerability affects LMDeploy deployments using the API server and exposing the /update_weights endpoint. It becomes risky when the endpoint is reachable by untrusted network clients and accepts serialized tensor data that is processed with ForkingPickler.loads without strict validation or an equivalent trust boundary. The reported affected release range is LMDeploy 0.9.0 through 0.18.0.
Exploit preconditions
- Attack surface: Network-accessible
/update_weightsAPI endpoint - Required access: No authentication is required when the endpoint is exposed without additional access controls
- Trigger point: Processing the
serialized_named_tensorsrequest data - Why exploitation is possible: Crafted serialized data reaches an unsafe pickle deserializer, which can reconstruct attacker-controlled objects and trigger command execution
- Attack surface: Network-accessible
/update_weightsAPI endpoint - Required access: No authentication is required when the endpoint is exposed without additional access controls
- Trigger point: Processing the
serialized_named_tensorsrequest data - Why exploitation is possible: Crafted serialized data reaches an unsafe pickle deserializer, which can reconstruct attacker-controlled objects and trigger command execution
Why this happens
The underlying issue is the use of Python pickle deserialization on attacker-influenced input without authentication, validation, or a restricted data format. Pickle deserialization can invoke object reconstruction behavior rather than merely decode data, allowing serialized content to perform unintended operations during loading. This maps to CWE-502: Deserialization of Untrusted Data.
The underlying issue is the use of Python pickle deserialization on attacker-influenced input without authentication, validation, or a restricted data format. Pickle deserialization can invoke object reconstruction behavior rather than merely decode data, allowing serialized content to perform unintended operations during loading. This maps to CWE-502: Deserialization of Untrusted Data.
Potential impact
- An attacker may execute arbitrary operating system commands
- The API server process may be fully compromised
- Sensitive model files, credentials, or environment data could be exposed
- The affected host or container may be used for lateral movement
- Model integrity and inference results could be altered
- The service may be disrupted or used to affect other workloads
- An attacker may execute arbitrary operating system commands
- The API server process may be fully compromised
- Sensitive model files, credentials, or environment data could be exposed
- The affected host or container may be used for lateral movement
- Model integrity and inference results could be altered
- The service may be disrupted or used to affect other workloads
General mitigation guidance
Mitigation generally focuses on removing unsafe object deserialization from unauthenticated request paths and reducing trust in client-supplied data.
Common defensive patterns include:
- Replacing pickle-based transport with a non-executable, schema-constrained serialization format
- Rejecting arbitrary object reconstruction and permitting only explicitly defined primitive data types
- Requiring authentication and authorization before weight-update operations
- Restricting the endpoint to trusted management networks or private service interfaces
- Applying strict request validation, size limits, and content checks before processing tensor data
- Running the API server with least privilege and isolating it from sensitive host resources
- Limiting credentials, filesystem access, and network permissions available to the service
Mitigation generally focuses on removing unsafe object deserialization from unauthenticated request paths and reducing trust in client-supplied data.
Common defensive patterns include:
- Replacing pickle-based transport with a non-executable, schema-constrained serialization format
- Rejecting arbitrary object reconstruction and permitting only explicitly defined primitive data types
- Requiring authentication and authorization before weight-update operations
- Restricting the endpoint to trusted management networks or private service interfaces
- Applying strict request validation, size limits, and content checks before processing tensor data
- Running the API server with least privilege and isolating it from sensitive host resources
- Limiting credentials, filesystem access, and network permissions available to the service
How teams detect issues like this
Organizations can look for:
- Static-analysis findings involving
pickle.loads,ForkingPickler.loads, or equivalent deserialization APIs on request-controlled data - Code review paths where serialized request fields reach object loaders without authentication or schema validation
- API inventories showing publicly reachable model-management or weight-update endpoints
- Network telemetry for unexpected requests to
/update_weights, especially from untrusted sources - Process-monitoring alerts for shell or operating-system command execution by the API server
- Policy checks requiring authentication, authorization, and approved serialization formats for administrative endpoints
Automated code review and software composition analysis tools may help identify unsafe deserialization patterns.
Organizations can look for:
- Static-analysis findings involving
pickle.loads,ForkingPickler.loads, or equivalent deserialization APIs on request-controlled data - Code review paths where serialized request fields reach object loaders without authentication or schema validation
- API inventories showing publicly reachable model-management or weight-update endpoints
- Network telemetry for unexpected requests to
/update_weights, especially from untrusted sources - Process-monitoring alerts for shell or operating-system command execution by the API server
- Policy checks requiring authentication, authorization, and approved serialization formats for administrative endpoints
Automated code review and software composition analysis tools may help identify unsafe deserialization patterns.
