Symfony Serializer is affected by CVE-2026-118515: according to the Symfony advisory of 4 November 2026, the Serializer could build UploadedFile objects from request data that point at any server file readable by PHP. Affected Serializer versions: before 5.4.56; from 6 before 6.4.50; from 7 before 7.4.23; from 8 before 8.1.11. Fixed in 5.4.56, 6.4.50, 7.4.23, and 8.1.11.
The issue hits every maintained branch whenever untrusted JSON or form data is deserialized into a type that holds an UploadedFile property — including Symfony 8.1’s common #[MapRequestPayload] + DTO pattern. No real upload is required. This article stays with impact and upgrade guidance from the advisory; no exploit steps, no payloads, no reproducible attack procedures.
Symfony Serializer: What Went Wrong
DataUriNormalizer built \SplFileInfo, \SplFileObject, and HttpFoundation File objects from data URIs — for those exact types only. A property typed as a subclass such as UploadedFile fell through to ObjectNormalizer, which instantiated it via its constructor from denormalized data, including path, original name, and the test flag. Untrusted input could therefore make the application treat any readable server file as an upload.
Per the advisory: with test: true, UploadedFile::isValid() skips is_uploaded_file() and move() falls back to rename(). Code that reads the file without calling isValid() does not even need the flag. Depending on what the app does next, this can expose any PHP-readable file (for example when uploads are stored and served back), move such a file when move() is called as the upload docs show, or reveal whether a path exists. Assert\File does not stop it, because it validates the real server file.
Fix and Protected Configuration
After the patch, DataUriNormalizer handles every subclass of \SplFileInfo: it passes through an instance of the expected type (as request files are) and rejects other data with NotNormalizableValueException, which #[MapRequestPayload] turns into a 422. File, \SplFileInfo, and \SplFileObject are still built from data URIs when the type is spelled as their ::class constant. Other spellings (leading backslash, different case, class alias) are handled like subclasses.
Important: a Serializer built without DataUriNormalizer ahead of the object normalizer does not get this protection. The serializer configured by FrameworkBundle has it. Patches are available for branch 5.4 and 6.4 (forward-ported to 7.4, 8.1, and 8.2). Credits: reported by Oliver Wenzel, fixed by Nicolas Grekas; CVE assignment help from Bruno Dias and Miguel Neves (Checkmarx).
What Teams Should Do Now
Upgrade the Serializer component (or the framework meta-package) to 5.4.56 / 6.4.50 / 7.4.23 / 8.1.11 or newer and verify lockfiles. Inventory DTOs and controllers with UploadedFile properties and #[MapRequestPayload]. Check custom serializer stacks so DataUriNormalizer sits ahead of the object normalizer. Align deployment and changelog with the advisory versions — not a full security review substitute, but the documented minimum.
Related November patch on code404zero: Symfony HTTP Foundation — two fixes, November 2026 (3466). Separate keyword and CVE; same patch wave. Further security context: GPT-6 Cyber and Patch Gap / GLM 5.3 — different surfaces, same upgrade pressure.
Framing Without Hype
Symfony Serializer CVE-2026-118515 is a deserialization / upload-mapping flaw with a clear fix path. The advisory states impact (read/move of readable server files, path existence) and resolution. code404zero does not publish reproduction steps or sample payloads beyond what the public advisory itself uses to describe the problem.
Bottom line: On 4 November 2026 Symfony published CVE-2026-118515 for the Serializer. Upgrade to 5.4.56, 6.4.50, 7.4.23, or 8.1.11; use the FrameworkBundle serializer or verify DataUriNormalizer order. Primary source: the Symfony blog advisory.
Separate From the HTTP Foundation Wave
Yesterday’s HTTP Foundation fixes and this Serializer CVE share the November 2026 window and Symfony’s security pipeline, but they are different components and keywords. Readers tracking both should version Serializer and HTTP Foundation independently — a framework bump often covers both; a targeted component update may not. Changelog plus composer show symfony/serializer / symfony/http-foundation remain the sources of truth.
For AppSec and platform teams: ticket with advisory URL, target versions, and lockfile proof; staging tests of upload/DTO paths after the patch; unexpected 422 responses on MapRequestPayload after the fix can be expected and desirable if invalid payloads were previously accepted silently.
Practical Checklist
1) Move Serializer to fixed versions. 2) Document custom normalizer order. 3) List every UploadedFile DTO mapping. 4) Coordinate with the November HTTP Foundation patches. 5) Do not mirror public PoCs into tickets — the advisory link is enough. That keeps Symfony Serializer CVE-2026-118515 an upgrade topic, not an exploit guide.
Component Upgrade vs Framework Bump
Many projects pin symfony/serializer indirectly via symfony/framework-bundle or the symfony/symfony meta-package. A targeted component update to 5.4.56 / 6.4.50 / 7.4.23 / 8.1.11 covers CVE-2026-118515 when the loaded serializer includes the patched DataUriNormalizer. Teams that wire normalizers manually must check order explicitly — the FrameworkBundle default is not every custom container.
QA after the patch: exercise MapRequestPayload flows with file properties in staging; expect invalid denormalized file structures to yield 422 instead of silently constructing an UploadedFile. Legitimate multipart uploads should keep working because request files are passed through as instances of the expected class. Regressions are more likely in custom normalizers and in tests that intentionally build test UploadedFiles — align test doubles with the new normalizer path.
Ticket documentation: advisory URL, before/after composer show, pointer to the related HTTP Foundation article, explicit “no PoC” note. That keeps handling of Symfony Serializer CVE-2026-118515 auditable and defensive.
Why the Keyword Is Serializer, Not Only the CVE ID
Search and reading flow: developers often query the component plus “security” or “UploadedFile”, not only the CVE number. We keep CVE-2026-118515 in the title and body while focusing the keyword and H2 on Symfony Serializer, parallel to yesterday’s HTTP Foundation piece — clear separation without cannibalization.
For automated Composer updates: wire Symfony security advisories and Packagist notices into CI so Serializer below the fixed versions fails the build. That does not replace a manual review of custom normalizers, but it shortens time-to-patch on the default stack. After deploy, briefly watch for 422 noise on payload mapping and share it with app teams.
Comms Note for Security and Dev Teams
Internal advisories should carry the CVE ID, fixed versions, and a link to the Symfony blog — without mirroring request examples from the advisory into public channels when that unnecessarily widens exposure. Private tickets need only the link. Developers newly adopting MapRequestPayload should read the upload docs alongside the patched normalizer path. Symfony Serializer stays a patch-and-verify topic: bump versions, check custom stacks, validate staging, then roll out.
