#php

A vulnerability was found in PHPList 3.2.6. It has been rated as critical. Affected by this issue is some unknown functionality of the component Subscription. The manipulation leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 3.3.1 is able to address this issue. It is recommended to upgrade the affected component.

A vulnerability, which was classified as problematic, has been found in PHPList 3.2.6. This issue affects some unknown processing of the file /lists/admin/ of the component Subscribe. The manipulation leads to cross site scripting (Persistent). The attack may be initiated remotely. Upgrading to version 3.3.1 is able to address this issue. It is recommended to upgrade the affected component.

A vulnerability classified as problematic was found in PHPList 3.2.6. This vulnerability affects unknown code of the file /lists/admin/ of the component List Name. The manipulation leads to cross site scripting (Persistent). The attack can be initiated remotely. Upgrading to version 3.3.1 is able to address this issue. It is recommended to upgrade the affected component.

A vulnerability was found in PHPList 3.2.6 and classified as critical. This issue affects some unknown processing of the file /lists/index.php of the component Edit Subscription. The manipulation leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 3.3.1 is able to address this issue. It is recommended to upgrade the affected component.

A vulnerability classified as problematic has been found in PHPList 3.2.6. This affects an unknown part of the file /lists/admin/. The manipulation of the argument page with the input send\'\";><script>alert(8)</script> leads to cross site scripting (Reflected). It is possible to initiate the attack remotely. Upgrading to version 3.3.1 is able to address this issue. It is recommended to upgrade the affected component.

A vulnerability, which was classified as problematic, was found in PHPList 3.2.6. Affected is an unknown function of the file /lists/admin/ of the component Bounce Rule. The manipulation leads to cross site scripting (Persistent). It is possible to launch the attack remotely. Upgrading to version 3.3.1 is able to address this issue. It is recommended to upgrade the affected component.

Guzzle is an open source PHP HTTP client. In affected versions `Authorization` headers on requests are sensitive information. On making a request using the `https` scheme to a server which responds with a redirect to a URI with the `http` scheme, we should not forward the `Authorization` header on. This is much the same as to how we don't forward on the header if the host changes. Prior to this fix, `https` to `http` downgrades did not result in the `Authorization` header being removed, only changes to the host. Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4. Users unable to upgrade may consider an alternative approach which would be to use their own redirect middleware. Alternately users may simply disable redirects all together if redirects are not expected or required.

Guzzle is an open source PHP HTTP client. In affected versions the `Cookie` headers on requests are sensitive information. On making a request using the `https` scheme to a server which responds with a redirect to a URI with the `http` scheme, or on making a request to a server which responds with a redirect to a a URI to a different host, we should not forward the `Cookie` header on. Prior to this fix, only cookies that were managed by our cookie middleware would be safely removed, and any `Cookie` header manually added to the initial request would not be stripped. We now always strip it, and allow the cookie middleware to re-add any cookies that it deems should be there. Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4. Users unable to upgrade may consider an alternative approach to use your own redirect middleware, rather than ours. If you do not require or expect red...

### Impact `Cookie` headers on requests are sensitive information. On making a request using the `https` scheme to a server which responds with a redirect to a URI with the `http` scheme, or on making a request to a server which responds with a redirect to a a URI to a different host, we should not forward the `Cookie` header on. Prior to this fix, only cookies that were managed by our cookie middleware would be safely removed, and any `Cookie` header manually added to the initial request would not be stripped. We now always strip it, and allow the cookie middleware to re-add any cookies that it deems should be there. ### Patches Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4. ### Workarounds An alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed...

### Impact `Authorization` headers on requests are sensitive information. On making a request using the `https` scheme to a server which responds with a redirect to a URI with the `http` scheme, we should not forward the `Authorization` header on. This is much the same as to how we don't forward on the header if the host changes. Prior to this fix, `https` to `http` downgrades did not result in the `Authorization` header being removed, only changes to the host. ### Patches Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4. ### Workarounds An alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together. ### References [RFC9110 Section 15.4](https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx) #...