#php

A potential hostname injection vulnerability has been found which could allow attackers to alter url resolution. If a request contains the X-Forwarded-Host HTTP header a website would then use its value in place of the actual HTTP hostname. In cases where caching is enabled, this could allow an attacker to potentially embed a remote url as the base_url for any site. This would then cause other visitors to the site to be redirected unknowingly. This header is necessary for servers running behind a reverse proxy (such as nginx). Such servers are likely not vulnerable to this risk. A fix has been merged into the default installer, although existing projects which do not run behind a reverse proxy should update their htaccess as below: ``` <IfModule mod_headers.c> # Remove X-Forwarded-Host header sent as a part of any request from the web RequestHeader unset X-Forwarded-Host </IfModule> ```

A Server-Side Request Forgery (SSRF) vulnerability in the /Upgrade/FixConfig route in Open Library Foundation VuFind 2.0 through 9.1 before 9.1.1 allows a remote attacker to overwrite local configuration files to gain access to the administrator panel and achieve Remote Code Execution. A mitigating factor is that it requires the allow_url_include PHP runtime setting to be on, which is off in default installations. It also requires the /Upgrade route to be exposed, which is exposed by default after installing VuFind, and is recommended to be disabled by setting autoConfigure to false in config.ini.

A Server-Side Request Forgery (SSRF) vulnerability in the /Cover/Show route (showAction in CoverController.php) in Open Library Foundation VuFind 2.4 through 9.1 before 9.1.1 allows remote attackers to access internal HTTP servers and perform Cross-Site Scripting (XSS) attacks by proxying arbitrary URLs via the proxy GET parameter.

This Metasploit module exploits an unauthenticated remote code execution vulnerability in the WWBNIndex plugin of the AVideo platform. The vulnerability exists within the submitIndex.php file, where user-supplied input is passed directly to the require() function without proper sanitization. By exploiting this, an attacker can leverage the PHP filter chaining technique to execute arbitrary PHP code on the server. This allows for the execution of commands and control over the affected system. The exploit is particularly dangerous because it does not require authentication, making it possible for any remote attacker to exploit this vulnerability.

The PHP file view/about.php is vulnerable to an XSS issue due to no sanitization of the user agent. At line [53], the website gets the user-agent from the headers through $_SERVER['HTTP_USER_AGENT'] and echo it without any sanitization. In PHP, echo a user generated statement, here the User-Agent Header, without any sanitization allows an attacker to inject malicious scripts into the output of a web page, which are then executed in the browser of anyone viewing that page.

The service offered by Pusher provides "private" channels with an authentication mechanism that restricts subscription access. The decision on allowing subscriptions to private channels is delegated to customers, who implement an authentication endpoint. End-users request a token from this endpoint to join a specific channel. The token is an HMAC signature of the end-user's connection ID (socket_id) and the desired channel. The issue arises from a lack of validation in the libraries provided to customers. This vulnerability allows a malicious end-user to submit a malformed socket_id field, leading the customer to unknowingly sign a string. This signed string grants access to a different private channel than the one the end-user is ostensibly requesting. Consequently, a malicious end-user, with permission to subscribe to one private channel, can forge permission for any private channel owned by the same customer. Additionally, the HTTP API is secured by requiring a signature with each...

The limit() query method is susceptible to catastrophic SQL injection with MySQL. For example, given a model User for a table users: ``` UserQuery::create()->limit('1;DROP TABLE users')->find(); ``` This will drop the users table! The cause appears to be a lack of integer casting of the limit input in either Propel\Runtime\ActiveQuery\Criteria::setLimit() or in Propel\Runtime\Adapter\Pdo\MysqlAdapter::applyLimit(). The code comments there seem to imply that casting was avoided due to overflow issues with 32-bit integers. This is surprising behavior since one of the primary purposes of an ORM is to prevent basic SQL injection. This affects all versions of Propel: 1.x, 2.x, and 3.

Versions preceding 0.6.1 of the phpxmlrpc/extras project are susceptible to a Cross-Site Scripting (XSS) vulnerability. This vulnerability exists within the class documenting_xmlrpc_server when processing the GET methodName parameter.

Passbolt uses three cookies: a session cookie, a CSRF protection cookie and a cookie to keep track of the multiple-factor authentication process. Both the session cookie and the mfa cookie are properly set HTTP-only to prevent an attacker from retrieving the content of those cookies if they managed to exploit an XSS. The /auth/verify.json endpoint returns a JSON that, among other things, contains the cookies sent in the request. (similar to the TRACE HTTP method) An attacker who manages to leverage an XSS vulnerability could retrieve the session cookies of a legitimate user, effectively granting them the ability to retrieve information (such as encrypted password list or group list) without requiring user interaction. This vulnerability has a low impact, but no immediate risk due to it requiring the exploitation of an XSS vulnerability that has yet to be found.

Vulnerability in onelogin/php-saml versions prior to 2.10.0 allows signature Wrapping attacks which may result in a malicious user gaining unauthorized access to a system.