#git

# Microsoft Security Advisory CVE-2024-30045 | .NET Remote code Execution Vulnerability ## <a name="executive-summary"></a>Executive summary Microsoft is releasing this security advisory to provide information about a vulnerability in .NET. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability. A Remote Code Execution vulnerability exists in .NET 7.0 and .NET 8.0 where a stack buffer overrun occurs in .NET Double Parse routine. ## Discussion Discussion for this issue can be found at https://github.com/dotnet/runtime/issues/102206 ## <a name="mitigation-factors"></a>Mitigation factors Microsoft has not identified any mitigating factors for this vulnerability. ## <a name="affected-software"></a>Affected software * Any .NET 7.0 application running on .NET 7.0.18 or earlier. * Any .NET 8.0 application running on .NET 8.0.4 or earlier. ## <a name="affected-packages"></a>Affected Packages The vulnerability affects...

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