<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title type="text"><![CDATA[RubySec]]></title>
  <subtitle type="text"><![CDATA[Providing security resources for the Ruby community]]></subtitle>
  <link href="https://rubysec.com/atom.xml" rel="self"/>
  <link href="https://rubysec.com/" rel="alternate" hreflang="en" />
  <updated>2026-03-30T15:44:17+00:00</updated>
  <id>https://rubysec.com/</id>
  <author>
    <name><![CDATA[RubySec]]></name>
    
  </author>
  <generator uri="https://jekyllrb.com/">Jekyll</generator>

  
  <entry>
    <title type="html"><![CDATA[CVE-2026-34060 (ruby-lsp): Ruby LSP has arbitrary code execution through branch setting]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-34060/"/>
    <id>https://rubysec.com/advisories/CVE-2026-34060</id>
    <updated>2026-03-27T00:00:00+00:00</updated>
    <content type="html"><![CDATA[
## Summary

The `rubyLsp.branch` VS Code workspace setting was interpolated without
sanitization into a generated Gemfile, allowing arbitrary Ruby code
execution when a user opens a project containing a malicious
`.vscode/settings.json`.

Other editors that support workspace setting that get automatically
applied upon opening the editor and trusting the workspace are also
impacted since the server is the component that performs the interpolation.

## Details

The `branch` CLI argument passed to the `ruby-lsp` server was
interpolated in the generated `.ruby-lsp/Gemfile` without sanitization.
 Editors that allow defining settings saved at the workspace level
(e.g.: `.vscode/settings.json`) that gets automatically applied open
the possibility to craft a malicious repository that once opened and
trusted in the editor would run arbitrary code.

## Impact

Code execution with the privileges of the user who opens the malicious
project. Ruby LSP assumes workspace code is trusted and so opening
the editor on an untrusted workspace can lead to executing potentially
dangerous code.

## Remediation

The `rubyLsp.branch` setting has been removed entirely. VS Code extensions
auto-update by default, so most users will receive the fix without
action. Users who have disabled auto-updates should update to extension
version >= 0.10.2.

The `branch` CLI flag was also entirely removed from the `ruby-lsp`
gem. For users that don't add `ruby-lsp` to their Gemfiles, the
server should auto-update. Users with the `ruby-lsp` in the Gemfile
and locked to a specific version should update to >= 0.26.9.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-33946 (mcp): MCP Ruby SDK - Insufficient Session Binding Allows SSE Stream Hijacking via Session ID Replay]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-33946/"/>
    <id>https://rubysec.com/advisories/CVE-2026-33946</id>
    <updated>2026-03-27T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

The Ruby SDK's [streamable_http_transport.rb](https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb)
implementation contains a session hijacking vulnerability. An attacker
who obtains a valid session ID can completely hijack the victim's
Server-Sent Events (SSE) stream and intercept all real-time data.

### Details

**Root Cause**

The StreamableHTTPTransport implementation stores only one SSE stream
object per session ID and lacks:

- Session-to-user identity binding
- Ownership validation when establishing SSE connections
- Protection against multiple simultaneous connections to the same session

### Impact

While the absence of user binding may not pose immediate risks if
session IDs are not used to store sensitive data or state, the
fundamental purpose of session IDs is to maintain stateful connections.
If the SDK or its consumers utilize session IDs for sensitive operations
without proper user binding controls, this creates a potential security
vulnerability. For example: In the case of the Ruby SDK, the attacker
was able to hijack the stream and receive all the tool responses
belonging to the victim. The tool responses can be sensitive
confidential data.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-33658 (activestorage): Rails Active Storage has a possible DoS vulnerability in proxy mode via multi-range requests]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-33658/"/>
    <id>https://rubysec.com/advisories/CVE-2026-33658</id>
    <updated>2026-03-25T00:00:00+00:00</updated>
    <content type="html"><![CDATA[## Impact

Active Storage’s proxy controller does not limit the number of byte
ranges in an HTTP Range header. A request with thousands of small
ranges causes disproportionate CPU usage compared to a normal
request for the same file, possibly resulting in a DoS vulnerability.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-33635 (icalendar): iCalendar has ICS injection via unsanitized URI property values]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-33635/"/>
    <id>https://rubysec.com/advisories/CVE-2026-33635</id>
    <updated>2026-03-24T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

.ics serialization does not properly sanitize URI property values,
enabling ICS injection through attacker-controlled input, adding
arbitrary calendar lines to the output.

### Details

`Icalendar::Values::Uri` falls back to the raw input string when
`URI.parse` fails and later serializes it with `value.to_s` without
removing or escaping `\r` or `\n` characters. That value is embedded
directly into the final ICS line by the normal serializer, so a
payload containing CRLF can terminate the original property and
create a new ICS property or component. (It looks like you can
inject via url, source, image, organizer, attach, attendee,
conference, tzurl because of this)

Relevant code:
- `lib/icalendar/values/uri.rb:16`

### Impact

Applications that generate `.ics` files from partially untrusted
metadata are impacted. As a result, downstream calendar clients
or importers may process attacker-supplied content as if it were
legitimate event data, such as added attendees, modified URLs,
alarms, or other calendar fields.

## Fix

Reject raw CR and LF characters in `URI`-typed values before
serialization, or escape/encode them so they cannot terminate
the current ICS content line.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-33286 (graphiti): Graphiti Affected by Arbitrary Method Execution via Unvalidated Relationship Names]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-33286/"/>
    <id>https://rubysec.com/advisories/CVE-2026-33286</id>
    <updated>2026-03-20T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

An arbitrary method execution vulnerability has been found which
affects Graphiti's JSONAPI write functionality. An attacker can
craft a malicious JSONAPI payload with arbitrary relationship
names to invoke any public method on the underlying model
instance, class or its associations.

### Impact

Any application exposing Graphiti write endpoints (create/update/delete)
to untrusted users is affected.

The `Graphiti::Util::ValidationResponse#all_valid?` method recursively
calls `model.send(name)` using relationship names taken directly from
user-supplied JSONAPI payloads, without validating them against the
resource's configured sideloads. This allows an attacker to potentially
run any public method on a given model instance, on the instance class
or associated instances or classes, including destructive operations.

### Patches

This is patched in Graphiti **v1.10.2**.
Users should upgrade as soon as possible.

### Workarounds

If upgrading to v1.10.2 is not immediately possible, consider one
or more of the following mitigations:

- **Restrict write access**: Ensure Graphiti write endpoints
  (create/update/delete) are not accessible to untrusted users.
- **Authentication & authorisation**: Apply strong authentication
  and authorisation checks before any write operation is processed,
  for example use Rails strong parameters to ensure only valid
  parameters are processed."
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-33306 (bcrypt): bcrypt-ruby has an Integer Overflow that Causes Zero Key-Strengthening Iterations at Cost=31 on JRuby]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-33306/"/>
    <id>https://rubysec.com/advisories/CVE-2026-33306</id>
    <updated>2026-03-19T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Impact

An integer overflow in the Java BCrypt implementation for JRuby can
cause zero iterations in the strengthening loop.  Impacted
applications must be setting the cost to 31 to see this happen.

The JRuby implementation of bcrypt-ruby (`BCrypt.java`) computes
the key-strengthening round count as a signed 32-bit integer.
When `cost=31` (the maximum allowed by the gem), signed integer
overflow causes the round count to become negative, and the
strengthening loop executes **zero iterations**. This collapses
bcrypt from 2^31 rounds of exponential key-strengthening to
effectively constant-time computation — only the initial
EksBlowfish key setup and final 64x encryption phase remain.

The resulting hash looks valid (`$2a$31$...`) and verifies
correctly via `checkpw`, making the weakness invisible to the
application. This issue is triggered only when cost=31 is
used or when verifying a `$2a$31$` hash.

### Patches

This problem has been fixed in version 3.1.22

### Workarounds

Set the cost to something less than 31.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-33210 (json): Ruby JSON has a format string injection vulnerability]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-33210/"/>
    <id>https://rubysec.com/advisories/CVE-2026-33210</id>
    <updated>2026-03-19T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Impact

A format string injection vulnerability than that lead to denial of
service attacks or information disclosure, when the `allow_duplicate_key:
false` parsing option is used to parse user supplied documents.

This option isn't the default, if you didn't opt-in to use it,
you are not impacted.

### Patches

Patched in `2.19.2`.

### Workarounds

The issue can be avoided by not using the `allow_duplicate_key: false`
parsing option.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[GHSA-46fp-8f5p-pf2m (loofah): Improper detection of disallowed URIs by Loofah `allowed_uri?`]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/GHSA-46fp-8f5p-pf2m/"/>
    <id>https://rubysec.com/advisories/GHSA-46fp-8f5p-pf2m</id>
    <updated>2026-03-18T00:00:00+00:00</updated>
    <content type="html"><![CDATA[## Summary

`Loofah::HTML5::Scrub.allowed_uri?` does not correctly reject
`javascript:` URIs when the scheme is split by HTML entity-encoded
control characters such as `&#13;` (carriage return), `&#10;`
(line feed), or `&#9;` (tab).

## Details

The `allowed_uri?` method strips literal control characters before
decoding HTML entities. Payloads like `java&#13;script:alert(1)`
survive the control character strip, then `&#13;` is decoded to
a carriage return, producing `java\rscript:alert(1)`.

Note that the Loofah sanitizer's default `sanitize()` path is
**not affected** because Nokogiri decodes HTML entities during
parsing before Loofah evaluates the URI protocol. This issue only
affects direct callers of the `allowed_uri?` string-level helper
when passing HTML-encoded strings.

## Impact

Applications that call `Loofah::HTML5::Scrub.allowed_uri?` to
validate user-controlled URLs and then render approved URLs into
`href` or other browser-interpreted URI attributes may be
vulnerable to cross-site scripting (XSS).

This only affects Loofah `2.25.0`.

## Mitigation

Upgrade to Loofah >= `2.25.1`.

## Credit

Responsibly reported by HackOne user `@smlee`.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-33209 (avo): Avo has a XSS vulnerability on `return_to` param]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-33209/"/>
    <id>https://rubysec.com/advisories/CVE-2026-33209</id>
    <updated>2026-03-18T00:00:00+00:00</updated>
    <content type="html"><![CDATA[## Description

A reflected cross-site scripting (XSS) vulnerability exists in
the `return_to` query parameter used in the avo interface.

An attacker can craft a malicious URL that injects arbitrary
JavaScript, which is executed when he clicks a dynamically
generated navigation button.

## Impact

This vulnerability may allow execution of arbitrary JavaScript
in the context of the application.

Impact varies depending on deployment:
- In unauthenticated setups: exploitable via crafted links sent to users.
- In authenticated setups: limited to authenticated users and
  requires interaction.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-4324 (katello): Katello - Denial of Service and potential information disclosure via SQL injection']]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-4324/"/>
    <id>https://rubysec.com/advisories/CVE-2026-4324</id>
    <updated>2026-03-17T00:00:00+00:00</updated>
    <content type="html"><![CDATA[A flaw was found in the Katello plugin for Red Hat Satellite. This
vulnerability, caused by improper sanitization of user-provided
input, allows a remote attacker to inject arbitrary SQL commands
into the sort_by parameter of the /api/hosts/bootc_images API
endpoint. This can lead to a Denial of Service (DoS) by triggering
database errors, and potentially enable Boolean-based Blind SQL
injection, which could allow an attacker to extract sensitive
information from the database.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[GHSA-57hq-95w6-v4fc (devise): Confirmable "change email" race condition permits user to confirm email they have no access to]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/GHSA-57hq-95w6-v4fc/"/>
    <id>https://rubysec.com/advisories/GHSA-57hq-95w6-v4fc</id>
    <updated>2026-03-16T00:00:00+00:00</updated>
    <content type="html"><![CDATA[## Impact

A race condition in Devise's Confirmable module allows an attacker
to confirm an email address they do not own. This affects any Devise
application using the reconfirmable option (the default when using
Confirmable with email changes).

By sending two concurrent email change requests, an attacker can
desynchronize the confirmation_token and unconfirmed_email fields.
The confirmation token is sent to an email the attacker controls,
but the unconfirmed_email in the database points to a victim's
email address. When the attacker uses the token, the victim's email
is confirmed on the attacker's account.

## Patch

This is patched in Devise v5.0.3. Users should upgrade as soon as possible.

## Workaround

Applications can override this specific method from Devise models
to force unconfirmed_email to be persisted when unchanged:
(assuming your model is User)

```
class User < ApplicationRecord
  protected

  def postpone_email_change_until_confirmation_and_regenerate_confirmation_token
    unconfirmed_email_will_change!
    super
  end
end
```

Note: Mongoid does not seem to respect that will_change! should
force the attribute to be persisted, even if it did not really
change, so you might have to implement a workaround similar to
Devise by setting changed_attributes["unconfirmed_email"] = nil as well.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-32700 (devise): Confirmable "change email" race condition permits user to confirm email they have no access to]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-32700/"/>
    <id>https://rubysec.com/advisories/CVE-2026-32700</id>
    <updated>2026-03-16T00:00:00+00:00</updated>
    <content type="html"><![CDATA[## Impact

A race condition in Devise's Confirmable module allows an attacker
to confirm an email address they do not own. This affects any Devise
application using the reconfirmable option (the default when using
Confirmable with email changes).

By sending two concurrent email change requests, an attacker can
desynchronize the confirmation_token and unconfirmed_email fields.
The confirmation token is sent to an email the attacker controls,
but the unconfirmed_email in the database points to a victim's
email address. When the attacker uses the token, the victim's email
is confirmed on the attacker's account.

## Patch

This is patched in Devise v5.0.3. Users should upgrade as soon as possible.

## Workaround

Applications can override this specific method from Devise models
to force unconfirmed_email to be persisted when unchanged:
(assuming your model is User)

```
class User < ApplicationRecord
  protected

  def postpone_email_change_until_confirmation_and_regenerate_confirmation_token
    unconfirmed_email_will_change!
    super
  end
end
```

Note: Mongoid does not seem to respect that will_change! should
force the attribute to be persisted, even if it did not really
change, so you might have to implement a workaround similar to
Devise by setting changed_attributes["unconfirmed_email"] = nil as well.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[GHSA-qmpg-8xg6-ph5q (action_text-trix): Trix has a Stored XSS vulnerability through serialized attributes]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/GHSA-qmpg-8xg6-ph5q/"/>
    <id>https://rubysec.com/advisories/GHSA-qmpg-8xg6-ph5q</id>
    <updated>2026-03-12T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Impact

The Trix editor, in versions prior to 2.1.17, is vulnerable to XSS
attacks when a `data-trix-serialized-attributes` attribute bypasses
the DOMPurify sanitizer.

An attacker could craft HTML containing a `data-trix-serialized-attributes`
attribute with a malicious payload that, when the content is rendered,
could execute arbitrary JavaScript code within the context of the user's
session, potentially leading to unauthorized actions being performed
or sensitive information being disclosed.

### Patches

Update Recommendation: Users should upgrade to Trix editor
version 2.1.17 or later.

### References

The XSS vulnerability was responsibly reported by Hackerone
researcher [newbiefromcoma](https://hackerone.com/newbiefromcoma).
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-31830 (sigstore): sigstore-ruby verifier returns success for DSSE bundles with mismatched in-toto subject digest]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-31830/"/>
    <id>https://rubysec.com/advisories/CVE-2026-31830</id>
    <updated>2026-03-11T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

`Sigstore::Verifier#verify` does not propagate the `VerificationFailure`
returned by `verify_in_toto` when the artifact digest does not match
the digest in the in-toto attestation subject. As a result, verification
of DSSE bundles containing in-toto statements returns `VerificationSuccess`
regardless of whether the artifact matches the attested subject.

### Details

In `lib/sigstore/verifier.rb`, the verify method calls `verify_in_toto`
(line 176) without capturing or checking its return value:

`verify_in_toto(input, in_toto)`

When `verify_in_toto` detects a digest mismatch, it returns a
`VerificationFailure` object. Because the caller discards this
return value, execution unconditionally falls through to return
`VerificationSuccess`. This is the only verification sub-check in
the method (out of 12) whose failure is not propagated.

The message_signature code path is not affected.

### Impact

An attacker who possesses a valid signed DSSE bundle containing an
in-toto attestation for artifact A can present it as a valid attestation
for a different artifact B. All other verification checks (DSSE envelope
signature, certificate chain, Rekor inclusion, SCTs, policy) pass because
they are independent of the artifact content. Only the in-toto subject
digest check detects the mismatch, and its result is discarded.

This allows an attacker to bypass artifact-to-attestation binding for
any consumer that relies on `Sigstore::Verifier#verify` to validate
DSSE/in-toto bundles.

### Workarounds

None. Consumers cannot work around this without patching the library.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-1776 (camaleon_cms): Camaleon CMS vulnerable to Path Traversal through AWS S3 uploader implementation]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-1776/"/>
    <id>https://rubysec.com/advisories/CVE-2026-1776</id>
    <updated>2026-03-10T00:00:00+00:00</updated>
    <content type="html"><![CDATA[Camaleon CMS versions 2.4.5.0 through 2.9.1, prior to commit f54a77e,
contain a path traversal vulnerability in the AWS S3 uploader
implementation that allows authenticated users to read arbitrary
files from the web server’s filesystem. The issue occurs in the
download_private_file functionality when the application is
configured to use the CamaleonCmsAwsUploader backend. Unlike the
local uploader implementation, the AWS uploader does not validate
file paths with valid_folder_path?, allowing directory traversal
sequences to be supplied via the file parameter. As a result, any
authenticated user, including low-privileged registered users, can
access sensitive files such as /etc/passwd. This issue represents a
bypass of the incomplete fix for CVE-2024-46987 and affects
deployments using the AWS S3 storage backend.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-27820 (zlib): Buffer overflow vulnerability in Zlib::GzipReader]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-27820/"/>
    <id>https://rubysec.com/advisories/CVE-2026-27820</id>
    <updated>2026-03-05T00:00:00+00:00</updated>
    <content type="html"><![CDATA[A buffer overflow vulnerability exists in Zlib::GzipReader.
This vulnerability has been assigned the CVE identifier
CVE-2026-27820. We recommend upgrading the zlib gem.

## Details

The zstream_buffer_ungets function prepends caller-provided bytes
ahead of previously produced output but fails to guarantee the
backing Ruby string has enough capacity before the memmove shifts
the existing data. This can lead to memory corruption when the
buffer length exceeds capacity.

## Recommended action

We recommend to update the zlib gem to version 3.2.3 or later.
In order to ensure compatibility with bundled version in older
Ruby series, you may update as follows instead:

* For Ruby 3.2 users: Update to zlib 3.0.1
* For Ruby 3.3 users: Update to zlib 3.1.2
* You can use gem update zlib to update it. If you are using
   bundler, please add gem "zlib", ">= 3.2.3" to your Gemfile.

## Affected versions:

zlib gem 3.2.2 or lower

## Credits

Thanks to calysteon for reporting this issue. Also thanks to
nobu for creating the patch.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-0980 (rubyipmi): rubyipmi is vulnerable to OS Command Injection through malicious usernames]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-0980/"/>
    <id>https://rubysec.com/advisories/CVE-2026-0980</id>
    <updated>2026-02-27T00:00:00+00:00</updated>
    <content type="html"><![CDATA[A flaw was found in rubyipmi, a gem used in the Baseboard Management
Controller (BMC) component of Red Hat Satellite. An authenticated
attacker with host creation or update permissions could exploit this
vulnerability by crafting a malicious username for the BMC interface.
This could lead to remote code execution (RCE) on the system.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[GHSA-wx95-c6cv-8532 (nokogiri): Nokogiri does not check the return value from xmlC14NExecute]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/GHSA-wx95-c6cv-8532/"/>
    <id>https://rubysec.com/advisories/GHSA-wx95-c6cv-8532</id>
    <updated>2026-02-18T00:00:00+00:00</updated>
    <content type="html"><![CDATA[## Summary

Nokogiri's CRuby extension fails to check the return value from
`xmlC14NExecute` in the method `Nokogiri::XML::Document#canonicalize`
and `Nokogiri::XML::Node#canonicalize`. When canonicalization fails,
an empty string is returned instead of raising an exception. This
incorrect return value may allow downstream libraries to accept
invalid or incomplete canonicalized XML, which has been demonstrated
to enable signature validation bypass in SAML libraries.

JRuby is not affected, as the Java implementation correctly
raises `RuntimeError` on canonicalization failure.

## Mitigation

Upgrade to Nokogiri `>= 1.19.1`.

## Severity

The maintainers have assessed this as **Medium** severity. Nokogiri
itself is a parsing library without a clear security boundary
related to canonicalization, so the direct impact is that a method
returns incorrect data on invalid input. However, this behavior
was exploited in practice to bypass SAML signature validation
in downstream libraries (see References).

## Credit

This vulnerability was responsibly reported by HackerOne
researcher `d4d`.
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-25500 (rack): Stored XSS in Rack::Directory via javascript: filenames rendered into anchor href]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-25500/"/>
    <id>https://rubysec.com/advisories/CVE-2026-25500</id>
    <updated>2026-02-17T00:00:00+00:00</updated>
    <content type="html"><![CDATA[## Summary

`Rack::Directory` generates an HTML directory index where each file entry is rendered as a clickable link. If a file exists on disk whose basename begins with the `javascript:` scheme (e.g. `javascript:alert(1)`), the generated index includes an anchor whose `href` attribute is exactly `javascript:alert(1)`. Clicking this entry executes arbitrary JavaScript in the context of the hosting application.

This results in a client-side XSS condition in directory listings generated by `Rack::Directory`.

## Details

`Rack::Directory` renders directory entries using an HTML row template similar to:

```html
<a href='%s'>%s</a>
```

The `%s` placeholder is populated directly with the file’s basename. If the basename begins with `javascript:`, the resulting HTML contains an executable JavaScript URL:

```html
<a href='javascript:alert(1)'>javascript:alert(1)</a>
```

Because the value is inserted directly into the `href` attribute without scheme validation or normalization, browsers interpret it as a JavaScript URI. When a user clicks the link, the JavaScript executes in the origin of the Rack application.

## Impact

If `Rack::Directory` is used to expose filesystem contents over HTTP, an attacker who can create or upload files within that directory may introduce a malicious filename beginning with `javascript:`.

When a user visits the directory listing and clicks the entry, arbitrary JavaScript executes in the application's origin. Exploitation requires user interaction (clicking the malicious entry).

## Mitigation

* Update to a patched version of Rack in which `Rack::Directory` prefixes generated anchors with a relative path indicator (e.g. `./filename`).
* Avoid exposing user-controlled directories via `Rack::Directory`.
* Apply a strict Content Security Policy (CSP) to reduce impact of potential client-side execution issues.
* Where feasible, restrict or sanitize uploaded filenames to disallow dangerous URI scheme prefixes.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-22860 (rack): Rack has a Directory Traversal via Rack:Directory]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-22860/"/>
    <id>https://rubysec.com/advisories/CVE-2026-22860</id>
    <updated>2026-02-17T00:00:00+00:00</updated>
    <content type="html"><![CDATA[## Summary

`Rack::Directory`’s path check used a string prefix match
on the expanded path. A request like `/../root_example/` can escape the configured
root if the target path starts with the root string, allowing directory listing
outside the intended root.

## Details

In `directory.rb`, `File.expand_path(File.join(root,
path_info)).start_with?(root)` does not enforce a path boundary. If the server root
is `/var/www/root`, a path like `/var/www/root_backup` passes the check because
it shares the same prefix, so `Rack::Directory` will list that directory also.

## Impact

Information disclosure via directory listing outside the configured root
when `Rack::Directory` is exposed to untrusted clients and a directory shares the
root prefix (e.g., `public2`, `www_backup`).

## Mitigation

* Update to a patched
version of Rack that correctly checks the root prefix.\n* Don't name directories
with the same prefix as one which is exposed via `Rack::Directory`."]]></content>
  </entry>
  
</feed>
