<?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-05-23T20:12:48+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-44837 (view_component): view_component - System Test Entry Point Path Check Allows Sibling Directory Escape]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-44837/"/>
    <id>https://rubysec.com/advisories/CVE-2026-44837</id>
    <updated>2026-05-08T00:00:00+00:00</updated>
    <content type="html"><![CDATA[The system test entrypoint canonicalizes a user-controlled file path
with `File.realpath`, then checks whether the resolved path starts
with the temp directory path. This is not a safe containment check
because sibling directories can share the same string prefix.

Severity: Medium; test-route scoped.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-44836 (view_component): view_component - Preview Route Can Dispatch Inherited Helper Methods']]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-44836/"/>
    <id>https://rubysec.com/advisories/CVE-2026-44836</id>
    <updated>2026-05-08T00:00:00+00:00</updated>
    <content type="html"><![CDATA[The preview route derives an example name from the URL and calls it
with `public_send`. The code does not verify that the requested
method is one of the preview examples explicitly defined by the
preview class.

As a result, inherited public methods on `ViewComponent::Preview`
are route-reachable. The most important one is `render_with_template`,
which accepts `template:` and `locals:`. Those values can come from
request params and are later passed to Rails as `render template:`.

If previews are exposed, an attacker can render internal Rails
templates that are not otherwise routable.

Severity: High if preview routes are externally reachable; Medium otherwise.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-40295 (devise): Devise has an Open Redirect via Unvalidated `request.referrer` in Timeoutable Session Timeout Handler]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-40295/"/>
    <id>https://rubysec.com/advisories/CVE-2026-40295</id>
    <updated>2026-05-08T00:00:00+00:00</updated>
    <content type="html"><![CDATA[## Summary

When the `Timeoutable` module is enabled in Devise, the
`FailureApp#redirect_url` method returns `request.referrer` — the
HTTP `Referer` header, which is attacker-controllable — without
validation for any non-GET request that results in a session timeout.
An attacker who hosts a page with an auto-submitting cross-origin
form can cause a victim with an expired Devise session to be
redirected to an arbitrary external URL. This contrasts with the
GET timeout path (which uses server-side `attempted_path`) and
Devise's own `store_location_for` mechanism (which strips external
hosts via `extract_path_from_location`), both of which are protected;
only the non-GET timeout redirect path is unprotected.

## Details

The vulnerable code is in `lib/devise/failure_app.rb`:

```ruby
def redirect_url
  if warden_message == :timeout
    flash[:timedout] = true if is_flashing_format?

    path = if request.get?
      attempted_path          # safe: server-side value from warden options
    else
      request.referrer        # UNSAFE: HTTP Referer header, attacker-controlled
    end

    path || scope_url
  else
    scope_url
  end
end
```

This is passed directly to `redirect_to`:

```ruby
def redirect
  store_location!
  # ...
  redirect_to redirect_url   # redirect_url may be an external attacker URL
end
```

The GET timeout path uses `attempted_path`, which is set server-side
by Warden and cannot be influenced by the client. The `store_location!`
method also only runs for GET requests, so no session-based protection
is applied on POST timeouts.

By contrast, Devise's `store_location_for` method (used elsewhere)
correctly sanitizes URLs via `extract_path_from_location`, which
strips the scheme and host.

## Impact

- Victims with expired sessions who click any attacker-crafted link
  or visit an attacker page with an auto-submitting form are redirected
  to an arbitrary external URL.
- The redirect happens transparently via a trusted domain (the target
  app's domain), bypassing browser phishing warnings.
- An attacker can redirect victims to a fake login page to harvest
  credentials (phishing), or to malicious download sites.

_Note_: Rails' built-in open-redirect protection does not mitigate
this issue. `Devise::FailureApp` is an `ActionController::Metal`
app with its own isolated copy of the relevant redirect configuration,
so `config.action_controller.action_on_open_redirect = :raise` (and
the older `raise_on_open_redirects` setting) do not reach it.

## Patches

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

## Workaround

None beyond upgrading. If an upgrade is not immediately possible, the
same changes from the patch commit can be applied as a monkey-patch
in a Rails initializer (`Devise::FailureApp#redirect_url` and
`Devise::Controllers::StoreLocation#extract_path_from_location`).
Remove the monkey-patch after upgrading.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-44511 (katalyst-koi): Session cookies can be replayed after user logout]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-44511/"/>
    <id>https://rubysec.com/advisories/CVE-2026-44511</id>
    <updated>2026-05-07T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Impact

Admin session cookies were not invalidated when an admin user logged
out. An attacker with access to a valid admin session cookie could
continue to access admin functionality after logout, until the
cookie expired or session secrets were rotated.

This affects applications using Koi admin authentication where an
admin session cookie may have been exposed, cached, intercepted, or
otherwise retained after logout.

### Patches

The issue has been patched by recording admin logout time and
rejecting any admin session cookie created before the user’s
most recent logout.

Users should upgrade to the patched Koi releases once available.

### Workarounds

Katalyst Koi recommends upgrading to the latest available version,
or back porting the changes released in 5.6.0/4.20.0

### Resources

This is an application of https://guides.rubyonrails.org/v5.2.0/security.html#replay-attacks-for-cookiestore-sessions .]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-44312 (css_parser): Improper Certificate Validation allows MITM injection of remote CSS content]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-44312/"/>
    <id>https://rubysec.com/advisories/CVE-2026-44312</id>
    <updated>2026-05-07T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

The CSS Parser gem does not validate HTTPS connections, allowing a
Man-in-the-Middle (MITM) attacker to inject or modify CSS content when
stylesheets are loaded via HTTPS. The connection is established with
`OpenSSL::SSL::VERIFY_NONE`, meaning any HTTPS certificate—even
entirely untrusted—will be accepted without validation.

### Details

In `lib/css_parser/parser.rb`, the HTTP client sets:
https://github.com/premailer/css_parser/blob/3f91e8db7547fac50ab50cb7f9920f785f722740/lib/css_parser/parser.rb#L646

```ruby
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
```

As a result, the library does not validate the authenticity of HTTPS
connections and does not protect against man-in-the-middle attacks.
Any attacker in a position to intercept network traffic can inject
or modify CSS loaded via HTTPS URLs without detection or warning.

### Impact

Applications using CSS Parser to load remote stylesheets over HTTPS
are vulnerable to CSS injection and content manipulation, regardless
of the trust status of the remote server. All users who use CSS Parser
to fetch external CSS over HTTPS may be impacted.

### Credit

This vulnerability was uncovered by @JLLeitschuh of the
@braze-inc security team.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2025-67202 (sidekiq-cron): Sidekiq-cron is vulnerable to a cross-site scripting (xss) vulnerability via crafted URL]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2025-67202/"/>
    <id>https://rubysec.com/advisories/CVE-2025-67202</id>
    <updated>2026-05-07T00:00:00+00:00</updated>
    <content type="html"><![CDATA[Sidekiq-cron thru 2.3.1, an open-source scheduling add-on for Sidekiq,
is vulnerable to a cross-site scripting (xss) vulnerability via
crafted URL being rended from cron.erb.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[GHSA-v2fc-qm4h-8hqv (nokogiri): Nokogiri XSLT transform has a memory leak]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/GHSA-v2fc-qm4h-8hqv/"/>
    <id>https://rubysec.com/advisories/GHSA-v2fc-qm4h-8hqv</id>
    <updated>2026-05-06T00:00:00+00:00</updated>
    <content type="html"><![CDATA[## Summary

Nokogiri's `Nokogiri::XSLT::Stylesheet#transform` leaks a small heap allocation when passed a Ruby string parameter containing a null byte.

For applications that pass attacker-controlled input through `XSLT.transform` parameters, this may be a vector for a denial of service attack against long-running processes.


## Mitigation

Upgrade to Nokogiri `>= 1.19.3`.

Users may also be able to mitigate this issue without upgrading by validating untrusted transform parameters before passing them to `Nokogiri::XSLT::Stylesheet#transform`.


## Severity

The Nokogiri maintainers have evaluated this as **Moderate Severity**, CVSS 5.3.

Each leaked allocation is approximately 24–32 bytes, so meaningful memory growth requires sustained attacker-controlled traffic at high call rates. The bug does not cause memory corruption, information disclosure, or any change in the behavior of the transform itself, and the string-handling exception is raised as expected.

Applications that do not pass raw attacker-controlled bytes to XSLT parameters are unlikely to be affected in practice.


## Resources

- [CWE-401: Missing Release of Memory after Effective Lifetime](https://cwe.mitre.org/data/definitions/401.html)


## Credit

This vulnerability was responsibly reported by @Captainjack-kor.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[GHSA-c4rq-3m3g-8wgx (nokogiri): Nokogiri CSS selector tokenizer has regular expression backtracking]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/GHSA-c4rq-3m3g-8wgx/"/>
    <id>https://rubysec.com/advisories/GHSA-c4rq-3m3g-8wgx</id>
    <updated>2026-05-06T00:00:00+00:00</updated>
    <content type="html"><![CDATA[## Summary

Nokogiri's CSS selector tokenizer contains regular expressions whose construction may result in exponential regex backtracking on adversarial selectors. Three ReDoS vectors are addressed in this release:

1. String-literal tokenization on certain unterminated quoted-string input.
2. String-literal tokenization on a separate class of hex-escape-rich input.
3. Identifier tokenization on hex-escape-rich input.

The public CSS selector methods that funnel through the affected tokenizer are `Nokogiri::CSS.xpath_for`, `Node#css`, `Node#at_css`, `Searchable#search`, and `CSS::Parser#parse`.


## Mitigation

Upgrade to Nokogiri `>= 1.19.3`.

If users are unable to upgrade, two options are available:

- Avoid the use of attacker-controlled text in CSS selectors. Applications that only pass developer-authored selectors to Nokogiri are not directly exposed.
- Set global `Regexp.timeout` (Ruby 3.2+, JRuby 9.4+) to bound parse time.

## Severity

The Nokogiri maintainers have evaluated this as **High Severity** (CVSS 7.5, `AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`).

An attacker able to inject user-supplied text into a CSS selector parse method can cause exponential backtracking, resulting in a potential denial of service.


## Resources

- [CWE-1333: Inefficient Regular Expression Complexity](https://cwe.mitre.org/data/definitions/1333.html)


## Credit

Vector 1 was responsibly reported by @colby-swandale. Vectors 2 and 3 were discovered by @flavorjones during the response to the original report.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[GHSA-3h96-34p3-xm76 (graphql): GraphQL-Ruby's Ruby lexer does not count comment tokens for the purposes of max_query_string_tokens]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/GHSA-3h96-34p3-xm76/"/>
    <id>https://rubysec.com/advisories/GHSA-3h96-34p3-xm76</id>
    <updated>2026-05-05T00:00:00+00:00</updated>
    <content type="html"><![CDATA[GraphQL-Ruby's `max_query_string_tokens` configuration didn't count
comment tokens against the limit, allowing strings to be processed
even after the configured maximum had actually been reached.

In patched versions, the Ruby lexer does count these tokens.

GraphQL-CParser is not affected by this problem.

`max_query_string_tokens` was introduced in v2.3.1. Each 2.x
version has received a new patch release for including a fix.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-42258 (net-imap): net-imap vulnerable to command Injection via unvalidated Symbol inputs]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-42258/"/>
    <id>https://rubysec.com/advisories/CVE-2026-42258</id>
    <updated>2026-05-04T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

Symbol arguments to commands are vulnerable to a CRLF Injection / IMAP Command
injection via Symbol arguments passed to IMAP commands.

### Details

Symbol arguments represent IMAP "system flags", which are formatted as "atoms"
(with no quoting) with a `"\"` prefix.  Vulnerable versions of Net::IMAP sends
the symbol name directly to the socket, with no validation.

Because the Symbol input is unvalidated, it could contain invalid `flag`
characters, including `SP` and `CRLF`, which could be used to finish the
current command and inject new commands.

Although IMAP `flag` arguments are only valid input for a few IMAP commands,
most Net::IMAP commands use generic argument handling, and will allow Symbol
(`flag`) inputs.

Note also that the list of valid symbol inputs should be restricted to an
enumerated set of standard RFC defined flag types, which have each been given
specific defined semantics.  Any user-provided values outside of that list of
standard "system flags" needs to use the IMAP `keyword` syntax, which are sent
as atoms, i.e: string inputs. Under no circumstances should `#to_sym` ever be
called on unvetted user-provided input: that will always be a bug in the
calling code for the simple reason that `user_input_atom` is as
`\user_input_atom`.

For forward compatibility with future IMAP extentions, Net::IMAP, does not
restrict flag inputs to an enumerated list.  That is the responsibility of the
calling application code, which knows which flag semantics are valid for its
context.

### Impact

If a developer passes user-controlled input as a Symbol to most Net::IMAP
commands, an attacker can append CRLF sequence followed by a new IMAP command
(like `DELETE mailbox`).

### Mitigation
* Upgrade to a version of Net::IMAP that validates Symbols are valid as an
  IMAP `flag`.

* User-provided input should never be able to control calling `#to_sym` on
  string arguments.

  For example, do not unsafely serialize and deserialize command arguments
  (e.g. with YAML or Marshal) in a way that could create unvetted Symbol
  arguments.

* For the few IMAP commands which do allow `flag` arguments, it may be
  appropriate to hard-code Symbol arguments or restrict them to an enumerated
  list which is valid for the calling application.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-42257 (net-imap): net-imap vulnerable to command Injection via "raw" arguments to multiple commands]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-42257/"/>
    <id>https://rubysec.com/advisories/CVE-2026-42257</id>
    <updated>2026-05-04T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

Several `Net::IMAP` commands accept a raw string argument that is sent to the
server without validation or escaping.  If this string is derived from
user-controlled input, it may contain contain `CRLF` sequences, which an
attacker can use to inject arbitrary IMAP commands.

### Details

`Net::IMAP`'s generic argument handling, used by most command arguments,
interprets string arguments as an IMAP `astring`.  Depending on the string
contents and the connection's UTF-8 support, this encodes strings as either a
`atom`, `quoted`, or `literal`.  These are safe from command or argument
injection.

But the following commands transform specific String arguments to
`Net::IMAP::RawData`, which bypasses normal argument validation and encoding
and prints the string directly to the socket:

* `#uid_search`, `#search`
  * when `criteria` is a String, it is sent raw
* `#uid_fetch`, `#fetch`
  * when `attr` is a String, it is sent raw
  * when `attr` is an Array, each String in `attr` is sent raw
* `#uid_store`, `#store`
  * when `attr` is a String, it is sent raw
* `#setquota`:
  * `limit` is interpolated with `#to_s` and that string is sent raw

Because these string arguments are sent without any neutralization, they serve
as a direct vector for command splitting.  Any user controlled data
interpolated into these strings can be used to break out of the intended
command context.

Using "raw data" arguments for `#uid_store`, `#store`, and `#setquota` I both
inappropriate and unnecessary.  `Net::IMAP`'s generic argument handling is
sufficient to safely validate and encode their arguments.  Users of the
library probably do not expect arguments to these commands to be sent raw and
might not be wary of passing unvalidated input.

The API for search criteria and fetch attributes is intentionally low-level
and "close to the wire".  It allows developers to use some IMAP extensions
without requiring explicit support from the library and allows developers to
use complex IMAP grammar without complex argument translation.  Even so, basic
validation is appropriate and could neutralize command injection.

Although this was explicitly documented for search `criteria`, it was
insufficiently documented for fetch `attr`.  So developers may not have
realized that the `attr` argument to `#fetch` and `#uid_fetch` is sent as "raw
data".

### Impact

If a developer passes an unvalidated user-controlled input for one of these
method arguments, an attacker can append CRLF sequence followed by a new IMAP
command (like DELETE mailbox).  Although this does not _directly_ enable data
exfiltration, it could be combined with other attack vectors or knowledge of
the target system's attributes, e.g.: shared mail folders or the application's
installed response handlers.

The SEARCH, STORE, and FETCH commands, and their UID variants are some of the
most commonly used features of the library.  Applications that build search
queries or fetch attributes dynamically based on user input (e.g., mail
clients or archival tools) may be at significant risk.

Expected use of `Net::IMAP#setquota` is much more limited: `SETQUOTA` is often
only usable by users with special administrative privileges.  Depending on the
server, quota administration might be managed through server configuration
rather than via the IMAP protocol `SETQUOTA` command.  It is expected to be
uncommonly used in system administration scripts or in interactive sessions,
it should be completely controlled by trusted users, and should only use
trusted inputs.  Calling `#setquota` with untrusted user input is expected to
be a very uncommon use case.  Please note however this might be combined with
other attacks, for example CSRF, which provide unauthorized access to trusted
inputs, and may specifically target users or scripts with administrator
privileges.

### Mitigation

- Update to a patched version of `net-imap` which:
  - validates that `Net::IMAP::RawData` is composed of well-formed IMAP
    `text`, `literal`, and `literal8` values, with no unescaped `NULL`, `CR`,
    or `LF` bytes.
  - does not use `Net::IMAP::RawData` for `#store`, `#uid_store`, or
    `#setquota`.
- Prefer to send search criteria as an array of key value pairs.  Avoid
  sending it as an interpolated string.
- If an immediate upgrade is not possible:
  - String inputs to search criteria and fetch attributes can be validated
    against command injection by checking for `\r` and `\n` characters.
  - Hard-coding the store `attr` argument is often appropriate.
    Alternatively, user controlled inputs can be restricted to a small
    enumerated list which is valid for the calling application.
  - Use `Kernel#Integer` to coerce and validate user controlled inputs to
    `#setquota` limit.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-42256 (net-imap): net-imap vulnerable to denial of service via high iteration count for `SCRAM-*` authentication]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-42256/"/>
    <id>https://rubysec.com/advisories/CVE-2026-42256</id>
    <updated>2026-05-04T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

When authenticating a connection with `SCRAM-SHA1` or `SCRAM-SHA256`, a
hostile server can perform a computational denial-of-service attack on the
client process by sending a big iteration count value.

### Details

A hostile IMAP server can send an arbitrarily large PBKDF2 iteration count in
the SCRAM server-first-message, causing the client to perform an expensive
`OpenSSL::KDF.pbkdf2_hmac` call.  Because the PBKDF2 function is a blocking C
extension and holds onto Ruby’s Global VM Lock, it can freeze the entire Ruby
VM for the duration of the computation.

OpenSSL enforces an effective maximum by using a 32-bit signed integer for the
iteration count, Depending on hardware capabilities and OpenSSL version, this
iteration count may be sufficient for to block all Ruby threads in the process
for over seven minutes.

This is listed as one of the \"Security Considerations\", in [RFC
7804](https://www.rfc-editor.org/rfc/rfc7804.html#page-15):

> A hostile server can perform a computational denial-of-service attack on
> clients by sending a big iteration count value.  In order to defend against
> that, a client implementation can pick a maximum iteration count that it is
> willing to use and reject any values that exceed that threshold (in such
> cases, the client, of course, has to fail the authentication).

### Impact

During SCRAM authentication to a hostile server, the entire Ruby VM will be
locked for the duration of the computation.  Depending on hardware
capabilities and OpenSSL version, this may take many minutes.

`OpenSSL::KDF.pbkdf2_hmac` is a blocking C function, so `Timeout` cannot be
used to guard against this.  And it retains the Global VM lock, so other ruby
threads will also be unable to run.

### Mitigation

* Upgrade to a patched version of `net-imap` that adds the `max_iterations`
  option to the `SASL-*` authenticators, and call `Net::IMAP#authenticate`
  with a `max_iterations` keyword argument.

  **NOTE:** The default `max_iterations` is `2³¹ - 1`, the maximum signed 32
  bit integer, the maximum allowed by OpenSSL.

  _To prevent a denial of service attack,_ this must be set to a safe value,
  depending on hardware and version of OpenSSL. _It is the user's
  responsibility_ to enforce minimum and maximum iteration counts that are
  appropriate for their security context.

* Alternatively, avoid `SCRAM-*` mechanisms when authenticating to untrusted
  servers.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-42246 (net-imap): net-imap vulnerable to STARTTLS stripping via invalid response timing]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-42246/"/>
    <id>https://rubysec.com/advisories/CVE-2026-42246</id>
    <updated>2026-05-04T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return
"successfully", without starting TLS.

### Details

When using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS,
a man-in-the-middle attacker can inject a tagged `OK` response with an easily
predictable tag.  By sending the response before the client finishes sending
the command, the command completes "successfully" before the response handler
is registered.  This allows `#starttls` to return without error, but the
response handler is never invoked, the TLS connection is never established,
and the socket remains unencrypted.

This allows man-in-the-middle attackers to perform a STARTTLS stripping
attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.

### Impact

TLS bypass, leading to cleartext transmission of sensitive information.

### Mitigation

* Upgrade to a patched version of net-imap that raises an exception whenever
  `#starttls` does not establish TLS.
* Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext
  port.
  This is strongly recommended anyway:
  * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered
    Obsolete: Use of Transport Layer Security (TLS) for Email Submission and
    Access
  * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without
    STARTTLS, A Security Analysis of STARTTLS in the Email Context
* Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the
  connection after `#starttls`.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-42245 (net-imap): net-imap has quadratic complexity when reading response literals]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-42245/"/>
    <id>https://rubysec.com/advisories/CVE-2026-42245</id>
    <updated>2026-05-04T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

`Net::IMAP::ResponseReader` has quadratic time complexity when reading large
responses containing many string literals.  A hostile server can send
responses which are crafted to exhaust the client's CPU for a denial of
service attack.

### Details

For each literal in a response, `ResponseReader` rescans the entire growing
response buffer.  The regular expression that is used to scan the response
buffer runs in linear time.  With many literals, this becomes O(n²) total
work.  The regular expression should run in constant time: it is anchored to
the end and only the last 23 bytes of the buffer are relevant.

Because the algorithmic complexity is super-linear, this bypasses protection
from `max_response_size`: a response can stay well below the default size
limit while still causing very large CPU cost.

`Net::IMAP::ResponseReader` runs continuously in the receiver thread until the
connection closes.

### Impact

This consumes disproportionate CPU time in the client's receiver thread.  A
hostile server could use this to exhaust the client's CPU for a denial of
service attack.

For a response near the default `max_response_size`, each individual regexp
scan could take between 100 to 200ms on common modern hardware, and this may
be repeated 200k times per megabyte of response.  While the regexp is
scanning, it retains the Global VM lock, preventing other threads from
running.

Although other threads should not be _completely_ blocked, their run time will
be significantly impacted.

### Mitigation
* Upgrade to a patched version of net-imap that reads responses more efficiently.
* Do not connect to untrusted IMAP servers.
* When connecting to untrusted servers, a _much_ smaller `max_response_size`
  (for example: 8KiB) will limit the impact.  Although this is too small for
  fetching unpaginated message bodies, it should be enough for most other
  operations.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-42205 (avo): Broken Access Control Through Unauthorized Execution of Arbitrary Action Classes Across Resources]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-42205/"/>
    <id>https://rubysec.com/advisories/CVE-2026-42205</id>
    <updated>2026-04-24T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

A critical Broken Access Control vulnerability was identified in the
`ActionsController` of the Avo framework (v3.x). Due to insecure
action lookup logic, an authenticated user can execute any Action
class (descendants of `Avo::BaseAction`) on any resource, even if
the action is not registered for that specific resource. This leads
to Privilege Escalation and unauthorized data manipulation across
the entire application.

### Details

The vulnerability exists in the `action_class` method within
`app/controllers/avo/actions_controller.rb`.

#### Vulnerable Code

```ruby
def action_class
  # It searches through ALL descendants of BaseAction without
  #    resource validation.
  Avo::BaseAction.descendants.find do |action|
    action.to_s == params[:action_id]
  end
end
```

The controller identifies the action class to execute solely based
on the `params[:action_id]` by searching through all `BaseAction`
descendants. It fails to verify whether the requested action is
actually permitted or registered for the resource context specified
in the request URL (e.g., `/admin/resources/posts/actions`).

Consequently, an attacker can invoke sensitive actions (e.g.,
`Avo::Actions::ToggleAdmin`) through an unrelated resource endpoint
(e.g., `Post`), bypassing the intended resource-action mapping.

### Impact

This flaw results in significant security risks:

- **Privilege Escalation:** An authenticated user with low privileges
  can execute administrative actions (like toggling admin roles) to
  escalate their own or others' permissions.
- **Unauthorized Operations:** Actions designed for restricted
  resources can be triggered against any record ID in the database.
- **Data Integrity Compromise:** Attackers can perform unauthorized
  destructive operations (e.g., Delete, Archive, or Update) on records
  they should not have access to.

### CREDIT

Illunight]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[GHSA-2wvh-87g2-89hr (openc3): OpenC3 COSMOS - Permissions Bypass Provides User Access to Unassigned Administrative Actions via Script Runner Tool]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/GHSA-2wvh-87g2-89hr/"/>
    <id>https://rubysec.com/advisories/GHSA-2wvh-87g2-89hr</id>
    <updated>2026-04-23T00:00:00+00:00</updated>
    <content type="html"><![CDATA[Vulnerability Type: Execution with Unnecessary Privileges Attack
type: Authenticated remote

Impact: Data disclosure/manipulation, privilege escalation

Affected components:

* The following docker images: Openc3inc/openc3-COSMOS-script-runner-api

The Script Runner widget allows users to execute Python and Ruby
scripts directly from the openc3-COSMOS-script-runner-api container.
Because all the docker containers share a network, users can execute
specially crafted scripts to bypass the API permissions check and
perform administrative actions, including reading and modifying data
inside the Redis database, which can be used to read secrets and
change COSMOS settings, as well as read and write to the buckets
service, which holds configuration, log,and plugin files. These
actions are normally only available from the Admin Console or with
administrative privileges. Any user with permission to create and
run scripts can connect to any service in the docker network.

## Recommendations

* Limit the permissions of the script runner API to prevent lower
  level users from performing administrative actions.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-42087 (openc3): OpenC3 COSMOS has SQL Injection in QuestDB Time-Series Database]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-42087/"/>
    <id>https://rubysec.com/advisories/CVE-2026-42087</id>
    <updated>2026-04-23T00:00:00+00:00</updated>
    <content type="html"><![CDATA[Vulnerability Type: CWE-89: Improper Neutralization of Special Elements
used in an SQL Command ('SQL Injection')

Attack type: Authenticated remote

Impact: Telemetry data disclosure and deletion

Affected components: openc3-tsdb (QuestDB)

A SQL injection vulnerability exists in the Time-Series Database (TSDB)
component of COSMOS. The `tsdb_lookup` function in the `cvt_model.rb`
file directly places user-supplied input into a SQL query without
sanitizing the input. As a result, a user can break out of the initial
SQL statement and execute arbitrary SQL commands, including deleting data.

## Recommendations

* Sanitize all user-supplied input before executing it.
* Use prepared statements with parameterized queries when
  executing SQL statements.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-42086 (openc3): OpenC3 COSMOS is Vulnerable to Self-XSS Through the Command Sender]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-42086/"/>
    <id>https://rubysec.com/advisories/CVE-2026-42086</id>
    <updated>2026-04-22T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

The Command Sender UI uses an unsafe `eval()` function on array-like
command parameters, which allows a user-supplied payload to execute
in the browser when sending a command. This creates a self-XSS risk
because an attacker can trigger their own script execution in the
victim’s session, if allowed to influence the array parameter input,
for example via phishing. If successful, an attacker may read or
modify data in the authenticated browser context, including session
tokens in local storage.

### Details

The unsafe `eval()`  usage on user-supplied ARRAY parameters happens
in `convertToValue` method in [CommandSender.vue](https://github.com/OpenC3/cosmos/blob/main/openc3-cosmos-init/plugins/packages/openc3-cosmos-tool-cmdsender/src/tools/CommandSender/CommandSender.vue)

### Impact

Local JavaScript execution in the user's browser.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-42085 (openc3): OpenC3 COSMOS allows arbitrary writes to plugins directory via path-traversed config filenames]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-42085/"/>
    <id>https://rubysec.com/advisories/CVE-2026-42085</id>
    <updated>2026-04-22T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

OpenC3 COSMOS contains a design flaw in the `save_tool_config()`
function that allows saving tool configuration files at arbitrary
locations inside the shared `/plugins` directory tree by supplying
crafted configuration filenames. Although the implementation
sufficiently mitigates standard path traversal attacks, by
canonicalizing filename to an absolute path, all plugins share this
same root directory. That enables users to create arbitrary file
structures and overwrite existing configuration files within the
shared `/plugins` directory.

### Details

In function `save_tool_config()` ([local_mode.rb](https://github.com/OpenC3/cosmos/blob/397abec0d57972881a2e8dc10902d0dce9c27f42/openc3/lib/openc3/utilities/local_mode.rb#L452))
responsible for saving user-supplied tool configuration, the desired
saving directory is not sufficiently enforced, instead allowing
writes inside entire `OPENC3_LOCAL_MODE_PATH`.

### Impact

Modifying the data of other plugins.]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[CVE-2026-42084 (openc3): OpenC3 COSMOS - Hijacked session token can be used to reset password for persistence]]></title>
    <link rel="alternate" href="https://rubysec.com/advisories/CVE-2026-42084/"/>
    <id>https://rubysec.com/advisories/CVE-2026-42084</id>
    <updated>2026-04-22T00:00:00+00:00</updated>
    <content type="html"><![CDATA[### Summary

The OpenC3 password change functionality allows a user to change their
password without providing the old password, by accepting a valid
session token instead. In assumed breach scenarios, this behaviour
can be exploited by an attacker who has already obtained a valid
session token, to gain persistence in hijacked account (including
admin) and prevent legitimate users from accessing the account.

### Details

The design flaw in authentication model ([authentication.rb](https://github.com/OpenC3/cosmos/blob/397abec0d57972881a2e8dc10902d0dce9c27f42/openc3/lib/openc3/utilities/authentication.rb))
allows for interchangeable use of password and session tokens for
user authentication As old tokens are not revoked upon password
reset, an attacker who has obtained a valid session token can
continue to authenticate and change the account’s password even
after the victim resets it, thereby maintaining persistent control
over the compromised account.

### Impact

Persistence of an attacker who obtained valid session token and
preventing legitimate users from account access.]]></content>
  </entry>
  
</feed>
