| विवरण | NOT a duplicate of CVE-2026-5536 / VDB-355289. That entry covers the function sendMessage of the file grpc_server.py of the gRPC server component, versions 0.8.0-0.8.9. FedML ships nine communication backends (grpc, mpi, mqtt, mqtt_s3, mqtt_s3_mnn, mqtt_thetastore, mqtt_web3, s3, trpc). This report concerns a different function in a different file on a different transport, and is not remediated by any fix to grpc_server.py. Verified present in the current release 0.9.6.
AFFECTED FUNCTION: S3Storage.read_model in fedml/core/distributed/communication/s3/remote_storage.py (line 313). COMPONENT: MQTT+S3 communication backend.
The S3 object key is taken directly from the incoming MQTT message payload and used without validation to fetch and deserialize a remote object.
Step 1, in fedml/core/distributed/communication/mqtt_s3/mqtt_s3_multi_clients_comm_manager.py, function _on_message_impl: the handler parses the MQTT payload with json.loads, then at line 203 reads s3_key_str = payload_obj.get(Message.MSG_ARG_KEY_MODEL_PARAMS, "") and at line 226 passes it to self.s3_storage.read_model(s3_key_str). The key is not validated: no prefix constraint, no ownership check, and no binding to the sender_id supplied in the same payload.
Step 2, in remote_storage.py read_model: the object is fetched with aws_s3_client.download_fileobj(Bucket=self.bucket_name, Key=message_key, ...) and then deserialized as: try torch.jit.load(temp_file_path) except -> torch.load(temp_file_path, pickle_module=dill) at line 313.
Two properties make this exploitable rather than merely unsafe. First, supplying an explicit pickle_module forces the legacy deserialization path: torch.load defaults to weights_only=True from torch 2.6, but that safe mode is incompatible with a custom pickle_module, so the ecosystem-wide hardening does not apply to this call site. Second, dill is strictly more permissive than pickle and reconstructs callables and types that pickle refuses. The preceding torch.jit.load is not a mitigation: it is wrapped in try/except, so a crafted pickle payload fails it and falls through to the dill branch, which is the path an attacker's payload reaches by construction.
SAME SINK REACHED FROM THREE FURTHER BACKENDS, each taking the storage key from its own MQTT payload: mqtt_thetastore_comm_manager.py line 196 (theta_storage.read_model), mqtt_web3_comm_manager.py line 196 (web3_storage.read_model), and s3/remote_storage_mnn.py line 36 (s3_storage.read_model). One root cause, four affected backends.
TRANSPORT IS UNENCRYPTED: fedml/core/distributed/communication/mqtt/mqtt_manager.py calls username_pw_set(user, pwd) then connect(host, port, keepalive). tls_set() is never invoked anywhere in the MQTT module (grep over core/distributed/communication/mqtt/ returns zero matches), so broker credentials and all payloads traverse the network in cleartext.
EXPLOITATION: the attacker places an object containing a crafted dill payload in the configured S3 bucket (uploading model objects is the normal participant workflow), then publishes an MQTT message whose MSG_ARG_KEY_MODEL_PARAMS field names that key. The receiving node downloads and deserializes it, executing the payload with the privileges of the training process.
IMPACT: arbitrary code execution on the aggregator and on any participant processing the message, typically GPU training nodes holding cloud credentials and training data. Federated learning exists so that participants need not trust one another with their data, so a participant obtaining code execution on the aggregator defeats the security premise of the deployment rather than a single host.
SUGGESTED CVSS v3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8). PR:L reflects that MQTT broker credentials are required in the default configuration. I have deliberately not claimed PR:N: credentials are shared federation-wide and the transport has no TLS, which would support PR:N, but that rests on the attacker's network position rather than on the code, so I have left it out of the vector and noted it here instead. CWE-502.
VERIFICATION STATUS, stated explicitly: all of the above was verified by reading the released fedml 0.9.6 wheel from PyPI - the payload-to-sink data flow, the absence of key validation, pickle_module=dill at remote_storage.py:313, the absence of tls_set in the MQTT module, and all three sibling call sites. Line numbers correspond to that release. NO PROOF-OF-CONCEPT WAS EXECUTED: doing so requires a live MQTT broker, an S3 bucket and a PyTorch installation, which were not available in the analysis environment. I am stating this rather than implying a tested exploit. CVE-2026-5536 already establishes that this deserialization pattern is real and remotely reachable in this codebase.
REMEDIATION: no vendor fix exists. Note that weights_only=True is not a drop-in fix here, because the project also writes with dill (remote_storage.py line 131, torch.save(model, path, pickle_module=dill)), so enabling the safe mode would break the serialization round-trip. A correct fix requires either a safe serialization format for these payloads, or authenticated integrity protection over the stored object combined with binding the object key to the authenticated sender.
VENDOR CONTACT: https://github.com/FedML-AI/FedML/issues/2267 opened 2026-08-01 requesting a private reporting channel (the repository has private vulnerability reporting disabled, /security/advisories/new returns 404, and there is no SECURITY.md). No response at time of submission. That issue deliberately contains no technical detail.
Discoverer: Mohammad Adnan (CyStack). |
|---|