#ruby

## Summary A possible information disclosure vulnerability existed in `Rack::Sendfile` when running behind a proxy that supports `x-sendfile` headers (such as Nginx). Specially crafted headers could cause `Rack::Sendfile` to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions. ## Details When `Rack::Sendfile` received untrusted `x-sendfile-type` or `x-accel-mapping` headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the proxy, prompting it to reissue a new internal request that was **not subject to the proxy's access controls**. An attacker could exploit this by: 1. Setting a crafted `x-sendfile-type: x-accel-redirect` header. 2. Setting a crafted `x-accel-mapping` header. 3. Requesting a path that qualifies for proxy-based acceleration. ## Impact Attackers could bypass proxy-enforced restrictions and access inte...

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

Cybersecurity researchers have flagged a previously undocumented Android banking trojan called Datzbro that can conduct device takeover (DTO) attacks and perform fraudulent transactions by preying on the elderly. Dutch mobile security company ThreatFabric said it discovered the campaign in August 2025 after users in Australia reported scammers managing Facebook groups promoting "active senior

### Impact The REXML gems from 3.3.3 to 3.4.1 have a DoS vulnerability when parsing XML containing multiple XML declarations. If you need to parse untrusted XMLs, you may be impacted to these vulnerabilities. ### Patches REXML gems 3.4.2 or later include the patches to fix these vulnerabilities. ### Workarounds Don't parse untrusted XMLs. ### References * https://www.ruby-lang.org/en/news/2025/09/18/dos-rexml-cve-2025-58767/ : An announcement on www.ruby-lang.org

In a world where threats are persistent, the modern CISO’s real job isn't just to secure technology—it's to preserve institutional trust and ensure business continuity. This week, we saw a clear pattern: adversaries are targeting the complex relationships that hold businesses together, from supply chains to strategic partnerships. With new regulations and the rise of AI-driven attacks, the

A Dark Web antihero has been stealing and then reselling credentials from unsavory online characters. Their motives are questionable, but the schadenfreude is irresistible.

A fresh set of 60 malicious packages has been uncovered targeting the RubyGems ecosystem by posing as seemingly innocuous automation tools for social media, blogging, or messaging services to steal credentials from unsuspecting users. The activity is assessed to be active since at least March 2023, according to the software supply chain security company Socket. Cumulatively, the gems have been

### Summary A denial-of-service vulnerability exists in ruby-saml even with the message_max_bytesize setting configured. The vulnerability occurs because the SAML response is validated for Base64 format prior to checking the message size, leading to potential resource exhaustion. ### Details `ruby-saml` includes a `message_max_bytesize` setting intended to prevent DOS attacks and decompression bombs. However, this protection is ineffective in some cases due to the order of operations in the code: https://github.com/SAML-Toolkits/ruby-saml/blob/fbbedc978300deb9355a8e505849666974ef2e67/lib/onelogin/ruby-saml/saml_message.rb ```ruby def decode_raw_saml(saml, settings = nil) return saml unless base64_encoded?(saml) # <--- Issue here. Should be moved after next code block. settings = OneLogin::RubySaml::Settings.new if settings.nil? if saml.bytesize > settings.message_max_bytesize raise ValidationError.new("Encoded SAML Message exceeds " + setting...