{"answers":{"affected":"2 open source packages ship an affected version, including vllm.","exploited":"There is no known exploitation of GHSA-ggpf-24jw-3fcw in the wild and no public exploit code.","fix":"Upgrade vllm to 0.8.0 or later.","what":"GHSA-ggpf-24jw-3fcw is an unsafe deserialization vulnerability in vllm, published on 23 Apr 2025. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link."},"fix_prompt":"Check this codebase for GHSA-ggpf-24jw-3fcw and fix it if it is affected.\n\nWhat it is: GHSA-ggpf-24jw-3fcw is an unsafe deserialization vulnerability in vllm, published on 23 Apr 2025. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link.\nExploitation: There is no known exploitation of GHSA-ggpf-24jw-3fcw in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- vllm (PyPI): affected all versions; fixed in 0.8.0\n- vllm (PyPI): affected all versions; fixed in 0.8.0\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-ggpf-24jw-3fcw/ (Markdown: https://insights.sbomify.com/GHSA-ggpf-24jw-3fcw/index.md)","id":"GHSA-ggpf-24jw-3fcw","markdown":"https://insights.sbomify.com/GHSA-ggpf-24jw-3fcw/index.md","name":"GHSA-ggpf-24jw-3fcw","record":{"aliases":[],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["code_execution"],"network_reachable":"yes","non_default_config":false,"product_category":"vLLM inference library","requires_auth":"none","summary":"Loading malicious models in vLLM with vulnerable PyTorch versions allows remote code execution via unsafe deserialization.","user_interaction":"required","vuln_class":"deserialization"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"## Description\n\nhttps://github.com/vllm-project/vllm/security/advisories/GHSA-rh4j-5rhw-hr54 reported a vulnerability where loading a malicious model could result in code execution on the vllm host. The fix applied to specify `weights_only=True` to calls to `torch.load()` did not solve the problem prior to PyTorch 2.6.0.\n\nPyTorch has issued a new CVE about this problem: https://github.com/advisories/GHSA-53q9-r3pm-6pq6\n\nThis means that versions of vLLM using PyTorch before 2.6.0 are vulnerable to this problem.\n## Background Knowledge\nWhen users install VLLM according to the official manual\n![image](https://github.com/user-attachments/assets/d17e0bdb-26f2-46d6-adf6-0b17e5ddf5c7)\n\nBut the version of PyTorch is specified in the requirements. txt file\n![image](https://github.com/user-attachments/assets/94aad622-ad6d-4741-b772-c342727c58c7)\n\nSo by default when the user install VLLM, it will install the PyTorch with version 2.5.1\n![image](https://github.com/user-attachments/assets/04ff31b0-aad1-490a-963d-00fda91da47b)\n\nIn CVE-2025-24357, weights_only=True was used for patching, but we know this is not secure.\nBecause we found that using Weights_only=True in pyTorch before 2.5.1 was unsafe\n\nHere, we use this interface to prove that it is not safe.\n![image](https://github.com/user-attachments/assets/0d86efcd-2aad-42a2-8ac6-cc96b054c925)\n\n## Fix\nupdate PyTorch version to 2.6.0\n\n## Credit\nThis vulnerability was found By Ji'an Zhou and Li'shuo Song","ecosystems":["PyPI"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"CVE-2025-24357 Malicious model remote code execution fix bypass with PyTorch \u003c 2.6.0","id":"GHSA-ggpf-24jw-3fcw","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"PyPI","product":null,"products":[],"type":"deserialization","year":"2025"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"PyPI","fixed":["0.8.0"],"introduced":["0"],"last_affected":[],"package":"vllm","purl":null,"source":"GHSA-ggpf-24jw-3fcw"},{"ecosystem":"PyPI","fixed":["0.8.0"],"introduced":["0"],"last_affected":[],"package":"vllm","purl":"pkg:pypi/vllm","source":"GHSA-ggpf-24jw-3fcw"}],"products":null,"published":"2025-04-23","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Loading malicious models in vLLM with vulnerable PyTorch versions allows remote code execution via unsafe deserialization.","url":"https://insights.sbomify.com/GHSA-ggpf-24jw-3fcw/"}