Skip to main content

CVE-2026-118515sensiolabs symfony external control of a file name

Schedule itHigh8.4EPSS not scored yet

CVE-2026-118515 is a external control of a file name in sensiolabs symfony, rated high (8.4 on CVSS 4.0).

Why this priority: High severity, with no exploitation signal yet.

Published · Updated · NVD status: Awaiting Analysis

What it is

Input decides which file the software opens, so a caller can point it elsewhere.

How it is reached

An attacker can exploit it over the network, without an account, and nobody has to click anything. Success also depends on conditions the attacker does not fully control.

What an attacker gains

A successful attack can read the data it protects and take it offline. In practice, this kind of flaw lets an attacker read or write files outside the folders the service meant to expose.

Is it being exploited?

There is no public report of exploitation yet.

What to do

  1. No fixed version is listed yet. Find every place sensiolabs symfony runs, watch the references for a fix, and plan a replacement if it is no longer supported.
  2. While there is no fix, keep it off the internet or behind a VPN, allowlist or authenticating proxy.

Description from NVD

The Symfony Serializer component DataUriNormalizer handles only the exact types SplFileInfo, SplFileObject, and File, so for a property typed with a subclass such as UploadedFile, ObjectNormalizer instantiates the object through its constructor from attacker-controlled data, including the file path. This allows an arbitrary file on the server to be treated as an uploaded file in Symfony versions prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11.

A request body such as {"image": {"path": "/path/to/project/.env.local", "originalName": "a.png", "test": true}} makes the application handle any file on the server as an upload, without the file being sent. With test: true, UploadedFile::isValid() skips is_uploaded_file() and move() falls back to rename(). Assert\File does not prevent this because it validates the file at the attacker-chosen path, which exists on the server. Any code that deserializes untrusted data into a type that holds such a property is affected. That includes #[MapRequestPayload] on a DTO with an UploadedFile property, which is how uploads are mapped in Symfony 8.1; a single unauthenticated request with a JSON or form body is enough. Depending on what the application does with the upload, this can expose any file readable by PHP (for instance, when uploads are stored and served back), move any such file when move() is called, and reveal whether a path exists.

A serializer built without DataUriNormalizer ahead of the object normalizer is not protected by the fix; the serializer configured by FrameworkBundle is.

What this means for your architecture.

A CVE names a product. Whether it matters depends on where that product sits in your systems: what reaches it, which trust boundary it guards and what it can reach once compromised. Veriom maps your components, their relationships and your trust boundaries from your code, cloud and delivery evidence, so you can see where a component like this sits. The radar itself does not look at your systems.

Components it touches

  • File storage the service can read or write. The flaw sits between the application and the file system it can reach.

Trust boundaries in play

  • Internet-facing entry points. No account is needed. Any instance reachable from outside your perimeter, through a load balancer, gateway, VPN or exposed admin port, is in scope.
  • Between the application and the file system it can reach. An attacker who crosses it can read or write files outside the folders the service meant to expose.

Questions to answer about your own systems

  • Where does sensiolabs symfony run in your systems, and at which version?
  • Which of those instances can be reached from the internet or partner networks?
  • What can it reach once compromised: which data stores, secrets and services?

Sources

  • CVE records and CVSS scores from the NVD CVE API. This product uses the NVD API but is not endorsed or certified by the NVD.
  • Exploitation status from CISA’s Known Exploited Vulnerabilities catalog.
  • Exploit likelihood from FIRST’s Exploit Prediction Scoring System (EPSS), refreshed daily.
  • Explanations are written by Veriom from fixed templates over each record’s data, not by a person reviewing each CVE. Descriptions are quoted from the records as published.