Symfony HTTP Foundation received two security advisories from Fabien Potencier on November 4, 2026 — both with the same fixed versions. One covers generated URLs that can point to a client-chosen host; the other covers path rules in front of PHP that can be bypassed by appending a path to the script name. Primary sources are the Symfony blog posts for GHSA-5mx8-mwrp-5693 and GHSA-3h27-hjv7-fqjx.
Fixed in Symfony HTTP Foundation 5.4.56, 6.4.50, 7.4.23, and 8.1.11. Operators should treat both advisories as one upgrade package: same component family, same patch level, two different surfaces. Symfony’s recommended documentation configurations are not affected by the first advisory; a version check is still warranted.
Symfony HTTP Foundation: Host in Generated URLs (GHSA-5mx8-mwrp-5693)
When Request::getBaseUrl() does not find the script name at the start of the request URI, it looks further into the path — useful for front controllers in subdirectories. That prefix could be influenced by the client. A request URI starting with // or /\ made the base URL start with a host. Per the advisory, links built with path() and form actions, redirects such as redirectToRoute(), and assets referenced with relative paths via asset() could then point at an attacker-controlled host.
Affected versions: <5.4.56, ≥6 and <6.4.50, ≥7 and <7.4.23, ≥8 and <8.1.11. Applications are affected when the front controller sits in a subdirectory and the web server forwards URIs that do not start with that directory — for example a root .htaccess rewriting everything to public/. Configurations that set SCRIPT_NAME to the request path (some nginx setups without fastcgi_split_path_info, php -S with a router outside the document root) are also called out. framework.trusted_hosts does not help, because the request host remains the real one. Fix: return an empty base URL when the request URI starts with // or /\.
Path Rules in Front of PHP (GHSA-3h27-hjv7-fqjx)
Since the fix for CVE-2025-64500, Request::getPathInfo() strips the script name from the start of the URL — even when the script name is only the start of a longer path segment. With SCRIPT_NAME=/index.php, a request to /index.phpadmin got path info /admin and was routed like /admin; encoded spellings such as /index%2Ephpadmin worked too. Before that fix, path info was admin, which matched no route.
Important: rules enforced by Symfony are not affected — access_control and firewalls read the same path info as the router. Rules enforced in front of PHP are: nginx location blocks, Apache <Location> sections, CDN or WAF rules on paths such as /admin. The nginx configuration in Symfony’s docs and the .htaccess from symfony/apache-pack make /index.php/admin unreachable but still pass /index.phpadmin to the front controller. Affected ranges: ≥5.4.50 <5.4.56, ≥6.4.29 <6.4.50, ≥7.3.7 <7.4.23, ≥8 <8.1.11. Fix: strip the script name only when followed by /, ?, or end of URL.
What Operators Should Do Now
Dependency check: raise HTTP Foundation or the Symfony metapackage to 5.4.56 / 6.4.50 / 7.4.23 / 8.1.11 (or newer on the same branch). Web server review: compare front-controller rewrites and SCRIPT_NAME/fastcgi_split_path_info against the advisory descriptions; prefer documented setups. WAF/CDN: do not treat path allowlists as sole protection for admin routes if requests can still reach the PHP front controller.
AppSec: fold both GHSAs into the same change request and run regression tests for URL generation and routing after the upgrade. No exploit recipes are required — the advisories already describe the concept publicly; patching and config alignment suffice. Credits: Nicolas Grekas (report on both issues, host-URL fix); Jack Worman (path-bypass fix).
Context Alongside Other Framework Patches
These Symfony fixes sit alongside other framework and runtime patches operators are tracking: our write-up on the critical PHP RCE emergency patches, the Rails Active Storage / ImageMagick flaw GHSA-f3w6, CVE-2026-119977 WordPress in CISA KEV, and the Next.js Security Release November 2026. Shared theme: upgrade obligation, clear fixed versions, no speculation beyond the advisories.
Limits and Misreadings
Symfony HTTP Foundation is the affected component; not every Symfony bundle is automatically “owned.” Trusted hosts do not replace the patch. Firewall access_control is not the bypass target for the path issue per the advisory — that eases app-security rule concerns but not reverse-proxy rules. Custom front-controller layouts or unusual nginx maps should be checked explicitly against the advisory scenarios.
We deliberately omit reproducible attack steps. The public blog posts are enough for impact and mitigation. For alerting: subscribe to Symfony security-release mail and keep Composer audits in CI.
Upgrade Checklist Without Exploit Detail
Practical order: bump Composer/lockfile to the fixed versions, run staging with the same rewrite rules as production, smoke-test URL generation (login forms, redirects, asset paths) and admin routes behind proxy/WAF, then roll out. Teams still on older 5.4/6.4/7.x/8.x intermediates below the fixed versions should mirror both advisories into the same Ops and AppSec release notes — different affected ranges, same patch level.
Post-deploy monitoring: odd requests with // or script-name concatenations in access logs are a scan signal, not proof of successful exploitation. Patch status remains the controllable variable. Symfony security mail plus Dependabot/Renovate on symfony/http-foundation cut latency to the next advisory.
Bottom line: On November 4, 2026, GHSA-5mx8-mwrp-5693 and GHSA-3h27-hjv7-fqjx close two HTTP Foundation issues in 5.4.56, 6.4.50, 7.4.23, and 8.1.11. Upgrade and align web server/WAF settings — without exploit instructions.
Other Symfony Advisories from November 4, 2026
Besides the two HTTP Foundation tickets, Symfony published further advisories the same day (including HttpClient, Routing, Serializer, Security-HTTP, Filesystem, Yaml, JsonPath). CERT-FR summarizes them under CERTFR-2026-AVI-1460. Operators who maintain the `symfony/symfony` metapackage or multiple components should aim for the same patch level 5.4.56 / 6.4.50 / 7.4.23 / 8.1.11 rather than bumping HTTP Foundation alone. Our focus stays deliberately on Symfony HTTP Foundation, because the host-URL and path-bypass issues touch the broadest web surfaces.
Composer audit and Dependabot/Renovate should pin `symfony/http-foundation` and related packages to the fixed versions. Teams on LTS branches stay on their branch and take only the security release — no forced major upgrade. Staging with production-identical rewrite rules is mandatory; otherwise the advisory scenarios stay invisible.
Concrete Web Server and Proxy Checks
Apache: a root `.htaccess` that rewrites everything to `public/` without URIs carrying the directory prefix is called out explicitly in the host advisory — prefer documented layouts. Nginx: verify `fastcgi_split_path_info` and a correct `SCRIPT_NAME`; setups that set `SCRIPT_NAME` to the request path widen the host-URL risk surface. CDN/WAF: do not treat path allowlists for `/admin` and similar prefixes as sole controls if requests can still reach the PHP front controller — the path advisory targets exactly that pre-PHP layer.
After the upgrade: smoke-test login forms, `redirectToRoute()`, asset paths, and admin routes; watch access logs for `//` prefixes and script-name concatenations. Patch status and config alignment remain the controllable variables — without exploit recipes and without speculation about zero-days beyond the public advisories on Symfony HTTP Foundation.
