ghsa

### 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)

### Problem The form manager backend module is vulnerable to cross-site scripting. Exploiting this vulnerability requires a valid backend user account with access to the form module. ### 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 core & security team member Benjamin Franzke who reported and fixed the issue. ### References * [TYPO3-CORE-SA-2024-008](https://typo3.org/security/advisory/typo3-core-sa-2024-008)

### Problem The history backend module is vulnerable to HTML injection. Although Content-Security-Policy headers effectively prevent JavaScript execution, adversaries can still inject malicious HTML markup. Exploiting this vulnerability requires a valid backend user account. ### Solution Update to TYPO3 version 13.1.1 that fixes the problem described. ### Credits Thanks to TYPO3 core team member Andreas Kienast who reported this issue and to TYPO3 core & security team Benjamin Franzke who fixed the issue. ### References * [TYPO3-CORE-SA-2024-007](https://typo3.org/security/advisory/typo3-core-sa-2024-007)

Microsoft Power BI Client JavaScript SDK Information Disclosure Vulnerability