#git

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.

### Impact _What kind of vulnerability is it? Who is impacted?_ A user with permissions to view Dynamic Group records (`extras.view_dynamicgroup` permission) can use the Dynamic Group detail UI view (`/extras/dynamic-groups/<uuid>/`) and/or the members REST API view (`/api/extras/dynamic-groups/<uuid>/members/`) to list the objects that are members of a given Dynamic Group. In versions of Nautobot between 1.3.0 (where the Dynamic Groups feature was added) and 1.6.22 inclusive, and 2.0.0 through 2.2.4 inclusive, Nautobot fails to restrict these listings based on the member object permissions - for example a Dynamic Group of Device objects will list all Devices that it contains, regardless of the user's `dcim.view_device` permissions or lack thereof. ### Patches _Has the problem been patched? What versions should users upgrade to?_ Fixed in Nautobot 1.6.23 and 2.2.5. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ This vulnerabil...

### Impact [If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since) [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since) Headers when used with anonymous requests by sending a random object name requests you can figure out if the object exists or not on the server on a specific bucket and also gain access to some amount of information such as ``` Last-Modified (of the latest version) Etag (of the latest version) x-amz-version-id (of the latest version) Expires (metadata value of the latest version) Cache-Control (metadata value of the latest version) ``` This conditional check was being honored before validating if the anonymous access is indeed allowed on the metadata of an object. ### Patches Yes this issue has been already fixed in ``` commit e0fe7cc391724fc5baa85b45508f425020fe4272 (HEAD -> master, origin/master) Author: Harshavardhana <[email protected]> Date: Mon May 27 12:17:46 2024...

The Fides webserver requires a connection to a hosted PostgreSQL database for persistent storage of application data. If the password used by the webserver for this database connection includes special characters such as `@` and `$`, webserver startup fails and the part of the password following the special character is exposed in webserver error logs. This is caused by improper escaping of the SQLAlchemy password string, see [here](https://docs.sqlalchemy.org/en/14/core/engines.html#escaping-special-characters-such-as-signs-in-passwords) and [here](https://github.com/sqlalchemy/sqlalchemy/discussions/6615) for more info. ### Impact Partial exposure of hosted database password in webserver logs ### Patches The vulnerability has been patched in Fides version `2.37.0`. Users are advised to upgrade to this version or later to secure their systems against this threat. ### Workarounds There are no workarounds. ### Proof of Concept 1. Create a hosted PostgreSQL database for Fides with a...