CVE-2024-8019 is a critical (CVSS 9.1) flaw in pytorch-lightning 2.3.2. On a Windows host, the LightningApp upload_file endpoint lets an attacker write or overwrite files by supplying a crafted filename, which could lead to code execution. The upstream fix removed the Lightning App code, so upgrade past that change.
What's affected
The record names lightning-ai/pytorch-lightning version 2.3.2. The vulnerable component is LightningApp, specifically the /api/v1/upload_file/ endpoint, and the description says it applies when the app runs on a Windows host.
The reference commit is titled "Remove the lightning app code" and removes the source, tests and docs for that app framework from the repository. So the upstream response was to delete the vulnerable component rather than patch the endpoint. That tells you something practical: if you do not use LightningApp, you likely do not run the vulnerable code, and a release that no longer ships it is the fix.
We could not confirm the exact first release without the app code from the sources we could read. Check the PyTorch Lightning release notes for the version that dropped it.
How to check if you're exposed
Check which version of the package your environments have installed.
pip show pytorch-lightning
pip list | grep -i pytorch-lightning
Run the commands inside each virtual environment, container image and notebook environment that might use it, because the system Python often differs from the project one. For a lockfile or requirements file, search for pytorch-lightning and read the pinned version.
Search your code for LightningApp or lightning.app imports. Many teams use the training library only and never run the app framework. Also check whether any LightningApp service runs on a Windows host and whether it is reachable from outside a trusted network.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan can read a dependency manifest and flag known vulnerable versions without installing anything.
What to do now
- Find installs of pytorch-lightning at 2.3.2 and nearby versions.
- Search for LightningApp usage and any running upload endpoint.
- Upgrade to a release that no longer includes the Lightning App framework, after confirming in the release notes.
- Do not expose LightningApp services to untrusted networks.
- Run any remaining app service under a low privilege account on a locked down folder.
Why it matters
The weakness is an upload handler that trusts the file name from the client. File names can carry directory parts, and on Windows there are extra surprises, such as backslashes, drive letters and reserved names, so code written with Linux paths in mind can behave differently there.
The class in the record is unrestricted upload of a dangerous file type. Writing a file to a chosen location is often enough to run code, for example by replacing a script that a service starts later. The safe pattern is to ignore client file names, generate your own, and store uploads in a folder that cannot execute code.
The weakness class is CWE-434: Unrestricted Upload of File with Dangerous Type. The CVSS vector in the record is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, which scores 9.1. This CVE is not listed in the CISA Known Exploited Vulnerabilities catalog at the time of writing.
Quick check
Does this affect the plain training library?
The record describes the LightningApp upload endpoint. If you only use the training library, you are probably not using that code, but check your imports.
Is Windows required?
The record says the issue occurs when the app runs on a Windows host.
Sources
Last reviewed: 19 October 2026.
