Latest News

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

A Vietnamese threat actor named BatShadow has been attributed to a new campaign that leverages social engineering tactics to deceive job seekers and digital marketing professionals to deliver a previously undocumented malware called Vampire Bot. "The attackers pose as recruiters, distributing malicious files disguised as job descriptions and corporate documents," Aryaka Threat Research Labs

Researchers say exploitation of CVE-2025-10035 requires a private key, and it's unclear how Storm-1175 threat actors pulled this off.

A text message tried to lure us to a fake Best Wallet site posing as an airdrop event to steal our crypto.

Latest reports suggest the critical GoAnywhere MFT vulnerability (CVE-2025-10035, CVSS 10.0) is actively exploited by the Medusa ransomware gang for unauthenticated RCE. Patch immediately.

Google's DeepMind division on Monday announced an artificial intelligence (AI)-powered agent called CodeMender that automatically detects, patches, and rewrites vulnerable code to prevent future exploits. The efforts add to the company's ongoing efforts to improve AI-powered vulnerability discovery, such as Big Sleep and OSS-Fuzz. DeepMind said the AI agent is designed to be both reactive and

Raleigh, United States, 7th October 2025, CyberNewsWire

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...