Skip to content

🚨 [security] Update all of rails: 5.2.4.2 → 5.2.6 (minor)#245

Closed
depfu[bot] wants to merge 1 commit intomasterfrom
depfu/update/group/rails-5.2.6
Closed

🚨 [security] Update all of rails: 5.2.4.2 → 5.2.6 (minor)#245
depfu[bot] wants to merge 1 commit intomasterfrom
depfu/update/group/rails-5.2.6

Conversation

@depfu
Copy link
Contributor

@depfu depfu bot commented May 6, 2021

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ rails (5.2.4.2 → 5.2.6) · Repo

Release Notes

5.2.6

More info than we can show here.

5.2.5

More info than we can show here.

5.2.4.6

More info than we can show here.

5.2.4.5

More info than we can show here.

5.2.4.4

More info than we can show here.

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

Commits

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

↗️ actioncable (indirect, 5.2.4.2 → 5.2.6) · Repo · Changelog

Release Notes

5.2.6 (from changelog)

More info than we can show here.

5.2.5 (from changelog)

More info than we can show here.

5.2.4.6 (from changelog)

More info than we can show here.

5.2.4.5 (from changelog)

More info than we can show here.

5.2.4.4 (from changelog)

More info than we can show here.

5.2.4.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ actionmailer (indirect, 5.2.4.2 → 5.2.6) · Repo · Changelog

Release Notes

5.2.6 (from changelog)

More info than we can show here.

5.2.5 (from changelog)

More info than we can show here.

5.2.4.6 (from changelog)

More info than we can show here.

5.2.4.5 (from changelog)

More info than we can show here.

5.2.4.4 (from changelog)

More info than we can show here.

5.2.4.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ actionpack (indirect, 5.2.4.2 → 5.2.6) · Repo · Changelog

Security Advisories 🚨

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

Release Notes

5.2.6 (from changelog)

More info than we can show here.

5.2.5 (from changelog)

More info than we can show here.

5.2.4.6 (from changelog)

More info than we can show here.

5.2.4.5 (from changelog)

More info than we can show here.

5.2.4.4 (from changelog)

More info than we can show here.

5.2.4.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ actionview (indirect, 5.2.4.2 → 5.2.6) · Repo · Changelog

Security Advisories 🚨

🚨 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

Release Notes

5.2.6 (from changelog)

More info than we can show here.

5.2.5 (from changelog)

More info than we can show here.

5.2.4.6 (from changelog)

More info than we can show here.

5.2.4.5 (from changelog)

More info than we can show here.

5.2.4.4 (from changelog)

More info than we can show here.

5.2.4.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ activejob (indirect, 5.2.4.2 → 5.2.6) · Repo · Changelog

Release Notes

5.2.6 (from changelog)

More info than we can show here.

5.2.5 (from changelog)

More info than we can show here.

5.2.4.6 (from changelog)

More info than we can show here.

5.2.4.5 (from changelog)

More info than we can show here.

5.2.4.4 (from changelog)

More info than we can show here.

5.2.4.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ activemodel (indirect, 5.2.4.2 → 5.2.6) · Repo · Changelog

Release Notes

5.2.6 (from changelog)

More info than we can show here.

5.2.5 (from changelog)

More info than we can show here.

5.2.4.6 (from changelog)

More info than we can show here.

5.2.4.5 (from changelog)

More info than we can show here.

5.2.4.4 (from changelog)

More info than we can show here.

5.2.4.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ activerecord (indirect, 5.2.4.2 → 5.2.6) · Repo · Changelog

Security Advisories 🚨

🚨 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

Release Notes

5.2.6 (from changelog)

More info than we can show here.

5.2.5 (from changelog)

More info than we can show here.

5.2.4.6 (from changelog)

More info than we can show here.

5.2.4.5 (from changelog)

More info than we can show here.

5.2.4.4 (from changelog)

More info than we can show here.

5.2.4.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ activestorage (indirect, 5.2.4.2 → 5.2.6) · Repo · Changelog

Security Advisories 🚨

🚨 Circumvention of file size limits in ActiveStorage

There is a vulnerability in ActiveStorage's S3 adapter that allows the Content-Length of a
direct file upload to be modified by an end user.

Versions Affected: rails < 5.2.4.2, rails < 6.0.3.1
Not affected: Applications that do not use the direct upload functionality of the ActiveStorage S3 adapter.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Utilizing this vulnerability, an attacker can control the Content-Length of an S3 direct upload URL without receiving a
new signature from the server. This could be used to bypass controls in place on the server to limit upload size.

Workarounds

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

Release Notes

5.2.6 (from changelog)

More info than we can show here.

5.2.5 (from changelog)

More info than we can show here.

5.2.4.6 (from changelog)

More info than we can show here.

5.2.4.5 (from changelog)

More info than we can show here.

5.2.4.4 (from changelog)

More info than we can show here.

5.2.4.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ activesupport (indirect, 5.2.4.2 → 5.2.6) · Repo · Changelog

Security Advisories 🚨

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

Release Notes

5.2.6 (from changelog)

More info than we can show here.

5.2.5 (from changelog)

More info than we can show here.

5.2.4.6 (from changelog)

More info than we can show here.

5.2.4.5 (from changelog)

More info than we can show here.

5.2.4.4 (from changelog)

More info than we can show here.

5.2.4.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ concurrent-ruby (indirect, 1.1.6 → 1.1.8) · Repo · Changelog

Release Notes

1.1.8 (from changelog)

More info than we can show here.

1.1.7 (from changelog)

More info than we can show here.

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

Commits

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

↗️ erubi (indirect, 1.9.0 → 1.10.0) · Repo · Changelog

Release Notes

1.10.0 (from changelog)

More info than we can show here.

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

Commits

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

↗️ i18n (indirect, 1.8.2 → 1.8.10) · Repo · Changelog

Release Notes

1.8.10

More info than we can show here.

1.8.9

More info than we can show here.

1.8.8

More info than we can show here.

1.8.7

More info than we can show here.

1.8.6

More info than we can show here.

1.8.4

More info than we can show here.

1.8.3

More info than we can show here.

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

Commits

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

↗️ loofah (indirect, 2.4.0 → 2.9.1) · Repo · Changelog

Release Notes

2.9.1

More info than we can show here.

2.9.0

More info than we can show here.

2.8.0

More info than we can show here.

2.7.0

More info than we can show here.

2.6.0 (from changelog)

More info than we can show here.

2.5.0 (from changelog)

More info than we can show here.

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

Commits

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

↗️ marcel (indirect, 0.3.3 → 1.0.1) · Repo

Release Notes

1.0.1

More info than we can show here.

1.0.0

More info than we can show here.

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

Commits

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

↗️ mini_mime (indirect, 1.0.2 → 1.1.0) · Repo · Changelog

Commits

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

↗️ mini_portile2 (indirect, 2.4.0 → 2.5.1) · Repo · Changelog

Release Notes

2.5.1

More info than we can show here.

2.5.0

More info than we can show here.

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

Commits

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

↗️ minitest (indirect, 5.14.0 → 5.14.4) · Repo · Changelog

Release Notes

5.14.4 (from changelog)

More info than we can show here.

5.14.3 (from changelog)

More info than we can show here.

5.14.2 (from changelog)

More info than we can show here.

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

Commits

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

↗️ nio4r (indirect, 2.5.2 → 2.5.7) · Repo · Changelog

Release Notes

2.5.4 (from changelog)

More info than we can show here.

2.5.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ nokogiri (indirect, 1.10.9 → 1.11.3) · Repo · Changelog

Security Advisories 🚨

🚨 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)
Release Notes

1.11.3

More info than we can show here.

1.11.2

More info than we can show here.

1.11.1

More info than we can show here.

1.11.0

More info than we can show here.

1.10.10

More info than we can show here.

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

Commits

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

↗️ rack (indirect, 2.2.2 → 2.2.3) · Repo · Changelog

Security Advisories 🚨

🚨 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
Commits

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

↗️ railties (indirect, 5.2.4.2 → 5.2.6) · Repo · Changelog

Release Notes

5.2.6 (from changelog)

More info than we can show here.

5.2.5 (from changelog)

More info than we can show here.

5.2.4.6 (from changelog)

More info than we can show here.

5.2.4.5 (from changelog)

More info than we can show here.

5.2.4.4 (from changelog)

More info than we can show here.

5.2.4.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ rake (indirect, 13.0.1 → 13.0.3) · Repo · Changelog

Release Notes

13.0.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ sprockets-rails (indirect, 3.2.1 → 3.2.2) · Repo · Changelog

Release Notes

3.2.2

More info than we can show here.

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

Commits

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

↗️ thor (indirect, 1.0.1 → 1.1.0) · Repo · Changelog

Release Notes

1.1.0 (from changelog)

More info than we can show here.

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

Commits

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

↗️ tzinfo (indirect, 1.2.6 → 1.2.9) · Repo · Changelog

Release Notes

1.2.9

More info than we can show here.

1.2.8

More info than we can show here.

1.2.7

More info than we can show here.

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

Commits

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

↗️ websocket-driver (indirect, 0.7.1 → 0.7.3) · Repo · Changelog

Release Notes

0.7.3 (from changelog)

More info than we can show here.

0.7.2 (from changelog)

More info than we can show here.

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

Commits

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

↗️ websocket-extensions (indirect, 0.1.4 → 0.1.5) · Repo · Changelog

Security Advisories 🚨

🚨 Regular Expression Denial of Service in websocket-extensions (RubyGem)

Impact

The ReDoS flaw allows an attacker to exhaust the server's capacity to process
incoming requests by sending a WebSocket handshake request containing a header
of the following form:

Sec-WebSocket-Extensions: a; b="\c\c\c\c\c\c\c\c\c\c ...

That is, a header containing an unclosed string parameter value whose content is
a repeating two-byte sequence of a backslash and some other character. The
parser takes exponential time to reject this header as invalid, and this will
block the processing of any other work on the same thread. Thus if you are
running a single-threaded server, such a request can render your service
completely unavailable.

Workarounds

There are no known work-arounds other than disabling any public-facing WebSocket functionality you are operating.

Release Notes

0.1.5 (from changelog)

More info than we can show here.

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

Commits

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

🆕 racc (added, 1.5.2)

🗑️ mimemagic (removed)

Depfu Status

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands
@​depfu rebase
Rebases against your default branch and redoes this update
@​depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@​depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@​depfu close
Closes this PR and deletes the branch
@​depfu reopen
Restores the branch and reopens this PR (if it's closed)
@​depfu pause
Ignores all future updates for this dependency and closes this PR
@​depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@​depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)

@depfu depfu bot added the depfu label May 6, 2021
This was referenced May 6, 2021
Closed
Closed
@depfu
Copy link
Contributor Author

depfu bot commented Feb 11, 2022

Closed in favor of #253.

@depfu depfu bot closed this Feb 11, 2022
@depfu depfu bot deleted the depfu/update/group/rails-5.2.6 branch February 11, 2022 23:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

depfu

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants