#vulnerability

Laravel 4.1.29 improves the column quoting for all database drivers. This protects your application from some mass assignment vulnerabilities when not using the fillable property on models. If you are using the fillable property on your models to protect against mass assignment, your application is not vulnerable. However, if you are using guarded and are passing a user controlled array into an "update" or "save" type function, you should upgrade to 4.1.29 immediately as your application may be at risk of mass assignment.

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.

A Local File Inclusion (LFI) vulnerability has been discovered in the gregwar/rst library, potentially exposing sensitive files on the server to unauthorized users. The issue arises from inadequate input validation, allowing an attacker to manipulate file paths and include arbitrary files.

Several widely-used JSON Web Token (JWT) libraries, including node-jsonwebtoken, pyjwt, namshi/jose, php-jwt, and jsjwt, are affected by critical vulnerabilities that could allow attackers to bypass the verification step when using asymmetric keys (RS256, RS384, RS512, ES256, ES384, ES512).

This vulnerability may cause OS commands to be executed when you pass unvalidated image filenames containing specially crafted strings to the ImageMagick driver.

Versions of FOSUserBundle prior to 1.2.1 have been found to be vulnerable to a security issue related to user identity validation. Specifically, user refreshing was performed using the primary key instead of the username, leading to a potential security risk if a user is allowed to change their username. The fix in version 1.2.1 addresses this issue by loading the user using the primary key during refreshing.

Versions of FOSUserBundle from 1.2.x to 1.2.4 have been found to contain a security vulnerability related to session hijacking. This issue has been addressed in version 1.2.4, and users are strongly advised to upgrade to the latest version to prevent potential session-related security risks.

### Description Because of the usage of base_convert which looses precision for large inputs, the entropy of tokens generated by FOSUserBundle for the email confirmation and password resetting is lost. This makes these tokens much less random than they are expected to be, and so not cryptographically safe. ### Resolution The token generation logic used in the 2.0.x branch based on base64 encoding has been backported. This changes the range of characters used in the token. Any route placeholder expected to match a token generated by FOSUserBundle must be updated to allow dashes, which are not allowed by \w in regexes. A \w+ requirement should so become [\w\-]+.

Starting with FOSRestBundle 1.2 we [switched](https://github.com/FriendsOfSymfony/FOSRestBundle/pull/642/files#diff-431bc57ca9ca16332c0cff43ad45263cR37) to using [willdurand/jsonp-callback-validator](https://github.com/willdurand/JsonpCallbackValidator) for validation of JSONP callbacks. However [the change was implemented](https://github.com/FriendsOfSymfony/FOSRestBundle/pull/665) incorrectly validating the callback query param name, rather than its value. Anyone using the JSONP handler (which is off by default) together with FOSRestBundle 1.2.0 or 1.2.1 should update to FOSRestBundle [1.2.2](https://github.com/FriendsOfSymfony/FOSRestBundle/releases/tag/1.2.2).