ghsa

When making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same origin will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. ### Remediation Any of these options can be used to remediate the current issue, we highly recommend upgrading as the preferred mitigation. * Upgrade to `requests>=2.32.0`. * For `requests<2.32.0`, avoid setting `verify=False` for the first request to a host while using a Requests Session. * For `requests<2.32.0`, call `close()` on `Session` objects to clear existing connections if `verify=False` is used. ### Related Links * https://github.com/psf/requests/pull/6655

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.

A Prototype Pollution issue in API Dev Tools json-schema-ref-parser v.11.0.0 and v.11.1.0 allows a remote attacker to execute arbitrary code via the `bundle()`, `parse()`, `resolve()`, `dereference()` functions.

A Prototype Pollution issue in MiguelCastillo @bit/loader v.10.0.3 allows an attacker to execute arbitrary code via the M function e argument in index.js.

A Prototype Pollution issue in Blackprint @blackprint/engine 0.8.12 through 0.9.1 allows an attacker to execute arbitrary code via the `_utils.setDeepProperty` function of `engine.min.js`.

A vulnerability has been identified in the robrichards/xmlseclibs library, specifically related to XPath injection. The issue arises from inadequate filtering of user input before it is incorporated into XPath expressions.

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 Criteria::setLimit() or in DBMySQL::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.

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.