ghsa

### Impact This is a critical network security vulnerability for Akka.Remote **users who have SSL / TLS enabled** on their Akka.Remote connections and were expecting certificate-based authentication to be enforced on all peers attempting to join the network. In all versions of Akka.Remote from v1.2.0 to v1.5.51, TLS could be enabled via our `akka.remote.dot-netty.tcp` transport and this would correctly enforce private key validation on the server-side of inbound connections. Akka.Remote, however, never asked the outbound-connecting client to present ITS certificate - therefore it's possible for untrusted parties to connect to a private key'd Akka.NET cluster and begin communicating with it **without any certificate**. The issue here is that for certificate-based authentication to work properly, ensuring that all members of the Akka.Remote network are secured with the same private key, Akka.Remote needed to implement mutual TLS. This was not the case before Akka.NET v1.5.52. If you...

## Summary `Rack::Multipart::Parser` can accumulate unbounded data when a multipart part’s header block never terminates with the required blank line (`CRLFCRLF`). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS). ## Details While reading multipart headers, the parser waits for `CRLFCRLF` using: ```ruby @sbuf.scan_until(/(.*?\r\n)\r\n/m) ``` If the terminator never appears, it continues appending data (`@sbuf.concat(content)`) indefinitely. There is no limit on accumulated header bytes, so a single malformed part can consume memory proportional to the request body size. ## Impact Attackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency. All applications handling multipart uploads may be affected. ## Mitigation * Upgrade to a patched Rack vers...

## Summary `Rack::Multipart::Parser` stores non-file form fields (parts without a `filename`) entirely in memory as Ruby `String` objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS). ## Details During multipart parsing, file parts are streamed to temporary files, but non-file parts are buffered into memory: ```ruby body = String.new # non-file → in-RAM buffer @mime_parts[mime_index].body << content ``` There is no size limit on these in-memory buffers. As a result, any large text field—while technically valid—will be loaded fully into process memory before being added to `params`. ## Impact Attackers can send large non-file fields to trigger excessive memory usage. Impact scales with request size and concurrency, potentially leading to worker crashes or severe garbage-collection overhead. All Rack applications p...

## Summary `Rack::Multipart::Parser` buffers the entire multipart **preamble** (bytes before the first boundary) in memory without any size limit. A client can send a large preamble followed by a valid boundary, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions. ## Details While searching for the first boundary, the parser appends incoming data into a shared buffer (`@sbuf.concat(content)`) and scans for the boundary pattern: ```ruby @sbuf.scan_until(@body_regex) ``` If the boundary is not yet found, the parser continues buffering data indefinitely. There is no trimming or size cap on the preamble, allowing attackers to send arbitrary amounts of data before the first boundary. ## Impact Remote attackers can trigger large transient memory spikes by including a long preamble in multipart/form-data requests. The impact scales with allowed request sizes and concurrency, potentially causing worker crashes or severe slowdown due to ...

### Summary The API key support in vLLM performed validation using a method that was vulnerable to a timing attack. This could potentially allow an attacker to discover a valid API key using an approach more efficient than brute force. ### Details https://github.com/vllm-project/vllm/blob/4b946d693e0af15740e9ca9c0e059d5f333b1083/vllm/entrypoints/openai/api_server.py#L1270-L1274 API key validation used a string comparison that will take longer the more characters the provided API key gets correct. Data analysis across many attempts can allow an attacker to determine when it finds the next correct character in the key sequence. ### Impact Deployments relying on vLLM's built-in API key validation are vulnerable to authentication bypass using this technique.

The email parsing library incorrectly handles quoted local-parts containing @. This leads to misrouting of email recipients, where the parser extracts and routes to an unintended domain instead of the RFC-compliant target. Payload: `"xclow3n@gmail.com x"@internal.domain` Using the following code to send mail ``` const nodemailer = require("nodemailer"); let transporter = nodemailer.createTransport({ service: "gmail", auth: { user: "", pass: "", }, }); let mailOptions = { from: '"Test Sender" <your_email@gmail.com>', to: "\"xclow3n@gmail.com x\"@internal.domain", subject: "Hello from Nodemailer", text: "This is a test email sent using Gmail SMTP and Nodemailer!", }; transporter.sendMail(mailOptions, (error, info) => { if (error) { return console.log("Error: ", error); } console.log("Message sent: %s", info.messageId); }); (async () => { const parser = await import("@sparser/email-address-parser"); const { EmailAddress, ParsingOptions } = parse...

### Summary A remote code execution vulnerability in python-socketio versions prior to 5.14.0 allows attackers to execute arbitrary Python code through malicious pickle deserialization in multi-server deployments on which the attacker previously gained access to the message queue that the servers use for internal communications. ### Details When Socket.IO servers are configured to use a message queue backend such as Redis for inter-server communication, messages sent between the servers are encoded using the `pickle` Python module. When a server receives one of these messages through the message queue, it assumes it is trusted and immediately deserializes it. The vulnerability stems from deserialization of messages using Python's `pickle.loads()` function. Having previously obtained access to the message queue, the attacker can send a python-socketio server a crafted pickle payload that executes arbitrary code during deserialization via Python's `__reduce__` method. ### Impact This ...

Versions of the package pdfmake before 0.3.0-beta.17 are vulnerable to Allocation of Resources Without Limits or Throttling via repeatedly redirect URL in file embedding. An attacker can cause the application to crash or become unresponsive by providing crafted input that triggers this condition.

The Profile widget in Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.8, 7.4 GA through update 92, and older unsupported versions uses a user’s name in the “Content-Disposition” header, which allows remote authenticated users to change the file extension when a vCard file is downloaded.

### Summary The web UI for SillyTavern is susceptible to DNS rebinding, allowing attackers to perform actions like install malicious extensions, read chats, inject arbitrary HTML for phishing, etc. ### Details DNS rebinding is a method to bypass the CORS policies by tricking the browser into resolving something like `127.0.0.1` for a site's DNS address. This allows anybody to get remote access to anyone's SillyTavern instance **without** it being exposed, just by visiting a website. ### PoC 1. Host the PoC HTML file on a `/rebind.html` endpoint (or any other endpoint) on a web server on port 8000 2. Go to https://lock.cmpxchg8b.com/rebinder.html and input your IP address (A) to rebind to 127.0.0.1 (B) 3. Replace the URL in the HTML with the returned URL on the site 4. Go to `http://[URL]:8000/rebind.html` in firefox or on any mobile browser if you're using termux 5. Check the developer tools console. It should return all of the data Here is the PoC code: ```html <!DOCTYPE html> <...