CVE-2024-5452: Critical RCE in PyTorch Lightning 2.2.1 via deepdiff

CVE-2024-5452 is a Critical (CVSS 9.8) remote code execution flaw in the lightning-ai/pytorch-lightning library version 2.2.1. A serialized deepdiff Delta object sent to a default endpoint can bypass the restriction on dunder attributes. The record names no fixed release, so check the project's advisory.

What's affected

• Product: the pytorch-lightning Python package from Lightning AI, specifically self-hosted applications that use its app framework, per the record.
• Affected version: 2.2.1 is the version the record names. The CPE is open ended, so do not assume other versions are safe.
• Fixed version: not stated in the record. The referenced commit is titled "Remove the lightning app code", which suggests the maintainers dealt with it by removing that code rather than by patching the endpoint. That is my reading of the commit title, not a statement from an advisory. Confirm the release that carries it on the project's release notes.
• Severity: Critical, CVSS 9.8, with network access, no privileges and no user interaction.
• Exploitation: the record's KEV flag is false. No source I read reports exploitation.

How to check if you're exposed

Start by finding out whether your code uses the Lightning app framework at all. Most teams use pytorch-lightning only for training loops, and the record's concern is the app server with its delta endpoint, which it says is enabled by default.

List the installed version and the packages involved:

pip show pytorch-lightning lightning deepdiff
pip list 2>/dev/null | grep -i -E "lightning|deepdiff"

Then search your code for imports of the app module, such as lightning.app. If nothing in production uses it, the vulnerable path is not live in that service, though the package may still be present in the image.

A reachability check helps here. A dependency scan tells you the package is installed, and reachability analysis tells you whether your code can reach the affected function. You can run the free in-browser scan at gold.safeguard.sh/scan on your lockfile to find every project that pulls it in.

What to do now

1. Inventory every service and notebook image that installs pytorch-lightning or lightning, and record versions.
2. Check the project's release notes and security advisory for the version that removes or fixes the app code, and upgrade.
3. If you run a Lightning app server, take it off untrusted networks until it is patched. The delta endpoint is the described attack surface.
4. Rebuild container images after upgrading so the old wheel does not linger in a cached layer.
5. Rotate secrets and credentials available to any host that ran a reachable app server, in case it was probed.

Why it matters

The record lists CWE-915, improperly controlled modification of dynamically determined object attributes, and CWE-913, improper control of dynamically managed code resources. The framework used deepdiff Delta objects to change application state from frontend actions. A whitelist limited what a delta could touch, but the record says special attributes could slip past it, which allows writes to objects the author never meant to expose.

Once an attacker can write arbitrary attributes in a running Python process, reaching other modules and classes is a short step to code execution. The key lesson is that deserializing data from the network and then applying it to live objects needs a hard boundary, and an allow list of names is a thin one.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Lightning AI commit 330af38, Remove the lightning app code
• NVD record data for CVE-2024-5452, as supplied in the batch record
• huntr bounty page linked from the record (did not render without JavaScript, so its contents are not used here)

Last reviewed: 19 October 2026.