Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Symfony\Component\Routing\Generator\UrlGenerator::doGenerate() percent-encodes . and .. path segments so that the generated URL still resolves to the originating route after RFC 3986 §5.2.4 dot-segment removal (which strict RFC-3986 consumers — routers, reverse proxies, HTTP clients — perform before percent-decoding). The encoding was implemented as strtr($url, ['/../' = '/%2E%2E/', '/./' = '/%2E/']) plus a trailing-segment fixup. strtr advances past the trailing / of each match, so the next dot-segment in a chained sequence was left unescaped: | Input | Output (before fix) | Expected | | -------------------- | ---------------------------------------- | ----------------------------------- | | /../../../ | /%2E%2E/../%2E%2E/ | /%2E%2E/%2E%2E/%2E%2E/ | | /foo/../../../bar | /foo/%2E%2E/../%2E%2E/bar | /foo/%2E%2E/%2E%2E/%2E%2E/bar | When a route exposes a parameter constrained by a permissive requirement (.+, ., or similar) that accepts dots and slashes, attacker-controlled…
Recommended action: Upgrade to 8.0.13, 7.4.13, 6.4.41 or 5.4.53 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Symfony routes can declare a requirements regex per path parameter, e.g. a route /{locale}/blog with requirements: { locale: 'en|fr|de' }. The Twig path() / url() helpers (backed by UrlGenerator) validate supplied parameter values against that regex before building the URL. UrlGenerator constructs the validation pattern as '#^'.$req.'$#', where $req is the raw requirement string. For a requirement expressed as an alternation, e.g. locale: 'ar|bg|...|vi|...|zhCN' (very common), ^ and $ anchor only the first and last alternatives, so any middle alternative matches as an unanchored substring. A value like /evil.com satisfies the requirement (because it contains vi), and the generated path becomes //evil.com/...: a protocol-relative URL the browser navigates off-site. Resolution The UrlGenerator class now wraps the requirement in a non-capturing group so the ^ and $ anchors apply to the whole alternation. The patch for this issue is available here for branch 5.4. Credits…
Recommended action: Upgrade to 8.0.12, 7.4.12, 6.4.40 or 5.4.52 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Symfony 2.0.11 carried a [similar] XXE security fix, however, on review of ZF2 I also noted a vulnerability to XML Entity Expansion (XEE) attacks whereby all extensions making use of libxml2 have no defense against XEE Quadratic Blowup Attacks. The vulnerability is a function of there being no current method of disabling custom entities in PHP (i.e. defined internal to the XML document without using external entities). In a QBA, a long entity can be defined and then referred to multiple times in document elements, creating a memory sink with which Denial Of Service attacks against a host's RAM can be mounted. The use of the LIBXMLNOENT or equivalent option in a dependent extension amplified the impact (it doesn't actually mean "No Entities"). In addition, libxml2's innate defense against the related Exponential or Billion Laugh's XEE attacks is active only so long as the LIBXMLPARSEHUGE is NOT set (it disables libxml2's hardcoded entity recursion limit). No instances of these two…
Recommended action: Upgrade to 2.0.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On the Symfony 2.0.x version, there's a security issue that allows access to routes protected by a firewall even when the user is not logged in. Both the Routing component and the Security component uses the path returned by getPathInfo() to match a Request. The getPathInfo() returns a decoded path, but the Routing component (Symfony\Component\Routing\Matcher\UrlMatcher) decodes the path a second time; whereas the Security component, Symfony\Component\HttpFoundation\RequestMatcher, does not. This difference causes Symfony 2.0 to be vulnerable to double encoding attacks.
Recommended action: Upgrade to 2.0.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.