Description

On Windows, when an executable file named cmd.exe is located in the current working directory it will be called by the Process class when preparing command arguments, leading to possible hijacking.

Resolution

The Process class now uses the absolute path to cmd.exe.

The patch for this issue is available here for branch 5.4.

Credits

We would like to thank Jordi Boggiano for reporting the issue and Nicolas Grekas for providing the fix.

An issue was discovered in the LDAP component in Symfony 2.8.x before 2.8.37, 3.3.x before 3.3.17, 3.4.x before 3.4.7, and 4.0.x before 4.0.7. It allows remote attackers to bypass authentication by logging in with a "null" password and valid username, which triggers an unauthenticated bind. NOTE: this issue exists because of an incomplete fix for CVE-2016-2403.

Certain Symfony products are affected by: Incorrect Access Control. This affects Symfony 2.7.30 and Symfony 2.8.23 and Symfony 3.2.10 and Symfony 3.3.3. The type of exploitation is: remote. The component is: Password validator.

CVE-2016-2403: Unauthorized access on a misconfigured Ldap server when using an empty password

CVE-2019-10910: Check service IDs are valid

An issue was discovered in Symfony 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. Serializing certain cache adapter interfaces could result in remote code injection. This is related to symfony/cache.

CVE-2019-10913: Reject invalid HTTP method overrides

An issue was discovered in Symfony before 4.2.12 and 4.3.x before 4.3.8. The VarExport component incorrectly escapes strings, allowing some specially crafted ones to escalate to execution of arbitrary PHP code. This is related to symfony/var-exporter.

Description

X509Authenticator implements client-certificate (mTLS) authentication: the web server validates the client's certificate against a trusted CA, then passes the certificate's Subject DN (Distinguished Name: a string like CN=Alice,O=Example,emailAddress=alice@example.com) to Symfony via $SERVER['SSLCLIENTSDN']. Symfony extracts the user identifier from that string.

The extraction uses an unanchored regex that matches emailAddress= anywhere in the DN string: including inside the value of a different RDN (Relative Distinguished Name: one key=value component of the DN), such as CN. An attacker who can obtain a certificate from a trusted CA with a free-text CN can smuggle emailAddress=victim@target inside the CN value and be authenticated as the victim.

Resolution

The X509Authenticator now uses a regex that anchors the match to an RDN boundary (start of string, or following a , / / separator).

The patch for this issue is available here for branch 5.4.

Credits

Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

Description

OidcTokenHandler is Symfony's built-in access-token handler for OpenID Connect: it validates a bearer JWT and returns the authenticated user identity. It delegates claim validation to the web-token/jwt-checker library's ClaimCheckerManager.

OidcTokenHandler::verifyClaims() registers audience (aud), issuer (iss), and expiry (exp) checkers, but never passes the $mandatoryClaims argument to ClaimCheckerManager::check(). That method only validates claims that are present in the token: a checker for an absent claim is silently skipped. A validly-signed JWT that simply omits aud, iss, and exp therefore passes verification.

Resolution

The OidcTokenHandler now calls the ClaimCheckerManager with the list of mandatory claims so that tokens missing aud, iss, or exp are rejected.

The patch for this issue is available here for branch 6.4.

Credits

Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

CVE-2021-32693: Authentication granted to all firewalls instead of just one

An issue was discovered in the Security component in Symfony 2.7.x before 2.7.48, 2.8.x before 2.8.41, 3.3.x before 3.3.17, 3.4.x before 3.4.11, and 4.0.x before 4.0.11. By default, a user's session is invalidated when the user is logged out. This behavior can be disabled through the invalidatesession option. In this case, CSRF tokens were not erased during logout which allowed for CSRF token fixation.

CVE-2022-24895: Possible CSRF token fixation

CVE-2021-41268: Remember me cookie persistance after password changes

CVE-2022-24894: Prevent storing cookie headers in HttpCache

CVE-2020-15094: Prevent RCE when calling untrusted remote with CachingHttpClient

CVE-2022-23601: CSRF token missing in forms

Description

Symfony Mailer selects a transport via the MAILERDSN environment variable / configuration (e.g. smtp://..., sendmail://..., native://default). SendmailTransport invokes the local sendmail binary and supports two modes: -bs (speak SMTP over stdin: the default) and -t (read the message on stdin, pass recipients as command-line arguments).

In -t mode, recipient addresses are appended to the sendmail command line without a -- end-of-options separator. A recipient address beginning with - (which Symfony\Component\Mime\Address accepts as valid) is therefore interpreted by sendmail as a command-line option rather than an address.

Resolution

The SendmailTransport transport now ensure -- is set before the list of recipients.

The patch for this issue is available here for branch 5.4.

Credits

Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

Description

Symfony\Component\Yaml\Parser resolves YAML aliases (anchor) during parsing. Aliases that reference collections (arrays, stdClass, TaggedValue-wrapped collections) can themselves point to other collections containing aliases, creating exponential expansion at resolution time. A small input can blow up into a multi-gigabyte structure and exhaust memory: the classic "Billion Laughs" denial-of-service against any parser exposed to untrusted YAML.

Resolution

The Parser now counts collection alias resolutions in a shared ParserState object, with a default limit of 128, following the SnakeYAML model. Scalar aliases remain unrestricted since they cannot drive exponential growth. The limit is configurable via a new $maxAliasesForCollections argument on Parser::construct(), Yaml::parse() and Yaml::parseFile(). A new Yaml::PARSEEXCEPTIONONALIAS flag also rejects all aliases outright when parsing fully untrusted input.

The patch for this issue is available here for branch 5.4.

Credits

Symfony would like to thank Pietro Tirenna (Shielder) for reporting the issue and Nicolas Grekas for fixing it.

Description

Symfony\Component\Yaml\Parser::cleanup() strips the optional %YAML directive header, leading comments, and document start/end markers before parsing. The original regexes contained overlapping quantifiers, most notably '#^%YAML[: ][\d.]+.\n#u', whose [\d.]+ and . overlap on the dot, that exhibit catastrophic backtracking on crafted input. A single oversized %YAML directive header (or comment / document-marker line) makes the parser hang for an arbitrarily long time, denying service.

Resolution

The four regexes in Parser::cleanup() (YAML directive header, leading comments, document-start marker, document-end marker) have been rewritten with possessive quantifiers and unambiguous character classes so backtracking cannot occur.

The patch for this issue is available here for branch 5.4.

Credits

Symfony would like to thank Pietro Tirenna (Shielder) for reporting the issue and Nicolas Grekas for fixing it.

Description

symfony/dom-crawler provides the Crawler class for navigating HTML/XML documents with CSS/XPath selectors; symfony/browser-kit's HttpBrowser uses it to parse fetched pages.

Crawler::addXmlContent() sets DOMDocument::$validateOnParse = true before calling loadXML(). Setting validateOnParse re-enables libxml's DTD subset processing, including external entity resolution, even though LIBXMLNONET is passed. LIBXMLNONET blocks network fetches but not file:// entities. An attacker-supplied XML document with a SYSTEM "file:///etc/passwd" entity is therefore expanded.

Resolution

The Crawler::addXmlContent method does not set the validateOnParse flag anymore.

The patch for this issue is available here for branch 5.4.

Credits

Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.

Description

When a firewall is configured with form-login (or any authenticator using DefaultAuthenticationFailureHandler) and the failureforward: true option, the handler reads the failurepath parameter from the failing login request and uses it as the path of an internal subrequest dispatched through HttpKernelInterface::SUBREQUEST.

Symfony's Firewall::onKernelRequest listener intentionally skips subrequests under the assumption they are internally generated and trusted, which also means AccessListener (the listener that evaluates accesscontrol) does not run. Because the attacker controls the target of the subrequest, an unauthenticated POST to the check path with failurepath=/admin/whatever performs a local request forgery that executes the target controller outside the firewall perimeter and returns its response to the caller.

Applications that follow Symfony's recommended best practice of protecting administrative areas with broad accesscontrol rules (e.g. ^/admin requires ROLEADMIN) and expose read-only GET endpoints under that area (data exports, internal APIs, account views) are fully exposed: any such GET route can be read by an unauthenticated attacker without any developer misconfiguration, debug mode, or state-changing GET handler being required.

Resolution

DefaultAuthenticationFailureHandler no longer honors the request-supplied failurepath parameter when failureforward is enabled. The subrequest is always dispatched to the configured failurepath option (defaulting to loginpath), which is set by the application owner and not by the request. The redirect branch (failureforward: false) is unchanged because redirects re-enter the firewall on the next request and are not subject to this bypass.

The patch for this issue is available here for branch 5.4.

Credits

Symfony would like to thank Nguyen Ngoc Toan Thang (@a-tt-om) and Tran Quoc Tri Trung (@teebow1e) for reporting the issue, and Nicolas Grekas for providing the fix.

Description

Symfony\Bridge\Monolog\Command\ServerLogCommand (the server:log console command) is a development-time helper that opens a TCP listener and displays log records pushed to it by the application's logging pipeline. Two unsafe defaults combine into a remotely reachable PHP object-deserialization sink:

1. The listener binds to 0.0.0.0:9911 by default; it accepts connections on every interface, not only loopback. 2. Each received frame is processed as unserialize(base64decode($message)) without an allowedclasses allowlist, without authentication, and without any integrity check. The decoded value is then passed to displayLog(..., array $record) which assumes (without validating) that the result is an array.

Any host that can reach TCP port 9911 on a machine running server:log can therefore submit attacker-chosen serialized PHP payloads. The minimum impact is an unauthenticated denial of service (sending a non-array, e.g. serialize(new stdClass()), crashes the listener with a type error). Object injection with magic-method side effects (wakeup() / destruct() / etc.) is reachable before the array type-check fires; full remote code execution is environment-dependent and contingent on usable gadget chains in the autoload set of the target process.

Resolution

The server:log command no longer binds to all interfaces by default: the default --host is now 127.0.0.1:9911, requiring explicit opt-in to accept off-host traffic. Message decoding is gated by an unserialize() allowlist restricted to the Symfony\Component\VarDumper\Caster\ and Symfony\Component\VarDumper\Cloner\ classes that legitimately appear inside dumped log records; any other class is rejected and the record discarded.

The patch for this issue is available here for branch 5.4.

Credits

Symfony would like to thank Toàn Thắng and Sam Sanoop for reporting the issue and Nicolas Grekas for fixing it.

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('ROLEADMIN', 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 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.

Description

CVE-2024-50340 (GHSA-x8vp-gf4q-mw5j) addressed an issue where, with registerargcargv=On, a crafted query string let an unauthenticated GET change the kernel environment and debug flag by feeding --env/--no-debug through $SERVER['argv']. The fix shipped in symfony/runtime 5.4.46 / 6.4.14 / 7.1.7 gated the argv read on empty($GET) as a proxy for "is this a CLI invocation".

That proxy is unsafe: parsestr() (which builds $GET) and the web SAPI (which builds $SERVER['argv'] from the raw query when registerargcargv=On) do not agree on every input, so an attacker can craft a query that leaves $GET empty while $SERVER['argv'] carries the attacker's flags. SymfonyRuntime::getInput() then parses them, restoring the exact primitive CVE-2024-50340 was meant to prevent.

Preconditions and impact match the original CVE: web SAPI, registerargcargv=On, app booted through symfony/runtime; from an unauthenticated GET an attacker can flip APPENV and toggle APPDEBUG.

Resolution

SymfonyRuntime now gates the argv read on isset($SERVER['QUERYSTRING']) rather than on empty($GET). QUERYSTRING is the same input the SAPI uses to build argv, so the security check and the thing it protects no longer parse different sources. Worker SAPIs (FrankenPHP / RoadRunner / Swoole) keep working because the runtime constructor runs once at boot when QUERYSTRING is unset.

The patch for this issue is available here for branch 5.4.

Credits

SymfonyRuntime would like to thank 0xEr3n for reporting the issue and Nicolas Grekas for providing the fix.

Description

Symfony\Component\Yaml\Parser is the entry point for parsing YAML strings into PHP values via Yaml::parse(). When the parser is exposed to attacker-controlled input, deeply nested mappings or sequences cause both the block-level (Parser::parseBlock()) and inline (Inline::parseSequence() / Inline::parseMapping()) parsers to recurse without a depth limit. A crafted document exhausts the PHP stack and crashes the worker.

Resolution

The Parser now tracks recursion depth in a shared ParserState object across both block-level and inline parsing, with a default limit of 128. The limit is configurable via a new $maxNestingLevel argument on Parser::construct(), Yaml::parse() and Yaml::parseFile().

The patch for this issue is available here for branch 5.4.

Credits

Symfony would like to thank Pietro Tirenna (Shielder) for reporting the issue and Nicolas Grekas for fixing it.

Description

The JsonPath component's match() and search() filter functions compile a caller-supplied pattern straight into pregmatch():

php 'match' => @pregmatch(\sprintf('/^%s$/u', $this->transformJsonPathRegex($argList[1])), $value), 'search' => @pregmatch("/{$this->transformJsonPathRegex($argList[1])}/u", $value),

transformJsonPathRegex() only performs cosmetic escaping: there is no length cap, no restriction to the RFC 9485 i-regexp subset, and no bound on backtracking. An application that evaluates an attacker-influenced JSONPath expression server-side (e.g. one taken from a query parameter or API field and passed to JsonCrawler) can therefore be made to run a catastrophic-backtracking pattern such as $[?search(@, "(a+)+$")]. Evaluated against a moderately sized document, this pins a CPU core for seconds per request, so a handful of concurrent requests exhausts the worker pool: a denial of service. Because the pregmatch() calls are prefixed with @, the PCRE backtrack-limit errors that would otherwise surface are suppressed, leaving no log trace.

Conditions for exploitation

An application that evaluates an attacker-influenced JSONPath expression containing a match() / search() filter against any non-trivial JSON input.

Resolution

JsonCrawler runs the pregmatch() calls through a helper that lowers pcre.backtracklimit to 10000 for the duration of the call (restoring the previous value afterwards), so a pathological pattern fails fast instead of stalling the worker.

The patch for this issue is available here for branch 7.4.

Credits

Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois for providing the fix.

An issue was discovered in the Security component in Symfony 2.7.x before 2.7.48, 2.8.x before 2.8.41, 3.3.x before 3.3.17, 3.4.x before 3.4.11, and 4.0.x before 4.0.11. A session fixation vulnerability within the "Guard" login feature may allow an attacker to impersonate a victim towards the web application if the session id value was previously known to the attacker.

CVE-2020-5275: All rules set in "accesscontrol" are required when the firewall is configured with the unanimous strategy

php-symfony2-Validator has loss of information during serialization