Five transitive advisories in uv.lock: cryptography and ray

[ajbarea]

Five open Dependabot alerts, all against uv.lock — every one is a transitive dependency pulled in by flwr / flwr[simulation], so none is listed in pyproject.toml and none is reachable by editing a direct pin.

package	severity	first patched	advisory
cryptography	high	50.0.0	PKCS#7 EnvelopedData decryption exposes a Bleichenbacher oracle through distinguishable errors and timing
cryptography	high	49.0.0	Duplicate self-signed intermediates can cause exponential path-building
cryptography	high	48.0.1	Vulnerable OpenSSL included in cryptography wheels
cryptography	medium	49.0.0	Verifier accepts wildcard DNS names, allowing escape from permittedSubtrees
ray	high	2.56.0	Arbitrary code execution via ray.data.read_webdataset default decoder (pickle.loads, torch.load(weights_only=False))

cryptography >= 50.0.0 clears all four of its advisories.

The ray advisory is in ray.data.read_webdataset, which this app does not call — ray is here only as the flwr simulation backend. Still worth taking, since the fix is a lockfile bump rather than a code change.

Recommended fix

Both are transitive, so bump them in the lock without touching pyproject.toml:

uv lock --upgrade-package cryptography --upgrade-package ray
uv sync --extra hf --extra torch
make lint && make test

Then confirm the resolved versions clear the floors:

grep -A1 'name = "cryptography"' uv.lock
grep -A1 'name = "ray"' uv.lock

If flwr 1.36's own constraints hold either below its floor, the bump belongs with the next flwr upgrade instead — flwr-version-target in pyproject.toml is 1.36.0, and pin-check guards that.

Worth checking afterwards whether dependabot.yml should group these: the existing config auto-merges patch updates only, and each of these is a major bump, which is why they have accumulated rather than landing on their own.