Vulnerable Library - symfony/framework-bundle-v7.3.4
Vulnerabilities
| Vulnerability |
Severity |
 CVSS |
Dependency |
Type |
Fixed in (symfony/framework-bundle-v7.3.4 version) |
Remediation Possible** |
| CVE-2025-64500 |
 High |
7.3 |
symfony/http-foundation-v7.3.4 |
Transitive |
N/A* |
❌ |
| CVE-2026-48736 |
High |
7.2 |
symfony/http-foundation-v7.3.4 |
Transitive |
N/A* |
❌ |
| CVE-2026-45073 |
High |
7.1 |
symfony/cache-v7.3.4 |
Transitive |
N/A* |
❌ |
| CVE-2026-45065 |
 Medium |
6.1 |
symfony/routing-v7.3.4 |
Transitive |
N/A* |
❌ |
| CVE-2026-48784 |
Medium |
5.8 |
symfony/routing-v7.3.4 |
Transitive |
N/A* |
❌ |
*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.
**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation
Details
CVE-2025-64500
Vulnerable Library - symfony/http-foundation-v7.3.4
Defines an object-oriented layer for the HTTP specification
Library home page: https://api.github.com/repos/symfony/http-foundation/zipball/c061c7c18918b1b64268771aad04b40be41dd2e6
Dependency Hierarchy:
- symfony/framework-bundle-v7.3.4 (Root Library)
- ❌ symfony/http-foundation-v7.3.4 (Vulnerable Library)
Found in base branch: main
Vulnerability Details
Symfony is a PHP framework for web and console applications and a set of reusable PHP components. Symfony's HttpFoundation component defines an object-oriented layer for the HTTP specification. Starting in version 2.0.0 and prior to version 5.4.50, 6.4.29, and 7.3.7, the "Request" class improperly interprets some "PATH_INFO" in a way that leads to representing some URLs with a path that doesn't start with a "/". This can allow bypassing some access control rules that are built with this "/"-prefix assumption. Starting in versions 5.4.50, 6.4.29, and 7.3.7, the "Request" class now ensures that URL paths always start with a "/".
Publish Date: 2025-11-12
URL: CVE-2025-64500
CVSS 3 Score Details (7.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: Low
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-3rg7-wf37-54rm
Release Date: 2025-11-12
Fix Resolution: symfony/symfony - v7.3.7,symfony/http-foundation - v6.4.29,symfony/http-foundation - v7.3.7,symfony/symfony - v6.4.29
CVE-2026-48736
Vulnerable Library - symfony/http-foundation-v7.3.4
Defines an object-oriented layer for the HTTP specification
Library home page: https://api.github.com/repos/symfony/http-foundation/zipball/c061c7c18918b1b64268771aad04b40be41dd2e6
Dependency Hierarchy:
- symfony/framework-bundle-v7.3.4 (Root Library)
- ❌ symfony/http-foundation-v7.3.4 (Vulnerable Library)
Found in base branch: main
Vulnerability Details
Description "Symfony\Component\HttpClient\NoPrivateNetworkHttpClient" is documented as a decorator that blocks requests to private networks by default. The list of blocked subnets ("Symfony\Component\HttpFoundation\IpUtils::PRIVATE_SUBNETS" on 6.4+, a private constant in "NoPrivateNetworkHttpClient" on 5.4) enumerates RFC1918, loopback, link-local and IPv4-mapped IPv6 ("::ffff:0:0/96") prefixes, but omits the remaining IPv6 transition forms that can embed a private IPv4 destination: 6to4 ("2002::/16", RFC 3056), Teredo ("2001::/32", RFC 4380), NAT64 ("64:ff9b::/96", RFC 6052 and "64:ff9b:1::/48", RFC 8215) and IPv4-compatible IPv6 ("::/96", RFC 4291 §2.5.5.1). "IpUtils::checkIp6()" is a pure bitwise CIDR comparison against the constants list and never extracts the embedded IPv4, so an attacker who can supply a URL writes the loopback / RFC1918 IPv4 target as e.g. "http://[2002:7f00:1::]/" (6to4 → 127.0.0.1), "http://[64:ff9b::7f00:1]/" (NAT64 → 127.0.0.1), "http://[::7f00:1]/" (IPv4-compatible → 127.0.0.1) or "http://[2001::1]/" (Teredo). "IpUtils::isPrivateIp()" returns "false" and "NoPrivateNetworkHttpClient" dispatches the request. Real-world reachability of the embedded IPv4 depends on the deploy's IPv6 routing (6to4 tunnel interface, upstream NAT64 gateway, kernel handling of IPv4-compatible addresses), but the security boundary the decorator promises — the dispatch decision — is crossed regardless of whether the packet ultimately lands on the embedded IPv4. Resolution The private-subnet list now includes "::/96", "2002::/16", "2001::/32", "64:ff9b::/96" and "64:ff9b:1::/48". Blanket blocking of these prefixes matches the policy applied by Chromium and Mozilla's Private Network Access; server-side HTTPS APIs are not legitimately published on these prefixes. The patches for this issue are available "here" (symfony/symfony@8276536) for branch 5.4 and "here" (symfony/symfony@85b8315) for branch 6.4 (and forward-ported to 7.4, 8.0 and 8.1). Credits Symfony would like to thank tonghuaroot for reporting the issue and Nicolas Grekas for providing the fix.
Publish Date: 2026-06-15
URL: CVE-2026-48736
CVSS 3 Score Details (7.2)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-38cx-cq6f-5755
Release Date: 2026-06-15
Fix Resolution: symfony/http-client - v5.4.53,symfony/http-foundation - v6.4.41,symfony/http-foundation - v8.0.13,symfony/http-foundation - v7.4.13,https://github.com/symfony/symfony.git - v6.4.41,https://github.com/symfony/symfony.git - v5.4.53,https://github.com/symfony/symfony.git - v8.0.13,https://github.com/symfony/symfony.git - v7.4.13
CVE-2026-45073
Vulnerable Library - symfony/cache-v7.3.4
Provides extended PSR-6, PSR-16 (and tags) implementations
Library home page: https://api.github.com/repos/symfony/cache/zipball/bf8afc8ffd4bfd3d9c373e417f041d9f1e5b863f
Dependency Hierarchy:
- symfony/framework-bundle-v7.3.4 (Root Library)
- ❌ symfony/cache-v7.3.4 (Vulnerable Library)
Found in base branch: main
Vulnerability Details
Description "Symfony\Component\Cache\Adapter\PdoAdapter" is the PDO-backed cache adapter. Its "clear($prefix)" method (inherited from "AbstractAdapterTrait") is documented to delete cache items whose key starts with "$prefix". In the non-versioning code path, the caller-supplied "$prefix" is concatenated into "$namespace = $this->namespace.$prefix" and passed to "PdoAdapter::doClear()", which builds: DELETE FROM
WHERE <id_col> LIKE '%' The value is interpolated directly into the SQL text and executed with "PDO::exec()": "$namespace" is not bound. A caller able to influence "$prefix" can break out of the literal and inject SQL, expanding deletion scope from the intended prefix to arbitrary rows, or otherwise reshape query semantics. Most applications don't expose "clear($prefix)" to untrusted input directly, but the contract of the method is to safely accept any prefix string, so the lack of escaping is a defect of the adapter itself. Resolution "AbstractAdapterTrait::clear()" now rejects any "$prefix" containing characters outside "[-+.A-Za-z0-9]": when an invalid prefix is supplied, the method logs a warning and returns "false" instead of reaching the SQL layer. This blocks quotes, "%", null bytes and other characters that would let an attacker break out of the "LIKE" literal. The patch for this issue is available "here" (symfony/symfony@ec50b79) for branch 5.4. Credits Symfony would like to thank secsys_codex for reporting the issue and Nicolas Grekas for fixing it.
Publish Date: 2026-05-31
URL: CVE-2026-45073
CVSS 3 Score Details (7.1)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: Low
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: Low
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-05-27
Fix Resolution: https://github.com/symfony/symfony.git - v7.4.12,https://github.com/symfony/symfony.git - v5.4.52,https://github.com/symfony/symfony.git - v8.0.12,https://github.com/symfony/symfony.git - v6.4.40
CVE-2026-45065
Vulnerable Library - symfony/routing-v7.3.4
Maps an HTTP request to a set of configuration variables
Library home page: https://api.github.com/repos/symfony/routing/zipball/8dc648e159e9bac02b703b9fbd937f19ba13d07c
Dependency Hierarchy:
- symfony/framework-bundle-v7.3.4 (Root Library)
- ❌ symfony/routing-v7.3.4 (Vulnerable Library)
Found in base branch: main
Vulnerability Details
Description Symfony routes can declare a requirements regex per path parameter, e.g. a route "/{_locale}/blog" with "requirements: { _locale: 'en|fr|de' }". The Twig "path()" / "url()" helpers (backed by "UrlGenerator") validate supplied parameter values against that regex before building the URL. UrlGenerator constructs the validation pattern as "'#^'.$req.'$#'", where "$req" is the raw requirement string. For a requirement expressed as an alternation, e.g. "_locale: 'ar|bg|...|vi|...|zh_CN'" (very common), "^" and "$" anchor only the first and last alternatives, so any middle alternative matches as an unanchored substring. A value like "/evil.com" satisfies the requirement (because it contains "vi"), and the generated path becomes "//evil.com/...": a protocol-relative URL the browser navigates off-site. Resolution The "UrlGenerator" class now wraps the requirement in a non-capturing group so the "^" and "$" anchors apply to the whole alternation. The patch for this issue is available "here" (symfony/symfony@bcf487c) for branch 5.4. Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.
Publish Date: 2026-06-10
URL: CVE-2026-45065
CVSS 3 Score Details (6.1)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-05-27
Fix Resolution: https://github.com/symfony/symfony.git - v8.0.9,https://github.com/symfony/symfony.git - v6.4.38,https://github.com/symfony/symfony.git - v7.4.9,https://github.com/symfony/symfony.git - v5.4.52
CVE-2026-48784
Vulnerable Library - symfony/routing-v7.3.4
Maps an HTTP request to a set of configuration variables
Library home page: https://api.github.com/repos/symfony/routing/zipball/8dc648e159e9bac02b703b9fbd937f19ba13d07c
Dependency Hierarchy:
- symfony/framework-bundle-v7.3.4 (Root Library)
- ❌ symfony/routing-v7.3.4 (Vulnerable Library)
Found in base branch: main
Vulnerability Details
Description "Symfony\Component\Routing\Generator\UrlGenerator::doGenerate()" percent-encodes "." and ".." path segments so that the generated URL still resolves to the originating route after RFC 3986 §5.2.4 dot-segment removal (which strict RFC-3986 consumers — routers, reverse proxies, HTTP clients — perform before percent-decoding). The encoding was implemented as "strtr($url, ['/../' => '/%2E%2E/', '/./' => '/%2E/'])" plus a trailing-segment fixup. "strtr" advances past the trailing "/" of each match, so the next dot-segment in a chained sequence was left unescaped: | Input | Output (before fix) | Expected | | -------------------- | ---------------------------------------- | ----------------------------------- | | "/../../../" | "/%2E%2E/../%2E%2E/" | "/%2E%2E/%2E%2E/%2E%2E/" | | "/foo/../../../bar" | "/foo/%2E%2E/../%2E%2E/bar" | "/foo/%2E%2E/%2E%2E/%2E%2E/bar" | When a route exposes a parameter constrained by a permissive requirement (".+", ".*", or similar) that accepts dots and slashes, attacker-controlled chained ".." or "." segments produce a generated URL that, under strict RFC 3986 normalization, collapses to a different path than the originating route. The Twig "path()" / "url()" helpers and any server-side use of "UrlGenerator" are affected. Same class of route round-trip integrity issue as CVE-2026-45065. Note: WHATWG-conformant browsers treat "%2E"/"%2E%2E" as dot-segments during URL parsing, so the encoding never protected browser-side traversal. The defense exists for RFC-3986-conformant consumers; restoring it for chained segments closes the gap there. Resolution "UrlGenerator" now matches every "/." or "/.." dot-segment in a single left-to-right "preg_replace_callback" pass using a lookahead that does not consume the trailing "/", so adjacent dot-segments are encoded correctly. The patches for this issue are available "here" (symfony/symfony@4b63c3a) for branch 5.4 (and forward-ported to 6.4, 7.4, 8.0 and 8.1). Credits Symfony would like to thank Alex Pott for reporting the issue and Nicolas Grekas for providing the fix.
Publish Date: 2026-06-15
URL: CVE-2026-48784
CVSS 3 Score Details (5.8)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-06-15
Fix Resolution: https://github.com/symfony/symfony.git - v8.0.13,https://github.com/symfony/symfony.git - v6.4.41,https://github.com/symfony/symfony.git - v7.4.13,https://github.com/symfony/symfony.git - v5.4.53
Vulnerabilities
*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.
**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation
Details
Vulnerable Library - symfony/http-foundation-v7.3.4
Defines an object-oriented layer for the HTTP specification
Library home page: https://api.github.com/repos/symfony/http-foundation/zipball/c061c7c18918b1b64268771aad04b40be41dd2e6
Dependency Hierarchy:
Found in base branch: main
Vulnerability Details
Symfony is a PHP framework for web and console applications and a set of reusable PHP components. Symfony's HttpFoundation component defines an object-oriented layer for the HTTP specification. Starting in version 2.0.0 and prior to version 5.4.50, 6.4.29, and 7.3.7, the "Request" class improperly interprets some "PATH_INFO" in a way that leads to representing some URLs with a path that doesn't start with a "/". This can allow bypassing some access control rules that are built with this "/"-prefix assumption. Starting in versions 5.4.50, 6.4.29, and 7.3.7, the "Request" class now ensures that URL paths always start with a "/".
Publish Date: 2025-11-12
URL: CVE-2025-64500
CVSS 3 Score Details (7.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: Low
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-3rg7-wf37-54rm
Release Date: 2025-11-12
Fix Resolution: symfony/symfony - v7.3.7,symfony/http-foundation - v6.4.29,symfony/http-foundation - v7.3.7,symfony/symfony - v6.4.29
Vulnerable Library - symfony/http-foundation-v7.3.4
Defines an object-oriented layer for the HTTP specification
Library home page: https://api.github.com/repos/symfony/http-foundation/zipball/c061c7c18918b1b64268771aad04b40be41dd2e6
Dependency Hierarchy:
Found in base branch: main
Vulnerability Details
Description "Symfony\Component\HttpClient\NoPrivateNetworkHttpClient" is documented as a decorator that blocks requests to private networks by default. The list of blocked subnets ("Symfony\Component\HttpFoundation\IpUtils::PRIVATE_SUBNETS" on 6.4+, a private constant in "NoPrivateNetworkHttpClient" on 5.4) enumerates RFC1918, loopback, link-local and IPv4-mapped IPv6 ("::ffff:0:0/96") prefixes, but omits the remaining IPv6 transition forms that can embed a private IPv4 destination: 6to4 ("2002::/16", RFC 3056), Teredo ("2001::/32", RFC 4380), NAT64 ("64:ff9b::/96", RFC 6052 and "64:ff9b:1::/48", RFC 8215) and IPv4-compatible IPv6 ("::/96", RFC 4291 §2.5.5.1). "IpUtils::checkIp6()" is a pure bitwise CIDR comparison against the constants list and never extracts the embedded IPv4, so an attacker who can supply a URL writes the loopback / RFC1918 IPv4 target as e.g. "http://[2002:7f00:1::]/" (6to4 → 127.0.0.1), "http://[64:ff9b::7f00:1]/" (NAT64 → 127.0.0.1), "http://[::7f00:1]/" (IPv4-compatible → 127.0.0.1) or "http://[2001::1]/" (Teredo). "IpUtils::isPrivateIp()" returns "false" and "NoPrivateNetworkHttpClient" dispatches the request. Real-world reachability of the embedded IPv4 depends on the deploy's IPv6 routing (6to4 tunnel interface, upstream NAT64 gateway, kernel handling of IPv4-compatible addresses), but the security boundary the decorator promises — the dispatch decision — is crossed regardless of whether the packet ultimately lands on the embedded IPv4. Resolution The private-subnet list now includes "::/96", "2002::/16", "2001::/32", "64:ff9b::/96" and "64:ff9b:1::/48". Blanket blocking of these prefixes matches the policy applied by Chromium and Mozilla's Private Network Access; server-side HTTPS APIs are not legitimately published on these prefixes. The patches for this issue are available "here" (symfony/symfony@8276536) for branch 5.4 and "here" (symfony/symfony@85b8315) for branch 6.4 (and forward-ported to 7.4, 8.0 and 8.1). Credits Symfony would like to thank tonghuaroot for reporting the issue and Nicolas Grekas for providing the fix.
Publish Date: 2026-06-15
URL: CVE-2026-48736
CVSS 3 Score Details (7.2)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-38cx-cq6f-5755
Release Date: 2026-06-15
Fix Resolution: symfony/http-client - v5.4.53,symfony/http-foundation - v6.4.41,symfony/http-foundation - v8.0.13,symfony/http-foundation - v7.4.13,https://github.com/symfony/symfony.git - v6.4.41,https://github.com/symfony/symfony.git - v5.4.53,https://github.com/symfony/symfony.git - v8.0.13,https://github.com/symfony/symfony.git - v7.4.13
Vulnerable Library - symfony/cache-v7.3.4
Provides extended PSR-6, PSR-16 (and tags) implementations
Library home page: https://api.github.com/repos/symfony/cache/zipball/bf8afc8ffd4bfd3d9c373e417f041d9f1e5b863f
Dependency Hierarchy:
Found in base branch: main
Vulnerability Details
Description "Symfony\Component\Cache\Adapter\PdoAdapter" is the PDO-backed cache adapter. Its "clear($prefix)" method (inherited from "AbstractAdapterTrait") is documented to delete cache items whose key starts with "$prefix". In the non-versioning code path, the caller-supplied "$prefix" is concatenated into "$namespace = $this->namespace.$prefix" and passed to "PdoAdapter::doClear()", which builds: DELETE FROM
WHERE <id_col> LIKE '%' The value is interpolated directly into the SQL text and executed with "PDO::exec()": "$namespace" is not bound. A caller able to influence "$prefix" can break out of the literal and inject SQL, expanding deletion scope from the intended prefix to arbitrary rows, or otherwise reshape query semantics. Most applications don't expose "clear($prefix)" to untrusted input directly, but the contract of the method is to safely accept any prefix string, so the lack of escaping is a defect of the adapter itself. Resolution "AbstractAdapterTrait::clear()" now rejects any "$prefix" containing characters outside "[-+.A-Za-z0-9]": when an invalid prefix is supplied, the method logs a warning and returns "false" instead of reaching the SQL layer. This blocks quotes, "%", null bytes and other characters that would let an attacker break out of the "LIKE" literal. The patch for this issue is available "here" (symfony/symfony@ec50b79) for branch 5.4. Credits Symfony would like to thank secsys_codex for reporting the issue and Nicolas Grekas for fixing it.Publish Date: 2026-05-31
URL: CVE-2026-45073
CVSS 3 Score Details (7.1)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: Low
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: Low
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-05-27
Fix Resolution: https://github.com/symfony/symfony.git - v7.4.12,https://github.com/symfony/symfony.git - v5.4.52,https://github.com/symfony/symfony.git - v8.0.12,https://github.com/symfony/symfony.git - v6.4.40
Vulnerable Library - symfony/routing-v7.3.4
Maps an HTTP request to a set of configuration variables
Library home page: https://api.github.com/repos/symfony/routing/zipball/8dc648e159e9bac02b703b9fbd937f19ba13d07c
Dependency Hierarchy:
Found in base branch: main
Vulnerability Details
Description Symfony routes can declare a requirements regex per path parameter, e.g. a route "/{_locale}/blog" with "requirements: { _locale: 'en|fr|de' }". The Twig "path()" / "url()" helpers (backed by "UrlGenerator") validate supplied parameter values against that regex before building the URL. UrlGenerator constructs the validation pattern as "'#^'.$req.'$#'", where "$req" is the raw requirement string. For a requirement expressed as an alternation, e.g. "_locale: 'ar|bg|...|vi|...|zh_CN'" (very common), "^" and "$" anchor only the first and last alternatives, so any middle alternative matches as an unanchored substring. A value like "/evil.com" satisfies the requirement (because it contains "vi"), and the generated path becomes "//evil.com/...": a protocol-relative URL the browser navigates off-site. Resolution The "UrlGenerator" class now wraps the requirement in a non-capturing group so the "^" and "$" anchors apply to the whole alternation. The patch for this issue is available "here" (symfony/symfony@bcf487c) for branch 5.4. Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.
Publish Date: 2026-06-10
URL: CVE-2026-45065
CVSS 3 Score Details (6.1)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-05-27
Fix Resolution: https://github.com/symfony/symfony.git - v8.0.9,https://github.com/symfony/symfony.git - v6.4.38,https://github.com/symfony/symfony.git - v7.4.9,https://github.com/symfony/symfony.git - v5.4.52
Vulnerable Library - symfony/routing-v7.3.4
Maps an HTTP request to a set of configuration variables
Library home page: https://api.github.com/repos/symfony/routing/zipball/8dc648e159e9bac02b703b9fbd937f19ba13d07c
Dependency Hierarchy:
Found in base branch: main
Vulnerability Details
Description "Symfony\Component\Routing\Generator\UrlGenerator::doGenerate()" percent-encodes "." and ".." path segments so that the generated URL still resolves to the originating route after RFC 3986 §5.2.4 dot-segment removal (which strict RFC-3986 consumers — routers, reverse proxies, HTTP clients — perform before percent-decoding). The encoding was implemented as "strtr($url, ['/../' => '/%2E%2E/', '/./' => '/%2E/'])" plus a trailing-segment fixup. "strtr" advances past the trailing "/" of each match, so the next dot-segment in a chained sequence was left unescaped: | Input | Output (before fix) | Expected | | -------------------- | ---------------------------------------- | ----------------------------------- | | "/../../../" | "/%2E%2E/../%2E%2E/" | "/%2E%2E/%2E%2E/%2E%2E/" | | "/foo/../../../bar" | "/foo/%2E%2E/../%2E%2E/bar" | "/foo/%2E%2E/%2E%2E/%2E%2E/bar" | When a route exposes a parameter constrained by a permissive requirement (".+", ".*", or similar) that accepts dots and slashes, attacker-controlled chained ".." or "." segments produce a generated URL that, under strict RFC 3986 normalization, collapses to a different path than the originating route. The Twig "path()" / "url()" helpers and any server-side use of "UrlGenerator" are affected. Same class of route round-trip integrity issue as CVE-2026-45065. Note: WHATWG-conformant browsers treat "%2E"/"%2E%2E" as dot-segments during URL parsing, so the encoding never protected browser-side traversal. The defense exists for RFC-3986-conformant consumers; restoring it for chained segments closes the gap there. Resolution "UrlGenerator" now matches every "/." or "/.." dot-segment in a single left-to-right "preg_replace_callback" pass using a lookahead that does not consume the trailing "/", so adjacent dot-segments are encoded correctly. The patches for this issue are available "here" (symfony/symfony@4b63c3a) for branch 5.4 (and forward-ported to 6.4, 7.4, 8.0 and 8.1). Credits Symfony would like to thank Alex Pott for reporting the issue and Nicolas Grekas for providing the fix.
Publish Date: 2026-06-15
URL: CVE-2026-48784
CVSS 3 Score Details (5.8)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-06-15
Fix Resolution: https://github.com/symfony/symfony.git - v8.0.13,https://github.com/symfony/symfony.git - v6.4.41,https://github.com/symfony/symfony.git - v7.4.13,https://github.com/symfony/symfony.git - v5.4.53