ghsa

### Impact Since PrestaShop 8.1.5, any invoice can be downloaded from front-office in anonymous mode, by supplying a random secure_key parameter in the url. ### Patches Patched in 8.1.6 ### Workarounds Upgrade to 8.1.6 Thank you to Samuel Bodevin, who found this vulnerability and shared it with the PrestaShop team.

### Impact Only PrestaShops with customer-thread feature flag enabled are impacted, starting from PrestaShop 8.1.0. The impact is substantial, when the customer thread feature flag is enabled, through the front-office contact form, a hacker can upload a malicious file containing an XSS that will be executed when an admin opens the attached file in back office. Consequence: the script injected can access the session and the security token, which allows it to perform any authenticated action in the scope of the administrator's right. ### Patches This vulnerability is patched in 8.1.6. ### Workarounds As long as you have not upgraded to 8.1.6, a simple workaround is to disable the customer-thread feature-flag. Thank you to Ayoub AIT ELMOKHTAR, who discovered this vulnerability and share it with the PrestaShop team.

### Impact Any user authorized to connect to a ssh server using `sshproxy` can inject options to the `ssh` command executed by `sshproxy`. All versions of `sshproxy` are impacted. ### Patches The problem is patched starting on version 1.6.3 ### Workarounds The only workaround is to use the `force_command` option in `sshproxy.yaml`, but it's rarely relevant. ### References

### Impact Scrapy was following redirects regardless of the URL protocol, so redirects were working for `data://`, `file://`, `ftp://`, `s3://`, and any other scheme defined in the `DOWNLOAD_HANDLERS` setting. However, HTTP redirects should only work between URLs that use the `http://` or `https://` schemes. A malicious actor, given write access to the start requests (e.g. ability to define `start_urls`) of a spider and read access to the spider output, could exploit this vulnerability to: - Redirect to any local file using the `file://` scheme to read its contents. - Redirect to an `ftp://` URL of a malicious FTP server to obtain the FTP username and password configured in the spider or project. - Redirect to any `s3://` URL to read its content using the S3 credentials configured in the spider or project. For `file://` and `s3://`, how the spider implements its parsing of input data into an output item determines what data would be vulnerable. A spider that always outputs the enti...

### Impact When using system proxy settings, which are scheme-specific (i.e. specific to `http://` or `https://` URLs), Scrapy was not accounting for scheme changes during redirects. For example, an HTTP request would use the proxy configured for HTTP and, when redirected to an HTTPS URL, the new HTTPS request would still use the proxy configured for HTTP instead of switching to the proxy configured for HTTPS. Same the other way around. If you have different proxy configurations for HTTP and HTTPS in your system for security reasons (e.g., maybe you don’t want one of your proxy providers to be aware of the URLs that you visit with the other one), this would be a security issue. ### Patches Upgrade to Scrapy 2.11.2. ### Workarounds Replace the built-in retry middlewares (`RedirectMiddleware` and `MetaRefreshMiddleware`) and the `HttpProxyMiddleware` middleware with custom ones that implement the fix from Scrapy 2.11.2, and verify that they work as intended. ### References This ...

### Impact Since version 2.11.1, Scrapy drops the `Authorization` header when a request is redirected to a different domain. However, it keeps the header if the domain remains the same but the scheme (http/https) or the port change, all scenarios where the header should also be dropped. In the context of a man-in-the-middle attack, this could be used to get access to the value of that `Authorization` header ### Patches Upgrade to Scrapy 2.11.2. ### Workarounds There is no easy workaround for unpatched versions of Scrapy. You can replace the built-in redirect middlewares with custom ones patched for this issue, but you have to patch them yourself, manually. ### References This security issue was reported and fixed by @szarny at https://huntr.com/bounties/27f6a021-a891-446a-ada5-0226d619dd1a/.

### Impact Input to functions such as `Client.rest.channels.removeBan` is not url-encoded, resulting in specially crafted input such as `../../../channels/{id}` being normalized into the url `/api/v10/channels/{id}`, and deleting a channel rather than removing a ban. ### Workarounds * Sanitizing user input, ensuring strings are valid for the purpose they are being used for. * Encoding input with `encodeURIComponent` before providing it to the library. ### References OceanicJS/Oceanic@8bf8ee8373b8c565fbdbf70a609aba4fbc1a1ffe

### Impact OctoPrint versions up until and including 1.10.0 contain a vulnerability that allows an unauthenticated attacker to completely bypass the authentication **if the `autologinLocal` option is enabled** within `config.yaml`, even if they come from networks that are not configured as `localNetworks`, by spoofing their IP via the `X-Forwarded-For` header. If autologin is not enabled, this vulnerability does not have any impact. ### Patches The vulnerability has been patched in version 1.10.1. ### Workaround Until the patch has been applied, OctoPrint administrators who have autologin enabled on their instances should disable it and/or to make the instance inaccessible from potentially hostile networks like the internet. ### PoC 1. Enable the `autologinAs` configuration within the `accessControl` section in the [OctoPrint yaml configuration file](https://docs.octoprint.org/en/master/configuration/config_yaml.html#access-control) 2. Set your browser to add the `X-Forwarded-F...

### Problem The `ShowImageController` (_eID tx_cms_showpic_) lacks a cryptographic HMAC-signature on the `frame` HTTP query parameter (e.g. `/index.php?eID=tx_cms_showpic?file=3&...&frame=12345`). This allows adversaries to instruct the system to produce an arbitrary number of thumbnail images on the server side. ### Solution Update to TYPO3 versions 9.5.48 ELTS, 10.4.45 ELTS, 11.5.37 LTS, 12.4.15 LTS, 13.1.1 that fix the problem described. #### ℹ️ **Strong security defaults - Manual actions required** The `frame` HTTP query parameter is now ignored, since it could not be used by core APIs. The new feature flag `security.frontend.allowInsecureFrameOptionInShowImageController` – which is disabled per default – can be used to reactivate the previous behavior. ### Credits Thanks to TYPO3 security team member Torben Hansen who reported this issue and to TYPO3 core & security team members Benjamin Mack and Benjamin Franzke who fixed the issue. ### References * [TYPO3-CORE-SA-2024-010]...

### Problem Failing to properly encode user-controlled values in file entities, the `ShowImageController` (_eID tx_cms_showpic_) is vulnerable to cross-site scripting. Exploiting this vulnerability requires a valid backend user account with access to file entities. ### Solution Update to TYPO3 versions 9.5.48 ELTS, 10.4.45 ELTS, 11.5.37 LTS, 12.4.15 LTS, 13.1.1 that fix the problem described. ### Credits Thanks to TYPO3 security team member Torben Hansen who reported this issue and to TYPO3 core & security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2024-009](https://typo3.org/security/advisory/typo3-core-sa-2024-009)