An attacker can access sensitive credentials including username, password, and host information by navigating to the storage/logs/laravel.log file in Laravel-based websites and searching for 'PDO->__construct('mysql:host='. This can lead to unauthorized access to the system.
Laravel Valet v1.1.4 to v2.0.3 is vulnerable to local privilege escalation on macOS. This bug got introduced when the sudoers files got added around commit b22c60dacab55ffe2dc4585bc88cd58623ec1f40. When the valet command is installed, composer will symlink the `valet` command to /usr/local/bin. This 'command' is writable by the user that installed it. Running `valet install`, will start the install routine. The very first action taken is to stop nginx (quietly?) with `sudo` which will prompt the user for the sudo password in the command line. From here (and in fact from any point where the valet tool uses sudo) the command can execute further commands as root without any further interaction needed by the user. With this 'sudo' access, the installer does it thing, and eventually installs two new sudoers rules for homebrew and valet. The problem with the sudoers rules now is the fact that a user controlled script (rememeber the valet command is writable to my user?) is allowed to be run with root privileges. More conveniently, without a password. So, to trivially privesc using this flaw, simply edit the `valet` command and drop `/bin/bash` in there.
We can bypass laravel image file upload functionality to upload arbitary files on the web server which let us run arbitary javascript and bypass the csrf token.
Laravel is prone to a security weakness due to pseudo password hash collision. Attackers can exploit this issue to bypass intended security restrictions. This may aid in further attacks. An attacker can use a 72 character string of 'A' to match two different passwords, one being 'mysupersecretpassword' and the other being 'longcatishere'.
A vulnerability in Laravel 8.4.2 allows an attacker to execute arbitrary code on the server by exploiting the debug mode. The vulnerability is caused by the lack of input validation in the debug mode, which allows an attacker to inject malicious code into the application. The attacker can then use the debug mode to execute the code on the server. The vulnerability can be exploited by sending a specially crafted request to the application.
An authenticated user can crash the application by setting a higher value to the 'range' (default 30) parameter and sending simultaneous requests (10 simultaneous requests was enough to DoS the server in my testing).
Services By CQR