Vulnerable Library - vich/uploader-bundle-v2.9.1
Vulnerabilities
| Vulnerability |
Severity |
 CVSS |
Dependency |
Type |
Fixed in (vich/uploader-bundle-v2.9.1 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* |
❌ |
| CVE-2026-45070 |
 Medium |
6.5 |
symfony/mime-v8.0.0 |
Transitive |
N/A* |
❌ |
| CVE-2026-45067 |
Medium |
6.5 |
symfony/mime-v8.0.0 |
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:
- vich/uploader-bundle-v2.9.1 (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:
- vich/uploader-bundle-v2.9.1 (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/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
Step up your Open Source Security Game with Mend here
CVE-2026-45070
Vulnerable Library - symfony/mime-v8.0.0
Allows manipulating MIME messages
Library home page: https://api.github.com/repos/symfony/mime/zipball/7576ce3b2b4d3a2a7fe7020a07a392065d6ffd40
Dependency Hierarchy:
- vich/uploader-bundle-v2.9.1 (Root Library)
- ❌ symfony/mime-v8.0.0 (Vulnerable Library)
Found in base branch: develop
Vulnerability Details
Description "Symfony\Component\Mime\Header\ParameterizedHeader" (and the related parameter handling reachable from "Symfony\Component\Mime\Header\Headers") is responsible for serializing structured headers such as "Content-Type" and "Content-Disposition", which carry "key=value" parameters (e.g. "Content-Disposition: attachment; filename="x""). RFC 2045 / RFC 5322 require parameter names to be "tokens": a restricted ASCII subset that excludes whitespace, CR/LF, and the "tspecials" set. Symfony's parameter handling validates and properly encodes parameter values, but does not validate parameter names: the supplied name is emitted verbatim into the serialized header. A caller that derives a parameter name from untrusted input, e.g. an application that lets a user influence a "Content-Disposition" parameter name, can include "\r\n" or other non-token bytes inside the name, terminating the current header and injecting additional headers in the rendered message. This is the classic CRLF / header-injection primitive applied to the parameter-name slot. Resolution "ParameterizedHeader" now rejects parameter names that contain bytes outside the RFC "token" character class. The patch for this issue is available "here" (symfony/symfony@e62ea21) for branch 5.4. Credits Symfony would like to thank Fabian Fleischer for reporting the issue and Alexandre Daubois for fixing it.
Publish Date: 2026-06-10
URL: CVE-2026-45070
CVSS 3 Score Details (6.5)
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: 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 - v7.4.10,https://github.com/symfony/symfony.git - v5.4.52,https://github.com/symfony/symfony.git - v8.0.10,https://github.com/symfony/symfony.git - v6.4.38
Step up your Open Source Security Game with Mend here
CVE-2026-45067
Vulnerable Library - symfony/mime-v8.0.0
Allows manipulating MIME messages
Library home page: https://api.github.com/repos/symfony/mime/zipball/7576ce3b2b4d3a2a7fe7020a07a392065d6ffd40
Dependency Hierarchy:
- vich/uploader-bundle-v2.9.1 (Root Library)
- ❌ symfony/mime-v8.0.0 (Vulnerable Library)
Found in base branch: develop
Vulnerability Details
Description "Symfony\Component\Mime\Address" is the value-object every Symfony Mailer address (to/cc/bcc/from/reply-to) flows through; its constructor is documented as validating the address and throwing on invalid input, so developers treat it as a security boundary. The constructor accepts email addresses whose local-part (the part before "@") is an RFC-5322 quoted string containing raw "\r\n" bytes, e.g. ""x\r\nBcc: attacker@evil"@example.com". The stored address is later emitted verbatim into (1) the rendered message headers and (2) "SmtpTransport"'s "MAIL FROM:<...>" / "RCPT TO:<...>" protocol lines, turning the embedded CRLF into a new mail header and/or a new SMTP command. Resolution The "Address" constructor now rejects addresses containing line breaks. The patch for this issue is available "here" (symfony/symfony@dc2dbd2) for branch 5.4. Credits We 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-45067
CVSS 3 Score Details (6.5)
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: 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.10,https://github.com/symfony/symfony.git - v6.4.38,https://github.com/symfony/symfony.git - v5.4.52,https://github.com/symfony/symfony.git - v7.4.10
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/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
Step up your Open Source Security Game with Mend here
Vulnerable Library - symfony/mime-v8.0.0
Allows manipulating MIME messages
Library home page: https://api.github.com/repos/symfony/mime/zipball/7576ce3b2b4d3a2a7fe7020a07a392065d6ffd40
Dependency Hierarchy:
Found in base branch: develop
Vulnerability Details
Description "Symfony\Component\Mime\Header\ParameterizedHeader" (and the related parameter handling reachable from "Symfony\Component\Mime\Header\Headers") is responsible for serializing structured headers such as "Content-Type" and "Content-Disposition", which carry "key=value" parameters (e.g. "Content-Disposition: attachment; filename="x""). RFC 2045 / RFC 5322 require parameter names to be "tokens": a restricted ASCII subset that excludes whitespace, CR/LF, and the "tspecials" set. Symfony's parameter handling validates and properly encodes parameter values, but does not validate parameter names: the supplied name is emitted verbatim into the serialized header. A caller that derives a parameter name from untrusted input, e.g. an application that lets a user influence a "Content-Disposition" parameter name, can include "\r\n" or other non-token bytes inside the name, terminating the current header and injecting additional headers in the rendered message. This is the classic CRLF / header-injection primitive applied to the parameter-name slot. Resolution "ParameterizedHeader" now rejects parameter names that contain bytes outside the RFC "token" character class. The patch for this issue is available "here" (symfony/symfony@e62ea21) for branch 5.4. Credits Symfony would like to thank Fabian Fleischer for reporting the issue and Alexandre Daubois for fixing it.
Publish Date: 2026-06-10
URL: CVE-2026-45070
CVSS 3 Score Details (6.5)
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: 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 - v7.4.10,https://github.com/symfony/symfony.git - v5.4.52,https://github.com/symfony/symfony.git - v8.0.10,https://github.com/symfony/symfony.git - v6.4.38
Step up your Open Source Security Game with Mend here
Vulnerable Library - symfony/mime-v8.0.0
Allows manipulating MIME messages
Library home page: https://api.github.com/repos/symfony/mime/zipball/7576ce3b2b4d3a2a7fe7020a07a392065d6ffd40
Dependency Hierarchy:
Found in base branch: develop
Vulnerability Details
Description "Symfony\Component\Mime\Address" is the value-object every Symfony Mailer address (to/cc/bcc/from/reply-to) flows through; its constructor is documented as validating the address and throwing on invalid input, so developers treat it as a security boundary. The constructor accepts email addresses whose local-part (the part before "@") is an RFC-5322 quoted string containing raw "\r\n" bytes, e.g. ""x\r\nBcc: attacker@evil"@example.com". The stored address is later emitted verbatim into (1) the rendered message headers and (2) "SmtpTransport"'s "MAIL FROM:<...>" / "RCPT TO:<...>" protocol lines, turning the embedded CRLF into a new mail header and/or a new SMTP command. Resolution The "Address" constructor now rejects addresses containing line breaks. The patch for this issue is available "here" (symfony/symfony@dc2dbd2) for branch 5.4. Credits We 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-45067
CVSS 3 Score Details (6.5)
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: 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.10,https://github.com/symfony/symfony.git - v6.4.38,https://github.com/symfony/symfony.git - v5.4.52,https://github.com/symfony/symfony.git - v7.4.10
Step up your Open Source Security Game with Mend here