What to expect in the next generation of Laravel Forge. Read the blog post
Blog /

Announcement

Announcement August 7, 2020

Security Release: Laravel 6.18.35, 7.24.0

**Note: This security patch only affects applications using the `$guarded` property on models. In addition, applications that set `$guarded` to `[]` or `['*']` are not affected by the bug described in this post.** Today we are releasing a follow-up to yesterday's security patches. Today's patch secures another subtle security issue when using `$request->all()` to update Eloquent's models that use the `$guarded` property. When listing individual columns in the `$guarded` property, any columns that are not included in the list can be updated via mass assignment. This is expected behavior. However, unexpected updates may happen if requests are crafted to contain JSON column nesting expressions (`{"foo->bar": "value"}`). Even if the JSON `foo` column is guarded, this expression could update the `bar` JSON key within the column (because `foo->bar` is not listed in the guarded clause). Today's patch fixes this and other potential unexpected behaviors by comparing the column that is being updated with an actual list of database columns that exist on the database table. We retrieve this column list using Laravel's schema inspection facilities that already existed in the framework. Note that this will introduce one extra database query to retrieve the column listing when attempting to mass assign attributes to a model that is using the `$guarded` property. If the `$guarded` property is empty or is set to `['*']` the extra query is unnecessary and will not be executed. Applications that use `$fillable` are already protected by default and do not require us to confirm the column's validity. **As a personal recommendation, I recommend always using `$fillable` instead of `$guarded`. In general, `$fillable` is a safer approach to mass assignment protection because you are forced to list any new columns added to the database to the `$fillable` array. In contrast, you may easily forget to add a new column to a `$guarded` array, leaving it open for mass assignment by default.**

Taylor Otwell

Announcement August 6, 2020

Security Release: Laravel 6.18.34, 7.23.2

Today we released a security patch for Laravel 6.x and 7.x. In previous releases of Laravel, 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 be able to upgrade without issues.**

Taylor Otwell

Announcement July 27, 2020

Security Release: Laravel 6.18.29, 7.22.2

Today we have released a security patch for Laravel versions 6.x and 7.x. These releases have been released as Laravel 6.18.29 and 7.22.2. All Laravel users are encouraged to upgrade to these versions as soon as possible. Upgrading to these versions will invalidate any existing cookies issued by your application; therefore, your application's users will need to re-authenticate. **Update:** Passport 9.3.2 has been released in order to provide compatibility with this security release.

Taylor Otwell

Announcement May 8, 2020

Passport v9.1.0 Breaking Changes

After the v9.0.0 release for Passport on Tuesday, we discovered an incompatibility with Personal Access Clients and the new client secret hashing feature. The fix that required for this introduces a breaking change for anyone who has already hashed the secret key of their Personal Access Client. > These steps are only necessary if you have already upgraded to v9 and already hashed your client secrets. When using the client secret hashing is to generate a new Personal Access Client for your application using the `passport:client` command, your plain-text client secret will be displayed once: ``` php artisan passport:client --personal  ``` After copying your client ID and secret you should place them in your `.env` file using the following environment variables: ``` PASSPORT_PERSONAL_ACCESS_CLIENT_ID=client-id-value PASSPORT_PERSONAL_ACCESS_CLIENT_SECRET=unhashed-client-secret-value ``` Finally, you should register them in the "boot" method of your "AppServiceProvider": ``` Passport::personalAccessClientId( config('passport.personal_access_client.id') ); Passport::personalAccessClientSecret( config('passport.personal_access_client.secret') ); ``` Your new Personal Access Client will now be used to issue new personal access tokens. Any previously issued tokens will be invalid and will need to be re-generated. For full details regarding upgrading to Passport v9 please [see the upgrade guide](https://github.com/laravel/passport/blob/9.x/UPGRADE.md#client-credentials-secret-hashing).

Dries Vints

Showing 11 - 20 of 85 results

Stay connected with the latest Laravel news