CVE-2021-21263

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.

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.

Laravel is a web application framework. Versions of Laravel before 6.20.11, 7.30.2 and 8.22.1 contain a query binding exploitation. This same exploit applies to the illuminate/database package which is used by Laravel. 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.

Laravel is a web application framework. Versions of Laravel before 6.20.11, 7.30.2 and 8.22.1 contain a query binding exploitation. This same exploit applies to the illuminate/database package which is used by Laravel. 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.

Laravel is a web application framework. Versions of Laravel before 6.20.11, 7.30.2 and 8.22.1 contain a query binding exploitation. This same exploit applies to the illuminate/database package which is used by Laravel. 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.

Description

Laravel versions <6.20.12, <7.30.3 & <8.22.1 contain a query binding exploitation.

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.

This vulnerability was discovered by Tim Groenevelt ([email protected]).

References

• https://github.com/laravel/framework/pull/35865

This is a follow-up to the previous security advisory (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.

Laravel is a web application framework. Versions of Laravel before 6.20.11, 7.30.2 and 8.22.1 contain a query binding exploitation. This same exploit applies to the illuminate/database package which is used by Laravel. 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.

TuxCare rebuilt laravel/framework to address 5 CVEs. Fixed in 5.8.38-p1+tuxcare.

TuxCare rebuilt illuminate/database to address 1 CVE. Fixed in 5.4.36-p1+tuxcare.

TuxCare rebuilt illuminate/database to address 1 CVE. Fixed in 5.4.36-p2+tuxcare.

TuxCare rebuilt laravel/framework to address 10 CVEs. Fixed in 5.4.36-p2+tuxcare.

TuxCare rebuilt laravel/framework to address 8 CVEs. Fixed in 5.5.50-p1+tuxcare.

TuxCare rebuilt laravel/framework to address 9 CVEs. Fixed in 5.6.40-p1+tuxcare.

TuxCare rebuilt laravel/framework to address 9 CVEs. Fixed in 5.7.29-p1+tuxcare.

TuxCare rebuilt laravel/framework to address 1 CVE. Fixed in 5.4.36-p3+tuxcare.

TuxCare rebuilt laravel/framework to address 3 CVEs. Fixed in 8.12.0-p1+tuxcare.

TuxCare rebuilt laravel/framework to address 8 CVEs. Fixed in 8.12.1-p1+tuxcare.

TuxCare rebuilt laravel/framework to address 8 CVEs. Fixed in 8.12.2-p1+tuxcare.

TuxCare rebuilt laravel/framework to address 8 CVEs. Fixed in 8.12.3-p1+tuxcare.

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.

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...
}

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.

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.