🚨 ActiveJob/ActiveStorage vulnerabilities

There is a vulnerability in Active Job. This vulnerability has been
assigned the CVE identifier CVE-2018-16476.

Versions Affected: >= 4.2.0
Not affected: < 4.2.0
Fixed Versions: 4.2.11, 5.0.7.1, 5.1.6.1, 5.2.1.1

Impact

Carefully crafted user input can cause Active Job to deserialize it using GlobalId
and allow an attacker to have access to information that they should not have.

Vulnerable code will look something like this:

MyJob.perform_later(user_input)

All users running an affected release should either upgrade or use one of the
workarounds immediately.

---

There is a vulnerability in Active Storage. This vulnerability has been
assigned the CVE identifier CVE-2018-16477.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 5.2.1.1

Impact

Signed download URLs generated by ActiveStorage for Google Cloud Storage
service and Disk service include content-disposition and content-type
parameters that an attacker can modify. This can be used to upload specially
crafted HTML files and have them served and executed inline. Combined with
other techniques such as cookie bombing and specially crafted AppCache manifests,
an attacker can gain access to private signed URLs within a specific storage path.

Vulnerable apps are those using either GCS or the Disk service in production.
Other storage services such as S3 or Azure aren't affected.

All users running an affected release should either upgrade or use one of the
workarounds immediately. For those using GCS, it's also recommended to run the
following to update existing blobs:

ActiveStorage::Blob.find_each do |blob|
  blob.send :update_service_metadata
end

🚨 ActiveJob/ActiveStorage vulnerabilities

There is a vulnerability in Active Job. This vulnerability has been
assigned the CVE identifier CVE-2018-16476.

Versions Affected: >= 4.2.0
Not affected: < 4.2.0
Fixed Versions: 4.2.11, 5.0.7.1, 5.1.6.1, 5.2.1.1

Impact

Carefully crafted user input can cause Active Job to deserialize it using GlobalId
and allow an attacker to have access to information that they should not have.

Vulnerable code will look something like this:

MyJob.perform_later(user_input)

All users running an affected release should either upgrade or use one of the
workarounds immediately.

---

There is a vulnerability in Active Storage. This vulnerability has been
assigned the CVE identifier CVE-2018-16477.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 5.2.1.1

Impact

Signed download URLs generated by ActiveStorage for Google Cloud Storage
service and Disk service include content-disposition and content-type
parameters that an attacker can modify. This can be used to upload specially
crafted HTML files and have them served and executed inline. Combined with
other techniques such as cookie bombing and specially crafted AppCache manifests,
an attacker can gain access to private signed URLs within a specific storage path.

Vulnerable apps are those using either GCS or the Disk service in production.
Other storage services such as S3 or Azure aren't affected.

All users running an affected release should either upgrade or use one of the
workarounds immediately. For those using GCS, it's also recommended to run the
following to update existing blobs:

ActiveStorage::Blob.find_each do |blob|
  blob.send :update_service_metadata
end

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by 4 commits:

• Preparing for 7.0.8.1 release
• update changelog
• fix XSS vulnerability when using translation
• Merge pull request #48869 from brunoprietog/disable-session-active-storage-proxy-controllers

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by 4 commits:

• Preparing for 7.0.8.1 release
• update changelog
• fix XSS vulnerability when using translation
• Merge pull request #48869 from brunoprietog/disable-session-active-storage-proxy-controllers

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by 4 commits:

• Preparing for 7.0.8.1 release
• update changelog
• fix XSS vulnerability when using translation
• Merge pull request #48869 from brunoprietog/disable-session-active-storage-proxy-controllers

🚨 Possible Sensitive Session Information Leak in Active Storage

There is a possible sensitive session information leak in Active Storage.
By default, Active Storage sends a Set-Cookie header along with the user’s
session cookie when serving blobs. It also sets Cache-Control to public.
Certain proxies may cache the Set-Cookie, leading to an information leak.

This vulnerability has been assigned the CVE identifier CVE-2024-26144.

Versions Affected: >= 5.2.0, < 7.1.0 Not affected: < 5.2.0, >= 7.1.0 Fixed Versions: 7.0.8.1, 6.1.7.7

Impact

A proxy which chooses to caches this request can cause users to share
sessions. This may include a user receiving an attacker’s session or vice
versa.

This was patched in 7.1.0 but not previously identified as a security
vulnerability.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

Upgrade to Rails 7.1.X, or configure caching proxies not to cache the
Set-Cookie headers.

🚨 Possible Sensitive Session Information Leak in Active Storage

There is a possible sensitive session information leak in Active Storage.
By default, Active Storage sends a Set-Cookie header along with the user’s
session cookie when serving blobs. It also sets Cache-Control to public.
Certain proxies may cache the Set-Cookie, leading to an information leak.

This vulnerability has been assigned the CVE identifier CVE-2024-26144.

Versions Affected: >= 5.2.0, < 7.1.0 Not affected: < 5.2.0, >= 7.1.0 Fixed Versions: 7.0.8.1, 6.1.7.7

Impact

A proxy which chooses to caches this request can cause users to share
sessions. This may include a user receiving an attacker’s session or vice
versa.

This was patched in 7.1.0 but not previously identified as a security
vulnerability.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

Upgrade to Rails 7.1.X, or configure caching proxies not to cache the
Set-Cookie headers.

🚨 Possible XSS Vulnerability in Action Controller

There is a possible XSS vulnerability when using the translation helpers
(translate, t, etc) in Action Controller. This vulnerability has been
assigned the CVE identifier CVE-2024-26143.

Versions Affected: All. Not affected: None Fixed Versions: 7.1.3.1, 7.0.8.1

Impact

Applications using translation methods like translate, or t on a
controller, with a key ending in “_html”, a :default key which contains
untrusted user input, and the resulting string is used in a view, may be
susceptible to an XSS vulnerability.

For example, impacted code will look something like this:

class ArticlesController < ApplicationController
  def show
    @message = t("message_html", default: untrusted_input)
    # The `show` template displays the contents of `@message`
  end
end

To reiterate the pre-conditions, applications must:

• Use a translation function from a controller (i.e. not I18n.t, or
  t from a view)
• Use a key that ends in _html
• Use a default value where the default value is untrusted and unescaped input
• Send the text to the victim (whether that’s part of a template, or a
  render call)

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

🚨 Possible XSS via User Supplied Values to redirect_to

The redirect_to method in Rails allows provided values to contain characters
which are not legal in an HTTP header value. This results in the potential for
downstream services which enforce RFC compliance on HTTP response headers to
remove the assigned Location header. This vulnerability has been assigned the
CVE identifier CVE-2023-28362.

Versions Affected: All. Not affected: None Fixed Versions: 7.0.5.1, 6.1.7.4

Impact

This introduces the potential for a Cross-site-scripting (XSS) payload to be
delivered on the now static redirection page. Note that this both requires
user interaction and for a Rails app to be configured to allow redirects to
external hosts (defaults to false in Rails >= 7.0.x).

Releases

The FIXED releases are available at the normal locations.

Workarounds

Avoid providing user supplied URLs with arbitrary schemes to the redirect_to
method.

🚨 Possible XSS via User Supplied Values to redirect_to

The redirect_to method in Rails allows provided values to contain characters
which are not legal in an HTTP header value. This results in the potential for
downstream services which enforce RFC compliance on HTTP response headers to
remove the assigned Location header. This vulnerability has been assigned the
CVE identifier CVE-2023-28362.

Versions Affected: All. Not affected: None Fixed Versions: 7.0.5.1, 6.1.7.4

Impact

This introduces the potential for a Cross-site-scripting (XSS) payload to be
delivered on the now static redirection page. Note that this both requires
user interaction and for a Rails app to be configured to allow redirects to
external hosts (defaults to false in Rails >= 7.0.x).

Releases

The FIXED releases are available at the normal locations.

Workarounds

Avoid providing user supplied URLs with arbitrary schemes to the redirect_to
method.

🚨 ReDoS based DoS vulnerability in Action Dispatch

There is a possible regular expression based DoS vulnerability in Action
Dispatch related to the If-None-Match header. This vulnerability has been
assigned the CVE identifier CVE-2023-22795.

Versions Affected: All
Not affected: None
Fixed Versions: 6.1.7.1, 7.0.4.1

Impact

A specially crafted HTTP If-None-Match header can cause the regular
expression engine to enter a state of catastrophic backtracking, when on a
version of Ruby below 3.2.0. This can cause the process to use large amounts
of CPU and memory, leading to a possible DoS vulnerability All users running
an affected release should either upgrade or use one of the workarounds
immediately.

Workarounds

We recommend that all users upgrade to one of the FIXED versions. In the
meantime, users can mitigate this vulnerability by using a load balancer or
other device to filter out malicious If-None-Match headers before they reach
the application.

Users on Ruby 3.2.0 or greater are not affected by this vulnerability.

🚨 Open Redirect Vulnerability in Action Pack

There is a vulnerability in Action Controller’s redirect_to. This
vulnerability has been assigned the CVE identifier CVE-2023-22797.

Versions Affected: >= 7.0.0
Not affected: < 7.0.0
Fixed Versions: 7.0.4.1

Impact

There is a possible open redirect when using the redirect_to helper with
untrusted user input.

Vulnerable code will look like this:

redirect_to(params[:some_param])

Rails 7.0 introduced protection against open redirects from calling
redirect_to with untrusted user input. In prior versions the developer was
fully responsible for only providing trusted input. However the check
introduced could be bypassed by a carefully crafted URL.

All users running an affected release should either upgrade or use one of
the workarounds immediately.

Workarounds

There are no feasible workarounds for this issue.

🚨 ReDoS based DoS vulnerability in Action Dispatch

There is a possible regular expression based DoS vulnerability in Action
Dispatch. This vulnerability has been assigned the CVE identifier
CVE-2023-22792.

Versions Affected: >= 3.0.0
Not affected: < 3.0.0
Fixed Versions: 6.1.7.1, 7.0.4.1

Impact

Specially crafted cookies, in combination with a specially crafted
X_FORWARDED_HOST header can cause the regular expression engine to enter a
state of catastrophic backtracking. This can cause the process to use large
amounts of CPU and memory, leading to a possible DoS vulnerability All users
running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

We recommend that all users upgrade to one of the FIXED versions. In the
meantime, users can mitigate this vulnerability by using a load balancer or
other device to filter out malicious X_FORWARDED_HOST headers before they
reach the application.

🚨 ReDoS based DoS vulnerability in Action Dispatch

There is a possible regular expression based DoS vulnerability in Action
Dispatch. This vulnerability has been assigned the CVE identifier
CVE-2023-22792.

Versions Affected: >= 3.0.0
Not affected: < 3.0.0
Fixed Versions: 6.1.7.1, 7.0.4.1

Impact

Specially crafted cookies, in combination with a specially crafted
X_FORWARDED_HOST header can cause the regular expression engine to enter a
state of catastrophic backtracking. This can cause the process to use large
amounts of CPU and memory, leading to a possible DoS vulnerability All users
running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

We recommend that all users upgrade to one of the FIXED versions. In the
meantime, users can mitigate this vulnerability by using a load balancer or
other device to filter out malicious X_FORWARDED_HOST headers before they
reach the application.

🚨 ReDoS based DoS vulnerability in Action Dispatch

There is a possible regular expression based DoS vulnerability in Action
Dispatch related to the If-None-Match header. This vulnerability has been
assigned the CVE identifier CVE-2023-22795.

Versions Affected: All
Not affected: None
Fixed Versions: 6.1.7.1, 7.0.4.1

Impact

A specially crafted HTTP If-None-Match header can cause the regular
expression engine to enter a state of catastrophic backtracking, when on a
version of Ruby below 3.2.0. This can cause the process to use large amounts
of CPU and memory, leading to a possible DoS vulnerability All users running
an affected release should either upgrade or use one of the workarounds
immediately.

Workarounds

We recommend that all users upgrade to one of the FIXED versions. In the
meantime, users can mitigate this vulnerability by using a load balancer or
other device to filter out malicious If-None-Match headers before they reach
the application.

Users on Ruby 3.2.0 or greater are not affected by this vulnerability.

🚨 Possible XSS Vulnerability in Action Pack

There is a possible XSS vulnerability in Rails / Action Pack. This vulnerability has been
assigned the CVE identifier CVE-2022-22577.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

CSP headers were only sent along with responses that Rails considered as
"HTML" responses. This left API requests without CSP headers, which could
possibly expose users to XSS attacks.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Set a CSP for your API responses manually.

🚨 Possible XSS Vulnerability in Action Pack

There is a possible XSS vulnerability in Rails / Action Pack. This vulnerability has been
assigned the CVE identifier CVE-2022-22577.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

CSP headers were only sent along with responses that Rails considered as
"HTML" responses. This left API requests without CSP headers, which could
possibly expose users to XSS attacks.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Set a CSP for your API responses manually.

🚨 Possible XSS Vulnerability in Action Pack

There is a possible XSS vulnerability in Rails / Action Pack. This vulnerability has been
assigned the CVE identifier CVE-2022-22577.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

CSP headers were only sent along with responses that Rails considered as
"HTML" responses. This left API requests without CSP headers, which could
possibly expose users to XSS attacks.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Set a CSP for your API responses manually.

🚨 Possible XSS Vulnerability in Action Pack

There is a possible XSS vulnerability in Rails / Action Pack. This vulnerability has been
assigned the CVE identifier CVE-2022-22577.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

CSP headers were only sent along with responses that Rails considered as
"HTML" responses. This left API requests without CSP headers, which could
possibly expose users to XSS attacks.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Set a CSP for your API responses manually.

🚨 Possible exposure of information vulnerability in Action Pack

Impact

Under certain circumstances response bodies will not be closed, for example a
bug in a webserver (puma/puma#2812) or a bug in a Rack
middleware. In the event a response is not notified of a close,
ActionDispatch::Executor will not know to reset thread local state for the
next request. This can lead to data being leaked to subsequent requests,
especially when interacting with ActiveSupport::CurrentAttributes.

Upgrading to the FIXED versions of Rails will ensure mitigation if this issue
even in the context of a buggy webserver or middleware implementation.

Patches

This has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

Workarounds

Upgrading is highly recommended, but to work around this problem the following
middleware can be used:

class GuardedExecutor < ActionDispatch::Executor
  def call(env)
    ensure_completed!
    super
  end

  private

    def ensure_completed!
      @executor.new.complete! if @executor.active?
    end
end

# Ensure the guard is inserted before ActionDispatch::Executor
Rails.application.configure do
  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor
end

🚨 Possible exposure of information vulnerability in Action Pack

Impact

Under certain circumstances response bodies will not be closed, for example a
bug in a webserver (puma/puma#2812) or a bug in a Rack
middleware. In the event a response is not notified of a close,
ActionDispatch::Executor will not know to reset thread local state for the
next request. This can lead to data being leaked to subsequent requests,
especially when interacting with ActiveSupport::CurrentAttributes.

Upgrading to the FIXED versions of Rails will ensure mitigation if this issue
even in the context of a buggy webserver or middleware implementation.

Patches

This has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

Workarounds

Upgrading is highly recommended, but to work around this problem the following
middleware can be used:

class GuardedExecutor < ActionDispatch::Executor
  def call(env)
    ensure_completed!
    super
  end

  private

    def ensure_completed!
      @executor.new.complete! if @executor.active?
    end
end

# Ensure the guard is inserted before ActionDispatch::Executor
Rails.application.configure do
  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor
end

🚨 Possible exposure of information vulnerability in Action Pack

Impact

Under certain circumstances response bodies will not be closed, for example a
bug in a webserver (puma/puma#2812) or a bug in a Rack
middleware. In the event a response is not notified of a close,
ActionDispatch::Executor will not know to reset thread local state for the
next request. This can lead to data being leaked to subsequent requests,
especially when interacting with ActiveSupport::CurrentAttributes.

Upgrading to the FIXED versions of Rails will ensure mitigation if this issue
even in the context of a buggy webserver or middleware implementation.

Patches

This has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

Workarounds

Upgrading is highly recommended, but to work around this problem the following
middleware can be used:

class GuardedExecutor < ActionDispatch::Executor
  def call(env)
    ensure_completed!
    super
  end

  private

    def ensure_completed!
      @executor.new.complete! if @executor.active?
    end
end

# Ensure the guard is inserted before ActionDispatch::Executor
Rails.application.configure do
  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor
end

🚨 Possible exposure of information vulnerability in Action Pack

Impact

Under certain circumstances response bodies will not be closed, for example a
bug in a webserver (puma/puma#2812) or a bug in a Rack
middleware. In the event a response is not notified of a close,
ActionDispatch::Executor will not know to reset thread local state for the
next request. This can lead to data being leaked to subsequent requests,
especially when interacting with ActiveSupport::CurrentAttributes.

Upgrading to the FIXED versions of Rails will ensure mitigation if this issue
even in the context of a buggy webserver or middleware implementation.

Patches

This has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

Workarounds

Upgrading is highly recommended, but to work around this problem the following
middleware can be used:

class GuardedExecutor < ActionDispatch::Executor
  def call(env)
    ensure_completed!
    super
  end

  private

    def ensure_completed!
      @executor.new.complete! if @executor.active?
    end
end

# Ensure the guard is inserted before ActionDispatch::Executor
Rails.application.configure do
  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor
end

🚨 Possible Open Redirect in Host Authorization Middleware

There is a possible open redirect vulnerability in the Host Authorization
middleware in Action Pack.

Specially crafted "X-Forwarded-Host" headers in combination with certain
"allowed host" formats can cause the Host Authorization middleware in Action
Pack to redirect users to a malicious website.

Impacted applications will have allowed hosts with a leading dot. For example,
configuration files that look like this:

config.hosts <<  '.EXAMPLE.com'

When an allowed host contains a leading dot, a specially crafted Host header
can be used to redirect to a malicious website.

This vulnerability is similar to CVE-2021-22881 and CVE-2021-22942.

Releases

The fixed releases are available at the normal locations.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

• 6-0-host-authorzation-open-redirect.patch - Patch for 6.0 series
• 6-1-host-authorzation-open-redirect.patch - Patch for 6.1 series
• 7-0-host-authorzation-open-redirect.patch - Patch for 7.0 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at
present. Users of earlier unsupported releases are advised to upgrade as soon
as possible as we cannot guarantee the continued availability of security
fixes for unsupported releases.

🚨 Possible Open Redirect in Host Authorization Middleware

There is a possible open redirect vulnerability in the Host Authorization
middleware in Action Pack.

Specially crafted "X-Forwarded-Host" headers in combination with certain
"allowed host" formats can cause the Host Authorization middleware in Action
Pack to redirect users to a malicious website.

Impacted applications will have allowed hosts with a leading dot. For example,
configuration files that look like this:

config.hosts <<  '.EXAMPLE.com'

When an allowed host contains a leading dot, a specially crafted Host header
can be used to redirect to a malicious website.

This vulnerability is similar to CVE-2021-22881 and CVE-2021-22942.

Releases

The fixed releases are available at the normal locations.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

• 6-0-host-authorzation-open-redirect.patch - Patch for 6.0 series
• 6-1-host-authorzation-open-redirect.patch - Patch for 6.1 series
• 7-0-host-authorzation-open-redirect.patch - Patch for 7.0 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at
present. Users of earlier unsupported releases are advised to upgrade as soon
as possible as we cannot guarantee the continued availability of security
fixes for unsupported releases.

🚨 Possible Open Redirect in Host Authorization Middleware

There is a possible open redirect vulnerability in the Host Authorization
middleware in Action Pack. This vulnerability has been assigned the CVE
identifier CVE-2021-22942.

Versions Affected: >= 6.0.0.
Not affected: < 6.0.0
Fixed Versions: 6.1.4.1, 6.0.4.1

Impact

Specially crafted “X-Forwarded-Host” headers in combination with certain
“allowed host” formats can cause the Host Authorization middleware in
Action Pack to redirect users to a malicious website.

Impacted applications will have allowed hosts with a leading dot.
For example, configuration files that look like this:

config.hosts <<  '.EXAMPLE.com'

When an allowed host contains a leading dot, a specially crafted
Host header can be used to redirect to a malicious website.

This vulnerability is similar to CVE-2021-22881, but CVE-2021-22881 did not
take in to account domain name case sensitivity.

Releases

The fixed releases are available at the normal locations.

Workarounds

In the case a patch can’t be applied, the following monkey patch can be
used in an initializer:

module ActionDispatch
  class HostAuthorization
    HOSTNAME = /[a-z0-9.-]+|\[[a-f0-9]*:[a-f0-9.:]+\]/i
    VALID_ORIGIN_HOST = /\A(#{HOSTNAME})(?::\d+)?\z/
    VALID_FORWARDED_HOST = /(?:\A|,[ ]?)(#{HOSTNAME})(?::\d+)?\z/

    private
      def authorized?(request)
        origin_host =
          request.get_header("HTTP_HOST")&.slice(VALID_ORIGIN_HOST, 1) || ""
        forwarded_host =
          request.x_forwarded_host&.slice(VALID_FORWARDED_HOST, 1) || ""
        @permissions.allows?(origin_host) &&
          (forwarded_host.blank? || @permissions.allows?(forwarded_host))
      end
  end
end

🚨 Possible Open Redirect in Host Authorization Middleware

There is a possible open redirect vulnerability in the Host Authorization
middleware in Action Pack. This vulnerability has been assigned the CVE
identifier CVE-2021-22942.

Versions Affected: >= 6.0.0.
Not affected: < 6.0.0
Fixed Versions: 6.1.4.1, 6.0.4.1

Impact

Specially crafted “X-Forwarded-Host” headers in combination with certain
“allowed host” formats can cause the Host Authorization middleware in
Action Pack to redirect users to a malicious website.

Impacted applications will have allowed hosts with a leading dot.
For example, configuration files that look like this:

config.hosts <<  '.EXAMPLE.com'

When an allowed host contains a leading dot, a specially crafted
Host header can be used to redirect to a malicious website.

This vulnerability is similar to CVE-2021-22881, but CVE-2021-22881 did not
take in to account domain name case sensitivity.

Releases

The fixed releases are available at the normal locations.

Workarounds

In the case a patch can’t be applied, the following monkey patch can be
used in an initializer:

module ActionDispatch
  class HostAuthorization
    HOSTNAME = /[a-z0-9.-]+|\[[a-f0-9]*:[a-f0-9.:]+\]/i
    VALID_ORIGIN_HOST = /\A(#{HOSTNAME})(?::\d+)?\z/
    VALID_FORWARDED_HOST = /(?:\A|,[ ]?)(#{HOSTNAME})(?::\d+)?\z/

    private
      def authorized?(request)
        origin_host =
          request.get_header("HTTP_HOST")&.slice(VALID_ORIGIN_HOST, 1) || ""
        forwarded_host =
          request.x_forwarded_host&.slice(VALID_FORWARDED_HOST, 1) || ""
        @permissions.allows?(origin_host) &&
          (forwarded_host.blank? || @permissions.allows?(forwarded_host))
      end
  end
end

🚨 Possible Information Disclosure / Unintended Method Execution in Action Pack

There is a possible information disclosure / unintended method execution
vulnerability in Action Pack which has been assigned the CVE identifier
CVE-2021-22885.

Versions Affected: >= 2.0.0.
Not affected: < 2.0.0.
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

There is a possible information disclosure / unintended method execution
vulnerability in Action Pack when using the redirect_to or polymorphic_url
helper with untrusted user input.

Vulnerable code will look like this:

redirect_to(params[:some_param])

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

To work around this problem, it is recommended to use an allow list for valid
parameters passed from the user. For example:

private def check(param)
  case param
  when "valid"
    param
  else
    "/"
  end
end

def index
  redirect_to(check(params[:some_param]))
end

Or force the user input to be cast to a string like this:

def index
  redirect_to(params[:some_param].to_s)
end

🚨 Possible DoS Vulnerability in Action Controller Token Authentication

There is a possible DoS vulnerability in the Token Authentication logic in
Action Controller. This vulnerability has been assigned the CVE identifier
CVE-2021-22904.

Versions Affected: >= 4.0.0
Not affected: < 4.0.0
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

Impacted code uses authenticate_or_request_with_http_token or
authenticate_with_http_token for request authentication. Impacted code will
look something like this:

class PostsController < ApplicationController
  before_action :authenticate

  private

  def authenticate
    authenticate_or_request_with_http_token do |token, options|
      # ...
    end
  end
end

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

The following monkey patch placed in an initializer can be used to work around
the issue:

module ActionController::HttpAuthentication::Token
  AUTHN_PAIR_DELIMITERS = /(?:,|;|\t)/
end

🚨 Possible DoS Vulnerability in Action Controller Token Authentication

There is a possible DoS vulnerability in the Token Authentication logic in
Action Controller. This vulnerability has been assigned the CVE identifier
CVE-2021-22904.

Versions Affected: >= 4.0.0
Not affected: < 4.0.0
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

Impacted code uses authenticate_or_request_with_http_token or
authenticate_with_http_token for request authentication. Impacted code will
look something like this:

class PostsController < ApplicationController
  before_action :authenticate

  private

  def authenticate
    authenticate_or_request_with_http_token do |token, options|
      # ...
    end
  end
end

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

The following monkey patch placed in an initializer can be used to work around
the issue:

module ActionController::HttpAuthentication::Token
  AUTHN_PAIR_DELIMITERS = /(?:,|;|\t)/
end

🚨 Possible DoS Vulnerability in Action Controller Token Authentication

There is a possible DoS vulnerability in the Token Authentication logic in
Action Controller. This vulnerability has been assigned the CVE identifier
CVE-2021-22904.

Versions Affected: >= 4.0.0
Not affected: < 4.0.0
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

Impacted code uses authenticate_or_request_with_http_token or
authenticate_with_http_token for request authentication. Impacted code will
look something like this:

class PostsController < ApplicationController
  before_action :authenticate

  private

  def authenticate
    authenticate_or_request_with_http_token do |token, options|
      # ...
    end
  end
end

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

The following monkey patch placed in an initializer can be used to work around
the issue:

module ActionController::HttpAuthentication::Token
  AUTHN_PAIR_DELIMITERS = /(?:,|;|\t)/
end

🚨 Possible DoS Vulnerability in Action Controller Token Authentication

There is a possible DoS vulnerability in the Token Authentication logic in
Action Controller. This vulnerability has been assigned the CVE identifier
CVE-2021-22904.

Versions Affected: >= 4.0.0
Not affected: < 4.0.0
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

Impacted code uses authenticate_or_request_with_http_token or
authenticate_with_http_token for request authentication. Impacted code will
look something like this:

class PostsController < ApplicationController
  before_action :authenticate

  private

  def authenticate
    authenticate_or_request_with_http_token do |token, options|
      # ...
    end
  end
end

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

The following monkey patch placed in an initializer can be used to work around
the issue:

module ActionController::HttpAuthentication::Token
  AUTHN_PAIR_DELIMITERS = /(?:,|;|\t)/
end

🚨 Possible Open Redirect Vulnerability in Action Pack

There is a possible Open Redirect Vulnerability in Action Pack. This
vulnerability has been assigned the CVE identifier CVE-2021-22903.

Versions Affected: >= v6.1.0.rc2
Not affected: < v6.1.0.rc2
Fixed Versions: 6.1.3.2

Impact

This is similar to CVE-2021-22881: Specially crafted Host headers in
combination with certain "allowed host" formats can cause the Host
Authorization middleware in Action Pack to redirect users to a malicious
website.

Since 9bc7ea5, strings in config.hosts that do not have a leading
dot are converted to regular expressions without proper escaping. This causes,
for example, config.hosts << "sub.example.com" to permit a request with a Host
header value of sub-example.com.

Workarounds

The following monkey patch put in an initializer can be used as a workaround:

class ActionDispatch::HostAuthorization::Permissions
  def sanitize_string(host)
    if host.start_with?(".")
      /\A(.+\.)?#{Regexp.escape(host[1..-1])}\z/i
    else
      /\A#{Regexp.escape host}\z/i
    end
  end
end

🚨 Possible Denial of Service vulnerability in Action Dispatch

There is a possible Denial of Service vulnerability in the Mime type parser of
Action Dispatch. This vulnerability has been assigned the CVE identifier
CVE-2021-22902.

Versions Affected: >= 6.0.0
Not affected: < 6.0.0
Fixed Versions: 6.0.3.7, 6.1.3.2

Impact

There is a possible Denial of Service vulnerability in Action Dispatch.
Carefully crafted Accept headers can cause the mime type parser in Action
Dispatch to do catastrophic backtracking in the regular expression engine.

Workarounds

The following monkey patch placed in an initializer can be used to work around
the issue:

module Mime
  class Type
    MIME_REGEXP = /\A(?:\*\/\*|#{MIME_NAME}\/(?:\*|#{MIME_NAME})(?>\s*#{MIME_PARAMETER}\s*)*)\z/
  end
end

🚨 Possible Denial of Service vulnerability in Action Dispatch

There is a possible Denial of Service vulnerability in the Mime type parser of
Action Dispatch. This vulnerability has been assigned the CVE identifier
CVE-2021-22902.

Versions Affected: >= 6.0.0
Not affected: < 6.0.0
Fixed Versions: 6.0.3.7, 6.1.3.2

Impact

There is a possible Denial of Service vulnerability in Action Dispatch.
Carefully crafted Accept headers can cause the mime type parser in Action
Dispatch to do catastrophic backtracking in the regular expression engine.

Workarounds

The following monkey patch placed in an initializer can be used to work around
the issue:

module Mime
  class Type
    MIME_REGEXP = /\A(?:\*\/\*|#{MIME_NAME}\/(?:\*|#{MIME_NAME})(?>\s*#{MIME_PARAMETER}\s*)*)\z/
  end
end

🚨 Possible Information Disclosure / Unintended Method Execution in Action Pack

There is a possible information disclosure / unintended method execution
vulnerability in Action Pack which has been assigned the CVE identifier
CVE-2021-22885.

Versions Affected: >= 2.0.0.
Not affected: < 2.0.0.
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

There is a possible information disclosure / unintended method execution
vulnerability in Action Pack when using the redirect_to or polymorphic_url
helper with untrusted user input.

Vulnerable code will look like this:

redirect_to(params[:some_param])

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

To work around this problem, it is recommended to use an allow list for valid
parameters passed from the user. For example:

private def check(param)
  case param
  when "valid"
    param
  else
    "/"
  end
end

def index
  redirect_to(check(params[:some_param]))
end

Or force the user input to be cast to a string like this:

def index
  redirect_to(params[:some_param].to_s)
end

🚨 Possible Information Disclosure / Unintended Method Execution in Action Pack

There is a possible information disclosure / unintended method execution
vulnerability in Action Pack which has been assigned the CVE identifier
CVE-2021-22885.

Versions Affected: >= 2.0.0.
Not affected: < 2.0.0.
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

There is a possible information disclosure / unintended method execution
vulnerability in Action Pack when using the redirect_to or polymorphic_url
helper with untrusted user input.

Vulnerable code will look like this:

redirect_to(params[:some_param])

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

To work around this problem, it is recommended to use an allow list for valid
parameters passed from the user. For example:

private def check(param)
  case param
  when "valid"
    param
  else
    "/"
  end
end

def index
  redirect_to(check(params[:some_param]))
end

Or force the user input to be cast to a string like this:

def index
  redirect_to(params[:some_param].to_s)
end

🚨 Possible Information Disclosure / Unintended Method Execution in Action Pack

There is a possible information disclosure / unintended method execution
vulnerability in Action Pack which has been assigned the CVE identifier
CVE-2021-22885.

Versions Affected: >= 2.0.0.
Not affected: < 2.0.0.
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

There is a possible information disclosure / unintended method execution
vulnerability in Action Pack when using the redirect_to or polymorphic_url
helper with untrusted user input.

Vulnerable code will look like this:

redirect_to(params[:some_param])

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

To work around this problem, it is recommended to use an allow list for valid
parameters passed from the user. For example:

private def check(param)
  case param
  when "valid"
    param
  else
    "/"
  end
end

def index
  redirect_to(check(params[:some_param]))
end

Or force the user input to be cast to a string like this:

def index
  redirect_to(params[:some_param].to_s)
end

🚨 Possible Open Redirect in Host Authorization Middleware

There is a possible open redirect vulnerability in the Host Authorization
middleware in Action Pack. This vulnerability has been assigned the CVE
identifier CVE-2021-22881.

Versions Affected: >= 6.0.0
Not affected: < 6.0.0
Fixed Versions: 6.1.2.1, 6.0.3.5

Impact

Specially crafted "Host" headers in combination with certain "allowed host"
formats can cause the Host Authorization middleware in Action Pack to redirect
users to a malicious website.

Impacted applications will have allowed hosts with a leading dot. For
example, configuration files that look like this:

config.hosts <<  '.tkte.ch'

When an allowed host contains a leading dot, a specially crafted Host header
can be used to redirect to a malicious website.

Workarounds

In the case a patch can't be applied, the following monkey patch can be used
in an initializer:

module ActionDispatch
  class HostAuthorization
    private
      def authorized?(request)
        valid_host = /
          \A
          (?<host>[a-z0-9.-]+|\[[a-f0-9]*:[a-f0-9\.:]+\])
          (:\d+)?
          \z
        /x

        origin_host = valid_host.match(
          request.get_header("HTTP_HOST").to_s.downcase)
        forwarded_host = valid_host.match(
          request.x_forwarded_host.to_s.split(/,\s?/).last)

        origin_host && @permissions.allows?(origin_host[:host]) && (
          forwarded_host.nil? || @permissions.allows?(forwarded_host[:host]))
      end
  end
end

🚨 Possible Open Redirect in Host Authorization Middleware

There is a possible open redirect vulnerability in the Host Authorization
middleware in Action Pack. This vulnerability has been assigned the CVE
identifier CVE-2021-22881.

Versions Affected: >= 6.0.0
Not affected: < 6.0.0
Fixed Versions: 6.1.2.1, 6.0.3.5

Impact

Specially crafted "Host" headers in combination with certain "allowed host"
formats can cause the Host Authorization middleware in Action Pack to redirect
users to a malicious website.

Impacted applications will have allowed hosts with a leading dot. For
example, configuration files that look like this:

config.hosts <<  '.tkte.ch'

When an allowed host contains a leading dot, a specially crafted Host header
can be used to redirect to a malicious website.

Workarounds

In the case a patch can't be applied, the following monkey patch can be used
in an initializer:

module ActionDispatch
  class HostAuthorization
    private
      def authorized?(request)
        valid_host = /
          \A
          (?<host>[a-z0-9.-]+|\[[a-f0-9]*:[a-f0-9\.:]+\])
          (:\d+)?
          \z
        /x

        origin_host = valid_host.match(
          request.get_header("HTTP_HOST").to_s.downcase)
        forwarded_host = valid_host.match(
          request.x_forwarded_host.to_s.split(/,\s?/).last)

        origin_host && @permissions.allows?(origin_host[:host]) && (
          forwarded_host.nil? || @permissions.allows?(forwarded_host[:host]))
      end
  end
end

🚨 Possible XSS Vulnerability in Action Pack in Development Mode

There is a possible XSS vulnerability in Action Pack while the application
server is in development mode. This vulnerability is in the Actionable
Exceptions middleware. This vulnerability has been assigned the CVE
identifier CVE-2020-8264.

Versions Affected: >= 6.0.0
Not affected: < 6.0.0
Fixed Versions: 6.0.3.4

Impact

When an application is running in development mode, and attacker can send or
embed (in another page) a specially crafted URL which can allow the attacker
to execute JavaScript in the context of the local application.

Workarounds

Until such time as the patch can be applied, application developers should
disable the Actionable Exceptions middleware in their development environment via
a line such as this one in their config/environment/development.rb:

config.middleware.delete ActionDispatch::ActionableExceptions

🚨 Untrusted users able to run pending migrations in production

There is a vulnerability in versions of Rails prior to 6.0.3.2 that allowed
an untrusted user to run any pending migrations on a Rails app running in
production.

This vulnerability has been assigned the CVE identifier CVE-2020-8185.

Versions Affected: 6.0.0 < rails < 6.0.3.2
Not affected: Applications with config.action_dispatch.show_exceptions = false (this is not a default setting in production)
Fixed Versions: rails >= 6.0.3.2

Impact

Using this issue, an attacker would be able to execute any migrations that
are pending for a Rails app running in production mode. It is important to
note that an attacker is limited to running migrations the application
developer has already defined in their application and ones that have not
already ran.

Workarounds

Until such time as the patch can be applied, application developers should
disable the ActionDispatch middleware in their production environment via
a line such as this one in their config/environment/production.rb:

config.middleware.delete ActionDispatch::ActionableExceptions

🚨 Possible Strong Parameters Bypass in ActionPack

There is a strong parameters bypass vector in ActionPack.

Versions Affected: rails <= 6.0.3
Not affected: rails < 4.0.0
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

In some cases user supplied information can be inadvertently leaked from
Strong Parameters. Specifically the return value of each, or each_value,
or each_pair will return the underlying "untrusted" hash of data that was
read from the parameters. Applications that use this return value may be
inadvertently use untrusted user input.

Impacted code will look something like this:

def update
  # Attacker has included the parameter: `{ is_admin: true }`
  User.update(clean_up_params)
end

def clean_up_params
   params.each { |k, v|  SomeModel.check(v) if k == :name }
end

Note the mistaken use of each in the clean_up_params method in the above
example.

Workarounds

Do not use the return values of each, each_value, or each_pair in your
application.

🚨 Ability to forge per-form CSRF tokens given a global CSRF token

It is possible to possible to, given a global CSRF token such as the one
present in the authenticity_token meta tag, forge a per-form CSRF token for
any action for that session.

Versions Affected: rails < 5.2.5, rails < 6.0.4
Not affected: Applications without existing HTML injection vulnerabilities.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Given the ability to extract the global CSRF token, an attacker would be able to
construct a per-form CSRF token for that session.

Workarounds

This is a low-severity security issue. As such, no workaround is necessarily
until such time as the application can be upgraded.

🚨 Ability to forge per-form CSRF tokens given a global CSRF token

It is possible to possible to, given a global CSRF token such as the one
present in the authenticity_token meta tag, forge a per-form CSRF token for
any action for that session.

Versions Affected: rails < 5.2.5, rails < 6.0.4
Not affected: Applications without existing HTML injection vulnerabilities.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Given the ability to extract the global CSRF token, an attacker would be able to
construct a per-form CSRF token for that session.

Workarounds

This is a low-severity security issue. As such, no workaround is necessarily
until such time as the application can be upgraded.

🚨 Possible Strong Parameters Bypass in ActionPack

There is a strong parameters bypass vector in ActionPack.

Versions Affected: rails <= 6.0.3
Not affected: rails < 4.0.0
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

In some cases user supplied information can be inadvertently leaked from
Strong Parameters. Specifically the return value of each, or each_value,
or each_pair will return the underlying "untrusted" hash of data that was
read from the parameters. Applications that use this return value may be
inadvertently use untrusted user input.

Impacted code will look something like this:

def update
  # Attacker has included the parameter: `{ is_admin: true }`
  User.update(clean_up_params)
end

def clean_up_params
   params.each { |k, v|  SomeModel.check(v) if k == :name }
end

Note the mistaken use of each in the clean_up_params method in the above
example.

Workarounds

Do not use the return values of each, each_value, or each_pair in your
application.

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by 4 commits:

• Preparing for 7.0.8.1 release
• update changelog
• fix XSS vulnerability when using translation
• Merge pull request #48869 from brunoprietog/disable-session-active-storage-proxy-controllers

🚨 DOM Based Cross-site Scripting in rails-ujs for contenteditable HTML Elements

NOTE: rails-ujs is part of Rails/actionview since 5.1.0.

There is a potential DOM based cross-site scripting issue in rails-ujs
which leverages the Clipboard API to target HTML elements that are
assigned the contenteditable attribute. This has the potential to
occur when pasting malicious HTML content from the clipboard that
includes a data-method, data-remote or data-disable-with attribute.

This vulnerability has been assigned the CVE identifier CVE-2023-23913.

Not affected: < 5.1.0
Versions Affected: >= 5.1.0
Fixed Versions: 6.1.7.3, 7.0.4.3

Impact
If the specified malicious HTML clipboard content is provided to a
contenteditable element, this could result in the arbitrary execution
of javascript on the origin in question.

Releases
The FIXED releases are available at the normal locations.

Workarounds
We recommend that all users upgrade to one of the FIXED versions.
In the meantime, users can attempt to mitigate this vulnerability
by removing the contenteditable attribute from elements in pages
that rails-ujs will interact with.

Patches
To aid users who aren’t able to upgrade immediately we have provided
patches for the two supported release series. They are in git-am
format and consist of a single changeset.

• rails-ujs-data-method-contenteditable-6-1.patch - Patch for 6.1 series
• rails-ujs-data-method-contenteditable-7-0.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are
supported at present, and 6.0.Z for severe vulnerabilities.

Users of earlier unsupported releases are advised to upgrade as
soon as possible as we cannot guarantee the continued availability
of security fixes for unsupported releases.

Credits
We would like to thank ryotak 15 for reporting this!

• rails-ujs-data-method-contenteditable-6-1.patch (8.5 KB)
• rails-ujs-data-method-contenteditable-7-0.patch (8.5 KB)
• rails-ujs-data-method-contenteditable-main.patch (8.9 KB)

🚨 DOM Based Cross-site Scripting in rails-ujs for contenteditable HTML Elements

NOTE: rails-ujs is part of Rails/actionview since 5.1.0.

There is a potential DOM based cross-site scripting issue in rails-ujs
which leverages the Clipboard API to target HTML elements that are
assigned the contenteditable attribute. This has the potential to
occur when pasting malicious HTML content from the clipboard that
includes a data-method, data-remote or data-disable-with attribute.

This vulnerability has been assigned the CVE identifier CVE-2023-23913.

Not affected: < 5.1.0
Versions Affected: >= 5.1.0
Fixed Versions: 6.1.7.3, 7.0.4.3

Impact
If the specified malicious HTML clipboard content is provided to a
contenteditable element, this could result in the arbitrary execution
of javascript on the origin in question.

Releases
The FIXED releases are available at the normal locations.

Workarounds
We recommend that all users upgrade to one of the FIXED versions.
In the meantime, users can attempt to mitigate this vulnerability
by removing the contenteditable attribute from elements in pages
that rails-ujs will interact with.

Patches
To aid users who aren’t able to upgrade immediately we have provided
patches for the two supported release series. They are in git-am
format and consist of a single changeset.

• rails-ujs-data-method-contenteditable-6-1.patch - Patch for 6.1 series
• rails-ujs-data-method-contenteditable-7-0.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are
supported at present, and 6.0.Z for severe vulnerabilities.

Users of earlier unsupported releases are advised to upgrade as
soon as possible as we cannot guarantee the continued availability
of security fixes for unsupported releases.

Credits
We would like to thank ryotak 15 for reporting this!

• rails-ujs-data-method-contenteditable-6-1.patch (8.5 KB)
• rails-ujs-data-method-contenteditable-7-0.patch (8.5 KB)
• rails-ujs-data-method-contenteditable-main.patch (8.9 KB)

🚨 Possible XSS Vulnerability in Action View tag helpers

There is a possible XSS vulnerability in Action View tag helpers. Passing
untrusted input as hash keys can lead to a possible XSS vulnerability. This
vulnerability has been assigned the CVE identifier CVE-2022-27777.

Versions Affected: ALL
Not affected: NONE
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

If untrusted data is passed as the hash key for tag attributes, there is a
possibility that the untrusted data may not be properly escaped which can
lead to an XSS vulnerability.

Impacted code will look something like this:

check_box_tag('thename', 'thevalue', false, aria: { malicious_input => 'thevalueofaria' })

Where the "malicious_input" variable contains untrusted data.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Escape the untrusted data before using it as a key for tag helper methods.

🚨 Possible XSS Vulnerability in Action View tag helpers

There is a possible XSS vulnerability in Action View tag helpers. Passing
untrusted input as hash keys can lead to a possible XSS vulnerability. This
vulnerability has been assigned the CVE identifier CVE-2022-27777.

Versions Affected: ALL
Not affected: NONE
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

If untrusted data is passed as the hash key for tag attributes, there is a
possibility that the untrusted data may not be properly escaped which can
lead to an XSS vulnerability.

Impacted code will look something like this:

check_box_tag('thename', 'thevalue', false, aria: { malicious_input => 'thevalueofaria' })

Where the "malicious_input" variable contains untrusted data.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Escape the untrusted data before using it as a key for tag helper methods.

🚨 Possible XSS Vulnerability in Action View tag helpers

There is a possible XSS vulnerability in Action View tag helpers. Passing
untrusted input as hash keys can lead to a possible XSS vulnerability. This
vulnerability has been assigned the CVE identifier CVE-2022-27777.

Versions Affected: ALL
Not affected: NONE
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

If untrusted data is passed as the hash key for tag attributes, there is a
possibility that the untrusted data may not be properly escaped which can
lead to an XSS vulnerability.

Impacted code will look something like this:

check_box_tag('thename', 'thevalue', false, aria: { malicious_input => 'thevalueofaria' })

Where the "malicious_input" variable contains untrusted data.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Escape the untrusted data before using it as a key for tag helper methods.

🚨 Possible XSS Vulnerability in Action View tag helpers

There is a possible XSS vulnerability in Action View tag helpers. Passing
untrusted input as hash keys can lead to a possible XSS vulnerability. This
vulnerability has been assigned the CVE identifier CVE-2022-27777.

Versions Affected: ALL
Not affected: NONE
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

If untrusted data is passed as the hash key for tag attributes, there is a
possibility that the untrusted data may not be properly escaped which can
lead to an XSS vulnerability.

Impacted code will look something like this:

check_box_tag('thename', 'thevalue', false, aria: { malicious_input => 'thevalueofaria' })

Where the "malicious_input" variable contains untrusted data.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Escape the untrusted data before using it as a key for tag helper methods.

🚨 Potential XSS vulnerability in Action View

There is a potential Cross-Site Scripting (XSS) vulnerability in Action
View's translation helpers. Views that allow the user to control the
default (not found) value of the t and translate helpers could be
susceptible to XSS attacks.

Impact

When an HTML-unsafe string is passed as the default for a missing
translation key named html or ending in _html,
the default string is incorrectly marked as HTML-safe and not escaped.
Vulnerable code may look like the following examples:

<%# The welcome_html translation is not defined for the current locale: %>
<%= t("welcome_html", default: untrusted_user_controlled_string) %>

<%# Neither the title.html translation nor the missing.html translation is defined for the current locale: %>
<%= t("title.html", default: [:"missing.html", untrusted_user_controlled_string]) %>

Workarounds

Impacted users who can’t upgrade to a patched Rails version can avoid
this issue by manually escaping default translations with the
html_escape helper (aliased as h):

<%= t("welcome_html", default: h(untrusted_user_controlled_string)) %>

🚨 Potential XSS vulnerability in Action View

There is a potential Cross-Site Scripting (XSS) vulnerability in Action
View's translation helpers. Views that allow the user to control the
default (not found) value of the t and translate helpers could be
susceptible to XSS attacks.

Impact

When an HTML-unsafe string is passed as the default for a missing
translation key named html or ending in _html,
the default string is incorrectly marked as HTML-safe and not escaped.
Vulnerable code may look like the following examples:

<%# The welcome_html translation is not defined for the current locale: %>
<%= t("welcome_html", default: untrusted_user_controlled_string) %>

<%# Neither the title.html translation nor the missing.html translation is defined for the current locale: %>
<%= t("title.html", default: [:"missing.html", untrusted_user_controlled_string]) %>

Workarounds

Impacted users who can’t upgrade to a patched Rails version can avoid
this issue by manually escaping default translations with the
html_escape helper (aliased as h):

<%= t("welcome_html", default: h(untrusted_user_controlled_string)) %>

🚨 CSRF Vulnerability in rails-ujs

There is an vulnerability in rails-ujs that allows attackers to send
CSRF tokens to wrong domains.

Versions Affected: rails <= 6.0.3
Not affected: Applications which don't use rails-ujs.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

This is a regression of CVE-2015-1840.

In the scenario where an attacker might be able to control the href attribute of an anchor tag or
the action attribute of a form tag that will trigger a POST action, the attacker can set the
href or action to a cross-origin URL, and the CSRF token will be sent.

Workarounds

To work around this problem, change code that allows users to control the href attribute of an anchor
tag or the action attribute of a form tag to filter the user parameters.

For example, code like this:

link_to params

to code like this:

link_to filtered_params

def filtered_params
  # Filter just the parameters that you trust
end

🚨 CSRF Vulnerability in rails-ujs

There is an vulnerability in rails-ujs that allows attackers to send
CSRF tokens to wrong domains.

Versions Affected: rails <= 6.0.3
Not affected: Applications which don't use rails-ujs.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

This is a regression of CVE-2015-1840.

In the scenario where an attacker might be able to control the href attribute of an anchor tag or
the action attribute of a form tag that will trigger a POST action, the attacker can set the
href or action to a cross-origin URL, and the CSRF token will be sent.

Workarounds

To work around this problem, change code that allows users to control the href attribute of an anchor
tag or the action attribute of a form tag to filter the user parameters.

For example, code like this:

link_to params

to code like this:

link_to filtered_params

def filtered_params
  # Filter just the parameters that you trust
end

🚨 Possible XSS vulnerability in ActionView

There is a possible XSS vulnerability in ActionView's JavaScript literal
escape helpers. Views that use the j or escape_javascript methods
may be susceptible to XSS attacks.

Versions Affected: All.
Not affected: None.
Fixed Versions: 6.0.2.2, 5.2.4.2

Impact

There is a possible XSS vulnerability in the j and escape_javascript
methods in ActionView. These methods are used for escaping JavaScript string
literals. Impacted code will look something like this:

<script>let a = `<%= j unknown_input %>`</script>

or

<script>let a = `<%= escape_javascript unknown_input %>`</script>

Releases

The 6.0.2.2 and 5.2.4.2 releases are available at the normal locations.

Workarounds

For those that can't upgrade, the following monkey patch may be used:

ActionView::Helpers::JavaScriptHelper::JS_ESCAPE_MAP.merge!(
  {
    "`" => "\\`",
    "$" => "\\$"
  }
)

module ActionView::Helpers::JavaScriptHelper
  alias :old_ej :escape_javascript
  alias :old_j :j

  def escape_javascript(javascript)
    javascript = javascript.to_s
    if javascript.empty?
      result = ""
    else
      result = javascript.gsub(/(\\|<\/|\r\n|\342\200\250|\342\200\251|[\n\r"']|[`]|[$])/u, JS_ESCAPE_MAP)
    end
    javascript.html_safe? ? result.html_safe : result
  end

  alias :j :escape_javascript
end

🚨 Possible XSS vulnerability in ActionView

There is a possible XSS vulnerability in ActionView's JavaScript literal
escape helpers. Views that use the j or escape_javascript methods
may be susceptible to XSS attacks.

Versions Affected: All.
Not affected: None.
Fixed Versions: 6.0.2.2, 5.2.4.2

Impact

There is a possible XSS vulnerability in the j and escape_javascript
methods in ActionView. These methods are used for escaping JavaScript string
literals. Impacted code will look something like this:

<script>let a = `<%= j unknown_input %>`</script>

or

<script>let a = `<%= escape_javascript unknown_input %>`</script>

Releases

The 6.0.2.2 and 5.2.4.2 releases are available at the normal locations.

Workarounds

For those that can't upgrade, the following monkey patch may be used:

ActionView::Helpers::JavaScriptHelper::JS_ESCAPE_MAP.merge!(
  {
    "`" => "\\`",
    "$" => "\\$"
  }
)

module ActionView::Helpers::JavaScriptHelper
  alias :old_ej :escape_javascript
  alias :old_j :j

  def escape_javascript(javascript)
    javascript = javascript.to_s
    if javascript.empty?
      result = ""
    else
      result = javascript.gsub(/(\\|<\/|\r\n|\342\200\250|\342\200\251|[\n\r"']|[`]|[$])/u, JS_ESCAPE_MAP)
    end
    javascript.html_safe? ? result.html_safe : result
  end

  alias :j :escape_javascript
end

🚨 Denial of Service Vulnerability in Action View

There is a potential denial of service vulnerability in actionview.
This vulnerability has been assigned the CVE identifier CVE-2019-5419.

Impact

Specially crafted accept headers can cause the Action View template location
code to consume 100% CPU, causing the server unable to process requests. This
impacts all Rails applications that render views.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

This vulnerability can be mitigated by wrapping render calls with
respond_to blocks. For example, the following example is vulnerable:

class UserController < ApplicationController
  def index
    render "index"
  end
end

But the following code is not vulnerable:

class UserController < ApplicationController
  def index
    respond_to |format|
      format.html { render "index" }
    end
  end
end

Implicit rendering is impacted, so this code is vulnerable:

class UserController < ApplicationController
  def index
  end
end

But can be changed this this:

class UserController < ApplicationController
  def index
    respond_to |format|
      format.html { render "index" }
    end
  end
end

Alternatively to specifying the format, the following monkey patch can be
applied in an initializer:

$ cat config/initializers/formats_filter.rb
# frozen_string_literal: true

ActionDispatch::Request.prepend(Module.new do
  def formats
    super().select do |format|
      format.symbol || format.ref == "*/*"
    end
  end
end)

Credits

Thanks to John Hawthorn john@hawthorn.email of GitHub

🚨 Denial of Service Vulnerability in Action View

There is a potential denial of service vulnerability in actionview.
This vulnerability has been assigned the CVE identifier CVE-2019-5419.

Impact

Specially crafted accept headers can cause the Action View template location
code to consume 100% CPU, causing the server unable to process requests. This
impacts all Rails applications that render views.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

This vulnerability can be mitigated by wrapping render calls with
respond_to blocks. For example, the following example is vulnerable:

class UserController < ApplicationController
  def index
    render "index"
  end
end

But the following code is not vulnerable:

class UserController < ApplicationController
  def index
    respond_to |format|
      format.html { render "index" }
    end
  end
end

Implicit rendering is impacted, so this code is vulnerable:

class UserController < ApplicationController
  def index
  end
end

But can be changed this this:

class UserController < ApplicationController
  def index
    respond_to |format|
      format.html { render "index" }
    end
  end
end

Alternatively to specifying the format, the following monkey patch can be
applied in an initializer:

$ cat config/initializers/formats_filter.rb
# frozen_string_literal: true

ActionDispatch::Request.prepend(Module.new do
  def formats
    super().select do |format|
      format.symbol || format.ref == "*/*"
    end
  end
end)

Credits

Thanks to John Hawthorn john@hawthorn.email of GitHub

🚨 File Content Disclosure in Action View

There is a possible file content disclosure vulnerability in Action View. This
vulnerability has been assigned the CVE identifier CVE-2019-5418.

Versions Affected: All.
Not affected: None.
Fixed Versions: 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, 4.2.11.1

Impact

There is a possible file content disclosure vulnerability in Action View.
Specially crafted accept headers in combination with calls to render file:
can cause arbitrary files on the target server to be rendered, disclosing the
file contents.

The impact is limited to calls to render which render file contents without
a specified accept format. Impacted code in a controller looks something like
this:

class UserController < ApplicationController
  def index
    render file: "#{Rails.root}/some/file"
  end
end

Rendering templates as opposed to files is not impacted by this vulnerability.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, and 4.2.11.1 releases are
available at the normal locations.

Workarounds

This vulnerability can be mitigated by specifying a format for file rendering,
like this:

class UserController < ApplicationController
  def index
    render file: "#{Rails.root}/some/file", formats: [:html]
  end
end

In summary, impacted calls to render look like this:

render file: "#{Rails.root}/some/file"

The vulnerability can be mitigated by changing to this:

render file: "#{Rails.root}/some/file", formats: [:html]

Other calls to render are not impacted.

Alternatively, the following monkey patch can be applied in an initializer:

$ cat config/initializers/formats_filter.rb
# frozen_string_literal: true

ActionDispatch::Request.prepend(Module.new do
  def formats
    super().select do |format|
      format.symbol || format.ref == "*/*"
    end
  end
end)

Credits

Thanks to John Hawthorn john@hawthorn.email of GitHub

🚨 File Content Disclosure in Action View

There is a possible file content disclosure vulnerability in Action View. This
vulnerability has been assigned the CVE identifier CVE-2019-5418.

Versions Affected: All.
Not affected: None.
Fixed Versions: 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, 4.2.11.1

Impact

There is a possible file content disclosure vulnerability in Action View.
Specially crafted accept headers in combination with calls to render file:
can cause arbitrary files on the target server to be rendered, disclosing the
file contents.

The impact is limited to calls to render which render file contents without
a specified accept format. Impacted code in a controller looks something like
this:

class UserController < ApplicationController
  def index
    render file: "#{Rails.root}/some/file"
  end
end

Rendering templates as opposed to files is not impacted by this vulnerability.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, and 4.2.11.1 releases are
available at the normal locations.

Workarounds

This vulnerability can be mitigated by specifying a format for file rendering,
like this:

class UserController < ApplicationController
  def index
    render file: "#{Rails.root}/some/file", formats: [:html]
  end
end

In summary, impacted calls to render look like this:

render file: "#{Rails.root}/some/file"

The vulnerability can be mitigated by changing to this:

render file: "#{Rails.root}/some/file", formats: [:html]

Other calls to render are not impacted.

Alternatively, the following monkey patch can be applied in an initializer:

$ cat config/initializers/formats_filter.rb
# frozen_string_literal: true

ActionDispatch::Request.prepend(Module.new do
  def formats
    super().select do |format|
      format.symbol || format.ref == "*/*"
    end
  end
end)

Credits

Thanks to John Hawthorn john@hawthorn.email of GitHub

🚨 File Content Disclosure in Action View

There is a possible file content disclosure vulnerability in Action View. This
vulnerability has been assigned the CVE identifier CVE-2019-5418.

Versions Affected: All.
Not affected: None.
Fixed Versions: 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, 4.2.11.1

Impact

There is a possible file content disclosure vulnerability in Action View.
Specially crafted accept headers in combination with calls to render file:
can cause arbitrary files on the target server to be rendered, disclosing the
file contents.

The impact is limited to calls to render which render file contents without
a specified accept format. Impacted code in a controller looks something like
this:

class UserController < ApplicationController
  def index
    render file: "#{Rails.root}/some/file"
  end
end

Rendering templates as opposed to files is not impacted by this vulnerability.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, and 4.2.11.1 releases are
available at the normal locations.

Workarounds

This vulnerability can be mitigated by specifying a format for file rendering,
like this:

class UserController < ApplicationController
  def index
    render file: "#{Rails.root}/some/file", formats: [:html]
  end
end

In summary, impacted calls to render look like this:

render file: "#{Rails.root}/some/file"

The vulnerability can be mitigated by changing to this:

render file: "#{Rails.root}/some/file", formats: [:html]

Other calls to render are not impacted.

Alternatively, the following monkey patch can be applied in an initializer:

$ cat config/initializers/formats_filter.rb
# frozen_string_literal: true

ActionDispatch::Request.prepend(Module.new do
  def formats
    super().select do |format|
      format.symbol || format.ref == "*/*"
    end
  end
end)

Credits

Thanks to John Hawthorn john@hawthorn.email of GitHub

🚨 Denial of Service Vulnerability in Action View

There is a potential denial of service vulnerability in actionview.
This vulnerability has been assigned the CVE identifier CVE-2019-5419.

Impact

Specially crafted accept headers can cause the Action View template location
code to consume 100% CPU, causing the server unable to process requests. This
impacts all Rails applications that render views.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

This vulnerability can be mitigated by wrapping render calls with
respond_to blocks. For example, the following example is vulnerable:

class UserController < ApplicationController
  def index
    render "index"
  end
end

But the following code is not vulnerable:

class UserController < ApplicationController
  def index
    respond_to |format|
      format.html { render "index" }
    end
  end
end

Implicit rendering is impacted, so this code is vulnerable:

class UserController < ApplicationController
  def index
  end
end

But can be changed this this:

class UserController < ApplicationController
  def index
    respond_to |format|
      format.html { render "index" }
    end
  end
end

Alternatively to specifying the format, the following monkey patch can be
applied in an initializer:

$ cat config/initializers/formats_filter.rb
# frozen_string_literal: true

ActionDispatch::Request.prepend(Module.new do
  def formats
    super().select do |format|
      format.symbol || format.ref == "*/*"
    end
  end
end)

Credits

Thanks to John Hawthorn john@hawthorn.email of GitHub

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by 4 commits:

• Preparing for 7.0.8.1 release
• update changelog
• fix XSS vulnerability when using translation
• Merge pull request #48869 from brunoprietog/disable-session-active-storage-proxy-controllers

🚨 Broken Access Control vulnerability in Active Job

There is a vulnerability in Active Job. This vulnerability has been
assigned the CVE identifier CVE-2018-16476.

Versions Affected: >= 4.2.0
Not affected: < 4.2.0
Fixed Versions: 4.2.11, 5.0.7.1, 5.1.6.1, 5.2.1.1

Impact

Carefully crafted user input can cause Active Job to deserialize it using GlobalId
and allow an attacker to have access to information that they should not have.

Vulnerable code will look something like this:

MyJob.perform_later(user_input)

All users running an affected release should either upgrade or use one of the
workarounds immediately.

🚨 Broken Access Control vulnerability in Active Job

There is a vulnerability in Active Job. This vulnerability has been
assigned the CVE identifier CVE-2018-16476.

Versions Affected: >= 4.2.0
Not affected: < 4.2.0
Fixed Versions: 4.2.11, 5.0.7.1, 5.1.6.1, 5.2.1.1

Impact

Carefully crafted user input can cause Active Job to deserialize it using GlobalId
and allow an attacker to have access to information that they should not have.

Vulnerable code will look something like this:

MyJob.perform_later(user_input)

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by 4 commits:

• Preparing for 7.0.8.1 release
• update changelog
• fix XSS vulnerability when using translation
• Merge pull request #48869 from brunoprietog/disable-session-active-storage-proxy-controllers

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by 4 commits:

• Preparing for 7.0.8.1 release
• update changelog
• fix XSS vulnerability when using translation
• Merge pull request #48869 from brunoprietog/disable-session-active-storage-proxy-controllers

🚨 SQL Injection Vulnerability via ActiveRecord comments

There is a possible vulnerability in ActiveRecord related to the
sanitization of comments. This vulnerability has been assigned the CVE
identifier CVE-2023-22794.

Versions Affected: >= 6.0.0
Not affected: < 6.0.0
Fixed Versions: 6.0.6.1, 6.1.7.1, 7.0.4.1

Impact

Previously the implementation of escaping for comments was insufficient for

If malicious user input is passed to either the annotate query method, the
optimizer_hints query method, or through the QueryLogs interface which
automatically adds annotations, it may be sent to the database with
insufficient sanitization and be able to inject SQL outside of the comment.

In most cases these interfaces won’t be used with user input and users
should avoid doing so.

Example vulnerable code:

Post.where(id: 1).annotate("#{params[:user_input]}")

Post.where(id: 1).optimizer_hints("#{params[:user_input]}")

Example vulnerable QueryLogs configuration (the default configuration is not
vulnerable):

config.active_record.query_log_tags = [
  {
    something: -> { <some value including user input> }
  }
]

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

Avoid passing user input to annotate and avoid using QueryLogs configuration
which can include user input.

🚨 SQL Injection Vulnerability via ActiveRecord comments

There is a possible vulnerability in ActiveRecord related to the
sanitization of comments. This vulnerability has been assigned the CVE
identifier CVE-2023-22794.

Versions Affected: >= 6.0.0
Not affected: < 6.0.0
Fixed Versions: 6.0.6.1, 6.1.7.1, 7.0.4.1

Impact

Previously the implementation of escaping for comments was insufficient for

If malicious user input is passed to either the annotate query method, the
optimizer_hints query method, or through the QueryLogs interface which
automatically adds annotations, it may be sent to the database with
insufficient sanitization and be able to inject SQL outside of the comment.

In most cases these interfaces won’t be used with user input and users
should avoid doing so.

Example vulnerable code:

Post.where(id: 1).annotate("#{params[:user_input]}")

Post.where(id: 1).optimizer_hints("#{params[:user_input]}")

Example vulnerable QueryLogs configuration (the default configuration is not
vulnerable):

config.active_record.query_log_tags = [
  {
    something: -> { <some value including user input> }
  }
]

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

Avoid passing user input to annotate and avoid using QueryLogs configuration
which can include user input.

🚨 Denial of Service Vulnerability in ActiveRecord’s PostgreSQL adapter

There is a potential denial of service vulnerability present in
ActiveRecord’s PostgreSQL adapter.

This has been assigned the CVE identifier CVE-2022-44566.

Versions Affected: All.
Not affected: None.
Fixed Versions: 7.0.4.1, 6.1.7.1

Impact

In ActiveRecord <7.0.4.1 and <6.1.7.1, when a value outside the range for a
64bit signed integer is provided to the PostgreSQL connection adapter, it
will treat the target column type as numeric. Comparing integer values
against numeric values can result in a slow sequential scan resulting in
potential Denial of Service.

Workarounds

Ensure that user supplied input which is provided to ActiveRecord clauses do
not contain integers wider than a signed 64bit representation or floats.

🚨 Denial of Service Vulnerability in ActiveRecord’s PostgreSQL adapter

There is a potential denial of service vulnerability present in
ActiveRecord’s PostgreSQL adapter.

This has been assigned the CVE identifier CVE-2022-44566.

Versions Affected: All.
Not affected: None.
Fixed Versions: 7.0.4.1, 6.1.7.1

Impact

In ActiveRecord <7.0.4.1 and <6.1.7.1, when a value outside the range for a
64bit signed integer is provided to the PostgreSQL connection adapter, it
will treat the target column type as numeric. Comparing integer values
against numeric values can result in a slow sequential scan resulting in
potential Denial of Service.

Workarounds

Ensure that user supplied input which is provided to ActiveRecord clauses do
not contain integers wider than a signed 64bit representation or floats.

🚨 SQL Injection Vulnerability via ActiveRecord comments

There is a possible vulnerability in ActiveRecord related to the
sanitization of comments. This vulnerability has been assigned the CVE
identifier CVE-2023-22794.

Versions Affected: >= 6.0.0
Not affected: < 6.0.0
Fixed Versions: 6.0.6.1, 6.1.7.1, 7.0.4.1

Impact

Previously the implementation of escaping for comments was insufficient for

If malicious user input is passed to either the annotate query method, the
optimizer_hints query method, or through the QueryLogs interface which
automatically adds annotations, it may be sent to the database with
insufficient sanitization and be able to inject SQL outside of the comment.

In most cases these interfaces won’t be used with user input and users
should avoid doing so.

Example vulnerable code:

Post.where(id: 1).annotate("#{params[:user_input]}")

Post.where(id: 1).optimizer_hints("#{params[:user_input]}")

Example vulnerable QueryLogs configuration (the default configuration is not
vulnerable):

config.active_record.query_log_tags = [
  {
    something: -> { <some value including user input> }
  }
]

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

Avoid passing user input to annotate and avoid using QueryLogs configuration
which can include user input.

🚨 Possible RCE escalation bug with Serialized Columns in Active Record

There is a possible escalation to RCE when using YAML serialized columns in
Active Record. This vulnerability has been assigned the CVE identifier
CVE-2022-32224.

Versions Affected: All.
Not affected: None
Fixed Versions: 7.0.3.1, 6.1.6.1, 6.0.5.1, 5.2.8.1

Impact

When serialized columns that use YAML (the default) are deserialized, Rails
uses YAML.unsafe_load to convert the YAML data in to Ruby objects. If an
attacker can manipulate data in the database (via means like SQL injection),
then it may be possible for the attacker to escalate to an RCE.

Impacted Active Record models will look something like this:

class User < ApplicationRecord
  serialize :options       # Vulnerable: Uses YAML for serialization
  serialize :values, Array # Vulnerable: Uses YAML for serialization
  serialize :values, JSON  # Not vulnerable
end

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

The released versions change the default YAML deserializer to use
YAML.safe_load, which prevents deserialization of possibly dangerous
objects. This may introduce backwards compatibility issues with existing
data.

In order to cope with that situation, the released version also contains two
new Active Record configuration options. The configuration options are as
follows:

• config.active_storage.use_yaml_unsafe_load

When set to true, this configuration option tells Rails to use the old
"unsafe" YAML loading strategy, maintaining the existing behavior but leaving
the possible escalation vulnerability in place. Setting this option to true
is not recommended, but can aid in upgrading.

• config.active_record.yaml_column_permitted_classes

The "safe YAML" loading method does not allow all classes to be deserialized
by default. This option allows you to specify classes deemed "safe" in your
application. For example, if your application uses Symbol and Time in
serialized data, you can add Symbol and Time to the allowed list as follows:

config.active_record.yaml_column_permitted_classes = [Symbol, Date, Time]

Workarounds

There are no feasible workarounds for this issue, but other coders (such as
JSON) are not impacted.

🚨 Possible RCE escalation bug with Serialized Columns in Active Record

There is a possible escalation to RCE when using YAML serialized columns in
Active Record. This vulnerability has been assigned the CVE identifier
CVE-2022-32224.

Versions Affected: All.
Not affected: None
Fixed Versions: 7.0.3.1, 6.1.6.1, 6.0.5.1, 5.2.8.1

Impact

When serialized columns that use YAML (the default) are deserialized, Rails
uses YAML.unsafe_load to convert the YAML data in to Ruby objects. If an
attacker can manipulate data in the database (via means like SQL injection),
then it may be possible for the attacker to escalate to an RCE.

Impacted Active Record models will look something like this:

class User < ApplicationRecord
  serialize :options       # Vulnerable: Uses YAML for serialization
  serialize :values, Array # Vulnerable: Uses YAML for serialization
  serialize :values, JSON  # Not vulnerable
end

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

The released versions change the default YAML deserializer to use
YAML.safe_load, which prevents deserialization of possibly dangerous
objects. This may introduce backwards compatibility issues with existing
data.

In order to cope with that situation, the released version also contains two
new Active Record configuration options. The configuration options are as
follows:

• config.active_storage.use_yaml_unsafe_load

When set to true, this configuration option tells Rails to use the old
"unsafe" YAML loading strategy, maintaining the existing behavior but leaving
the possible escalation vulnerability in place. Setting this option to true
is not recommended, but can aid in upgrading.

• config.active_record.yaml_column_permitted_classes

The "safe YAML" loading method does not allow all classes to be deserialized
by default. This option allows you to specify classes deemed "safe" in your
application. For example, if your application uses Symbol and Time in
serialized data, you can add Symbol and Time to the allowed list as follows:

config.active_record.yaml_column_permitted_classes = [Symbol, Date, Time]

Workarounds

There are no feasible workarounds for this issue, but other coders (such as
JSON) are not impacted.

🚨 Possible RCE escalation bug with Serialized Columns in Active Record

There is a possible escalation to RCE when using YAML serialized columns in
Active Record. This vulnerability has been assigned the CVE identifier
CVE-2022-32224.

Versions Affected: All.
Not affected: None
Fixed Versions: 7.0.3.1, 6.1.6.1, 6.0.5.1, 5.2.8.1

Impact

When serialized columns that use YAML (the default) are deserialized, Rails
uses YAML.unsafe_load to convert the YAML data in to Ruby objects. If an
attacker can manipulate data in the database (via means like SQL injection),
then it may be possible for the attacker to escalate to an RCE.

Impacted Active Record models will look something like this:

class User < ApplicationRecord
  serialize :options       # Vulnerable: Uses YAML for serialization
  serialize :values, Array # Vulnerable: Uses YAML for serialization
  serialize :values, JSON  # Not vulnerable
end

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

The released versions change the default YAML deserializer to use
YAML.safe_load, which prevents deserialization of possibly dangerous
objects. This may introduce backwards compatibility issues with existing
data.

In order to cope with that situation, the released version also contains two
new Active Record configuration options. The configuration options are as
follows:

• config.active_storage.use_yaml_unsafe_load

When set to true, this configuration option tells Rails to use the old
"unsafe" YAML loading strategy, maintaining the existing behavior but leaving
the possible escalation vulnerability in place. Setting this option to true
is not recommended, but can aid in upgrading.

• config.active_record.yaml_column_permitted_classes

The "safe YAML" loading method does not allow all classes to be deserialized
by default. This option allows you to specify classes deemed "safe" in your
application. For example, if your application uses Symbol and Time in
serialized data, you can add Symbol and Time to the allowed list as follows:

config.active_record.yaml_column_permitted_classes = [Symbol, Date, Time]

Workarounds

There are no feasible workarounds for this issue, but other coders (such as
JSON) are not impacted.

🚨 Possible RCE escalation bug with Serialized Columns in Active Record

There is a possible escalation to RCE when using YAML serialized columns in
Active Record. This vulnerability has been assigned the CVE identifier
CVE-2022-32224.

Versions Affected: All.
Not affected: None
Fixed Versions: 7.0.3.1, 6.1.6.1, 6.0.5.1, 5.2.8.1

Impact

When serialized columns that use YAML (the default) are deserialized, Rails
uses YAML.unsafe_load to convert the YAML data in to Ruby objects. If an
attacker can manipulate data in the database (via means like SQL injection),
then it may be possible for the attacker to escalate to an RCE.

Impacted Active Record models will look something like this:

class User < ApplicationRecord
  serialize :options       # Vulnerable: Uses YAML for serialization
  serialize :values, Array # Vulnerable: Uses YAML for serialization
  serialize :values, JSON  # Not vulnerable
end

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

The released versions change the default YAML deserializer to use
YAML.safe_load, which prevents deserialization of possibly dangerous
objects. This may introduce backwards compatibility issues with existing
data.

In order to cope with that situation, the released version also contains two
new Active Record configuration options. The configuration options are as
follows:

• config.active_storage.use_yaml_unsafe_load

When set to true, this configuration option tells Rails to use the old
"unsafe" YAML loading strategy, maintaining the existing behavior but leaving
the possible escalation vulnerability in place. Setting this option to true
is not recommended, but can aid in upgrading.

• config.active_record.yaml_column_permitted_classes

The "safe YAML" loading method does not allow all classes to be deserialized
by default. This option allows you to specify classes deemed "safe" in your
application. For example, if your application uses Symbol and Time in
serialized data, you can add Symbol and Time to the allowed list as follows:

config.active_record.yaml_column_permitted_classes = [Symbol, Date, Time]

Workarounds

There are no feasible workarounds for this issue, but other coders (such as
JSON) are not impacted.

🚨 Possible DoS Vulnerability in Active Record PostgreSQL adapter

There is a possible DoS vulnerability in the PostgreSQL adapter in Active
Record. This vulnerability has been assigned the CVE identifier CVE-2021-22880.

Versions Affected: >= 4.2.0
Not affected: < 4.2.0
Fixed Versions: 6.1.2.1, 6.0.3.5, 5.2.4.5

Impact

Carefully crafted input can cause the input validation in the "money" type of
the PostgreSQL adapter in Active Record to spend too much time in a regular
expression, resulting in the potential for a DoS attack.

This only impacts Rails applications that are using PostgreSQL along with
money type columns that take user input.

Workarounds

In the case a patch can't be applied, the following monkey patch can be used
in an initializer:

module ActiveRecord
  module ConnectionAdapters
    module PostgreSQL
      module OID # :nodoc:
        class Money < Type::Decimal # :nodoc:
          def cast_value(value)
            return value unless ::String === value

            value = value.sub(/^\((.+)\)$/, '-\1') # (4)
            case value
            when /^-?\D*+[\d,]+\.\d{2}$/  # (1)
              value.gsub!(/[^-\d.]/, "")
            when /^-?\D*+[\d.]+,\d{2}$/  # (2)
              value.gsub!(/[^-\d,]/, "").sub!(/,/, ".")
            end

            super(value)
          end
        end
      end
    end
  end
end

🚨 Possible DoS Vulnerability in Active Record PostgreSQL adapter

There is a possible DoS vulnerability in the PostgreSQL adapter in Active
Record. This vulnerability has been assigned the CVE identifier CVE-2021-22880.

Versions Affected: >= 4.2.0
Not affected: < 4.2.0
Fixed Versions: 6.1.2.1, 6.0.3.5, 5.2.4.5

Impact

Carefully crafted input can cause the input validation in the "money" type of
the PostgreSQL adapter in Active Record to spend too much time in a regular
expression, resulting in the potential for a DoS attack.

This only impacts Rails applications that are using PostgreSQL along with
money type columns that take user input.

Workarounds

In the case a patch can't be applied, the following monkey patch can be used
in an initializer:

module ActiveRecord
  module ConnectionAdapters
    module PostgreSQL
      module OID # :nodoc:
        class Money < Type::Decimal # :nodoc:
          def cast_value(value)
            return value unless ::String === value

            value = value.sub(/^\((.+)\)$/, '-\1') # (4)
            case value
            when /^-?\D*+[\d,]+\.\d{2}$/  # (1)
              value.gsub!(/[^-\d.]/, "")
            when /^-?\D*+[\d.]+,\d{2}$/  # (2)
              value.gsub!(/[^-\d,]/, "").sub!(/,/, ".")
            end

            super(value)
          end
        end
      end
    end
  end
end

🚨 Possible DoS Vulnerability in Active Record PostgreSQL adapter

There is a possible DoS vulnerability in the PostgreSQL adapter in Active
Record. This vulnerability has been assigned the CVE identifier CVE-2021-22880.

Versions Affected: >= 4.2.0
Not affected: < 4.2.0
Fixed Versions: 6.1.2.1, 6.0.3.5, 5.2.4.5

Impact

Carefully crafted input can cause the input validation in the "money" type of
the PostgreSQL adapter in Active Record to spend too much time in a regular
expression, resulting in the potential for a DoS attack.

This only impacts Rails applications that are using PostgreSQL along with
money type columns that take user input.

Workarounds

In the case a patch can't be applied, the following monkey patch can be used
in an initializer:

module ActiveRecord
  module ConnectionAdapters
    module PostgreSQL
      module OID # :nodoc:
        class Money < Type::Decimal # :nodoc:
          def cast_value(value)
            return value unless ::String === value

            value = value.sub(/^\((.+)\)$/, '-\1') # (4)
            case value
            when /^-?\D*+[\d,]+\.\d{2}$/  # (1)
              value.gsub!(/[^-\d.]/, "")
            when /^-?\D*+[\d.]+,\d{2}$/  # (2)
              value.gsub!(/[^-\d,]/, "").sub!(/,/, ".")
            end

            super(value)
          end
        end
      end
    end
  end
end

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by 4 commits:

• Preparing for 7.0.8.1 release
• update changelog
• fix XSS vulnerability when using translation
• Merge pull request #48869 from brunoprietog/disable-session-active-storage-proxy-controllers

🚨 Possible File Disclosure of Locally Encrypted Files

There is a possible file disclosure of locally encrypted files in Active Support. This vulnerability has been assigned the CVE identifier CVE-2023-38037.

Versions Affected: >= 5.2.0 Not affected: < 5.2.0 Fixed Versions: 7.0.7.1, 6.1.7.5

Impact

ActiveSupport::EncryptedFile writes contents that will be encrypted to a temporary file. The temporary file’s permissions are defaulted to the user’s current umask settings, meaning that it’s possible for other users on the same system to read the contents of the temporary file.

Attackers that have access to the file system could possibly read the contents of this temporary file while a user is editing it.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

To work around this issue, you can set your umask to be more restrictive like this:

$ umask 0077

🚨 Possible File Disclosure of Locally Encrypted Files

There is a possible file disclosure of locally encrypted files in Active Support. This vulnerability has been assigned the CVE identifier CVE-2023-38037.

Versions Affected: >= 5.2.0 Not affected: < 5.2.0 Fixed Versions: 7.0.7.1, 6.1.7.5

Impact

ActiveSupport::EncryptedFile writes contents that will be encrypted to a temporary file. The temporary file’s permissions are defaulted to the user’s current umask settings, meaning that it’s possible for other users on the same system to read the contents of the temporary file.

Attackers that have access to the file system could possibly read the contents of this temporary file while a user is editing it.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

To work around this issue, you can set your umask to be more restrictive like this:

$ umask 0077

🚨 Possible XSS Security Vulnerability in SafeBuffer#bytesplice

There is a vulnerability in ActiveSupport if the new bytesplice method is called on a SafeBuffer with untrusted user input.
This vulnerability has been assigned the CVE identifier CVE-2023-28120.

Versions Affected: All. Not affected: None Fixed Versions: 7.0.4.3, 6.1.7.3

Impact

ActiveSupport uses the SafeBuffer string subclass to tag strings as html_safe after they have been sanitized.
When these strings are mutated, the tag is should be removed to mark them as no longer being html_safe.

Ruby 3.2 introduced a new bytesplice method which ActiveSupport did not yet understand to be a mutation.
Users on older versions of Ruby are likely unaffected.

All users running an affected release and using bytesplice should either upgrade or use one of the workarounds immediately.

Workarounds

Avoid calling bytesplice on a SafeBuffer (html_safe) string with untrusted user input.

🚨 Possible XSS Security Vulnerability in SafeBuffer#bytesplice

There is a vulnerability in ActiveSupport if the new bytesplice method is called on a SafeBuffer with untrusted user input.
This vulnerability has been assigned the CVE identifier CVE-2023-28120.

Versions Affected: All. Not affected: None Fixed Versions: 7.0.4.3, 6.1.7.3

Impact

ActiveSupport uses the SafeBuffer string subclass to tag strings as html_safe after they have been sanitized.
When these strings are mutated, the tag is should be removed to mark them as no longer being html_safe.

Ruby 3.2 introduced a new bytesplice method which ActiveSupport did not yet understand to be a mutation.
Users on older versions of Ruby are likely unaffected.

All users running an affected release and using bytesplice should either upgrade or use one of the workarounds immediately.

Workarounds

Avoid calling bytesplice on a SafeBuffer (html_safe) string with untrusted user input.

🚨 ReDoS based DoS vulnerability in Active Support’s underscore

There is a possible regular expression based DoS vulnerability in Active
Support. This vulnerability has been assigned the CVE identifier
CVE-2023-22796.

Versions Affected: All
Not affected: None
Fixed Versions: 6.1.7.1, 7.0.4.1

Impact

A specially crafted string passed to the underscore method can cause the
regular expression engine to enter a state of catastrophic backtracking.
This can cause the process to use large amounts of CPU and memory, leading
to a possible DoS vulnerability.

This affects String#underscore, ActiveSupport::Inflector.underscore,
String#titleize, and any other methods using these.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

There are no feasible workarounds for this issue.

Users on Ruby 3.2.0 or greater may be able to reduce the impact by
configuring Regexp.timeout.

🚨 ReDoS based DoS vulnerability in Active Support’s underscore

There is a possible regular expression based DoS vulnerability in Active
Support. This vulnerability has been assigned the CVE identifier
CVE-2023-22796.

Versions Affected: All
Not affected: None
Fixed Versions: 6.1.7.1, 7.0.4.1

Impact

A specially crafted string passed to the underscore method can cause the
regular expression engine to enter a state of catastrophic backtracking.
This can cause the process to use large amounts of CPU and memory, leading
to a possible DoS vulnerability.

This affects String#underscore, ActiveSupport::Inflector.underscore,
String#titleize, and any other methods using these.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

There are no feasible workarounds for this issue.

Users on Ruby 3.2.0 or greater may be able to reduce the impact by
configuring Regexp.timeout.

🚨 Potentially unintended unmarshalling of user-provided objects in MemCacheStore and RedisCacheStore

There is potentially unexpected behaviour in the MemCacheStore and RedisCacheStore where, when
untrusted user input is written to the cache store using the raw: true parameter, re-reading the result
from the cache can evaluate the user input as a Marshalled object instead of plain text. Vulnerable code looks like:

data = cache.fetch("demo", raw: true) { untrusted_string }

Versions Affected: rails < 5.2.5, rails < 6.0.4
Not affected: Applications not using MemCacheStore or RedisCacheStore. Applications that do not use the raw option when storing untrusted user input.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Unmarshalling of untrusted user input can have impact up to and including RCE. At a minimum,
this vulnerability allows an attacker to inject untrusted Ruby objects into a web application.

In addition to upgrading to the latest versions of Rails, developers should ensure that whenever
they are calling Rails.cache.fetch they are using consistent values of the raw parameter for both
reading and writing, especially in the case of the RedisCacheStore which does not, prior to these changes,
detect if data was serialized using the raw option upon deserialization.

Workarounds

It is recommended that application developers apply the suggested patch or upgrade to the latest release as
soon as possible. If this is not possible, we recommend ensuring that all user-provided strings cached using
the raw argument should be double-checked to ensure that they conform to the expected format.

🚨 Potentially unintended unmarshalling of user-provided objects in MemCacheStore and RedisCacheStore

There is potentially unexpected behaviour in the MemCacheStore and RedisCacheStore where, when
untrusted user input is written to the cache store using the raw: true parameter, re-reading the result
from the cache can evaluate the user input as a Marshalled object instead of plain text. Vulnerable code looks like:

data = cache.fetch("demo", raw: true) { untrusted_string }

Versions Affected: rails < 5.2.5, rails < 6.0.4
Not affected: Applications not using MemCacheStore or RedisCacheStore. Applications that do not use the raw option when storing untrusted user input.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Unmarshalling of untrusted user input can have impact up to and including RCE. At a minimum,
this vulnerability allows an attacker to inject untrusted Ruby objects into a web application.

In addition to upgrading to the latest versions of Rails, developers should ensure that whenever
they are calling Rails.cache.fetch they are using consistent values of the raw parameter for both
reading and writing, especially in the case of the RedisCacheStore which does not, prior to these changes,
detect if data was serialized using the raw option upon deserialization.

Workarounds

It is recommended that application developers apply the suggested patch or upgrade to the latest release as
soon as possible. If this is not possible, we recommend ensuring that all user-provided strings cached using
the raw argument should be double-checked to ensure that they conform to the expected format.

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by 4 commits:

• Preparing for 7.0.8.1 release
• update changelog
• fix XSS vulnerability when using translation
• Merge pull request #48869 from brunoprietog/disable-session-active-storage-proxy-controllers

1.2.3

What's Changed

• Fix TimerTask :execution_interval docs by @freemanoid in #994
• Fix TimerTask docs to not refer to #execute as "blocking" by @bensheldon in #996
• Fix TimerTask example output by @bensheldon in #1003
• Fix broken CI due to rake-compiler error on Ruby < 2.6 by @mattbrictson in #1007
• Fix doc typo: yeild → yield by @mattbrictson in #1006
• Fix DaemonThreadFactory - reuse single Java thread factory by @obulkin in #1009
• Fix sporadic failures testing with JRuby by @headius in #1012
• Allow TimerSet to safely handle an executor raising RejectedExecutionError by @bensheldon in #999
• Use executor from arg in then_on/rescue_on/chain_on for Promises by @tgwizard in #1005
• Allow TimerTask to be initialized with a specified Executor by @bensheldon in #1000
• Create method ThreadPoolExecutor#active_count to expose the number of threads that are actively executing tasks by @bensheldon in #1002
• Drop dependency on mutex_m by @casperisfine in #1013
• Fix compile error on FreeBSD 14 by @janbiedermann in #1014
• Fix spurious return in Promises#wait_until_resolved by @eregon in #1016
• Remove AtomicReferenceMapBackend and CheapLockable by @eregon in #1018
• Add Ruby 3.3 in CI by @eregon in #1021
• docs: fix typo in throttle docs by @G-Rath in #1024
• docs: update promises grammar by @G-Rath in #1026
• Add TimerTask#interval_type option to configure interval calculation by @bensheldon in #997

New Contributors

• @freemanoid made their first contribution in #994
• @bensheldon made their first contribution in #996
• @mattbrictson made their first contribution in #1007
• @obulkin made their first contribution in #1009
• @headius made their first contribution in #1012
• @tgwizard made their first contribution in #1005
• @janbiedermann made their first contribution in #1014
• @G-Rath made their first contribution in #1024

Full Changelog: v1.2.2...v1.2.3

1.2.2

concurrent-ruby 1.2.2:

• (#993) Fix arguments passed to Concurrent::Map's default_proc.

1.2.1

concurrent-ruby 1.2.1:

• (#990) Add missing require 'fiber' for FiberLocalVar.
• (#989) Optimize Concurrent::Map#[] on CRuby by letting the backing Hash handle the default_proc.

1.2.0

concurrent-ruby 1.2.0:

• (#975) Set the Ruby compatibility version at 2.3
• (#962) Fix ReentrantReadWriteLock to use the same granularity for locals as for Mutex it uses.
• (#983) Add FiberLocalVar
• (#934) concurrent-ruby now supports requiring individual classes (public classes listed in the docs), e.g., require 'concurrent/map'
• (#976) Let Promises.any_fulfilled_future take an Event
• Improve documentation of various classes
• (#972) Remove Rubinius-related code

concurrent-ruby-edge 0.7.0:

• (#975) Set the Ruby compatibility version at 2.3
• (#934) concurrent-ruby now supports requiring individual classes (public classes listed in the docs), e.g., require 'concurrent/map'
• (#972) Remove Rubinius-related code

1.1.10

concurrent-ruby:

• (#951) Set the Ruby compatibility version at 2.2
• (#939, #933) The caller_runs fallback policy no longer blocks reads from the job queue by worker threads
• (#938, #761, #652) You can now explicitly prune_pool a thread pool (Sylvain Joyeux)
• (#937, #757, #670) We switched the Yahoo stock API for demos to Alpha Vantage (Gustavo Caso)
• (#932, #931) We changed how SafeTaskExecutor handles local jump errors (Aaron Jensen)
• (#927) You can use keyword arguments in your initialize when using Async (Matt Larraz)
• (#926, #639) We removed timeout from TimerTask because it wasn't sound, and now it's a no-op with a warning (Jacob Atzen)
• (#919) If you double-lock a re-entrant read-write lock, we promote to locked for writing (zp yuan)
• (#915) monotonic_time now accepts an optional unit parameter, as Ruby's clock_gettime (Jean Boussier)

1.1.9 (from changelog)

concurrent-ruby:

• (#866) Child promise state not set to :pending immediately after #execute when parent has completed
• (#905, #872) Fix RubyNonConcurrentPriorityQueue#delete method
• (2df0337d) Make sure locks are not shared on shared when objects are dup/cloned
• (#900, #906, #796, #847, #911) Fix Concurrent::Set tread-safety issues on CRuby
• (#907) Add new ConcurrentMap backend for TruffleRuby

1.1.8 (from changelog)

• (#885) Fix race condition in TVar for stale reads
• (#884) RubyThreadLocalVar: Do not iterate over hash which might conflict with new pair addition

1.1.7 (from changelog)

concurrent-ruby:

• (#879) Consider falsy value on Concurrent::Map#compute_if_absent for fast non-blocking path
• (#876) Reset Async queue on forking, makes Async fork-safe
• (#856) Avoid running problematic code in RubyThreadLocalVar on MRI that occasionally results in segfault
• (#853) Introduce ThreadPoolExecutor without a Queue

1.1.6 (from changelog)

concurrent-ruby:

• (#841) Concurrent.disable_at_exit_handlers! is no longer needed and was deprecated.
• (#841) AbstractExecutorService#auto_terminate= was deprecated and has no effect. Set :auto_terminate option instead when executor is initialized.

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by more commits than we can show here.

1.0.6

• Number values are now limited to a maximum of Float::MAX and a minimum of negative Float::MAX. (#11)

• Added project metadata to the gemspec. (#9 - @orien)

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by 4 commits:

• Release 1.0.6
• Limit number values to a sensible range
• Update history
• Add project metadata to the gemspec

1.12.0 (from changelog)

* Use erb/escape for faster html escaping if available (jeremyevans)

* Default :freeze_template_literals option to false if running with --enable-frozen-string-literal (casperisfine) (#35)

1.11.0 (from changelog)

* Support :freeze_template_literals option for configuring whether to add .freeze to template literal strings (casperisfine) (#33)

* Support :chain_appends option for chaining appends to the buffer variable (casperisfine, jeremyevans) (#32)

* Avoid unnecessary defined? usage on Ruby 3+ when using the :ensure option (jeremyevans)

1.10.0 (from changelog)

* Improve template parsing, mostly by reducing allocations (jeremyevans)

* Do not ship tests in the gem, reducing gem size about 20% (jeremyevans)

* Support :literal_prefix and :literal_postfix options for how to output literal tags (e.g. <%% code %>) (jaredcwhite) (#26, #27)

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by 49 commits:

• Bump version to 1.12.0
• Add nocov markings around use of erb/escape
• Add mailing_list_uri to the gem metadata
• Use erb/escape for faster html escaping if available
• Avoid unused variable verbose warning on JRuby in test
• Test JRuby 9.4 in CI
• Update memory footprint comparison
• Update CHANGELOG
• Disable freeze_template_literals if `--enable-frozen-string-literal`
• Bump version to 1.11.0
• Fix tests, update documentation and CHANGELOG
• Add `freeze_template_literals` option to avoid String#freeze
• Add chain_appends option to simplify VM instructions (Fixes #32)
• Add space after semicolon in generated output
• Avoid unnecessary defined? usage on Ruby 3+ when using the :ensure option
• Add a test for no tags with frozen source
• Tighten CI permissions
• Test Ruby 3.1 in CI
• Run specs in verbose mode on Ruby 3+
• Try Ruby 1.9.3, 2.0, and JRuby 9.3 on GitHub Actions
• Extract default regexp to Constant
• Stop using Travis
• Bump copyright year
• Start testing on truffleruby, and simplify ci.yml
• Test on ruby 3.0
• RANGE_ALL is not in use since 4dc81c210664bfa244c6015bb3aa034b29f5a66f
• Use GitHub Actions CI for supported Ruby versions
• Bump version to 1.10.0
• Enable branch coverage when testing
• Move <% case above <%# and <%% cases as it is more common
• Cover some rspace/lspace branches in CaptureEndEngine
• Test <%= tailch rspace branch and src ending with newline branch
• Remove unnecessary line
• Remove unnecessary branch
• Adjust nocov markings
• Don't call add_text with nil
• Fix regression where only first backslash/apostrophe was escaped
• Improve template parsing, mostly by reducing allocations
• Do not ship tests in the gem, reducing gem size about 20%
• Start testing Ruby 2.7 on Travis
• Update copyright year
• Add nocov markers
• Make spec_w task use warning gem instead of egrep for filtering
• Improve rdoc formatting
• Update CHANGELOG
• Allow the literal prefix/postfix to be configured (Fixes #26, #27)
• Refactor and simplify internals
• Reduce memory usage when escaping text
• Fix documentation of options bufval, bufvar in Erubi::Engine's initializer

🚨 ReDoS based DoS vulnerability in GlobalID

There is a ReDoS based DoS vulnerability in the GlobalID gem. This
vulnerability has been assigned the CVE identifier CVE-2023-22799.

Versions Affected: >= 0.2.1
Not affected: < 0.2.1
Fixed Versions: 1.0.1

Impact

There is a possible DoS vulnerability in the model name parsing section
of the GlobalID gem. Carefully crafted input can cause the regular
expression engine to take an unexpected amount of time. All users running
an affected release should either upgrade or use one of the workarounds
immediately.

Workarounds

There are no feasible workarounds for this issue.

1.2.0

What's Changed

• Drop support to Rails < 6.1 and Ruby <2.7 by @rafaelfranca in #153
• Don't show secrets for SignedGlobalID#inspect by @p8 in #160
• Allow for composite identifiers delimited by / by @nvasilevski in #163
• Add Eager Load Option by @rafacoello in #139

New Contributors

• @rafaelfranca made their first contribution in #153
• @p8 made their first contribution in #159
• @nvasilevski made their first contribution in #162
• @rafacoello made their first contribution in #139

Full Changelog: v1.1.0...v1.2.0

1.1.0

What's Changed

• URI::GID: Update #check_scheme, no need to call super by @alexcwatt in #146
• JSON-encode GlobalIDs as strings by @georgeclaghorn in #149
• Support pattern matching of GlobalID & GlobalID::URI by @ojab in #140
• prevent double find by @ooooooo-q in #148
• implement non signed global_id helper method on fixture set by @rainerborene in #144

New Contributors

• @daemonsy made their first contribution in #142
• @alexcwatt made their first contribution in #146
• @liijunwei made their first contribution in #150
• @ojab made their first contribution in #140
• @ooooooo-q made their first contribution in #148
• @rainerborene made their first contribution in #144

Full Changelog: v1.0.1...v1.1.0

1.0.1

Possible ReDoS based DoS vulnerability in GlobalID

There is a ReDoS based DoS vulnerability in the GlobalID gem. This
vulnerability has been assigned the CVE identifier CVE-2023-22799.

Versions Affected: >= 0.2.1
Not affected: NOTAFFECTED
Fixed Versions: 1.0.1

Impact

There is a possible DoS vulnerability in the model name parsing section of the
GlobalID gem. Carefully crafted input can cause the regular expression engine
to take an unexpected amount of time. All users running an affected release
should either upgrade or use one of the workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Credits

Thank you ooooooo_k for reporting this!

1.0.0

Stable API release.

The code is the same as the 0.6.0 release.

0.6.0

• Add ActiveRecord::FixtureSet.signed_global_id helper to generate signed ids inside fixtures.

0.5.2

• Add back Ruby 2.5 support so gem install rails works out of the box, thereby satisfying Rails' Ruby version requirement. See rails/rails#42931

0.5.1

• New: Allow expiration to be turned off globally #128
• Fixed: Support for ruby-head #132
• Maintainance: Drop support for EOL'ed Rubies (< 2.6.0) and Rails 4.2

0.4.2

• Allow configuration in initialisers 3c8f909

• Clear to_global_id memoization on dup #109

• Adds hash equality #108

Commits: v0.4.1...v0.4.2

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by more commits than we can show here.

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by more commits than we can show here.

🚨 Inefficient Regular Expression Complexity in Loofah

Summary

Loofah < 2.19.1 contains an inefficient regular expression that is susceptible to excessive backtracking when attempting to sanitize certain SVG attributes. This may lead to a denial of service through CPU resource consumption.

Mitigation

Upgrade to Loofah >= 2.19.1.

Severity

The Loofah maintainers have evaluated this as High Severity 7.5 (CVSS3.1).

References

• CWE - CWE-1333: Inefficient Regular Expression Complexity (4.9)
• https://hackerone.com/reports/1684163

Credit

This vulnerability was responsibly reported by @ooooooo-q (https://github.com/ooooooo-q).

🚨 Improper neutralization of data URIs may allow XSS in Loofah

Summary

Loofah >= 2.1.0, < 2.19.1 is vulnerable to cross-site scripting via the image/svg+xml media type in data URIs.

Mitigation

Upgrade to Loofah >= 2.19.1.

Severity

The Loofah maintainers have evaluated this as Medium Severity 6.1.

References

• CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)
• SVG MIME Type (image/svg+xml) is misleading to developers · Issue #266 · w3c/svgwg
• https://hackerone.com/reports/1694173
• #101

Credit

This vulnerability was responsibly reported by Maciej Piechota (@haqpl).

🚨 Uncontrolled Recursion in Loofah

Summary

Loofah >= 2.2.0, < 2.19.1 uses recursion for sanitizing CDATA sections, making it susceptible to stack exhaustion and raising a SystemStackError exception. This may lead to a denial of service through CPU resource consumption.

Mitigation

Upgrade to Loofah >= 2.19.1.

Users who are unable to upgrade may be able to mitigate this vulnerability by limiting the length of the strings that are sanitized.

Severity

The Loofah maintainers have evaluated this as High Severity 7.5 (CVSS3.1).

References

• CWE - CWE-674: Uncontrolled Recursion (4.9)

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by more commits than we can show here.

See the full diff on Github. The new version differs by more commits than we can show here.

See the full diff on Github. The new version differs by 17 commits:

• Merge pull request #64 from banister/release-1-0-0
• Release v1.0.0
• Merge pull request #63 from banister/travis-removal
• Test solely on CircleCI, remove Travis
• Merge pull request #62 from banister/circleci
• Test on CircleCI
• Merge pull request #61 from jasonkarns/patch-1
• More closely match MIT License text verbatim
• Merge pull request #59 from casperisfine/fix-ruby-2.7
• Test against Ruby 2.7 on CI
• Handle new message for unterminated lists on MRI 2.7
• Merge pull request #60 from casperisfine/fix-ci
• Fix ruby warning in spec_helper
• Add MRI 2.5 and 2.6
• Fix CI build
• Merge pull request #56 from nisusam/fix_documentation_link
• Fix `documentation` link

See the full diff on Github. The new version differs by 55 commits:

• Update mime types from upstream and bump
• Version bump
• Handle MIME::Types differences on Windows
• Shim IO#pread when not supported
• Version bump
• Make the library fork safe and drop the mutex
• DB updates 2023-03-01T10:03:17Z (#49)
• Adds Ruby 3.2 to the CI matrix. Requires Ruby >= 2.6. (#48)
• DEV: Require ruby >= 2.5 (#46)
• DEV: Update gem description to match repo desc (#47)
• DB updates 2022-01-06T11:58:07Z (#45)
• Update CI config (#42)
• Add Ruby 3.0 to CI (#40)
• version bump
• DB updates 2021-10-01T10:15:26Z
• version bump and changelog
• DB updates 2021-08-01T10:14:51Z
• DEV: Allow recent versions of gems in development
• version bump
• FEATURE: perform case insensitive lookups
• Update ci.yml (#35)
• Version bump and database update
• Rebuild DBs to fix specs
• Update mime-types-data before rebuilding DB
• Abort if steps fail in automated DB update
• Simplify gem caching for build job
• Automate DB updates with scheduled GH Action
• Update to the latest mime-types-data (#31)
• DEV: Switch from Travis to Actions (#29)
• List .lookup_by_extension in the README (#28)
• Changelog and prepare for release
• FEATURE: update for latest parity with mime types data
• Remove unsupported rubies from travis test matrix
• relax bundler version
• Update benchmark in readme
• Add gems to Gemfile for bench script
• Allow custom db paths
• Update benchmark
• Test on Ruby 2.5 and Ruby 2.6
• Merge pull request #16 from Aqualon/readme_improvements
• Fix some typos/whitespace
• Fix link to bench.rb
• bump cache on travis
• Merge branch 'master' of github.com:discourse/mini_mime
• bump version
• Merge pull request #14 from ahorek/replace_sub
• Update mime types from upstream
• Merge pull request #13 from ahorek/lookup_by_ext
• replace sub
• expose lookup by extension
• Fix typos.
• Merge pull request #11 from attritionorg/patch-1
• Update LICENSE.txt with an actual name
• Merge pull request #10 from esparta/adjusting_lookup_by_filename
• Adjusting lookup_by_filename on performance & style

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by more commits than we can show here.

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by more commits than we can show here.

2.7.0

What's Changed

• Fix changelog_uri in gemspec metadata by @MaximeD in #303
• Fix license by @voxik in #309
• Convert NIO objects to TypedData API by @casperisfine in #310

New Contributors

• @MaximeD made their first contribution in #303
• @voxik made their first contribution in #309
• @casperisfine made their first contribution in #310

Full Changelog: v2.6.1...v2.7.0

2.5.4 (from changelog)

• #251 Intermittent SEGV during GC. (@boazsegev)

2.5.3 (from changelog)

• #241 Possible bug with Ruby >= 2.7.0 and GC.compact. (@boazsegev)

2.5.2 (from changelog)

• #220 Update to libev-4.27 & fix assorted warnings. (@ioquatix)

• #225 Avoid need for linux headers. (@ioquatix)

2.4.0 (from changelog)

• #211 Enable KQUEUE on macOS 10.14+. (@ioquatix)

• Bump minimum supported Ruby to 2.3. (@ioquatix)

• Assorted fixes for TruffleRuby & JRuby. (@eregon, @olleolleolle)

• Update libev to v4.25. (@ioquatix)

• Bind to ephemeral (port 0) for more reliable specs. (@ioquatix)

• Improve handling of SSL sockets and related specs. (@MSP-Greg)

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by more commits than we can show here.

🚨 Improper Handling of Unexpected Data Type in Nokogiri

Summary

Nokogiri v1.16.2 upgrades the version of its dependency libxml2 to v2.12.5.

libxml2 v2.12.5 addresses the following vulnerability:

CVE-2024-25062 / https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-25062
described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/604
patched by https://gitlab.gnome.org/GNOME/libxml2/-/commit/92721970

Please note that this advisory only applies to the CRuby implementation of
Nokogiri < 1.16.2, and only if the packaged libraries are being used. If
you've overridden defaults at installation time to use system libraries
instead of packaged libraries, you should instead pay attention to your
distro's libxml2 release announcements.

Severity

The Nokogiri maintainers have evaluated this as Moderate.

Mitigation

Upgrade to Nokogiri >= 1.16.2.

Users who are unable to upgrade Nokogiri may also choose a more complicated
mitigation: compile and link Nokogiri against external libraries libxml2 >=
2.12.5 which will also address these same issues.

JRuby users are not affected.

Workarounds

🚨 Update packaged libxml2 to v2.10.4 to resolve multiple CVEs

Summary

Nokogiri v1.14.3 upgrades the packaged version of its dependency libxml2 to
v2.10.4 from v2.10.3.

libxml2 v2.10.4 addresses the following known vulnerabilities:

• CVE-2023-29469: Hashing of
  empty dict strings isn't deterministic
• CVE-2023-28484: Fix null deref
  in xmlSchemaFixupComplexType
• Schemas: Fix null-pointer-deref in xmlSchemaCheckCOSSTDerivedOK

Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.14.3,
and only if the packaged libraries are being used. If you've overridden defaults at installation
time to use system libraries instead of packaged libraries, you should instead pay attention to
your distro's libxml2 release announcements.

Mitigation

Upgrade to Nokogiri >= 1.14.3.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile
and link Nokogiri against external libraries libxml2 >= 2.10.4 which will also address these
same issues.

Impact

No public information has yet been published about the security-related issues other than the
upstream commits. Examination of those changesets indicate that the more serious issues relate to
libxml2 dereferencing NULL pointers and potentially segfaulting while parsing untrusted inputs.

The commits can be examined at:

• [CVE-2023-29469] Hashing of empty dict strings isn't deterministic (09a2dd45)
• [CVE-2023-28484] Fix null deref in xmlSchemaFixupComplexType (647e072e)
• schemas: Fix null-pointer-deref in xmlSchemaCheckCOSSTDerivedOK (4c6922f7)

🚨 Unchecked return value from xmlTextReaderExpand

Summary

Nokogiri 1.13.8, 1.13.9 fails to check the return value from xmlTextReaderExpand in the method Nokogiri::XML::Reader#attribute_hash. This can lead to a null pointer exception when invalid markup is being parsed.

For applications using XML::Reader to parse untrusted inputs, this may potentially be a vector for a denial of service attack.

Mitigation

Upgrade to Nokogiri >= 1.13.10.

Users may be able to search their code for calls to either XML::Reader#attributes or XML::Reader#attribute_hash to determine if they are affected.

Severity

The Nokogiri maintainers have evaluated this as High Severity 7.5 (CVSS3.1).

References

• CWE - CWE-252: Unchecked Return Value (4.9)
• CWE - CWE-476: NULL Pointer Dereference (4.9)

Credit

This vulnerability was responsibly reported by @davidwilemski.

🚨 Nokogiri Implements libxml2 version vulnerable to use-after-free

There's a flaw in libxml2 in versions before 2.9.11. An attacker
who is able to submit a crafted file to be processed by an application
linked with libxml2 could trigger a use-after-free. The greatest
impact from this flaw is to confidentiality, integrity, and availability.

🚨 Nokogiri Implements libxml2 version vulnerable to null pointer dereferencing

A vulnerability found in libxml2 in versions before 2.9.11 shows
that it did not propagate errors while parsing XML mixed content,
causing a NULL dereference. If an untrusted XML document was parsed
in recovery mode and post-validated, the flaw could be used to crash
the application. The highest threat from this vulnerability
is to system availability.

🚨 Nokogiri contains libxml Out-of-bounds Write vulnerability

There is a flaw in the xml entity encoding functionality of libxml2 in versions before 2.9.11. An attacker who is able to supply a crafted file to be processed by an application linked with the affected functionality of libxml2 could trigger an out-of-bounds read. The most likely impact of this flaw is to application availability, with some potential impact to confidentiality and integrity if an attacker is able to use memory information to further exploit the application.

Nokogiri prior to version 1.11.4 used a vulnerable version of libxml2. Nokogiri 1.11.4 updated libxml2 to version 2.9.11 to address this and other vulnerabilities in libxml2.

🚨 Improper Handling of Unexpected Data Type in Nokogiri

Summary

Nokogiri < v1.13.6 does not type-check all inputs into the XML and HTML4 SAX parsers.
For CRuby users, this may allow specially crafted untrusted inputs to cause illegal
memory access errors (segfault) or reads from unrelated memory.

Severity

The Nokogiri maintainers have evaluated this as High 8.2 (CVSS3.1).

Mitigation

CRuby users should upgrade to Nokogiri >= 1.13.6.

JRuby users are not affected.

Workarounds

To avoid this vulnerability in affected applications, ensure the untrusted input is a
String by calling #to_s or equivalent.

🚨 Integer Overflow or Wraparound in libxml2 affects Nokogiri

Summary

Nokogiri v1.13.5 upgrades the packaged version of its dependency libxml2 from
v2.9.13 to v2.9.14.

libxml2 v2.9.14 addresses CVE-2022-29824.
This version also includes several security-related bug fixes for which CVEs were not created,
including a potential double-free, potential memory leaks, and integer-overflow.

Please note that this advisory only applies to the CRuby implementation of Nokogiri
< 1.13.5, and only if the packaged libraries are being used. If you've overridden
defaults at installation time to use system libraries instead of packaged libraries,
you should instead pay attention to your distro's libxml2 and libxslt release announcements.

Mitigation

Upgrade to Nokogiri >= 1.13.5.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation:
compile and link Nokogiri against external libraries libxml2 >= 2.9.14 which will also
address these same issues.

Impact

libxml2 CVE-2022-29824

• CVSS3 score:
  • Unspecified upstream
  • Nokogiri maintainers evaluate at 8.6 (High) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H). Note that this is different from the CVSS assessed by NVD.
• Type: Denial of service, information disclosure
• Description: In libxml2 before 2.9.14, several buffer handling functions in buf.c (xmlBuf*) and tree.c (xmlBuffer*) don't check for integer overflows. This can result in out-of-bounds memory writes. Exploitation requires a victim to open a crafted, multi-gigabyte XML file. Other software using libxml2's buffer functions, for example libxslt through 1.1.35, is affected as well.
• Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/2554a24

All versions of libml2 prior to v2.9.14 are affected.

Applications parsing or serializing multi-gigabyte documents (in excess of INT_MAX bytes) may be vulnerable to an integer overflow bug in buffer handling that could lead to exposure of confidential data, modification of unrelated data, or a segmentation fault resulting in a denial-of-service.

References

• libxml2 v2.9.14 release notes
• CVE-2022-29824
• CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

🚨 XML Injection in Xerces Java affects Nokogiri

Summary

Nokogiri v1.13.4 updates the vendored xerces:xercesImpl from 2.12.0 to
2.12.2, which addresses CVE-2022-23437.
That CVE is scored as CVSS 6.5 "Medium" on the NVD record.

Please note that this advisory only applies to the JRuby implementation
of Nokogiri < 1.13.4.

Mitigation

Upgrade to Nokogiri >= v1.13.4.

Impact

CVE-2022-23437 in xerces-J

• Severity: Medium
• Type: CWE-91 XML Injection (aka Blind XPath Injection)
• Description: There's a vulnerability within the Apache Xerces Java
  (XercesJ) XML parser when handling specially crafted XML document payloads.
  This causes, the XercesJ XML parser to wait in an infinite loop, which may
  sometimes consume system resources for prolonged duration. This vulnerability
  is present within XercesJ version 2.12.1 and the previous versions.
• See also: GHSA-h65f-jvqw-m9fj

🚨 Inefficient Regular Expression Complexity in Nokogiri

Summary

Nokogiri < v1.13.4 contains an inefficient regular expression that is
susceptible to excessive backtracking when attempting to detect encoding
in HTML documents.

Mitigation

Upgrade to Nokogiri >= 1.13.4.

🚨 Denial of Service (DoS) in Nokogiri on JRuby

Summary

Nokogiri v1.13.4 updates the vendored org.cyberneko.html library to
1.9.22.noko2 which addresses CVE-2022-24839.
That CVE is rated 7.5 (High Severity).

See GHSA-9849-p7jc-9rmv
for more information.

Please note that this advisory only applies to the JRuby implementation of Nokogiri < 1.13.4.

Mitigation

Upgrade to Nokogiri >= 1.13.4.

Impact

CVE-2022-24839 in nekohtml

• Severity: High 7.5
• Type: CWE-400 Uncontrolled Resource Consumption
• Description: The fork of org.cyberneko.html used by Nokogiri (Rubygem) raises a
  java.lang.OutOfMemoryError exception when parsing ill-formed HTML markup.
• See also: GHSA-9849-p7jc-9rmv

🚨 Out-of-bounds Write in zlib affects Nokogiri

Summary

Nokogiri v1.13.4 updates the vendored zlib from 1.2.11
to 1.2.12, which addresses CVE-2018-25032.
That CVE is scored as CVSS 7.4 "High" on the NVD record as of 2022-04-05.

Please note that this advisory only applies to the CRuby implementation of
Nokogiri < 1.13.4, and only if the packaged version of zlib is being used.
Please see this document
for a complete description of which platform gems vendor zlib. If you've
overridden defaults at installation time to use system libraries instead of
packaged libraries, you should instead pay attention to your distro's zlib
release announcements.

Mitigation

Upgrade to Nokogiri >= v1.13.4.

Impact

CVE-2018-25032 in zlib

• Severity: High
• Type: CWE-787
  Out of bounds write
• Description: zlib before 1.2.12 allows memory corruption when
  deflating (i.e., when compressing) if the input has many distant matches.

🚨 Update packaged libxml2 (2.9.12 → 2.9.13) and libxslt (1.1.34 → 1.1.35)

Summary

Nokogiri v1.13.2 upgrades two of its packaged dependencies:

• vendored libxml2 from v2.9.12 to v2.9.13
• vendored libxslt from v1.1.34 to v1.1.35

Those library versions address the following upstream CVEs:

• libxslt: CVE-2021-30560 (CVSS 8.8, High severity)
• libxml2: CVE-2022-23308 (Unspecified severity, see more information below)

Those library versions also address numerous other issues including performance
improvements, regression fixes, and bug fixes, as well as memory leaks and other
use-after-free issues that were not assigned CVEs.

Please note that this advisory only applies to the CRuby implementation of
Nokogiri < 1.13.2, and only if the packaged libraries are being used. If you've
overridden defaults at installation time to use system libraries instead of
packaged libraries, you should instead pay attention to your distro's libxml2
and libxslt release announcements.

Mitigation

Upgrade to Nokogiri >= 1.13.2.

Users who are unable to upgrade Nokogiri may also choose a more complicated
mitigation: compile and link an older version Nokogiri against external libraries
libxml2 >= 2.9.13 and libxslt >= 1.1.35, which will also address these same CVEs.

Impact

• libxslt CVE-2021-30560
• CVSS3 score: 8.8 (High)

Fixed by https://gitlab.gnome.org/GNOME/libxslt/-/commit/50f9c9c

All versions of libxslt prior to v1.1.35 are affected.

Applications using untrusted XSL stylesheets to transform XML are vulnerable to
a denial-of-service attack and should be upgraded immediately.

libxml2 CVE-2022-23308

• As of the time this security advisory was published, there is no officially
  published information available about this CVE's severity. The above NIST link
  does not yet have a published record, and the libxml2 maintainer has declined
  to provide a severity score.
• Fixed by https://gitlab.gnome.org/GNOME/libxml2/-/commit/652dd12
• Further explanation is at https://mail.gnome.org/archives/xml/2022-February/msg00015.html

The upstream commit and the explanation linked above indicate that an application
may be vulnerable to a denial of service, memory disclosure, or code execution if
it parses an untrusted document with parse options DTDVALID set to true, and NOENT
set to false.

An analysis of these parse options:

• While NOENT is off by default for Document, DocumentFragment, Reader, and
  Schema parsing, it is on by default for XSLT (stylesheet) parsing in Nokogiri
  v1.12.0 and later.
• DTDVALID is an option that Nokogiri does not set for any operations, and so
  this CVE applies only to applications setting this option explicitly.

It seems reasonable to assume that any application explicitly setting the parse
option DTDVALID when parsing untrusted documents is vulnerable and should be
upgraded immediately.

🚨 Improper Restriction of XML External Entity Reference (XXE) in Nokogiri on JRuby

Severity

The Nokogiri maintainers have evaluated this as High Severity 7.5 (CVSS3.0) for JRuby users. (This security advisory does not apply to CRuby users.)

Impact

In Nokogiri v1.12.4 and earlier, on JRuby only, the SAX parser resolves external entities by default.

Users of Nokogiri on JRuby who parse untrusted documents using any of these classes are affected:

• Nokogiri::XML::SAX::Parser
• Nokogiri::HTML4::SAX::Parser or its alias Nokogiri::HTML::SAX::Parser
• Nokogiri::XML::SAX::PushParser
• Nokogiri::HTML4::SAX::PushParser or its alias Nokogiri::HTML::SAX::PushParser

Mitigation

JRuby users should upgrade to Nokogiri v1.12.5 or later. There are no workarounds available for v1.12.4 or earlier.

CRuby users are not affected.

🚨 Update packaged dependency libxml2 from 2.9.10 to 2.9.12

Summary

Nokogiri v1.11.4 updates the vendored libxml2 from v2.9.10 to v2.9.12 which addresses:

• CVE-2019-20388 (Medium severity)
• CVE-2020-24977 (Medium severity)
• CVE-2021-3517 (Medium severity)
• CVE-2021-3518 (Medium severity)
• CVE-2021-3537 (Low severity)
• CVE-2021-3541 (Low severity)

Note that two additional CVEs were addressed upstream but are not relevant to this release. CVE-2021-3516 via xmllint is not present in Nokogiri, and CVE-2020-7595 has been patched in Nokogiri since v1.10.8 (see #1992).

Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.11.4, and only if the packaged version of libxml2 is being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 release announcements.

Mitigation

Upgrade to Nokogiri >= 1.11.4.

Impact

I've done a brief analysis of the published CVEs that are addressed in this upstream release. The libxml2 maintainers have not released a canonical set of CVEs, and so this list is pieced together from secondary sources and may be incomplete.

All information below is sourced from security.archlinux.org, which appears to have the most up-to-date information as of this analysis.

CVE-2019-20388

• Severity: Medium
• Type: Denial of service
• Description: A memory leak was found in the xmlSchemaValidateStream function of libxml2. Applications that use this library may be vulnerable to memory not being freed leading to a denial of service.
• Fixed: https://gitlab.gnome.org/GNOME/libxml2/commit/7ffcd44d7e6c46704f8af0321d9314cd26e0e18a

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4.

CVE-2020-7595

• Severity: Medium
• Type: Denial of service
• Description: xmlStringLenDecodeEntities in parser.c in libxml2 2.9.10 has an infinite loop in a certain end-of-file situation.
• Fixed: https://gitlab.gnome.org/GNOME/libxml2/commit/0e1a49c8907645d2e155f0d89d4d9895ac5112b5

This has been patched in Nokogiri since v1.10.8 (see #1992).

CVE-2020-24977

• Severity: Medium
• Type: Information disclosure
• Description: GNOME project libxml2 <= 2.9.10 has a global buffer over-read vulnerability in xmlEncodeEntitiesInternal at libxml2/entities.c.
• Fixed: https://gitlab.gnome.org/GNOME/libxml2/commit/50f06b3efb638efb0abd95dc62dca05ae67882c2

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4.

CVE-2021-3516

• Severity: Medium
• Type: Arbitrary code execution (no remote vector)
• Description: A use-after-free security issue was found libxml2 before version 2.9.11 when "xmllint --html --push" is used to process crafted files.
• Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/230
• Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/1358d157d0bd83be1dfe356a69213df9fac0b539

Verified that the fix commit first appears in v2.9.11. This vector does not exist within Nokogiri, which does not ship xmllint.

CVE-2021-3517

• Severity: Medium
• Type: Arbitrary code execution
• Description: A heap-based buffer overflow was found in libxml2 before version 2.9.11 when processing truncated UTF-8 input.
• Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/235
• Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/bf22713507fe1fc3a2c4b525cf0a88c2dc87a3a2

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4.

CVE-2021-3518

• Severity: Medium
• Type: Arbitrary code execution
• Description: A use-after-free security issue was found in libxml2 before version 2.9.11 in xmlXIncludeDoProcess() in xinclude.c when processing crafted files.
• Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/237
• Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/1098c30a040e72a4654968547f415be4e4c40fe7

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4.

CVE-2021-3537

• Severity: Low
• Type: Denial of service
• Description: It was found that libxml2 before version 2.9.11 did not propagate errors while parsing XML mixed content, causing a NULL dereference. If an untrusted XML document was parsed in recovery mode and post-validated, the flaw could be used to crash the application.
• Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/243
• Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/babe75030c7f64a37826bb3342317134568bef61

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4.

CVE-2021-3541

• Severity: Low
• Type: Denial of service
• Description: A security issue was found in libxml2 before version 2.9.11. Exponential entity expansion attack its possible bypassing all existing protection mechanisms and leading to denial of service.
• Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/8598060bacada41a0eb09d95c97744ff4e428f8e

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4, however Nokogiri's default parse options prevent the attack from succeeding (it is necessary to opt into DTDLOAD which is off by default).

For more details supporting this analysis of this CVE, please visit #2233.

🚨 Nokogiri::XML::Schema trusts input by default, exposing risk of an XXE vulnerability

Description

In Nokogiri versions <= 1.11.0.rc3, XML Schemas parsed by Nokogiri::XML::Schema
are trusted by default, allowing external resources to be accessed over the
network, potentially enabling XXE or SSRF attacks.

This behavior is counter to
the security policy followed by Nokogiri maintainers, which is to treat all input
as untrusted by default whenever possible.

Please note that this security
fix was pushed into a new minor version, 1.11.x, rather than a patch release to
the 1.10.x branch, because it is a breaking change for some schemas and the risk
was assessed to be "Low Severity".

Affected Versions

Nokogiri <= 1.10.10 as well as prereleases 1.11.0.rc1, 1.11.0.rc2, and 1.11.0.rc3

Mitigation

There are no known workarounds for affected versions. Upgrade to Nokogiri
1.11.0.rc4 or later.

If, after upgrading to 1.11.0.rc4 or later, you wish
to re-enable network access for resolution of external resources (i.e., return to
the previous behavior):

1. Ensure the input is trusted. Do not enable this option
   for untrusted input.
2. When invoking the Nokogiri::XML::Schema constructor,
   pass as the second parameter an instance of Nokogiri::XML::ParseOptions with the
   NONET flag turned off.

So if your previous code was:

# in v1.11.0.rc3 and earlier, this call allows resources to be accessed over the network
# but in v1.11.0.rc4 and later, this call will disallow network access for external resources
schema = Nokogiri::XML::Schema.new(schema)

# in v1.11.0.rc4 and later, the following is equivalent to the code above
# (the second parameter is optional, and this demonstrates its default value)
schema = Nokogiri::XML::Schema.new(schema, Nokogiri::XML::ParseOptions::DEFAULT_SCHEMA)

Then you can add the second parameter to indicate that the input is trusted by changing it to:

# in v1.11.0.rc3 and earlier, this would raise an ArgumentError
# but in v1.11.0.rc4 and later, this allows resources to be accessed over the network
schema = Nokogiri::XML::Schema.new(trusted_schema, Nokogiri::XML::ParseOptions.new.nononet)

🚨 xmlStringLenDecodeEntities in parser.c in libxml2 2.9.10 has an infinite loop in a certain end-of-file situation.

Pulled in upstream patch from libxml that addresses CVE-2020-7595. Full details are available in #1992. Note that this patch is not yet (as of 2020-02-10) in an upstream release of libxml.

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by more commits than we can show here.

🚨 Denial of Service Vulnerability in Rack Content-Type Parsing

There is a possible denial of service vulnerability in the content type
parsing component of Rack. This vulnerability has been assigned the CVE
identifier CVE-2024-25126.

Versions Affected: >= 0.4 Not affected: < 0.4 Fixed Versions: 3.0.9.1, 2.2.8.1

Impact

Carefully crafted content type headers can cause Rack’s media type parser to
take much longer than expected, leading to a possible denial of service
vulnerability.

Impacted code will use Rack’s media type parser to parse content type headers.
This code will look like below:

request.media_type

## OR
request.media_type_params

## OR
Rack::MediaType.type(content_type)

Some frameworks (including Rails) call this code internally, so upgrading is
recommended!

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

🚨 Possible DoS Vulnerability with Range Header in Rack

There is a possible DoS vulnerability relating to the Range request header in
Rack. This vulnerability has been assigned the CVE identifier CVE-2024-26141.

Versions Affected: >= 1.3.0. Not affected: < 1.3.0 Fixed Versions: 3.0.9.1, 2.2.8.1

Impact

Carefully crafted Range headers can cause a server to respond with an
unexpectedly large response. Responding with such large responses could lead
to a denial of service issue.

Vulnerable applications will use the Rack::File middleware or the
Rack::Utils.byte_ranges methods (this includes Rails applications).

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

🚨 Possible Denial of Service Vulnerability in Rack Header Parsing

There is a possible denial of service vulnerability in the header parsing
routines in Rack. This vulnerability has been assigned the CVE identifier
CVE-2024-26146.

Versions Affected: All. Not affected: None Fixed Versions: 2.0.9.4, 2.1.4.4, 2.2.8.1, 3.0.9.1

Impact

Carefully crafted headers can cause header parsing in Rack to take longer than
expected resulting in a possible denial of service issue. Accept and
Forwarded headers are impacted.

Ruby 3.2 has mitigations for this problem, so Rack applications using
Ruby 3.2 or newer are unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

🚨 Possible Denial of Service Vulnerability in Rack Header Parsing

There is a possible denial of service vulnerability in the header parsing
routines in Rack. This vulnerability has been assigned the CVE identifier
CVE-2024-26146.

Versions Affected: All. Not affected: None Fixed Versions: 2.0.9.4, 2.1.4.4, 2.2.8.1, 3.0.9.1

Impact

Carefully crafted headers can cause header parsing in Rack to take longer than
expected resulting in a possible denial of service issue. Accept and
Forwarded headers are impacted.

Ruby 3.2 has mitigations for this problem, so Rack applications using
Ruby 3.2 or newer are unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

🚨 Possible Denial of Service Vulnerability in Rack Header Parsing

There is a possible denial of service vulnerability in the header parsing
routines in Rack. This vulnerability has been assigned the CVE identifier
CVE-2024-26146.

Versions Affected: All. Not affected: None Fixed Versions: 2.0.9.4, 2.1.4.4, 2.2.8.1, 3.0.9.1

Impact

Carefully crafted headers can cause header parsing in Rack to take longer than
expected resulting in a possible denial of service issue. Accept and
Forwarded headers are impacted.

Ruby 3.2 has mitigations for this problem, so Rack applications using
Ruby 3.2 or newer are unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

🚨 Possible Denial of Service Vulnerability in Rack’s header parsing

There is a denial of service vulnerability in the header parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27539.

Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.2.6.4, 3.0.6.1

Impact

Carefully crafted input can cause header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse headers using Rack (virtually all Rails applications) are impacted.

Workarounds

Setting Regexp.timeout in Ruby 3.2 is a possible workaround.

🚨 Possible DoS Vulnerability in Multipart MIME parsing

There is a possible DoS vulnerability in the Multipart MIME parsing code in Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27530.

Versions Affected: All. Not affected: None Fixed Versions: 3.0.4.2, 2.2.6.3, 2.1.4.3, 2.0.9.3

Impact

The Multipart MIME parsing code in Rack limits the number of file parts, but does not limit the total number of parts that can be uploaded. Carefully crafted requests can abuse this and cause multipart parsing to take longer than expected.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Workarounds

A proxy can be configured to limit the POST body size which will mitigate this issue.

🚨 Possible DoS Vulnerability in Multipart MIME parsing

There is a possible DoS vulnerability in the Multipart MIME parsing code in Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27530.

Versions Affected: All. Not affected: None Fixed Versions: 3.0.4.2, 2.2.6.3, 2.1.4.3, 2.0.9.3

Impact

The Multipart MIME parsing code in Rack limits the number of file parts, but does not limit the total number of parts that can be uploaded. Carefully crafted requests can abuse this and cause multipart parsing to take longer than expected.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Workarounds

A proxy can be configured to limit the POST body size which will mitigate this issue.

🚨 Possible DoS Vulnerability in Multipart MIME parsing

There is a possible DoS vulnerability in the Multipart MIME parsing code in Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27530.

Versions Affected: All. Not affected: None Fixed Versions: 3.0.4.2, 2.2.6.3, 2.1.4.3, 2.0.9.3

Impact

The Multipart MIME parsing code in Rack limits the number of file parts, but does not limit the total number of parts that can be uploaded. Carefully crafted requests can abuse this and cause multipart parsing to take longer than expected.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Workarounds

A proxy can be configured to limit the POST body size which will mitigate this issue.

🚨 Denial of service via header parsing in Rack

There is a possible denial of service vulnerability in the Range header
parsing component of Rack. This vulnerability has been assigned the CVE
identifier CVE-2022-44570.

Versions Affected: >= 1.5.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.2, 3.0.4.1

Impact

Carefully crafted input can cause the Range header parsing component in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. Any applications that deal with Range requests (such
as streaming applications, or applications that serve files) may be impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of service via header parsing in Rack

There is a possible denial of service vulnerability in the Range header
parsing component of Rack. This vulnerability has been assigned the CVE
identifier CVE-2022-44570.

Versions Affected: >= 1.5.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.2, 3.0.4.1

Impact

Carefully crafted input can cause the Range header parsing component in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. Any applications that deal with Range requests (such
as streaming applications, or applications that serve files) may be impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of Service Vulnerability in Rack Content-Disposition parsing

There is a denial of service vulnerability in the Content-Disposition parsing
component of Rack. This vulnerability has been assigned the CVE identifier
CVE-2022-44571.

Versions Affected: >= 2.0.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1

Impact

Carefully crafted input can cause Content-Disposition header parsing in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. This header is used typically used in multipart
parsing. Any applications that parse multipart posts using Rack (virtually
all Rails applications) are impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of service via multipart parsing in Rack

There is a denial of service vulnerability in the multipart parsing component
of Rack. This vulnerability has been assigned the CVE identifier
CVE-2022-44572.

Versions Affected: >= 2.0.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1

Impact

Carefully crafted input can cause RFC2183 multipart boundary parsing in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. Any applications that parse multipart posts using
Rack (virtually all Rails applications) are impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of Service Vulnerability in Rack Content-Disposition parsing

There is a denial of service vulnerability in the Content-Disposition parsing
component of Rack. This vulnerability has been assigned the CVE identifier
CVE-2022-44571.

Versions Affected: >= 2.0.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1

Impact

Carefully crafted input can cause Content-Disposition header parsing in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. This header is used typically used in multipart
parsing. Any applications that parse multipart posts using Rack (virtually
all Rails applications) are impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of service via multipart parsing in Rack

There is a denial of service vulnerability in the multipart parsing component
of Rack. This vulnerability has been assigned the CVE identifier
CVE-2022-44572.

Versions Affected: >= 2.0.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1

Impact

Carefully crafted input can cause RFC2183 multipart boundary parsing in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. Any applications that parse multipart posts using
Rack (virtually all Rails applications) are impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of Service Vulnerability in Rack Content-Disposition parsing

There is a denial of service vulnerability in the Content-Disposition parsing
component of Rack. This vulnerability has been assigned the CVE identifier
CVE-2022-44571.

Versions Affected: >= 2.0.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1

Impact

Carefully crafted input can cause Content-Disposition header parsing in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. This header is used typically used in multipart
parsing. Any applications that parse multipart posts using Rack (virtually
all Rails applications) are impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of service via multipart parsing in Rack

There is a denial of service vulnerability in the multipart parsing component
of Rack. This vulnerability has been assigned the CVE identifier
CVE-2022-44572.

Versions Affected: >= 2.0.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1

Impact

Carefully crafted input can cause RFC2183 multipart boundary parsing in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. Any applications that parse multipart posts using
Rack (virtually all Rails applications) are impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of service via header parsing in Rack

There is a possible denial of service vulnerability in the Range header
parsing component of Rack. This vulnerability has been assigned the CVE
identifier CVE-2022-44570.

Versions Affected: >= 1.5.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.2, 3.0.4.1

Impact

Carefully crafted input can cause the Range header parsing component in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. Any applications that deal with Range requests (such
as streaming applications, or applications that serve files) may be impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Possible shell escape sequence injection vulnerability in Rack

There is a possible shell escape sequence injection vulnerability in the Lint
and CommonLogger components of Rack. This vulnerability has been assigned the
CVE identifier CVE-2022-30123.

Versions Affected: All.
Not affected: None
Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1

Impact

Carefully crafted requests can cause shell escape sequences to be written to
the terminal via Rack's Lint middleware and CommonLogger middleware. These
escape sequences can be leveraged to possibly execute commands in the victim's
terminal.

Impacted applications will have either of these middleware installed, and
vulnerable apps may have something like this:

use Rack::Lint

Or

use Rack::CommonLogger

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

Remove these middleware from your application

🚨 Denial of Service Vulnerability in Rack Multipart Parsing

There is a possible denial of service vulnerability in the multipart parsing
component of Rack. This vulnerability has been assigned the CVE identifier
CVE-2022-30122.

Versions Affected: >= 1.2
Not affected: < 1.2
Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1

Impact

Carefully crafted multipart POST requests can cause Rack's multipart parser to
take much longer than expected, leading to a possible denial of service
vulnerability.

Impacted code will use Rack's multipart parser to parse multipart posts. This
includes directly using the multipart parser like this:

params = Rack::Multipart.parse_multipart(env)

But it also includes reading POST data from a Rack request object like this:

p request.POST # read POST data
p request.params # reads both query params and POST data

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of Service Vulnerability in Rack Multipart Parsing

There is a possible denial of service vulnerability in the multipart parsing
component of Rack. This vulnerability has been assigned the CVE identifier
CVE-2022-30122.

Versions Affected: >= 1.2
Not affected: < 1.2
Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1

Impact

Carefully crafted multipart POST requests can cause Rack's multipart parser to
take much longer than expected, leading to a possible denial of service
vulnerability.

Impacted code will use Rack's multipart parser to parse multipart posts. This
includes directly using the multipart parser like this:

params = Rack::Multipart.parse_multipart(env)

But it also includes reading POST data from a Rack request object like this:

p request.POST # read POST data
p request.params # reads both query params and POST data

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

There are no feasible workarounds for this issue.

🚨 Possible shell escape sequence injection vulnerability in Rack

There is a possible shell escape sequence injection vulnerability in the Lint
and CommonLogger components of Rack. This vulnerability has been assigned the
CVE identifier CVE-2022-30123.

Versions Affected: All.
Not affected: None
Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1

Impact

Carefully crafted requests can cause shell escape sequences to be written to
the terminal via Rack's Lint middleware and CommonLogger middleware. These
escape sequences can be leveraged to possibly execute commands in the victim's
terminal.

Impacted applications will have either of these middleware installed, and
vulnerable apps may have something like this:

use Rack::Lint

Or

use Rack::CommonLogger

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

Remove these middleware from your application

🚨 Possible shell escape sequence injection vulnerability in Rack

There is a possible shell escape sequence injection vulnerability in the Lint
and CommonLogger components of Rack. This vulnerability has been assigned the
CVE identifier CVE-2022-30123.

Versions Affected: All.
Not affected: None
Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1

Impact

Carefully crafted requests can cause shell escape sequences to be written to
the terminal via Rack's Lint middleware and CommonLogger middleware. These
escape sequences can be leveraged to possibly execute commands in the victim's
terminal.

Impacted applications will have either of these middleware installed, and
vulnerable apps may have something like this:

use Rack::Lint

Or

use Rack::CommonLogger

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

Remove these middleware from your application

🚨 Denial of Service Vulnerability in Rack Multipart Parsing

There is a possible denial of service vulnerability in the multipart parsing
component of Rack. This vulnerability has been assigned the CVE identifier
CVE-2022-30122.

Versions Affected: >= 1.2
Not affected: < 1.2
Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1

Impact

Carefully crafted multipart POST requests can cause Rack's multipart parser to
take much longer than expected, leading to a possible denial of service
vulnerability.

Impacted code will use Rack's multipart parser to parse multipart posts. This
includes directly using the multipart parser like this:

params = Rack::Multipart.parse_multipart(env)

But it also includes reading POST data from a Rack request object like this:

p request.POST # read POST data
p request.params # reads both query params and POST data

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

There are no feasible workarounds for this issue.

🚨 Percent-encoded cookies can be used to overwrite existing prefixed cookie names

It is possible to forge a secure or host-only cookie prefix in Rack using
an arbitrary cookie write by using URL encoding (percent-encoding) on the
name of the cookie. This could result in an application that is dependent on
this prefix to determine if a cookie is safe to process being manipulated
into processing an insecure or cross-origin request.
This vulnerability has been assigned the CVE identifier CVE-2020-8184.

Versions Affected: rack < 2.2.3, rack < 2.1.4
Not affected: Applications which do not rely on __Host- and __Secure- prefixes to determine if a cookie is safe to process
Fixed Versions: rack >= 2.2.3, rack >= 2.1.4

Impact

An attacker may be able to trick a vulnerable application into processing an
insecure (non-SSL) or cross-origin request if they can gain the ability to write
arbitrary cookies that are sent to the application.

Workarounds

If your application is impacted but you cannot upgrade to the released versions or apply
the provided patch, this issue can be temporarily addressed by adding the following workaround:

module Rack
  module Utils
    module_function def parse_cookies_header(header)
      return {} unless header
      header.split(/[;] */n).each_with_object({}) do |cookie, cookies|
        next if cookie.empty?
        key, value = cookie.split('=', 2)
        cookies[key] = (unescape(value) rescue value) unless cookies.key?(key)
      end
    end
  end
end

🚨 Percent-encoded cookies can be used to overwrite existing prefixed cookie names

It is possible to forge a secure or host-only cookie prefix in Rack using
an arbitrary cookie write by using URL encoding (percent-encoding) on the
name of the cookie. This could result in an application that is dependent on
this prefix to determine if a cookie is safe to process being manipulated
into processing an insecure or cross-origin request.
This vulnerability has been assigned the CVE identifier CVE-2020-8184.

Versions Affected: rack < 2.2.3, rack < 2.1.4
Not affected: Applications which do not rely on __Host- and __Secure- prefixes to determine if a cookie is safe to process
Fixed Versions: rack >= 2.2.3, rack >= 2.1.4

Impact

An attacker may be able to trick a vulnerable application into processing an
insecure (non-SSL) or cross-origin request if they can gain the ability to write
arbitrary cookies that are sent to the application.

Workarounds

If your application is impacted but you cannot upgrade to the released versions or apply
the provided patch, this issue can be temporarily addressed by adding the following workaround:

module Rack
  module Utils
    module_function def parse_cookies_header(header)
      return {} unless header
      header.split(/[;] */n).each_with_object({}) do |cookie, cookies|
        next if cookie.empty?
        key, value = cookie.split('=', 2)
        cookies[key] = (unescape(value) rescue value) unless cookies.key?(key)
      end
    end
  end
end

🚨 Directory traversal in Rack::Directory app bundled with Rack

There was a possible directory traversal vulnerability in the Rack::Directory app
that is bundled with Rack.

Versions Affected: rack < 2.2.0
Not affected: Applications that do not use Rack::Directory.
Fixed Versions: 2.1.3, >= 2.2.0

Impact

If certain directories exist in a director that is managed by
Rack::Directory, an attacker could, using this vulnerability, read the
contents of files on the server that were outside of the root specified in the
Rack::Directory initializer.

Workarounds

Until such time as the patch is applied or their Rack version is upgraded,
we recommend that developers do not use Rack::Directory in their
applications.

🚨 Directory traversal in Rack::Directory app bundled with Rack

There was a possible directory traversal vulnerability in the Rack::Directory app
that is bundled with Rack.

Versions Affected: rack < 2.2.0
Not affected: Applications that do not use Rack::Directory.
Fixed Versions: 2.1.3, >= 2.2.0

Impact

If certain directories exist in a director that is managed by
Rack::Directory, an attacker could, using this vulnerability, read the
contents of files on the server that were outside of the root specified in the
Rack::Directory initializer.

Workarounds

Until such time as the patch is applied or their Rack version is upgraded,
we recommend that developers do not use Rack::Directory in their
applications.

🚨 Possible information leak / session hijack vulnerability

There's a possible information leak / session hijack vulnerability in Rack.

Attackers may be able to find and hijack sessions by using timing attacks
targeting the session id. Session ids are usually stored and indexed in a
database that uses some kind of scheme for speeding up lookups of that
session id. By carefully measuring the amount of time it takes to look up
a session, an attacker may be able to find a valid session id and hijack
the session.

The session id itself may be generated randomly, but the way the session is
indexed by the backing store does not use a secure comparison.

Impact:

The session id stored in a cookie is the same id that is used when querying
the backing session storage engine. Most storage mechanisms (for example a
database) use some sort of indexing in order to speed up the lookup of that
id. By carefully timing requests and session lookup failures, an attacker
may be able to perform a timing attack to determine an existing session id
and hijack that session.

2.2.8.1

What's Changed

• Fixed ReDoS in Accept header parsing [CVE-2024-26146]
• Fixed ReDoS in Content Type header parsing [CVE-2024-25126]
• Reject Range headers which are too large [CVE-2024-26141]

Full Changelog: v2.2.8...v2.2.8.1

2.2.7

What's Changed

• Correct the year number in the changelog by @kimulab in #2015
• Support underscore in host names for Rack 2.2 (Fixes #2070) by @jeremyevans in #2071

New Contributors

• @kimulab made their first contribution in #2015

Full Changelog: v2.2.6.4...v2.2.7

2.2.2 (from changelog)

Fixed

• Fix incorrect Rack::Request#host value. (#1591, @ioquatix)
• Revert Rack::Handler::Thin implementation. (#1583, @jeremyevans)
• Double assignment is still needed to prevent an "unused variable" warning. (#1589, @kamipo)
• Fix to handle same_site option for session pool. (#1587, @kamipo)

2.2.1 (from changelog)

Fixed

• Rework Rack::Request#ip to handle empty forwarded_for. (#1577, @ioquatix)

2.2.0 (from changelog)

SPEC Changes

• rack.session request environment entry must respond to to_hash and return unfrozen Hash. (@jeremyevans)
• Request environment cannot be frozen. (@jeremyevans)
• CGI values in the request environment with non-ASCII characters must use ASCII-8BIT encoding. (@jeremyevans)
• Improve SPEC/lint relating to SERVER_NAME, SERVER_PORT and HTTP_HOST. (#1561, @ioquatix)

Added

• rackup supports multiple -r options and will require all arguments. (@jeremyevans)
• Server supports an array of paths to require for the :require option. (@khotta)
• Files supports multipart range requests. (@fatkodima)
• Multipart::UploadedFile supports an IO-like object instead of using the filesystem, using :filename and :io options. (@jeremyevans)
• Multipart::UploadedFile supports keyword arguments :path, :content_type, and :binary in addition to positional arguments. (@jeremyevans)
• Static supports a :cascade option for calling the app if there is no matching file. (@jeremyevans)
• Session::Abstract::SessionHash#dig. (@jeremyevans)
• Response.[] and MockResponse.[] for creating instances using status, headers, and body. (@ioquatix)
• Convenient cache and content type methods for Rack::Response. (#1555, @ioquatix)

Changed

• Request#params no longer rescues EOFError. (@jeremyevans)
• Directory uses a streaming approach, significantly improving time to first byte for large directories. (@jeremyevans)
• Directory no longer includes a Parent directory link in the root directory index. (@jeremyevans)
• QueryParser#parse_nested_query uses original backtrace when reraising exception with new class. (@jeremyevans)
• ConditionalGet follows RFC 7232 precedence if both If-None-Match and If-Modified-Since headers are provided. (@jeremyevans)
• .ru files supports the frozen-string-literal magic comment. (@eregon)
• Rely on autoload to load constants instead of requiring internal files, make sure to require 'rack' and not just 'rack/...'. (@jeremyevans)
• Etag will continue sending ETag even if the response should not be cached. (@henm)
• Request#host_with_port no longer includes a colon for a missing or empty port. (@AlexWayfer)
• All handlers uses keywords arguments instead of an options hash argument. (@ioquatix)
• Files handling of range requests no longer return a body that supports to_path, to ensure range requests are handled correctly. (@jeremyevans)
• Multipart::Generator only includes Content-Length for files with paths, and Content-Disposition filename if the UploadedFile instance has one. (@jeremyevans)
• Request#ssl? is true for the wss scheme (secure websockets). (@jeremyevans)
• Rack::HeaderHash is memoized by default. (#1549, @ioquatix)
• Rack::Directory allow directory traversal inside root directory. (#1417, @ThomasSevestre)
• Sort encodings by server preference. (#1184, @ioquatix, @wjordan)
• Rework host/hostname/authority implementation in Rack::Request. #host and #host_with_port have been changed to correctly return IPv6 addresses formatted with square brackets, as defined by RFC3986. (#1561, @ioquatix)
• Rack::Builder parsing options on first #\ line is deprecated. (#1574, @ioquatix)

Removed

• Directory#path as it was not used and always returned nil. (@jeremyevans)
• BodyProxy#each as it was only needed to work around a bug in Ruby <1.9.3. (@jeremyevans)
• URLMap::INFINITY and URLMap::NEGATIVE_INFINITY, in favor of Float::INFINITY. (@ch1c0t)
• Deprecation of Rack::File. It will be deprecated again in rack 2.2 or 3.0. (@rafaelfranca)
• Support for Ruby 2.2 as it is well past EOL. (@ioquatix)
• Remove Rack::Files#response_body as the implementation was broken. (#1153, @ioquatix)
• Remove SERVER_ADDR which was never part of the original SPEC. (#1573, @ioquatix)

Fixed

• Directory correctly handles root paths containing glob metacharacters. (@jeremyevans)
• Cascade uses a new response object for each call if initialized with no apps. (@jeremyevans)
• BodyProxy correctly delegates keyword arguments to the body object on Ruby 2.7+. (@jeremyevans)
• BodyProxy#method correctly handles methods delegated to the body object. (@jeremyevans)
• Request#host and Request#host_with_port handle IPv6 addresses correctly. (@AlexWayfer)
• Lint checks when response hijacking that rack.hijack is called with a valid object. (@jeremyevans)
• Response#write correctly updates Content-Length if initialized with a body. (@jeremyevans)
• CommonLogger includes SCRIPT_NAME when logging. (@Erol)
• Utils.parse_nested_query correctly handles empty queries, using an empty instance of the params class instead of a hash. (@jeremyevans)
• Directory correctly escapes paths in links. (@yous)
• Request#delete_cookie and related Utils methods handle :domain and :path options in same call. (@jeremyevans)
• Request#delete_cookie and related Utils methods do an exact match on :domain and :path options. (@jeremyevans)
• Static no longer adds headers when a gzipped file request has a 304 response. (@chooh)
• ContentLength sets Content-Length response header even for bodies not responding to to_ary. (@jeremyevans)
• Thin handler supports options passed directly to Thin::Controllers::Controller. (@jeremyevans)
• WEBrick handler no longer ignores :BindAddress option. (@jeremyevans)
• ShowExceptions handles invalid POST data. (@jeremyevans)
• Basic authentication requires a password, even if the password is empty. (@jeremyevans)
• Lint checks response is array with 3 elements, per SPEC. (@jeremyevans)
• Support for using :SSLEnable option when using WEBrick handler. (Gregor Melhorn)
• Close response body after buffering it when buffering. (@ioquatix)
• Only accept ; as delimiter when parsing cookies. (@mrageh)
• Utils::HeaderHash#clear clears the name mapping as well. (@raxoft)
• Support for passing nil Rack::Files.new, which notably fixes Rails' current ActiveStorage::FileServer implementation. (@ioquatix)

Documentation

• CHANGELOG updates. (@aupajo)
• Added CONTRIBUTING. (@dblock)

2.1.4.4

What's Changed

• Fixed ReDoS in Accept header parsing [CVE-2024-26146]

Full Changelog: v2.1.4.3...v2.1.4.4

2.1.2 (from changelog)

• Fix multipart parser for some files to prevent denial of service (@aiomaster)
• Fix Rack::Builder#use with keyword arguments (@kamipo)
• Skip deflating in Rack::Deflater if Content-Length is 0 (@jeremyevans)
• Remove SessionHash#transform_keys, no longer needed (@pavel)
• Add to_hash to wrap Hash and Session classes (@oleh-demyanyuk)
• Handle case where session id key is requested but missing (@jeremyevans)

2.1.1 (from changelog)

• Remove Rack::Chunked from Rack::Server default middleware. (#1475, @ioquatix)
• Restore support for code relying on SessionId#to_s. (@jeremyevans)

2.1.0 (from changelog)

Added

• Add support for SameSite=None cookie value. (@hennikul)
• Add trailer headers. (@eileencodes)
• Add MIME Types for video streaming. (@styd)
• Add MIME Type for WASM. (@buildrtech)
• Add Early Hints(103) to status codes. (@egtra)
• Add Too Early(425) to status codes. (@y-yagi)
• Add Bandwidth Limit Exceeded(509) to status codes. (@CJKinni)
• Add method for custom ip_filter. (@svcastaneda)
• Add boot-time profiling capabilities to rackup. (@tenderlove)
• Add multi mapping support for X-Accel-Mappings header. (@yoshuki)
• Add sync: false option to Rack::Deflater. (Eric Wong)
• Add Builder#freeze_app to freeze application and all middleware instances. (@jeremyevans)
• Add API to extract cookies from Rack::MockResponse. (@petercline)

Changed

• Don't propagate nil values from middleware. (@ioquatix)
• Lazily initialize the response body and only buffer it if required. (@ioquatix)
• Fix deflater zlib buffer errors on empty body part. (@felixbuenemann)
• Set X-Accel-Redirect to percent-encoded path. (@diskkid)
• Remove unnecessary buffer growing when parsing multipart. (@tainoe)
• Expand the root path in Rack::Static upon initialization. (@rosenfeld)
• Make ShowExceptions work with binary data. (@axyjo)
• Use buffer string when parsing multipart requests. (@janko-m)
• Support optional UTF-8 Byte Order Mark (BOM) in config.ru. (@mikegee)
• Handle X-Forwarded-For with optional port. (@dpritchett)
• Use Time#httpdate format for Expires, as proposed by RFC 7231. (@nanaya)
• Make Utils.status_code raise an error when the status symbol is invalid instead of 500. (@adambutler)
• Rename Request::SCHEME_WHITELIST to Request::ALLOWED_SCHEMES.
• Make Multipart::Parser.get_filename accept files with + in their name. (@lucaskanashiro)
• Add Falcon to the default handler fallbacks. (@ioquatix)
• Update codebase to avoid string mutations in preparation for frozen_string_literals. (@pat)
• Change MockRequest#env_for to rely on the input optionally responding to #size instead of #length. (@janko)
• Rename Rack::File -> Rack::Files and add deprecation notice. (@postmodern).
• Prefer Base64 “strict encoding” for Base64 cookies. (@ioquatix)

Removed

• Remove to_ary from Response (@tenderlove)
• Deprecate Rack::Session::Memcache in favor of Rack::Session::Dalli from dalli gem (@fatkodima)

Fixed

• Eliminate warnings for Ruby 2.7. (@osamtimizer)

Documentation

• Update broken example in Session::Abstract::ID documentation. (tonytonyjan)
• Add Padrino to the list of frameworks implmenting Rack. (@wikimatze)
• Remove Mongrel from the suggested server options in the help output. (@tricknotes)
• Replace HISTORY.md and NEWS.md with CHANGELOG.md. (@twitnithegirl)
• CHANGELOG updates. (@drenmi, @p8)

2.0.9.4

What's Changed

• Fixed ReDoS in Accept header parsing [CVE-2024-26146]

Full Changelog: v2.0.9.3...v2.0.9.4

2.0.8 (from changelog)

• [CVE-2019-16782] Prevent timing attacks targeted at session ID lookup. (@tenderlove, @rafaelfranca)

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by more commits than we can show here.

2.1.0 (from changelog)

• Breaking changes:

  • Digest authentication support, deprecated in 2.0.0, has been removed (Jeremy Evans #307)
  • requiring rack/mock_session, deprecated in 2.0.0, has been removed (Jeremy Evans #307)

• Minor enhancements:

  • The original_filename for Rack::Test::UploadedFile can now be set even if the content of the file comes from a file path (Stuart Chinery #314)
  • Add Rack::Test::Session#restore_state, for executing a block and restoring current state (last request, last response, and cookies) after the block (Jeremy Evans #316)
  • Make Rack::Test::Methods support default_host method similar to app, which will set the default host used for requests to the app (Jeremy Evans #317 #318)
  • Allow responses to set cookie paths not matching the current request URI. Such cookies will only be sent for paths matching the cookie path (Chris Waters #322)
  • Ignore leading dot for cookie domains, per RFC 6265 (Stephen Crosby #329)
  • Avoid creating empty multipart body if params is empty in Rack::Test::Session#env_for (Ryunosuke Sato #331)

2.0.2 (from changelog)

• Bug fixes:
  • Fix additional incompatible character encodings error when building uploaded bodies (Jeremy Evans #311)

2.0.1 (from changelog)

• Bug fixes:
  • Fix incompatible character encodings error when building uploaded file bodies (Jeremy Evans #308 #309)

2.0.0 (from changelog)

• Breaking changes:

  • Digest authentication support is now deprecated, as it relies on digest authentication support in rack, which has been deprecated (Jeremy Evans #294)
  • Rack::Test::Utils.build_primitive_part no longer handles array values (Jeremy Evans #292)
  • Rack::Test::Utils module methods other than build_nested_query and build_multipart are now private methods (Jeremy Evans #297)
  • Rack::MockSession has been combined into Rack::Test::Session, and remains as an alias to Rack::Test::Session, but to keep some backwards compatibility, Rack::Test::Session.new will accept a Rack::Test::Session instance and return it (Jeremy Evans #297)
  • Previously protected methods in Rack::Test::Cookie{,Jar} are now private methods (Jeremy Evans #297)
  • Rack::Test::Methods no longer defines build_rack_mock_session, but for backwards compatibility, build_rack_test_session will call build_rack_mock_session if it is defined (Jeremy Evans #297)
  • Rack::Test::Methods::METHODS is no longer defined (Jeremy Evans #297)
  • Rack::Test::Methods#_current_session_names has been removed (Jeremy Evans #297)
  • Headers used/accessed by rack-test are now lower case, for rack 3 compliance (Jeremy Evans #295)
  • Frozen literal strings are now used internally, which may break code that mutates static strings returned by rack-test, if any (Jeremy Evans #304)

• Minor enhancements:

  • rack-test now works with the rack main branch (what will be rack 3) (Jeremy Evans #280 #292)
  • rack-test only loads the parts of rack it uses when running on the rack main branch (what will be rack 3) (Jeremy Evans #292)
  • Development dependencies have been significantly reduced, and are now a subset of the development dependencies of rack itself (Jeremy Evans #292)
  • Avoid creating multiple large copies of uploaded file data in memory (Jeremy Evans #286)
  • Specify HTTP/1.0 when submitting requests, to avoid responses with Transfer-Encoding: chunked (Jeremy Evans #288)
  • Support :query_params in rack environment for parameters that are appended to the query string instead of used in the request body (Jeremy Evans #150 #287)
  • Reduce required ruby version to 2.0, since tests run fine on Ruby 2.0 (Jeremy Evans #292)
  • Support :multipart env key for request methods to force multipart input (Jeremy Evans #303)
  • Force multipart input for request methods if content type starts with multipart (Jeremy Evans #303)
  • Improve performance of Utils.build_multipart by using an append-only design (Jeremy Evans #304)
  • Improve performance of Utils.build_nested_query for array values (Jeremy Evans #304)

• Bug fixes:

  • The CONTENT_TYPE of multipart requests is now respected, if it starts with multipart/ (Tom Knig #238)
  • Work correctly with responses that respond to to_a but not to_ary (Sergio Faria #276)
  • Raise an ArgumentError instead of a TypeError when providing a StringIO without an original filename when creating an UploadedFile (Nuno Correia #279)
  • Allow combining both an UploadedFile and a plain string when building a multipart upload (Mitsuhiro Shibuya #278)
  • Fix the generation of filenames with spaces to use path escaping instead of regular escaping, since path unescaping is used to decode it (Muir Manders, Jeremy Evans #275 #284)
  • Rewind tempfile used for multipart uploads before it is submitted to the application (Jeremy Evans, Alexander Dervish #261 #268 #286)
  • Fix Rack::Test.encoding_aware_strings to be true only on rack 1.6+ (Jeremy Evans #292)
  • Make Rack::Test::CookieJar#valid? return true/false (Jeremy Evans #292)
  • Cookies without a domain attribute no longer are submitted to requests for subdomains of that domain, for RFC 6265 compliance (Jeremy Evans #292)
  • Increase required rack version to 1.3, since tests fail on rack 1.2 and below (Jeremy Evans #293)

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by more commits than we can show here.

2.2.0

What's Changed

• Allow user to choose the HTML parser used by @flavorjones in #109
• Fix string substitution regression by @nicoco007 in #110

New Contributors

• @nicoco007 made their first contribution in #110

Full Changelog: v2.1.1...v2.2.0

2.1.1

What's Changed

• Fix issue when application isn't using minitest.

Full Changelog: v2.1.0...v2.1.1

2.1.0

What's Changed

• Address warning: mismatched indentations at 'when' with 'case' by @yahonda in #74
• Make assert_dom_equal ignore insignificant whitespace when walking the node tree by @jduff in #84
• Expand Substitution Matching Types support by @seanpdoyle in #90
• Alias assert_select methods to assert_dom versions by @seanpdoyle in #93
• Raise an error if the last arg is the wrong format by @ghiculescu in #96
• Fix replacement for multiple substitutions by @speckins in #76
• Better error message if response.body is blank or not parseable by Nokogiri by @ghiculescu in #97
• selector_assertions/html_selector: No trailing . on content_mismatch by @issyl0 in #102
• Use Minitest::Assertion#diff for content failure messages by @flavorjones in #106

New Contributors

• @nicolasleger made their first contribution in #73
• @yahonda made their first contribution in #74
• @dependabot made their first contribution in #79
• @jduff made their first contribution in #86
• @amatsuda made their first contribution in #88
• @seanpdoyle made their first contribution in #90
• @ghiculescu made their first contribution in #96
• @jbampton made their first contribution in #95
• @speckins made their first contribution in #76
• @issyl0 made their first contribution in #102
• @flavorjones made their first contribution in #103

Full Changelog: v2.0.3...v2.1.0

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by more commits than we can show here.

🚨 Inefficient Regular Expression Complexity in rails-html-sanitizer

Summary

Certain configurations of rails-html-sanitizer < 1.4.4 use an inefficient regular expression that is susceptible to excessive backtracking when attempting to sanitize certain SVG attributes. This may lead to a denial of service through CPU resource consumption.

Mitigation

Upgrade to rails-html-sanitizer >= 1.4.4.

Severity

The maintainers have evaluated this as High Severity 7.5 (CVSS3.1).

References

• CWE - CWE-1333: Inefficient Regular Expression Complexity (4.9)
• https://hackerone.com/reports/1684163

Credit

This vulnerability was responsibly reported by @ooooooo-q (https://github.com/ooooooo-q).

🚨 Improper neutralization of data URIs may allow XSS in rails-html-sanitizer

Summary

rails-html-sanitizer >= 1.0.3, < 1.4.4 is vulnerable to cross-site scripting via data URIs when used in combination with Loofah >= 2.1.0.

Mitigation

Upgrade to rails-html-sanitizer >= 1.4.4.

Severity

The maintainers have evaluated this as Medium Severity 6.1.

References

• CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)
• SVG MIME Type (image/svg+xml) is misleading to developers · Issue #266 · w3c/svgwg
• #135
• https://hackerone.com/reports/1694173

Credit

This vulnerability was independently reported by Maciej Piechota (@haqpl) and Mrinmoy Das (@goromlagche).

🚨 Possible XSS vulnerability with certain configurations of rails-html-sanitizer

Summary

There is a possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer.

• Versions affected: ALL
• Not affected: NONE
• Fixed versions: 1.4.4

Impact

A possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer may allow an attacker to inject content if the application developer has overridden the sanitizer's allowed tags in either of the following ways:

• allow both "math" and "style" elements,
• or allow both "svg" and "style" elements

Code is only impacted if allowed tags are being overridden. Applications may be doing this in four different ways:

1. using application configuration:

# In config/application.rb
config.action_view.sanitized_allowed_tags = ["math", "style"]
# or
config.action_view.sanitized_allowed_tags = ["svg", "style"]

see https://guides.rubyonrails.org/configuring.html#configuring-action-view

2. using a :tags option to the Action View helper sanitize:

<%= sanitize @comment.body, tags: ["math", "style"] %>
<%# or %>
<%= sanitize @comment.body, tags: ["svg", "style"] %>

see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize

3. using Rails::Html::SafeListSanitizer class method allowed_tags=:

# class-level option
Rails::Html::SafeListSanitizer.allowed_tags = ["math", "style"]
# or
Rails::Html::SafeListSanitizer.allowed_tags = ["svg", "style"]

4. using a :tags options to the Rails::Html::SafeListSanitizer instance method sanitize:

# instance-level option
Rails::Html::SafeListSanitizer.new.sanitize(@article.body, tags: ["math", "style"])
# or
Rails::Html::SafeListSanitizer.new.sanitize(@article.body, tags: ["svg", "style"])

All users overriding the allowed tags by any of the above mechanisms to include (("math" or "svg") and "style") should either upgrade or use one of the workarounds immediately.

Workarounds

Remove "style" from the overridden allowed tags, or remove "math" and "svg" from the overridden allowed tags.

References

• CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)
• https://hackerone.com/reports/1656627

Credit

This vulnerability was responsibly reported by Dominic Breuker.

🚨 Possible XSS vulnerability with certain configurations of rails-html-sanitizer

Summary

There is a possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer. This is due to an incomplete fix of CVE-2022-32209.

• Versions affected: ALL
• Not affected: NONE
• Fixed versions: 1.4.4

Impact

A possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer may allow an attacker to inject content if the application developer has overridden the sanitizer's allowed tags to allow both "select" and "style" elements.

Code is only impacted if allowed tags are being overridden using either of the following two mechanisms:

1. Using the Rails configuration config.action_view.sanitized_allow_tags=:

# In config/application.rb
config.action_view.sanitized_allowed_tags = ["select", "style"]

(see https://guides.rubyonrails.org/configuring.html#configuring-action-view)

2. Using the class method Rails::Html::SafeListSanitizer.allowed_tags=:

# class-level option
Rails::Html::SafeListSanitizer.allowed_tags = ["select", "style"]

All users overriding the allowed tags by either of the above mechanisms to include both "select" and "style" should either upgrade or use one of the workarounds immediately.

NOTE: Code is not impacted if allowed tags are overridden using either of the following mechanisms:

• the :tags option to the Action View helper method sanitize.
• the :tags option to the instance method SafeListSanitizer#sanitize.

Workarounds

Remove either "select" or "style" from the overridden allowed tags.

References

• CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32209
• https://hackerone.com/reports/1654310

Credit

This vulnerability was responsibly reported by Dominic Breuker.

🚨 Possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer

There is a possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer.
This vulnerability has been assigned the CVE identifier CVE-2022-32209.

Versions Affected: ALL
Not affected: NONE
Fixed Versions: v1.4.3

Impact

A possible XSS vulnerability with certain configurations of
Rails::Html::Sanitizer may allow an attacker to inject content if the
application developer has overridden the sanitizer's allowed tags to allow
both select and style elements.

Code is only impacted if allowed tags are being overridden. This may be done via application configuration:

# In config/application.rb
config.action_view.sanitized_allowed_tags = ["select", "style"]

see https://guides.rubyonrails.org/configuring.html#configuring-action-view

Or it may be done with a :tags option to the Action View helper sanitize:

<%= sanitize @comment.body, tags: ["select", "style"] %>

see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize

Or it may be done with Rails::Html::SafeListSanitizer directly:

# class-level option
Rails::Html::SafeListSanitizer.allowed_tags = ["select", "style"]

or

# instance-level option
Rails::Html::SafeListSanitizer.new.sanitize(@article.body, tags: ["select", "style"])

All users overriding the allowed tags by any of the above mechanisms to include both "select" and "style" should either upgrade or use one of the workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Remove either select or style from the overridden allowed tags.

Credits

This vulnerability was responsibly reported by windshock.

1.6.0

1.6.0 / 2023-05-26

• Dependencies have been updated:

  • Loofah ~>2.21 and Nokogiri ~>1.14 for HTML5 parser support
  • As a result, required Ruby version is now >= 2.7.0

  Security updates will continue to be made on the 1.5.x release branch as long as Rails 6.1
  (which supports Ruby 2.5) is still in security support.

  Mike Dalessio

• HTML5 standards-compliant sanitizers are now available on platforms supported by
  Nokogiri::HTML5. These are available as:

  • Rails::HTML5::FullSanitizer
  • Rails::HTML5::LinkSanitizer
  • Rails::HTML5::SafeListSanitizer

  And a new "vendor" is provided at Rails::HTML5::Sanitizer that can be used in a future version
  of Rails.

  Note that for symmetry Rails::HTML4::Sanitizer is also added, though its behavior is identical
  to the vendor class methods on Rails::HTML::Sanitizer.

  Users may call Rails::HTML::Sanitizer.best_supported_vendor to get back the HTML5 vendor if it's
  supported, else the legacy HTML4 vendor.

  Mike Dalessio

• Module namespaces have changed, but backwards compatibility is provided by aliases.

  The library defines three additional modules:

  • Rails::HTML for general functionality (replacing Rails::Html)
  • Rails::HTML4 containing sanitizers that parse content as HTML4
  • Rails::HTML5 containing sanitizers that parse content as HTML5

  The following aliases are maintained for backwards compatibility:

  • Rails::Html points to Rails::HTML
  • Rails::HTML::FullSanitizer points to Rails::HTML4::FullSanitizer
  • Rails::HTML::LinkSanitizer points to Rails::HTML4::LinkSanitizer
  • Rails::HTML::SafeListSanitizer points to Rails::HTML4::SafeListSanitizer

  Mike Dalessio

• LinkSanitizer always returns UTF-8 encoded strings. SafeListSanitizer and FullSanitizer
  already ensured this encoding.

  Mike Dalessio

• SafeListSanitizer allows time tag and lang attribute by default.

  Mike Dalessio

• The constant Rails::Html::XPATHS_TO_REMOVE has been removed. It's not necessary with the
  existing sanitizers, and should have been a private constant all along anyway.

  Mike Dalessio

1.5.0

1.5.0 / 2023-01-20

• SafeListSanitizer, PermitScrubber, and TargetScrubber now all support pruning of unsafe tags.

  By default, unsafe tags are still stripped, but this behavior can be changed to prune the element
  and its children from the document by passing prune: true to any of these classes' constructors.

  @seyerian

1.4.4

1.4.4 / 2022-12-13

• Address inefficient regular expression complexity with certain configurations of Rails::Html::Sanitizer.

  Fixes CVE-2022-23517. See GHSA-5x79-w82f-gw8w for more information.

  Mike Dalessio

• Address improper sanitization of data URIs.

  Fixes CVE-2022-23518 and #135. See GHSA-mcvf-2q2m-x72m for more information.

  Mike Dalessio

• Address possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer.

  Fixes CVE-2022-23520. See GHSA-rrfc-7g8p-99q8 for more information.

  Mike Dalessio

• Address possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer.

  Fixes CVE-2022-23519. See GHSA-9h9g-93gc-623h for more information.

  Mike Dalessio

1.4.3

1.4.3 / 2022-06-09

• Address a possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer.

  Prevent the combination of select and style as allowed tags in SafeListSanitizer.

  Fixes CVE-2022-32209

  Mike Dalessio

1.4.2

1.4.2 / 2021-08-23

• Slightly improve performance.

  Assuming elements are more common than comments, make one less method call per node.

1.4.1

1.4.1 / 2021-08-18

• Fix regression in v1.4.0 that did not pass comment nodes to the scrubber.

  Some scrubbers will want to override the default behavior and allow comments, but v1.4.0 only
  passed through elements to the scrubber's keep_node? method.

  This change once again allows the scrubber to make the decision on comment nodes, but still skips
  other non-elements like processing instructions (see #115).

  Mike Dalessio

1.4.0

1.4.0 / 2021-08-18

• Processing Instructions are no longer allowed by Rails::Html::PermitScrubber

  Previously, a PI with a name (or "target") matching an allowed tag name was not scrubbed. There
  are no known security issues associated with these PIs, but similar to comments it's preferred to
  omit these nodes when possible from sanitized output.

  Fixes #115.

  Mike Dalessio

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by more commits than we can show here.

🚨 Possible Remote Code Execution Exploit in Rails Development Mode

There is a possible a possible remote code executing exploit in Rails when in
development mode. This vulnerability has been assigned the CVE identifier
CVE-2019-5420.

Versions Affected: 6.0.0.X, 5.2.X.
Not affected: None.
Fixed Versions: 6.0.0.beta3, 5.2.2.1

Impact

With some knowledge of a target application it is possible for an attacker to
guess the automatically generated development mode secret token. This secret
token can be used in combination with other Rails internals to escalate to a
remote code execution exploit.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The 6.0.0.beta3 and 5.2.2.1 releases are available at the normal locations.

Workarounds

This issue can be mitigated by specifying a secret key in development mode.
In "config/environments/development.rb" add this:

config.secret_key_base = SecureRandom.hex(64)

Credits

Thanks to ooooooo_q

🚨 Possible Remote Code Execution Exploit in Rails Development Mode

There is a possible a possible remote code executing exploit in Rails when in
development mode. This vulnerability has been assigned the CVE identifier
CVE-2019-5420.

Versions Affected: 6.0.0.X, 5.2.X.
Not affected: None.
Fixed Versions: 6.0.0.beta3, 5.2.2.1

Impact

With some knowledge of a target application it is possible for an attacker to
guess the automatically generated development mode secret token. This secret
token can be used in combination with other Rails internals to escalate to a
remote code execution exploit.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The 6.0.0.beta3 and 5.2.2.1 releases are available at the normal locations.

Workarounds

This issue can be mitigated by specifying a secret key in development mode.
In "config/environments/development.rb" add this:

config.secret_key_base = SecureRandom.hex(64)

Credits

Thanks to ooooooo_q

Too many releases to show here. View the full release notes.

See the full diff on Github. The new version differs by 4 commits:

• Preparing for 7.0.8.1 release
• update changelog
• fix XSS vulnerability when using translation
• Merge pull request #48869 from brunoprietog/disable-session-active-storage-proxy-controllers

13.1.0

What's Changed

• Added dependabot.yml for actions by @hsbt in #416
• Add Ruby 3.1 to the CI matrix by @petergoldstein in #415
• (Performance) Remove unnecessary I/O syscalls for FileTasks by @da2x in #393
• Skip test failure with JRuby by @hsbt in #418
• Bump actions/checkout from 2 to 3 by @dependabot in #417
• Remove bin/rdoc by @tnir in #421
• Remove bin/rake by @tnir in #422
• Remove bin/bundle by @tnir in #425
• Apply RuboCop linting for Ruby 2.3 by @tnir in #423
• Update rubocop to work with Ruby 2.4 compatible by @tnir in #424
• chore: fix typo in comments by @tnir in #429
• Use 'test' as workflow name on Actions by @tnir in #427
• docs: update CONTRIBUTING.rdoc by @tnir in #428
• Add RuboCop job to Actions by @tnir in #426
• Lock minitest-5.15.0 for Ruby 2.2 by @hsbt in #442
• Eagerly require set in thread_pool.rb by @jeremyevans in #440
• Avoid creating an unnecessary thread pool by @jeremyevans in #441
• Add credit for maintenance in Rake 12/13 by @tnir in #443
• Sh fully echoes commands which error exit by @MarkDBlackwell in #147
• Correct RuboCop offenses by @deivid-rodriguez in #444
• [StepSecurity] ci: Harden GitHub Actions by @step-security-bot in #450
• Bump ruby/setup-ruby from 1.126.0 to 1.127.0 by @dependabot in #453
• Bump actions/checkout from 3.1.0 to 3.2.0 by @dependabot in #454
• Bump ruby/setup-ruby from 1.127.0 to 1.131.0 by @dependabot in #457
• Add ruby 3.2 to test matrix by @hanneskaeufler in #458
• Bump ruby/setup-ruby from 1.131.0 to 1.133.0 by @dependabot in #459
• Bump actions/checkout from 3.2.0 to 3.3.0 by @dependabot in #463
• Bump ruby/setup-ruby from 1.133.0 to 1.133.1 by @dependabot in #462
• Bump ruby/setup-ruby from 1.133.1 to 1.133.2 by @dependabot in #464
• Bump ruby/setup-ruby from 1.133.2 to 1.134.0 by @dependabot in #466
• Missing 'do' on example by @zzak in #467
• Try to use dependabot automerge by @hsbt in #470
• Rewrite auto-merge feature for dependabot by @hsbt in #471
• Bump ruby/setup-ruby from 1.134.0 to 1.137.2 by @dependabot in #469
• Update bundler in Dependabot by @ono-max in #472
• Bump ruby/setup-ruby from 1.137.2 to 1.138.0 by @dependabot in #473
• Update minitest requirement from 5.15.0 to 5.17.0 by @dependabot in #474
• Fix grammar in help text by @mebezac in #381
• Try to use ruby/ruby/.github/workflows/ruby_versions.yml@master by @hsbt in #475
• Bump lewagon/wait-on-check-action from 1.2.0 to 1.3.1 by @dependabot in #476
• Use GitHub Pages Action for generating rdoc page by @hsbt in #477
• Bump ruby/setup-ruby from 1.138.0 to 1.143.0 by @dependabot in #478
• Update minitest requirement from 5.17.0 to 5.18.0 by @dependabot in #479
• Bump ruby/setup-ruby from 1.143.0 to 1.144.0 by @dependabot in #480
• Bump ruby/setup-ruby from 1.144.0 to 1.144.1 by @dependabot in #482
• Bump actions/deploy-pages from 1 to 2 by @dependabot in #481
• Bump ruby/setup-ruby from 1.144.1 to 1.144.2 by @dependabot in #484
• Update rubocop requirement from ~> 1.12.1 to ~> 1.48.1 by @dependabot in #485
• Bump ruby/setup-ruby from 1.144.2 to 1.145.0 by @dependabot in #487
• Update rubocop requirement from ~> 1.48.1 to ~> 1.49.0 by @dependabot in #488
• Support #detailed_message when task failed by @ksss in #486
• Debug at stop when task fail by @ksss in #489
• Drop to support Ruby 2.2 by @hsbt in #492
• Bump ruby/setup-ruby from 1.145.0 to 1.146.0 by @dependabot in #491
• Update rubocop requirement from ~> 1.49.0 to ~> 1.50.1 by @dependabot in #493
• Bump up setup-ruby by @hsbt in #497
• Bump ruby/setup-ruby from 1.148.0 to 1.149.0 by @dependabot in #498
• Update rubocop requirement from ~> 1.50.1 to ~> 1.51.0 by @dependabot in #499
• Bump ruby/setup-ruby from 1.149.0 to 1.150.0 by @dependabot in #500
• Update rubocop requirement from ~> 1.51.0 to ~> 1.52.0 by @dependabot in #502
• Bump ruby/setup-ruby from 1.150.0 to 1.151.0 by @dependabot in #503
• Update development dependencies by @hsbt in #505
• Bump ruby/setup-ruby from 1.151.0 to 1.152.0 by @dependabot in #506
• Bump actions/upload-pages-artifact from 1 to 2 by @dependabot in #508
• Bump actions/checkout from 3 to 4 by @dependabot in #513
• Bump ruby/setup-ruby from 1.152.0 to 1.153.0 by @dependabot in #514
• Bump actions/checkout from 4.0.0 to 4.1.0 by @dependabot in #516
• Bump ruby/setup-ruby from 1.153.0 to 1.154.0 by @dependabot in #517
• Bump ruby/setup-ruby from 1.154.0 to 1.155.0 by @dependabot in #518
• Bump ruby/setup-ruby from 1.155.0 to 1.156.0 by @dependabot in #519
• Bump actions/checkout from 4.1.0 to 4.1.1 by @dependabot in #520
• Bump ruby/setup-ruby from 1.156.0 to 1.157.0 by @dependabot in #521

New Contributors

• @petergoldstein made their first contribution in #415
• @da2x made their first contribution in #393
• @dependabot made their first contribution in #417
• @tnir made their first contribution in #421
• @step-security-bot made their first contribution in #450
• @hanneskaeufler made their first contribution in #458
• @ono-max made their first contribution in #472
• @mebezac made their first contribution in #381
• @ksss made their first contribution in #486

Full Changelog: v13.0.6...v13.1.0

13.0.6 (from changelog)

• Additional fix for #389 Pull request #390 by hsbt

13.0.5 (from changelog)

• Fixed the regression of #388 Pull request #389 by hsbt

13.0.4 (from changelog)

• Fix rake test loader swallowing useful error information. Pull request #367 by deivid-rodriguez

• Add -C/–directory option the same as GNU make. Pull request #376 by nobu

13.0.3 (from changelog)

• Fix breaking change of execution order on TestTask. Pull request #368 by ysakasin

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by more commits than we can show here.

4.2.1

What's Changed

• Fix .jpeg precompile issue by @ghiculescu in #781
• CI against Ruby 3.2 [changelog skip] by @amatsuda in #777
• Fix header casing compatibility with Rails 7 by @skipkayhil in #790
• fix: set application/css-sourcemap+json default charset to unicode by @chadlwilson in #764

New Contributors

• @ghiculescu made their first contribution in #781
• @skipkayhil made their first contribution in #791
• @jpbalarini made their first contribution in #768
• @chadlwilson made their first contribution in #764

Full Changelog: v4.2.0...v4.2.1

4.2.0 (from changelog)

• Rack 3 compatibility. #758
• Fix thread safety of Sprockets::CachedEnvironment and Sprockets::Cache::MemoryStore. #771
• Add support for Rack 3.0. Headers set by sprockets will now be lower case. #758
• Make Sprockets::Utils.module_include thread safe on JRuby. #759

4.1.1

• Fix Sprockets::Server to return response headers to compatible with with Rack::Lint 2.0.

Full Changelog: v4.1.0...v4.1.1

4.1.0

What's Changed

• Lowercase all response headers by @amatsuda in #744
• Ensure compatibility with esbuilds' base32 digests by @dhh in #726
• cache nil values in the CachedEnvironment by @lsylvester in #723
• Explain configuration for Rails engines by @pjmorse in #694
• Get rid off undefined method `start_with?' for nil:NilClass error by @dakolech in #684
• Added support for ERB in webmanifest files by @mashedkeyboard in #608
• Set application/js-sourcemap+json charset to unicode by @andresakata in #669
• Adding directive depends_on_directory by @jessecollier in #668
• Fix cache key for coffee script processor by @code-constructor in #670
• Add text/ejs to register_transformer_suffix for ERBProcessor by @cgunther in #674
• Allow age to be altered in clean_assets rake task by @nikolai-b in #677

New Contributors

• @dhh made their first contribution in #726
• @lsylvester made their first contribution in #723
• @pjmorse made their first contribution in #694
• @dakolech made their first contribution in #684
• @mashedkeyboard made their first contribution in #608
• @andresakata made their first contribution in #669
• @jessecollier made their first contribution in #668
• @code-constructor made their first contribution in #670
• @cgunther made their first contribution in #674
• @nikolai-b made their first contribution in #677

Full Changelog: v4.0.3...v4.1.0

4.0.3 (from changelog)

• Fix Manifest#find yielding from a Promise causing issue on Ruby 3.1.0-dev. #720
• Better detect the ERB version to avoid deprecation warnings. #719
• Allow assets already fingerprinted to be served through Sprockets::Server
• Do not fingerprint files that already contain a valid digest in their name
• Remove remaining support for Ruby < 2.4.#672

4.0.2 (from changelog)

• Fix etag and digest path compilation that were generating string with invalid digest since 4.0.1.

4.0.1 (from changelog)

• Fix for Ruby 2.7 keyword arguments warning in base.rb. #660
• Fix for when x_sprockets_linecount is missing from a source map.
• Fix subresource integrity to match the digest of the asset.

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by more commits than we can show here.

3.4.2

What's Changed

• Fix protocol relative URLs amended accidentally by @PikachuEXE in #485
• Add assets.resolve_assets_in_css_urls configuration option to allow disabling AssetUrlProcessor by @rmacklin in #489

New Contributors

• @PikachuEXE made their first contribution in #485
• @rmacklin made their first contribution in #489

Full Changelog: v3.4.1...v3.4.2

3.4.1

What's Changed

• expose dependencies from AssetUrlProcessor by @zarqman in #480
• Fix issues with relative paths from AssetUrlProcessor by @jcoyne in #482
• Fix sourcemapping url replacement by @dhh in #484

Full Changelog: v3.4.0...v3.4.1

3.4.0

What's Changed

• Ensure source mapping URLs set by transpilers are not broken by appending a semicolon to their path and translate the paths to the digested versions for deployment by @dhh in #479

This makes sprockets-rails compatible out of the box with sourcemap generation from jsbundling-rails.

3.3.0

What's Changed

• Process css files so that they get digested paths for asset files by @jcoyne in #476. This allows you to use sprockets-rails together with cssbundling-rails and be able to reference assets in the asset pipeline without additional compilation.
• Raise the error that includes an error message by @ghiculescu in #472

Full Changelog: v3.2.2...v3.3.0

3.2.2

• Fix extending ActionView::Base instances with Sprockets::Rails::Helper on Rails 6.1
• Fix deprecation warning on Ruby 2.7 [#454]
• action_view/base is no longer required when rake tasks are loaded [#455]
• Asset not precompiled error exception renamed to AssetNotPrecompiledError [#414]

Does any of this look wrong? Please let us know.

See the full diff on Github. The new version differs by 75 commits:

• Bump for 3.4.2
• Add `assets.resolve_assets_in_css_urls` configuration option to allow disabling `AssetUrlProcessor` (#489)
• Merge pull request #490 from ghiculescu/patch-1
• Update README.md
• Be more explicit that `config.assets.debug` does nothing in Sprockets 4+
• Merge pull request #485 from PikachuEXE/fix/protocol-relative-urls
• Fix protocol relative URLs amended accidentally
• Bump for 3.4.1
• Fix sourcemapping url replacement (#484)
• Strip away the relative path (#482)
• Whitespaces :scissors:
• Merge pull request #474 from jbampton/fix-spelling
• Merge pull request #477 from jcoyne/rails-6.1
• Merge pull request #480 from zarqman/track-dependent-assets
• Remove warning of unused variable
• Bump for 3.4.0
• Process source mapping URLs be set by transpilers (#479)
• expose dependencies from AssetUrlProcessor
• Bump for 3.3.0
• Process css files so that they get digested paths for asset files (#476)
• Test on Rails 6.1.x
• Merge pull request #475 from hahmed/ha/move-to-gitub-actions
• Fixes build for Gemfile, rails 7 by adding a new method that checks the rails version and appends media="screen" to the assertions. The setting config.action_view.apply_stylesheet_media_default = true was added in rails 7.
• Move to github actions
• Merge pull request #472 from ghiculescu/use-the-good-error
• Raise the error that includes an error message
• chore: fix spelling
• Merge pull request #469 from skatkov/travis-remove-unsupported-versions
• Update gemspec with minimum ruby/rails versions
• Travis-ci: remove unsupported rubies and rails versions
• Prepare 3.2.2 release
• Merge pull request #465 from rails/fix-tests-and-add-ruby-2-7
• Fix extending ActionView::Base instances
• Silence warnings about static path fallback
• Fix Action View deprecation warning
• Require Rails::VERSION so test can run in isolation
• Fix Sprockets deprecation warning
• Only use kwargs splat operator on Ruby 2.7+
• Exclude Rails 5.2.x/Ruby 2.2 from build matrix
• Update ruby version testing matrix
• Merge pull request #455 from Edouard-chin/ec-action-view-noneed-toload
• Don't require ActionView::Base when rake tasks get loaded:
• Merge pull request #454 from connorshea/fix-ruby-27-deprecations
• Fix Ruby 2.7 deprecation in helper.rb.
• Improve error message by pointing to the upgrading guide
• Merge pull request #442 from jaredbeck/test_rails_6.0.0
• Test rails 6.0.0
• Merge pull request #440 from olleolleolle/patch-2
• Merge pull request #420 from artfuldodger/patch-1
• Merge pull request #439 from olleolleolle/patch-1
• CI: Sprockets 4 req. Ruby 2.5.0+
• README: Remove Gemnsium badge
• CI against ruby 2.6
• rails 6.x now requires ruby >= 2.5.0
• oops!
• We're still testing against old rubies that aren't supported by bundler 2.x
• CI against newer rubies
• Merge pull request #434 from lostapathy/patch-1
• limit minitest version to resolve test failures
• Workaround issue with sprockets-4.0.0.beta
• resolve security warnings on current bundler
• Corrections to gemfiles/travis config
• Test against ruby 2.5.1
• Merge pull request #428 from mvz/document-non-digest-options
• Document other gem options
• Point to gem fork with a friendlier name
• Merge pull request #429 from justin808/patch-1
• Missing space in error message
• Document options for generating non-digest assets
• Fix typo
• Merge pull request #414 from rails/schneems/more-error-stuff
• Extra newline in exception
• Use word “error” in error class.
• Always use newest bundler in the CI
• Remove CHANGELOG

1.3.0

What's Changed

• use the correct class for shared namespaces by @Gerst20051 in #754
• Allow to Override Order of Commands in Help by @alessio-signorini in #642
• Add support for providing http headers to get by @dnlgrv in #801
• Don't document negative boolean option named no_* by @BrentWheeldon in #797
• CreateFile#identical? fixed for files containing multi-byte UTF-8 codepoints by @tomclose in #786
• Drop support to Ruby 2.6 by @rafaelfranca in #821
• Fix dashless option usage info by @sambostock in #800
• Support Range in enum option by @phene in #775
• Check if type: array values are in enum by @movermeyer in #784
• Fix inject into file warning by @nicolas-brousse in #709
• Support Thor::CoreExt::HashWithIndifferentAccess#slice method by @shuuuuun in #812
• 🌧️ long_desc: new option to disable wrapping by @igneus in #739
• Print default in help when option type is :boolean and default is false by @nevesenin in #849
• Silence encoding warnings in specs by @p8 in #857
• Validate arguments for method_option and class_option by @p8 in #856
• Fix help for file_collision method without block by @shuuuuun in #858
• Extract print methods to seperate classes by @p8 in #854
• Add support for printing tables with borders by @p8 in #855
• Fix printing tables with borders and indentation by @p8 in #861

New Contributors

• @Gerst20051 made their first contribution in #754
• @alessio-signorini made their first contribution in #642
• @dnlgrv made their first contribution in #801
• @BrentWheeldon made their first contribution in #797
• @tomclose made their first contribution in #786
• @sambostock made their first contribution in #800
• @phene made their first contribution in #775
• @movermeyer made their first contribution in #784
• @nicolas-brousse made their first contribution in #709
• @shuuuuun made their first contribution in #812
• @igneus made their first contribution in #739
• @nevesenin made their first contribution in #849

Full Changelog: v1.2.2...v1.3.0

1.2.2

What's Changed

• Respect implicit encoding of thorfiles by @timdiggins in #782
• Switch hash from MD5 to SHA256 by @stanhu in #785
• Respect the updated NO_COLOR specification by @coderjoe in #796
• Remove support for deprecated OS by @peterzhu2118 in #798
• Support thor install <uri> to install remote thor files by @deivid-rodriguez in #787
• Update error message for content already exists case. by @jpgeek in #799
• Allow setting file permissions with create_file by @skipkayhil in #820
• Properly pad aliases for option usage by @p8 in #810

New Contributors

• @ytkg made their first contribution in #767
• @timdiggins made their first contribution in #780
• @stanhu made their first contribution in #785
• @jdufresne made their first contribution in #806
• @peterzhu2118 made their first contribution in #798
• @casperisfine made their first contribution in #807
• @jpgeek made their first contribution in #799
• @skipkayhil made their first contribution in #820
• @p8 made their first contribution in #810

Full Changelog: v1.2.1...v1.2.2

1.2.1

What's Changed

• Fix regressions with insert_into_file

Full Changelog: v1.2.0...v1.2.1

1.2.0

What's Changed

• Support Thor::CoreExt::HashWithIndifferentAccess#except for Rails 6.0 by @koic in #734
• The klass parameter 'inject_into_class' should be given a string type.(also inject_into_module) by @ratovia in #752
• Added Shell::Basic#say_error by @postmodern in #750
• Check for duplicate content in relevant section when inserting into files by @excid3 in #735
• Loaded the directory under tasks. by @Mitsuru53 in #747
• Update Thor::Actions#inside to return the value yielded by the block by @jordan-brough in #712
• remove_file should unlink broken symlinks by @2called-chaos in #720
• Use string interpolation for trailing whitespace by @jonathanhefner in #730
• Indent multiline messages in say_status by @jonathanhefner in #714
• Allow leading hyphen in switch values when specified with = by @univerio in #737
• Fix for #707 by @scambra in #708
• Support latest did_you_mean by @deivid-rodriguez in #761

New Contributors

• @ratovia made their first contribution in #752
• @excid3 made their first contribution in #735
• @Mitsuru53 made their first contribution in #747
• @jordan-brough made their first contribution in #712
• @2called-chaos made their first contribution in #720
• @univerio made their first contribution in #737
• @scambra made their first contribution in #708

Full Changelog: v1.1.0...v1.2.0