Affected versions
Symfony versions <5.4.55, >=6, <6.4.49, >=7, <7.4.22, >=8, <8.1.10 of the Symfony MIME component are affected by this security issue.
The issue has been fixed in Symfony 5.4.55, 6.4.49, 7.4.22, 8.1.10.
This post previously listed 5.4.52, 6.4.40, 7.4.12 and 8.0.12 as fixed versions. They don't contain the fix, see the resolution below.
Description
Symfony (and the related parameter handling reachable from Symfony) 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 fix was first committed as e62ea217f8b4ca8ae922ad0f949e0c4dc1f9b613, but that commit was never merged into a release branch. Versions 5.4.52, 6.4.40, 7.4.12 and 8.0.12, which were previously listed as patched, are therefore still affected. The fix first shipped in 5.4.55, 6.4.49, 7.4.22 and 8.1.10. Symfony 8.0 is no longer maintained, so 8.0 users have to upgrade to 8.1.10.
The patch for this issue is available here for branch 5.4 (and forward-ported to 6.4, 7.4, 8.1 and 8.2).
Credits
We would like to thank Fabian Fleischer for reporting the issue and Alexandre Daubois for fixing it. We would also like to thank Ta Thien, Duc Anh Nguyen, Ilia Alshanetsky and Zachariah Mithani from AploSec for their follow-up reports on the delivery of this fix.