#php

Magento Commerce 1.14.4.0 and Open Source 1.9.4.0 have been enhanced with critical security updates to address multiple vulnerabilities, including remote code execution (RCE), cross-site scripting (XSS), cross-site request forgery (CSRF), and more. The following issues have been identified and remediated: - PRODSECBUG-1589: Stops Brute Force Requests via basic RSS authentication - MAG-23: M1 Credit Card Storage Capability - PRODSECBUG-2149: Authenticated RCE using customer import - PRODSECBUG-2159: API Based RCE Vulnerability - PRODSECBUG-2156: RCE Via Unauthorized Upload - PRODSECBUG-2155: Authenticated RCE using dataflow - PRODSECBUG-2053: Prevents XSS in Newsletter Template - PRODSECBUG-2142: XSS in CMS Preview - PRODSECBUG-1860: Admin Account XSS Attack Cessation via Filename - PRODSECBUG-2119: EE Patch to include names in templates - PRODSECBUG-2129: XSS in Google Analytics Vulnerability - PRODSECBUG-2019: Merchant Wishlist Security Strengthening - PRODSECBUG-2104: Send to a Frie...

Magento Commerce 1.14.3.9 and Open Source 1.9.3.9 bring essential security enhancements with Patch SUPEE-10752. These updates address various vulnerabilities, including authenticated Admin user remote code execution (RCE), cross-site request forgery (CSRF), and more. Key Security Improvements: - APPSEC-2001: Authenticated Remote Code Execution (RCE) using custom layout XML - APPSEC-2015: Authenticated Remote Code Execution (RCE) through the Create New Order feature (Commerce only) - APPSEC-2042: PHP Object Injection and RCE in the Magento admin panel (Commerce Target Rule module) - APPSEC-2029: PHP Object Injection and Remote Code Execution (RCE) in the Admin panel (Commerce) - APPSEC-2007: Authenticated SQL Injection when saving a category - APPSEC-2027: CSRF is possible against Web sites, Stores, and Store Views - APPSEC-1882: The cron.php file can leak database credentials - APPSEC-2006: Stored cross-site scripting (XSS) through the Enterprise Logging extension - APPSEC-2005: Pers...

### Impact Those using SQL Server with Laravel and allowing user input to be passed directly to the limit and offset functions are vulnerable to SQL injection. Other database drivers such as MySQL and Postgres are not affected by this vulnerability. ### Patches This problem has been patched on Laravel versions 6.20.26, 7.30.5, and 8.40.0. ### Workarounds You may workaround this vulnerability by ensuring that only integers are passed to the limit and offset functions, as well as the skip and take functions.

This is a follow-up to the security advisory https://github.com/laravel/framework/security/advisories/GHSA-3p32-j457-pg5x which addresses a few additional edge cases. If a request is crafted where a field that is normally a non-array value is an array, and that input is not validated or cast to its expected type before being passed to the query builder, an unexpected number of query bindings can be added to the query. In some situations, this will simply lead to no results being returned by the query builder; however, it is possible certain queries could be affected in a way that causes the query to return unexpected results.

In laravel releases before 6.18.34 and 7.23.2. It was possible to mass assign Eloquent attributes that included the model's table name: ``` $model->fill(['users.name' => 'Taylor']); ``` When doing so, Eloquent would remove the table name from the attribute for you. This was a "convenience" feature of Eloquent and was not documented. However, when paired with validation, this can lead to unexpected and unvalidated values being saved to the database. For this reason, we have removed the automatic stripping of table names from mass-asignment operations so that the attributes go through the typical "fillable" / "guarded" logic. Any attributes containing table names that are not explicitly declared as fillable will be discarded. This security release will be a breaking change for applications that were relying on the undocumented table name stripping during mass assignment. Since this feature was relatively unknown and undocumented, we expect the vast majority of Laravel applications to b...

The Laravel Encrypter component is susceptible to a vulnerability that may result in decryption failure, leading to an unexpected return of `false`. Exploiting this issue requires the attacker to manipulate the encrypted payload before decryption. When combined with weak type comparisons in the application's code, such as the example below: ``` <?php $decyptedValue = decrypt($secret); if ($decryptedValue == '') { // Code is run even though decrypted value is false... } ```

Laravel 4.1.26 introduces security improvements for "remember me" cookies. Before this update, if a remember cookie was hijacked by another malicious user, the cookie would remain valid for a long period of time, even after the true owner of the account reset their password, logged out, etc. This change requires the addition of a new remember_token column to your users (or equivalent) database table. After this change, a fresh token will be assigned to the user each time they login to your application. The token will also be refreshed when the user logs out of the application. The implications of this change are: if a "remember me" cookie is hijacked, simply logging out of the application will invalidate the cookie.

A potential exploit of the Laravel Encrypter component that may cause the Encrypter to fail on decryption and unexpectedly return false. To exploit this, the attacker must be able to modify the encrypted payload before it is decrypted. Depending on the code within your application, this could lead to unexpected behavior when combined with weak type comparisons, for example: ```php <?php $decyptedValue = decrypt($secret); if ($decryptedValue == '') { // Code is run even though decrypted value is false... } ```

Application's using the "cookie" session driver were the primary applications affected by this vulnerability. Since we have not yet released a security release for the Laravel 5.5 version of the framework, we recommend that all applications running Laravel 5.5 and earlier do not use the "cookie" session driver in their production deployments. Regarding the vulnerability, applications using the "cookie" session driver that were also exposing an encryption oracle via their application were vulnerable to remote code execution. An encryption oracle is a mechanism where arbitrary user input is encrypted and the encrypted string is later displayed or exposed to the user. This combination of scenarios lets the user generate valid Laravel signed encryption strings for any plain-text string, thus allowing them to craft Laravel session payloads when an application is using the "cookie" driver. This fix prefixes cookie values with an HMAC hash of the cookie's name before encryption and then ver...

Laravel 4.1.26 introduces security improvements for "remember me" cookies. Before this update, if a remember cookie was hijacked by another malicious user, the cookie would remain valid for a long period of time, even after the true owner of the account reset their password, logged out, etc. This change requires the addition of a new remember_token column to your users (or equivalent) database table. After this change, a fresh token will be assigned to the user each time they login to your application. The token will also be refreshed when the user logs out of the application. The implications of this change are: if a "remember me" cookie is hijacked, simply logging out of the application will invalidate the cookie.