The Symfony Serializer component’s DataUriNormalizer protects only the exact types SplFileInfo, SplFileObject, and File. When a property is typed with a subclass such as UploadedFile, the ObjectNormalizer constructs an UploadedFile instance from the request data, passing the supplied file path to its constructor. If an attacker supplies any path to a server file, that file becomes treated as an uploaded file without being sent. With the test flag set to true, isValid() bypasses is_uploaded_file() and the move() method falls back to rename(), allowing the attacker to read, move, or otherwise manipulate any file readable by PHP. This can expose sensitive configuration files, enable deletion or relocation of files, or cause the application to serve the file, resulting in substantial confidentiality and integrity impacts.

Symfony framework versions prior to 5.4.56, 6.4.50, 7.4.23, and 8.1.11 are affected. Any application that uses the Serializer component and accepts untrusted data into a property typed as UploadedFile—such as DTOs annotated with #[MapRequestPayload]—falls into the risk zone. Custom serializers that do not load DataUriNormalizer before the ObjectNormalizer are also vulnerable, while the default configuration provided by FrameworkBundle is protected by the fix.

The flaw manifests when a request contains a property of type UploadedFile, so a single unauthenticated request with the desired file path is sufficient to trigger the vulnerability. Once the object is constructed, application logic may store or serve the ‘uploaded’ file, exposing its contents, and if move() is called the file may be relocated. No elevated privileges are required; any PHP‑readable file can be targeted. The CVSS score of 8.4 reflects the significant impact, while the absence of EPSS data indicates no current exploitation statistics, yet the attack surface via HTTP or JSON remains large. The vulnerability is not listed in CISA KEV, so administrators should treat this as a high‑priority issue.