ghsa

### Summary A ReDoS vulnerability occurs when nodemailer tries to parse img files with the parameter `attachDataUrls` set, causing the stuck of event loop. Another flaw was found when nodemailer tries to parse an attachments with a embedded file, causing the stuck of event loop. ### Details Regex: /^data:((?:[^;]*;)*(?:[^,]*)),(.*)$/ Path: compile -> getAttachments -> _processDataUrl Regex: /(<img\b[^>]* src\s*=[\s"']*)(data:([^;]+);[^"'>\s]+)/ Path: _convertDataImages ### PoC https://gist.github.com/francoatmega/890dd5053375333e40c6fdbcc8c58df6 https://gist.github.com/francoatmega/9aab042b0b24968d7b7039818e8b2698 ### Impact ReDoS causes the event loop to stuck a specially crafted evil email can cause this problem.

### Impact It is possible to craft an OCI tar archive that, when stereoscope attempts to unarchive the contents, will result in writing to paths outside of the unarchive temporary directory. Specifically, use of `github.com/anchore/stereoscope/pkg/file.UntarToDirectory()` function, the `github.com/anchore/stereoscope/pkg/image/oci.TarballImageProvider` struct, or the higher level `github.com/anchore/stereoscope/pkg/image.Image.Read()` function express this vulnerability. ### Patches Patched in v0.0.1 ### Workarounds If you are using the OCI archive as input into stereoscope then you can switch to using an [OCI layout](https://github.com/opencontainers/image-spec/blob/main/image-layout.md) by unarchiving the tar archive and provide the unarchived directory to stereoscope. ### References - Patch PR https://github.com/anchore/stereoscope/pull/214

### Summary CSV injection is a vulnerability where untrusted user input in CSV files can lead to unauthorized access or data manipulation. In my subsequent testing of the application. ### Details I discovered that there is an option to "Export Data" from the web app to your personal computer, which exports a "csv" file that can be opened with Excel software that supports macros. P.S I discovered that the web application's is offering a demo-site that anyone may access to play with the web application. So, there's a chance that someone will export the data (CVS) from the demo site and execute it on their PC, giving the malicious actor a complete control over their machine. (if a user enters a malicious payload to the website). ### PoC You can check out my vulnerability report if you need more details/PoC with screenshots: (removed by JC5) ### Impact An attacker can exploit this by entering a specially crafted payload to one of the fields, and when a user export the csv file using ...

### Description: When the application is password-protected (deployed with the `ACCESS_CODE` option), it is possible to access plugins without proper authorization (without password). ### Proof-of-Concept: Let’s suppose that application has been deployed with following command: ```sudo docker run -d -p 3210:3210 -e OPENAI_API_KEY=sk-[REDACTED] -e ACCESS_CODE=TEST123 --name lobe-chat lobehub/lobe-chat``` Due to the utilization of the `ACCESS_CODE`, access to the chat is possible only after entering the password:  However, it is possible to interact with chat plugins without entering the `ACCESS_CODE`. Example HTTP request: ``` POST /api/plugin/gateway HTTP/1.1 Host: localhost:3210 Content-Length: 1276 {"apiName":"checkWeatherUsingGET","arguments":"{\n \"location\": \"London\"\n}","identifier":"WeatherGPT","type":"default","manifest":{"api":[{"description":"Get current weather information","name"...

### Impact OctoPrint versions up until and including 1.9.3 contain a vulnerability that allows malicious admins to change the password of other admin accounts, including their own, without having to repeat their password. An attacker who managed to hijack an admin account might use this to lock out actual admins from their OctoPrint instance. ### Patches The vulnerability will be patched in version 1.10.0. ### Workarounds OctoPrint administrators are strongly advised to thoroughly vet who has admin access to their installation. ### Credits This vulnerability was discovered and responsibly disclosed to OctoPrint by Timothy "TK" Ruppert.

# Introduction This write-up describes a vulnerability found in [Label Studio](https://github.com/HumanSignal/label-studio), a popular open source data labeling tool. The vulnerability affects all versions of Label Studio prior to [`1.11.0`](https://github.com/HumanSignal/label-studio/releases/tag/1.11.0) and was tested on version `1.8.2`. # Overview Label Studio's SSRF protections that can be enabled by setting the `SSRF_PROTECTION_ENABLED` environment variable can be bypassed to access internal web servers. This is because the current SSRF validation is done by executing a single DNS lookup to verify that the IP address is not in an excluded subnet range. This protection can be bypassed by either using HTTP redirection or performing a [DNS rebinding attack](https://en.wikipedia.org/wiki/DNS_rebinding). # Description The following `tasks_from_url` method in [`label_studio/data_import/uploader.py`](https://github.com/HumanSignal/label-studio/blob/1.8.2/label_studio/data_import/upl...

Server-Side Request Forgery (SSRF) vulnerability in Apache ServiceComb Service-Center. Attackers can obtain sensitive server information through specially crafted requests.This issue affects Apache ServiceComb before 2.1.0 (included). Users are recommended to upgrade to version 2.2.0, which fixes the issue.

Exposure of Sensitive Information to an Unauthorized Actor in Apache ServiceComb Service-Center. This issue affects Apache ServiceComb Service-Center before 2.1.0 (included). Users are recommended to upgrade to version 2.2.0, which fixes the issue.

In Spring Cloud Contract, versions 4.1.x prior to 4.1.1, versions 4.0.x prior to 4.0.5, and versions 3.1.x prior to 3.1.10, test execution is vulnerable to local information disclosure via temporary directory created with unsafe permissions through the shaded com.google.guava:guava dependency in the org.springframework.cloud:spring-cloud-contract-shade dependency.

HashiCorp Vault and Vault Enterprise versions 0.8.3 and newer, when configured with the GCP GCE auth method, may be vulnerable to authentication bypass. Fixed in 1.2.5, 1.3.8, 1.4.4, and 1.5.1.