#php

All 2.0.X, 2.1.X, 2.2.X, 2.3.X, 2.4.X, and 2.5.X versions of the Symfony HttpFoundation component are affected by this security issue. This issue has been fixed in Symfony 2.3.19, 2.4.9, and 2.5.4. Note that no fixes are provided for Symfony 2.0, 2.1, and 2.2 as they are not maintained anymore. Description When an arbitrarily long hostname is sent by a client, its parsing in `Request::getHost()` can lead to a DoS attack, due to the way we validate the hostname via a regular expression. Resolution The regular expression used to parse and validate the hostname from the HTTP request has been modified to avoid too much sensitivity to the submitted value length. The patch for this issue is available here: https://github.com/symfony/symfony/pull/11828

An application is vulnerable if it uses the client IP address as returned by the Request::getClientIp() method for sensitive decisions like IP based access control. To fix this security issue, the following changes have been made to all versions of Symfony2: A new Request::setTrustedProxies() method has been introduced and should be used intead of Request::trustProxyData() to enable the trust proxy mode. It takes an array of trusted proxy IP addresses as its argument: ``` // before (probably in your front controller script) Request::trustProxyData(); // after Request::setTrustedProxies(array('1.1.1.1')); // 1.1.1.1 being the IP address of a trusted reverse proxy ``` The Request::trustProxyData() method has been deprecated (when used, it automatically trusts the latest proxy in the chain -- which is the current remote address): ``` Request::trustProxyData(); // is equivalent to Request::setTrustedProxies(array($request->server->get('REMOTE_ADDR'))); ``` We encourage all Symfony2 use...

When investigating issue [#11093](https://github.com/symfony/symfony/issues/11093), [Jeremy Derussé](https://connect.sensiolabs.com/profile/jderusse) found a serious code injection issue in the way Symfony implements translation caching in FrameworkBundle. - Your Symfony application is vulnerable if you meet the following conditions: - You are using the Symfony translation system from FrameworkBundle (so basically if you are using Symfony full-stack -- you are not affected if you are using the Translation component with Silex for instance); You don't sanitize locales coming from a URL (any route with a _locale argument for instance): When vulnerable, an attacker can submit a non-valid locale value that can contain some PHP code that will be executed by Symfony. That's because the locale value is dumped into a PHP file generated in the cache without being sanitized first.

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 LIBXML_NOENT 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 LIBXML_PARSEHUGE is NOT set (it disables libxml2's hardcoded entity recursion limit). No instances of these two opt...

A potential deserialisation vulnerability has been identified in the symbiote/silverstripe-multivaluefield which could allow an attacker to exploit implementations of this module via object injection. Support for handling PHP objects as values in this module has been deprecated, and the serialisation technique has been switched to using JSON for handling arrays. As well as this, a potential XSS (cross-site scripting) vulnerability has been identified and remediated.

Sylius 1.0.0 to 1.0.16, 1.1.0 to 1.1.8, 1.2.0 to 1.2.1 versions of AdminBundle and ResourceBundle are affected by this security issue. This issue has been fixed in Sylius 1.0.17, 1.1.9 and 1.2.2. Development branch for 1.3 release has also been fixed. ### Description The following actions in the admin panel did not require a CSRF token: - marking order’s payment as completed - marking order’s payment as refunded - marking product review as accepted - marking product review as rejected ### Resolution The issue is fixed by adding a required CSRF token to those actions. We also fixed `ResourceController`‘s `applyStateMachineTransitionAction` method by adding a CSRF token check. If you use that action in the API context, you can disable it by adding `csrf_protection:` false to its routing configuration

Sylius 1.0.0 to 1.0.16, 1.1.0 to 1.1.8, 1.2.0 to 1.2.1 versions of AdminBundle and ResourceBundle are affected by this security issue. This issue has been fixed in Sylius 1.0.17, 1.1.9 and 1.2.2. Development branch for 1.3 release has also been fixed. ### Description The following actions in the admin panel did not require a CSRF token: - marking order’s payment as completed - marking order’s payment as refunded - marking product review as accepted - marking product review as rejected ### Resolution The issue is fixed by adding a required CSRF token to those actions. We also fixed `ResourceController`‘s `applyStateMachineTransitionAction` method by adding a CSRF token check. If you use that action in the API context, you can disable it by adding `csrf_protection:` false to its routing configuration

### Impact Template authors could inject php code by choosing a malicous file name for an extends-tag. Users that cannot fully trust template authors should update asap. ### Patches Please upgrade to the most recent version of Smarty v4 or v5. There is no patch for v3.

The vulnerability pertains to the usage of an insecure random number generator (RNG) in the "stormpath-sdk-php" library. Specifically, the issue is present in the generation of UUID (Universally Unique Identifier) version 4 within the codebase.

### Background SimpleSAMLphp 1.17 includes a preview of the new user interface to be included in the future version 2.0. This new user interface can be enabled by setting the usenewui configuration option to true, and it includes a new admin interface in a module called admin, which can be disabled. ### Description The new admin interface includes a way to view information about the host where SimpleSAMLphp is installed, by means of the phpinfo() PHP function. An endpoint that exposes the output of that function is included in the admin module for easier debugging. The aforementioned endpoint had no checks for administrator privileges. This would allow any individual to access the given endpoint without authenticating, gathering information about the affected system. ### Affected versions All SimpleSAMLphp 1.17 versions up to 1.17.7 are affected, provided that the new, experimental use interface is enabled, together with the new admin module. ### Impact An attacker could leverage t...