Vulnerable Library - doctrine/doctrine-migrations-bundle-4.0.0
Vulnerabilities
| Vulnerability |
Severity |
CVSS |
Dependency |
Type |
Fixed in (doctrine/doctrine-migrations-bundle version) |
Remediation Possible** |
| CVE-2026-45075 |
High |
8.1 |
symfony/http-kernel-v8.0.2 |
Transitive |
N/A* |
❌ |
| CVE-2026-48736 |
High |
7.2 |
symfony/http-foundation-v8.0.1 |
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-2026-45075
Vulnerable Library - symfony/http-kernel-v8.0.2
Provides a structured process for converting a Request into a Response
Library home page: https://api.github.com/repos/symfony/http-kernel/zipball/bcef77a3c8ae8934ce7067172e2a1a6491a62a7d
Dependency Hierarchy:
- doctrine/doctrine-migrations-bundle-4.0.0 (Root Library)
- ❌ symfony/http-kernel-v8.0.2 (Vulnerable Library)
Found in base branch: develop
Vulnerability Details
Description Symfony's "#[IsGranted('...')]", "#[IsSignatureValid]", and "#[IsCsrfTokenValid(...)]" attributes allow you to define a "methods: [...]" argument to only enforce these checks for the listed HTTP methods and skip them otherwise. E.g. an attribute defining "methods: ['GET']" would be ignored for a "HEAD" request. On the other hand, Symfony's router (and HTTP semantics generally) serves "HEAD" requests using the "GET" handler. Therefore, a controller protected by e.g. "#[IsGranted('ROLE_ADMIN', methods: ['GET'])]" can be reached via "HEAD" with the authorization check silently skipped. Even if the "HEAD" request won't get any response content, response headers leak ("Content-Length", "Location", custom headers). Also, the controller still executes and any side effects (DB writes, state changes) occur. Resolution When adding "GET" in the "methods" option of these attributes, Symfony now also include the "HEAD" method automatically. The patch for this issue is available "here" (symfony/symfony@fa8d5c6) for branch 7.4. Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Alexandre Daubois for fixing it.
Publish Date: 2026-05-31
URL: CVE-2026-45075
CVSS 3 Score Details (8.1)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: Low
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: High
- 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 - v5.4.52,https://github.com/symfony/symfony.git - v8.0.11,https://github.com/symfony/symfony.git - v7.4.11,https://github.com/symfony/symfony.git - v6.4.39
Step up your Open Source Security Game with Mend here
CVE-2026-48736
Vulnerable Library - symfony/http-foundation-v8.0.1
Defines an object-oriented layer for the HTTP specification
Library home page: https://api.github.com/repos/symfony/http-foundation/zipball/3690740e2e8b19d877f20d4f10b7a489cddf0fe2
Dependency Hierarchy:
- doctrine/doctrine-migrations-bundle-4.0.0 (Root Library)
- ❌ symfony/http-foundation-v8.0.1 (Vulnerable Library)
Found in base branch: develop
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/symfony - v7.4.13,symfony/symfony - v8.0.13,symfony/http-foundation - v7.4.13,symfony/symfony - v5.4.53,symfony/http-foundation - v6.4.41,symfony/symfony - v6.4.41,symfony/http-client - v5.4.53,symfony/http-foundation - v8.0.13
Step up your Open Source Security Game with Mend here
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-kernel-v8.0.2
Provides a structured process for converting a Request into a Response
Library home page: https://api.github.com/repos/symfony/http-kernel/zipball/bcef77a3c8ae8934ce7067172e2a1a6491a62a7d
Dependency Hierarchy:
Found in base branch: develop
Vulnerability Details
Description Symfony's "#[IsGranted('...')]", "#[IsSignatureValid]", and "#[IsCsrfTokenValid(...)]" attributes allow you to define a "methods: [...]" argument to only enforce these checks for the listed HTTP methods and skip them otherwise. E.g. an attribute defining "methods: ['GET']" would be ignored for a "HEAD" request. On the other hand, Symfony's router (and HTTP semantics generally) serves "HEAD" requests using the "GET" handler. Therefore, a controller protected by e.g. "#[IsGranted('ROLE_ADMIN', methods: ['GET'])]" can be reached via "HEAD" with the authorization check silently skipped. Even if the "HEAD" request won't get any response content, response headers leak ("Content-Length", "Location", custom headers). Also, the controller still executes and any side effects (DB writes, state changes) occur. Resolution When adding "GET" in the "methods" option of these attributes, Symfony now also include the "HEAD" method automatically. The patch for this issue is available "here" (symfony/symfony@fa8d5c6) for branch 7.4. Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Alexandre Daubois for fixing it.
Publish Date: 2026-05-31
URL: CVE-2026-45075
CVSS 3 Score Details (8.1)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: Low
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: High
- 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 - v5.4.52,https://github.com/symfony/symfony.git - v8.0.11,https://github.com/symfony/symfony.git - v7.4.11,https://github.com/symfony/symfony.git - v6.4.39
Step up your Open Source Security Game with Mend here
Vulnerable Library - symfony/http-foundation-v8.0.1
Defines an object-oriented layer for the HTTP specification
Library home page: https://api.github.com/repos/symfony/http-foundation/zipball/3690740e2e8b19d877f20d4f10b7a489cddf0fe2
Dependency Hierarchy:
Found in base branch: develop
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/symfony - v7.4.13,symfony/symfony - v8.0.13,symfony/http-foundation - v7.4.13,symfony/symfony - v5.4.53,symfony/http-foundation - v6.4.41,symfony/symfony - v6.4.41,symfony/http-client - v5.4.53,symfony/http-foundation - v8.0.13
Step up your Open Source Security Game with Mend here