🚨 [security] Update activerecord 5.2.4.3 → 6.1.7.6 (major)

[depfu]

---

Welcome to Depfu 👋

This is one of the first three pull requests with dependency updates we've sent your way. We tried to start with a few easy patch-level updates. Hopefully your tests will pass and you can merge this pull request without too much risk. This should give you an idea how Depfu works in general.

After you merge your first pull request, we'll send you a few more. We'll never open more than seven PRs at the same time so you're not getting overwhelmed with updates.

Let us know if you have any questions. Thanks so much for giving Depfu a try!

---

---

🚨 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 upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ activerecord (5.2.4.3 → 6.1.7.6) · Repo · Changelog

Security Advisories 🚨

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

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

Release Notes

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

Commits

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

↗️ activemodel (indirect, 5.2.4.3 → 6.1.7.6) · Repo · Changelog

Release Notes

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

Commits

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

↗️ activesupport (indirect, 5.2.4.3 → 6.1.7.6) · Repo · Changelog

Security Advisories 🚨

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

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

Release Notes

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

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.2.2) · Repo · Changelog

Release Notes

1.2.2

More info than we can show here.

1.2.1

More info than we can show here.

1.2.0

More info than we can show here.

1.1.10

More info than we can show here.

1.1.9 (from changelog)

More info than we can show here.

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.

↗️ i18n (indirect, 1.8.3 → 1.14.1) · Repo · Changelog

Release Notes

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

Commits

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

↗️ minitest (indirect, 5.14.1 → 5.19.0) · Repo · Changelog

Release Notes

5.19.0 (from changelog)

More info than we can show here.

5.18.1 (from changelog)

More info than we can show here.

5.18.0 (from changelog)

More info than we can show here.

5.17.0 (from changelog)

More info than we can show here.

5.16.3 (from changelog)

More info than we can show here.

5.16.2 (from changelog)

More info than we can show here.

5.16.1 (from changelog)

More info than we can show here.

5.16.0 (from changelog)

More info than we can show here.

5.15.0 (from changelog)

More info than we can show here.

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.

↗️ tzinfo (indirect, 1.2.7 → 2.0.6) · Repo · Changelog

Security Advisories 🚨

🚨 TZInfo relative path traversal vulnerability allows loading of arbitrary files

Impact

Affected versions

• 0.3.60 and earlier.
• 1.0.0 to 1.2.9 when used with the Ruby data source (tzinfo-data).

Vulnerability

With the Ruby data source (the tzinfo-data gem for tzinfo version 1.0.0 and
later and built-in to earlier versions), time zones are defined in Ruby files.
There is one file per time zone. Time zone files are loaded with require on
demand. In the affected versions, TZInfo::Timezone.get fails to validate
time zone identifiers correctly, allowing a new line character within the
identifier. With Ruby version 1.9.3 and later, TZInfo::Timezone.get can be
made to load unintended files with require, executing them within the Ruby
process.

For example, with version 1.2.9, you can run the following to load a file with
path /tmp/payload.rb:

TZInfo::Timezone.get(\"foo\
/../../../../../../../../../../../../../../../../tmp/payload\")

The exact number of parent directory traversals needed will vary depending on
the location of the tzinfo-data gem.

TZInfo versions 1.2.6 to 1.2.9 can be made to load files from outside of the
Ruby load path. Versions up to and including 1.2.5 can only be made to load
files from directories within the load path.

This could be exploited in, for example, a Ruby on Rails application using
tzinfo version 1.2.9, that allows file uploads and has a time zone selector
that accepts arbitrary time zone identifiers.
The CVSS score and severity have been set on this basis.

Versions 2.0.0 and later are not vulnerable.

Patches

Versions 0.3.61 and 1.2.10 include fixes to correctly validate time zone
identifiers.

Note that version 0.3.61 can still load arbitrary files from the Ruby load
path if their name follows the rules for a valid time zone identifier and the
file has a prefix of tzinfo/definition within a directory in the load path.
For example if /tmp/upload was in the load path, then
TZInfo::Timezone.get('foo') could load a file with path
/tmp/upload/tzinfo/definition/foo.rb. Applications should ensure that
untrusted files are not placed in a directory on the load path.

Workarounds

As a workaround, the time zone identifier can be validated before passing to
TZInfo::Timezone.get by ensuring it matches the regular expression
\\A[A-Za-z0-9+\\-_]+(?:\\/[A-Za-z0-9+\\-_]+)*\\z.

Release Notes

2.0.6

More info than we can show here.

2.0.5

More info than we can show here.

2.0.4

More info than we can show here.

2.0.3

More info than we can show here.

2.0.2

More info than we can show here.

2.0.1

More info than we can show here.

2.0.0

More info than we can show here.

1.2.11

More info than we can show here.

1.2.10

More info than we can show here.

1.2.9

More info than we can show here.

1.2.8

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.

🆕 zeitwerk (added, 2.6.11)

🗑️ arel (removed)

🗑️ thread_safe (removed)

---

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 cancel merge

Cancels automatic merging of this PR

@​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)