ghsa-f74j-gffq-vm9p
Vulnerability from github
Description
In the FlightServer class of the pyquokka framework, the do_action() method directly uses pickle.loads() to deserialize action bodies received from Flight clients without any sanitization or validation, which results in a remote code execution vulnerability. The vulnerable code is located in pyquokka/flight.py at line 283, where arbitrary data from Flight clients is directly passed to pickle.loads().
Even more concerning, when FlightServer is configured to listen on 0.0.0.0 (as shown in the provided server example at line 339), this allows attackers across the entire network to perform arbitrary remote code execution by sending malicious pickled payloads through the set_configs action.
In addition, the functions cache_garbage_collect, do_put, and do_get also contain vulnerability points where pickle.loads is used to deserialize untrusted remote data. Please review and fix these issues accordingly. This report uses the set_configs action as an example.
Proof of Concept
- Step 1: The victim user starts a FlightServer that binds to the network interface, e.g.: ``` server = FlightServer("0.0.0.0", location = "grpc+tcp://0.0.0.0:5005") server.serve() ````
- Step 2: The attacker can then send malicious pickle dump data through the Flight client connection. The provided PoC demonstrates how an attacker can execute "ls -l" command:
```python class RCE: def reduce(self): import os return (os.system, ('ls -l',))
import pickle action_body = pickle.dumps(RCE()) action = pyarrow.flight.Action("set_configs", action_body) ```
When the server receives this payload, the FlightServer.do_action() method calls pickle.loads(action.body.to_pybytes()) on line 283, which triggers the execution of the malicious code through Python's pickle deserialization mechanism. The provided flight_client.py demonstrates a complete PoC that connects to the vulnerable server and executes arbitrary commands through the pickle deserialization vulnerability.
When the vulnerability is reproduced, python flight.py can be run to init the server and then run flight_client.py. There is an attack demo in the attachment.
Impact
Remote code execution on the victim's machine over the network. Once the victim starts the FlightServer with network binding (especially 0.0.0.0), an attacker on the network can gain arbitrary code execution by connecting to the Flight endpoint and sending crafted pickle payloads through the set_configs action. This vulnerability allows for:
- Complete system compromise
- Data exfiltration
- Lateral movement within the network
- Denial of service attacks
- Installation of persistent backdoors
Mitigation
- Replace unsafe deserialization: Replace
pickle.loads()with safer alternatives such as: - JSON serialization for simple data structures
- Protocol Buffers or MessagePack for complex data
-
If pickle must be used, implement a custom
Unpicklerwith a restrictedfind_class()method that only allows whitelisted classes -
Network security:
- If the service is intended for internal use only, bind to localhost (
127.0.0.1) instead of0.0.0.0 -
Implement authentication and authorization mechanisms
-
Security warnings: When starting the service on public interfaces, display clear security warnings to inform users about the risks.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pyquokka"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-62515"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-17T18:08:09Z",
"nvd_published_at": "2025-10-17T21:15:36Z",
"severity": "CRITICAL"
},
"details": "### Description\n\nIn the FlightServer class\u00a0of the pyquokka framework, the\u00a0do_action()\u00a0method\u00a0directly uses\u00a0pickle.loads()\u00a0to deserialize action\u00a0bodies received\u00a0from Flight clients without any sanitization or validation, which results in a remote code execution vulnerability. The vulnerable code is located in\u00a0pyquokka/flight.py\u00a0at\u00a0line 283, where arbitrary data from Flight clients\u00a0is directly passed\u00a0to\u00a0pickle.loads().\n\nEven\u00a0more concerning, when FlightServer is configured to listen on\u00a00.0.0.0\u00a0(as shown\u00a0in the provided server example at line\u00a0339), this allows attackers across the entire network to perform arbitrary remote code execution\u00a0by sending malicious pickled payloads through the\u00a0set_configs\u00a0action.\n\nIn addition, the functions cache_garbage_collect, do_put, and do_get also contain vulnerability points where pickle.loads is used to deserialize untrusted remote data. Please review and fix these issues accordingly. This report uses the set_configs action as an example.\n\n\n### Proof of Concept\n\n* Step 1:\nThe victim user\u00a0starts a FlightServer that binds to the network interface, e.g.:\n```\nserver\u00a0=\u00a0FlightServer(\"0.0.0.0\",\u00a0location\u00a0=\u00a0\"grpc+tcp://0.0.0.0:5005\")\nserver.serve()\n````\n* Step 2:\nThe attacker can then send malicious pickle dump data through\u00a0the Flight client connection. The provided PoC demonstrates how an attacker can execute \"ls -l\" command:\n\n```python\nclass RCE:\ndef __reduce__(self):\nimport os\nreturn (os.system, (\u0027ls -l\u0027,))\n\nimport pickle\naction_body = pickle.dumps(RCE())\naction = pyarrow.flight.Action(\"set_configs\", action_body)\n```\n\nWhen the\u00a0server receives this payload, the\u00a0FlightServer.do_action()\u00a0method calls\u00a0pickle.loads(action.body.to_pybytes())\u00a0on line 283,\u00a0which triggers the execution\u00a0of the malicious code through Python\u0027s pickle deserialization mechanism. The provided\u00a0flight_client.py\u00a0demonstrates a complete\u00a0PoC that connects to the vulnerable server and executes arbitrary commands through\u00a0the pickle deserialization vulnerability.\n\nWhen the vulnerability is reproduced, python flight.py can be run to init the server and then run flight_client.py. There is an attack demo in the attachment.\n\n### Impact\n\nRemote code execution on the\u00a0victim\u0027s machine over the network. Once the victim starts\u00a0the FlightServer with network binding (especially\u00a00.0.0.0), an attacker on\u00a0the network\u00a0can gain arbitrary code execution by connecting to the Flight endpoint\u00a0and sending crafted pickle payloads through the\u00a0set_configs\u00a0action. This vulnerability allows\u00a0for:\n\n- Complete system compromise\n- Data exfiltration\n- Lateral movement within the network\n- Denial of service attacks\n- Installation of persistent backdoors\n\n### Mitigation\n\n1. **Replace unsafe deserialization**: Replace `pickle.loads()` with safer alternatives such as:\n - JSON serialization for simple data structures\n - Protocol Buffers or MessagePack for complex data\n - If pickle must be used, implement a custom `Unpickler` with a restricted `find_class()` method that only allows whitelisted classes\n\n2. **Network security**: \n - If the service is intended for internal use only, bind to localhost (`127.0.0.1`) instead of `0.0.0.0`\n - Implement authentication and authorization mechanisms\n\n3. **Security warnings**: When starting the service on public interfaces, display clear security warnings to inform users about the risks.",
"id": "GHSA-f74j-gffq-vm9p",
"modified": "2025-10-17T21:32:52Z",
"published": "2025-10-17T18:08:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/marsupialtail/quokka/security/advisories/GHSA-f74j-gffq-vm9p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62515"
},
{
"type": "PACKAGE",
"url": "https://github.com/marsupialtail/quokka"
},
{
"type": "WEB",
"url": "https://github.com/marsupialtail/quokka/blob/master/pyquokka/flight.py#L283"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "pyquokka is Vulnerable to Remote Code Execution by Pickle Deserialization via FlightServer "
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.