Ce mail provient de l'extérieur, restons vigilants

=====================================================================


                            CERT-Renater

                Note d'Information No. 2026/VULN1039
_____________________________________________________________________

DATE                : 16/10/2026

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running symfony (Composer), 
                     symfony/expression-language (Composer) versions
                          prior to 5.4.54, 6.4.48, 7.4.21, 8.1.9,
                    symfony/yaml (Composer) versions prior to 5.4.54,
                                 6.4.45, 7.4.18, 8.1.6,
                    symfony/http-foundation (Composer) versions prior
                           to 5.4.5, 6.4.46, 7.4.19, 8.1.7.

====================================================================
https://github.com/symfony/symfony/security/advisories/GHSA-7rpj-w9pf-39rr
https://github.com/symfony/symfony/security/advisories/GHSA-2v3c-qxhr-7vpv
https://github.com/symfony/symfony/security/advisories/GHSA-r925-mgvr-h9cc
_____________________________________________________________________

Unbounded Nesting in the Expression Parser Lets Untrusted Expressions
Crash the Process

High
fabpot published GHSA-7rpj-w9pf-39rr 

Package
symfony/expression-language (Composer)

Affected versions
<5.4.54
>=6, <6.4.48
>=7, <7.4.21
>=8, <8.1.9

Patched versions
5.4.54
6.4.48
7.4.21
8.1.9

symfony/symfony (Composer)
Affected versions
<5.4.54
>=6, <6.4.48
>=7, <7.4.21
>=8, <8.1.9
Patched versions
5.4.54
6.4.48
7.4.21
8.1.9


Description

Description

The parser of the ExpressionLanguage component built its node tree
with no bound on its depth. An expression made of tens of thousands
of nested unary operators, array literals, binary operators or
property accesses crashed the PHP process, while the tree was being
freed.

#[Assert\ExpressionSyntax] passes the validated value to
ExpressionLanguage::lint(), so an application validating expressions
written by its users could be crashed by a single request, and so
could any code parsing untrusted expressions.


Resolution

The parser now counts the nodes stacked on the branch it is building,
including the shapes that fold iteratively rather than recursively,
and raises a SyntaxError beyond 256 levels, which callers already
handle as an invalid expression.

The first release of this fix, in 6.4.45, 7.4.18 and 8.1.6, missed
the levels that a chain of binary operators or of property accesses
adds above its first operand. With 60 levels of parentheses holding
60 additions each, as in ((1 + 1 + 1) + 1 + 1), the expression was
still accepted, and serializing it for the default cache crashed the
process. The parser now also checks the depth of the node tree once
parsed. 6.4.48, 7.4.21 and 8.1.9 contain both changes.

The patches for this issue are 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 Nicolas Grekas for reporting the issue and
providing the fix.

We would also like to thank Bruno Dias from Checkmarx for his help
getting a CVE assigned.

References

    Fix: #65690
    Follow-up: #66723
    Follow-up for chained ternaries: #66720

Severity
High
8.7/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity None
Availability High
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

CVE ID
CVE-2026-109449

Weaknesses
Weakness CWE-674

Credits

    @nicolas-grekas nicolas-grekas Remediation developer
_____________________________________________________________________

Unbounded Recursion in the YAML Inline Lexer Lets a Single Document
Crash the Process

High
fabpot published GHSA-2v3c-qxhr-7vpv

Package
symfony/symfony (Composer)

Affected versions
<5.4.54
>=6, <6.4.45
>=7, <7.4.18
>=8, <8.1.6

Patched versions
5.4.54
6.4.45
7.4.18
8.1.6

symfony/yaml (Composer)

Affected versions
<5.4.54
>=6, <6.4.45
>=7, <7.4.18
>=8, <8.1.6
Patched versions
5.4.54
6.4.45
7.4.18
8.1.6


Description

Description

Yaml\Parser::lexInlineStructure() recursed through lexInlineMapping() and
lexInlineSequence() for every { and [ of an inline collection, without
entering the nesting level that the rest of the parser bounds with
maxNestingLevel. A document made of deeply nested inline collections, such
as [[[[...]]]], exhausted the stack while it was being lexed: depending on
the PHP version and its stack settings, the process crashed or the request
ended with a fatal error.

Any code parsing untrusted YAML is affected. That includes
#[MapRequestPayload] when the Yaml component is installed and the endpoint
does not restrict acceptFormat: a single unauthenticated request with a
YAML content type is enough.


Resolution

The inline lexer now enters and leaves the same nesting level as the rest of
the parser, so nested inline collections are bounded by maxNestingLevel, and
the parser raises a ParseException beyond it.

The patches for this issue are 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 Nicolas Grekas for reporting the issue and providing
the fix.

We would also like to thank Bruno Dias from Checkmarx for his help getting a
CVE assigned.


References

    Fix: #65688

Severity
High
8.7/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity None
Availability High
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

CVE ID
CVE-2026-109413

Weaknesses
Weakness CWE-674

Credits

    @nicolas-grekas nicolas-grekas Remediation developer
_____________________________________________________________________


ReDoS in HeaderUtils::split() Reachable Through the Cache-Control
Request Header

High
fabpot published GHSA-r925-mgvr-h9cc

Package
symfony/http-foundation (Composer)

Affected versions
>=4.1.0, <5.4.54
>=6, <6.4.46
>=7, <7.4.19
>=8, <8.1.7
Patched versions
5.4.54
6.4.46
7.4.19
8.1.7

symfony/symfony (Composer)
Affected versions
>=4.1.0, <5.4.54
>=6, <6.4.46
>=7, <7.4.19
>=8, <8.1.7
Patched versions
5.4.54
6.4.46
7.4.19
8.1.7


Description
Description

HeaderUtils::split() parsed header values with a pattern whose token
alternative also matched whitespace, followed by a (?<!\s) lookbehind.
A run of whitespace placed before a separator could be divided among the
iterations of the enclosing repetition in exponentially many ways, and
the engine tried all of them before settling. HeaderBag calls it for
the Cache-Control header whenever a Request is built, so any application
handling HTTP requests is reachable, with no authentication.

A single request carrying such a header costs close to a second of CPU
(813 ms for a run of 17 spaces in an 8 KB header on PHP 8.5, doubling
with each extra space). From 18 spaces on, preg_match_all() gives up at
pcre.backtrack_limit and split() returns an empty array, so every
directive of the header is silently dropped.


Resolution

The pattern now consumes whitespace only when more of the value follows it,
so a value can no longer end on whitespace, nothing has to be given back,
and every quantifier is possessive. The first release of this fix broke
splitting on a whitespace separator: HeaderUtils::split('foo bar', ' ')
returned a single value in 6.4.46 to 6.4.47, 7.4.19 to 7.4.20 and 8.1.7
to 8.1.8. Whitespace characters used as separators are now left out of the
whitespace branch, which 6.4.48, 7.4.21 and 8.1.9 contain.

The patches for this issue are 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 r3verii for reporting the issue and Nicolas Grekas
for providing the fix.

We would also like to thank Bruno Dias from Checkmarx for his help getting
a CVE assigned.


References

    Fix: #66048
    Follow-up: #66491

Severity
High
8.7/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity None
Availability High
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

CVE ID
CVE-2026-108082

Weaknesses
Weakness CWE-1333

Credits

    @r3verii r3verii Finder
    @nicolas-grekas nicolas-grekas Remediation developer
    @duartecsantos duartecsantos Other

=========================================================
+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=========================================================




