Symfony Serializer: Fake UploadedFile Data Can Point at Any Server File

Published as "CVE-2026-118515: The Serializer Builds UploadedFile Objects From Request Data, Letting a Client Point an Upload at Any Server File"

high Symfony Symfony components · Last reviewed Nov 6, 2026

CVE: CVE-2026-118515
GHSA: None
Packagist: PKSA-grh8-hvfp-h9pf
Reported: Nov 4, 2026

Lets a client make an app treat any server file as an upload in apps that deserialize request data into UploadedFile properties.

Affected and fixed versions

In 2 packages: symfony/serializer and symfony/symfony. Find the row for the version you run, and update to the release next to it.

If you run	Update to	Support
8.1.0 – 8.1.10	8.1.11	Supported
7.4.0 – 7.4.22	7.4.23	Supported
6.4.0 – 6.4.49	6.4.50	Supported
5.4.0 – 5.4.55	5.4.56	Supported

Show 16 older branches, no longer supported

8.0.0 – 8.0.x	8.1.11
7.0.0 – 7.0.x	7.4.23
7.1.0 – 7.1.x	7.4.23
7.2.0 – 7.2.x	7.4.23
7.3.0 – 7.3.x	7.4.23
6.0.0 – 6.0.x	6.4.50
6.1.0 – 6.1.x	6.4.50
6.2.0 – 6.2.x	6.4.50
6.3.0 – 6.3.x	6.4.50
2.0.0 – 2.x	5.4.56
3.0.0 – 3.x	5.4.56
4.0.0 – 4.x	5.4.56
5.0.0 – 5.0.x	5.4.56
5.1.0 – 5.1.x	5.4.56
5.2.0 – 5.2.x	5.4.56
5.3.0 – 5.3.x	5.4.56

Upgrade

Run the line for the branch you are on. 1 other package listed above is affected too; update it the same way.

composer require symfony/serializer:^8.1.11
composer require symfony/serializer:^7.4.23
composer require symfony/serializer:^6.4.50
composer require symfony/serializer:^5.4.56

What this means

A client can make your app treat any file on the server as if it were an upload, without uploading anything. Depending on what your app does with uploads, it could expose files like .env, move them, or reveal whether a path exists.

The Serializer built UploadedFile objects straight from request data, including the file path.

Who is affected

Apps that deserialize untrusted data with symfony/serializer (also part of symfony/symfony) into a property typed UploadedFile, or another subclass of \SplFileInfo. The Symfony advisory says this includes #[MapRequestPayload] DTOs with an UploadedFile property, which is how uploads are mapped in Symfony 8.1, with JSON or form bodies.

Assert\File doesn't stop it, because it checks the real server file. Apps that never deserialize client data into these types aren't exposed.

What to do

Update to 5.4.56, 6.4.50, 7.4.23 or 8.1.11. If you're on 8.0, update to 8.1.11. The fix (5.4, 6.4) makes DataUriNormalizer handle these types and reject anything that isn't a real file object, which #[MapRequestPayload] turns into a 422 response. A serializer you build yourself without DataUriNormalizer before the object normalizer doesn't get this protection.

The same release fixes GHSA-pxj9-jh84-vhm5, a related file read through DataUriNormalizer.

Reported by Oliver Wenzel.

Check your app with an agent

Paste this into a coding agent that can read your project, such as Claude Code, Codex or Amp. It checks your composer.lock against the versions above and tells you what to update, without changing anything.

Check whether the PHP project you have access to is affected by this security advisory, and tell me what to update. Do a read-only check: don't edit files, don't run composer update or composer require, and don't try to reproduce the flaw.

Advisory: Symfony Serializer: Fake UploadedFile Data Can Point at Any Server File (CVE-2026-118515)
Details: https://phpnews.net/security/symfony/cve-2026-118515

Affected versions, as Composer constraints:
- symfony/serializer, symfony/symfony: >=2.0.0,<3.0.0|>=3.0.0,<4.0.0|>=4.0.0,<5.0.0|>=5.0.0,<5.1.0|>=5.1.0,<5.2.0|>=5.2.0,<5.3.0|>=5.3.0,<5.4.0|>=5.4.0,<5.4.56|>=6.0.0,<6.1.0|>=6.1.0,<6.2.0|>=6.2.0,<6.3.0|>=6.3.0,<6.4.0|>=6.4.0,<6.4.50|>=7.0.0,<7.1.0|>=7.1.0,<7.2.0|>=7.2.0,<7.3.0|>=7.3.0,<7.4.0|>=7.4.0,<7.4.23|>=8.0.0,<8.1.0|>=8.1.0,<8.1.11

Fixed releases on branches that still get security fixes:
- 8.1.0 – 8.1.10: update to 8.1.11
- 7.4.0 – 7.4.22: update to 7.4.23
- 6.4.0 – 6.4.49: update to 6.4.50
- 5.4.0 – 5.4.55: update to 5.4.56

1. Find every composer.lock in the project outside vendor/ (a monorepo can have one per app) and read the installed version of each package above. Packages installed as dependencies of other packages count too.
2. Compare each installed version with its constraint: "|" separates alternative ranges, and "," means both bounds apply.
3. For each affected install, read "What this means" at https://phpnews.net/security/symfony/cve-2026-118515 and check whether the project meets the conditions it describes (a feature in use, a config value, a driver). Say which conditions you could check and which you couldn't.
4. Report a table: lock file | package | installed version | affected (yes, no or unknown) | conditions met (yes, no or unknown) | update to | evidence. For each affected package, give the command that would fix it, without running it: composer update <package> --with-dependencies when it is only installed as a dependency of another package, or composer require with the fixed version when composer.json requires it directly. If the installed version is on a branch with no fixed release listed, say it needs a move to a newer branch.

Sources

← All Symfony advisories