Short answer
On 4 November 2026 Symfony published a batch of security advisories fixed in 5.4.56, 6.4.50, 7.4.23 and 8.1.11. Five are rated high: a client can read any server file through the Serializer, crash a worker with a 93-byte YAML document, steal API credentials from HTTP clients, log in as another user with a crafted certificate, or escape a base directory through file paths. Upgrade every Symfony application to those versions this week, starting with public APIs.
- 5 - high-severity flaws in this signal set, all fixed in the same releases
- 8.7 - highest CVSS v4 score: the YAML parser denial of service
- 0 - logins needed for four of the five
- 4 - maintained branches patched: 5.4, 6.4, 7.4 and 8.1
Symfony is the PHP framework behind a large share of business applications, and its components also sit inside other products, from Drupal to Laravel packages and in-house tools. On 4 November 2026 the Symfony team published a batch of security advisories alongside new releases of every maintained branch. This guide covers the five high-severity flaws our newsroom flagged for immediate action, what each one means in business terms, who is exposed and how to decide what to patch first.
What was fixed, in plain English
FlawComponentWhat an attacker can doSeverityDataUriNormalizer reads local files (CVE-2026-121623)SerializerSend a crafted value such as DATA: with capital letters and read any file the server can read, including configuration and secretsHigh, CVSS 8.2YAML parse times explode (CVE-2026-123792)YamlSend a tiny YAML or JSON document that keeps a PHP worker busy until its time limit; the advisory’s 93-byte example took 15 secondsHigh, CVSS 8.7ScopingHttpClient leaks credentials (CVE-2026-121971)HttpClientMake the application send its API tokens or certificates to a server the attacker controls, if they influence part of a URLHigh, CVSS 8.2X.509 login spoofing (CVE-2026-118513)SecurityLog in as any user, including an administrator, with a certificate from a trusted CA and a crafted name field; an incomplete fix for an earlier flawHigh, CVSS 7.7Filesystem Path escapes its base directoryFilesystemRead or write files outside an allowed folder when the application checks user paths with Symfony’s Path helpersHigh, no CVSS listed
The same release also fixes a closely related Serializer flaw (CVE-2026-118515), where a request can point an UploadedFile at any server file, and several other advisories, including issues in URL generation, trusted forwarded headers and the JsonPath component. Because they share the same fixed versions, one upgrade covers all of them.
Why decision makers should care
Four of the five need no account at all. Two can expose files such as environment files, private keys or database credentials, which turns a framework bug into a data breach. One leaks the credentials your application uses to call payment, CRM or cloud APIs, so the damage can spread to systems outside the application. One lets an attacker impersonate any user, and one can take a public API offline with very little traffic. None of the advisories reports exploitation in the wild at the time of writing, but detailed descriptions and example payloads are public, which shortens the time before attackers try them.
A five-minute exposure check
Before any upgrade work starts, a short conversation with the team responsible for each application gives you a rough risk rating. Each “yes” below raises the priority.
QuestionWhy it mattersAffected flawIs the application reachable from the internet without logging in?Four of the five flaws need no accountAll except X.509 loginDo any endpoints map request bodies into objects, or deserialize client data?This is the path to reading server filesSerializer file readIs the symfony/yaml package installed, and do APIs accept any format?Small requests can tie up workersYAML parser slowdownDoes the application call other services with stored tokens or certificates?Those credentials could be sent elsewhereHTTP client credential leakDo users or systems log in with client certificates?An attacker with a trusted certificate could impersonate othersX.509 login spoofingDo features build file paths from user input or third-party packages?Files could be read or written outside their folderFilesystem path escape
An application with three or more “yes” answers belongs at the top of the list. One with none still needs the upgrade, but it can follow the normal release schedule rather than an emergency one.
Fixed versions and what they mean for your upgrade
You runUpgrade toEffortSymfony 5.45.4.56 or laterPatch release: usually a routine dependency updateSymfony 6.0 to 6.36.4.50 or laterMinor-version upgrade: test before releaseSymfony 6.46.4.50 or laterPatch releaseSymfony 7.0 to 7.37.4.23 or laterMinor-version upgrade: test before releaseSymfony 7.47.4.23 or laterPatch releaseSymfony 8.08.1.11 or laterMinor-version upgradeSymfony 8.18.1.11 or laterPatch release
The advisories also note small behaviour changes that teams should test. #[MapRequestPayload] no longer decodes YAML and CSV unless the endpoint lists them in acceptFormat, a slash-separated certificate DN must now start with a slash, and invalid file data sent to the Serializer is rejected with a 422 error instead of being processed.
Check and upgrade
# Which Symfony versions does this application use?
composer show "symfony/*"
# Does Composer know of advisories affecting the installed packages?
composer audit
# Update Symfony packages within your current constraints
composer update "symfony/*" --with-all-dependencies
# Confirm the result, then run your test suite before deploying
composer show symfony/serializer symfony/yaml symfony/http-client symfony/security-http symfony/filesystem
How to decide what to patch first
- **Exposure: **is the application reachable from the internet, and do anonymous users send it structured data?
- **Data at stake: **what could a file read expose: configuration, keys, customer records?
- **Credentials held: **which external systems could an attacker reach with the tokens this application stores?
- **Upgrade distance: **a patch release can go out in a day; a move from an unsupported branch needs planning and testing.
- **Ownership: **vendor products need the vendor’s update, so ask suppliers for their timeline now.
A practical target for most organisations is to patch internet-facing applications within a few days and everything else within two weeks, with any exception approved by a named owner. If an application can’t be upgraded quickly because it sits on an unsupported branch, treat that as a risk decision for leadership, not a technical detail: every future Symfony security release will raise the same problem until the application is moved to a maintained branch.
If you also run PHP itself on older versions, our guide to the October PHP2Shell release covers the runtime side; framework and runtime patches are separate, and both are needed.
If you suspect an attack: what to check
Most organisations will patch before anyone tries these flaws against them. But the descriptions and example payloads are public, so it is worth checking whether anything happened between 4 November and your upgrade, especially for internet-facing APIs.
FlawSigns to look forIf you find themSerializer file readRequest bodies containing DATA: or Data: with unusual capitalisation, or file paths with ../ segmentsAssume the files the process could read were exposed; rotate secrets in configuration and environment filesYAML parser slowdownSmall requests with YAML or JSON bodies that ran until the PHP time limit; bursts of worker timeoutsBlock the source, restrict accepted formats on that endpoint and patchHTTP client credential leakOutbound requests from the application to hosts it doesn’t normally callRevoke and reissue the API tokens or certificates that client usesX.509 login spoofingCertificate logins whose subject name contains escaped commas, slashes or an unexpected email addressReview what those accounts did, revoke the certificates and reset affected sessionsFilesystem path escapeFiles written outside upload, export or asset folders; unexpected files in the public directoryRemove them, check for web shells and review the feature that wrote them
Rotating credentials is the step most often skipped. If an application could have read its own configuration, every secret in it, from database passwords to payment API keys, should be treated as exposed until it is replaced.
Questions to ask software vendors and agencies
Many organisations run Symfony without knowing it, inside a product bought from a vendor or an application built and hosted by an agency. Those suppliers have to ship the update, and their timelines become your exposure. Ask them directly:
- **Do you use Symfony components, **and which versions are in the release we run?
- **When will you ship an update **that includes 5.4.56, 6.4.50, 7.4.23 or 8.1.11, or confirm we are not affected?
- **Are any of the affected features in use, **such as request mapping into file objects, YAML input, scoped HTTP clients or certificate logins?
- **Have you checked your logs **for the signs listed above since 4 November?
- **Which of our systems are on unsupported versions, **and what would it take to move them?
Record the answers. If a supplier can’t give a date, that is a risk to put in front of whoever owns the contract, because the same gap will reappear with every future framework security release.
Metrics to track until the release is closed
A security release like this is a small project with a clear finish line. Five numbers are enough to know whether it is under control and to report progress to leadership.
Questions to ask your engineering leaders
Are we covered?
- Which of our applications and vendor products use Symfony, and on which versions?
- Are all internet-facing applications on 5.4.56, 6.4.50, 7.4.23, 8.1.11 or later, and when will the rest be?
- Do any public APIs map client data into file objects or accept YAML?
- Which API credentials do our Symfony applications hold, and would we know if they were sent elsewhere?
- Which applications are on unsupported Symfony branches, and what is the plan to move them?
Application security
Need help patching your Symfony applications?
We can inventory your PHP applications, upgrade Symfony safely, and review the endpoints and integrations these flaws target.
Sources
- GHSA-pxj9-jh84-vhm5: DataUriNormalizer reads local files (Symfony)
- GHSA-hwfg-qwvh-2wfx: YAML parser parse times (Symfony)
- GHSA-gq53-v8w2-gjhj: ScopingHttpClient sends credentials to other origins (Symfony)
- GHSA-5w3m-mfwg-9f8r: X509Authenticator DN parsing (Symfony)
- GHSA-6prc-h956-hxjq: Filesystem Path escapes its base directory (Symfony)
- GHSA-h38r-xrmh-cwhr: Serializer builds UploadedFile from request data (Symfony)
- Security advisories (Symfony blog)
Originally published at phpscientist.com.
Top comments (0)