2024-03-26T23:28:25+00:00https://rubysec.com/Jekyllhttps://rubysec.com/advisories/CVE-2024-290342024-03-25T00:00:00+00:00https://rubysec.com/advisories/CVE-2024-272812024-03-21T00:00:00+00:00= 6.6.3.1"` to your `Gemfile`.
Note: 6.3.4, 6.4.1, 6.5.1 and 6.6.3 have a incorrect fix. We recommend to
upgrade 6.3.4.1, 6.4.1.1, 6.5.1.1 and 6.6.3.1 instead of them.
]]>https://rubysec.com/advisories/CVE-2024-272802024-03-21T00:00:00+00:00= 3.0.1.2"` to your `Gemfile`.
]]>https://rubysec.com/advisories/GHSA-vcc3-rw6f-jv972024-03-18T00:00:00+00:00 When using the XML Reader interface with DTD validation and
> XInclude expansion enabled, processing crafted XML documents
> can lead to an xmlValidatePopElement use-after-free.
### Mitigation
Upgrade to Nokogiri `~> 1.15.6` or `>= 1.16.2`.
Users who are unable to upgrade Nokogiri may also choose a more
complicated mitigation: compile and link Nokogiri against patched
external libxml2 libraries which will also address these same issues.
]]>https://rubysec.com/advisories/CVE-2024-288622024-03-18T00:00:00+00:00https://rubysec.com/advisories/CVE-2024-281812024-03-15T00:00:00+00:00https://rubysec.com/advisories/CVE-2024-281992024-03-12T00:00:00+00:00` tag with an `href` attribute set to a
user-provided link, that link could potentially execute JavaScript
when clicked by another user.
```ruby
a(href: user_profile) { "Profile" }
```
If you splat user-provided attributes when rendering any HTML or
SVG tag, malicious event attributes could be included in the output,
executing JavaScript when the events are triggered by another user.
```ruby
h1(**JSON.parse(user_attributes))
```
### Patches
Patches are [available on RubyGems](https://rubygems.org/gems/phlex)
for all `1.x` minor versions. The patched versions are:
- [1.9.1](https://rubygems.org/gems/phlex/versions/1.9.1)
- [1.8.2](https://rubygems.org/gems/phlex/versions/1.8.2)
- [1.7.1](https://rubygems.org/gems/phlex/versions/1.7.1)
- [1.6.2](https://rubygems.org/gems/phlex/versions/1.6.2)
- [1.5.2](https://rubygems.org/gems/phlex/versions/1.5.2)
- [1.4.1](https://rubygems.org/gems/phlex/versions/1.4.1)
- [1.3.3](https://rubygems.org/gems/phlex/versions/1.3.3)
- [1.2.2](https://rubygems.org/gems/phlex/versions/1.2.2)
- [1.1.1](https://rubygems.org/gems/phlex/versions/1.1.1)
- [1.0.1](https://rubygems.org/gems/phlex/versions/1.0.1)
If you are on `main`, it has been patched since
[`aa50c60`](https://github.com/phlex-ruby/phlex/commit/aa50c604cdee1d0ce7ef068a4c66cbd5d43f96a1)
### Workarounds
Configuring a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)
that does not allow [`unsafe-inline`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline)
would effectively prevent this vulnerability from being exploited.
### References
In addition to upgrading to a patched version of Phlex, we strongly
recommend configuring a Content Security Policy header that does not
allow `unsafe-inline`. Here’s how you can configure a Content Security
Policy header in Rails.
https://guides.rubyonrails.org/security.html#content-security-policy-header
]]>https://rubysec.com/advisories/CVE-2024-281212024-03-12T00:00:00+00:00= required_params.size && arguments.size <= required_params.size + optional_params.size
reflex.public_send(method_name, *arguments)
end
```
This is problematic as `reflex.method(method_name)` can be more methods than those explicitly specified by the developer in their reflex class. A good example is the `instance_variable_set` method.
```json
{
"target": "StimulusReflex::Reflex#render_collection",
"args": [
{ "inline": "<% system('[command here]') %>" }
]
}
```
### Patches
Patches are available on [RubyGems] and on [NPM].
[RubyGems]: https://rubygems.org/gems/stimulus_reflex
[NPM]: https://npmjs.org/package/stimulus_reflex
The patched versions are:
- [`3.4.2`](https://github.com/stimulusreflex/stimulus_reflex/releases/tag/v3.4.2)
- [`3.5.0.rc4`](https://github.com/stimulusreflex/stimulus_reflex/releases/tag/v3.5.0.rc4)
### Workaround
You can add this guard to mitigate the issue if running an unpatched
version of the library.
1.) Make sure all your reflexes inherit from the `ApplicationReflex`
class
2.) Add this `before_reflex` callback to your `app/reflexes/application_reflex.rb` file:
```ruby
class ApplicationReflex < StimulusReflex::Reflex
before_reflex do
ancestors = self.class.ancestors[0..self.class.ancestors.index(StimulusReflex::Reflex) - 1]
allowed = ancestors.any? { |a| a.public_instance_methods(false).any?(method_name.to_sym) }
raise ArgumentError.new("Reflex method '#{method_name}' is not defined on class '#{self.class.name}' or on any of its ancestors") if !allowed
end
end
```
]]>https://rubysec.com/advisories/CVE-2023-517742024-02-29T00:00:00+00:00https://rubysec.com/advisories/CVE-2024-272852024-02-28T00:00:00+00:00
var match = unescape(window.location.hash).match(/^#!(.+)/);
var name = match ? match[1] : '<%= url_for_main %>';
name = name.replace(/^(\w+):\/\//, '').replace(/^\/\//, '');
window.top.location = name;
```
(v0.9.35)
```erb
```
### PoC (Proof of Concept)
To exploit this vulnerability:
1. Gain access to the generated Yard Doc.
2. Locate and access the "frames.html" file.
3. Construct a URL containing the malicious payload in the hash
segment, for instance: `#!javascript:xss` for v0.9.34, and
`#:javascript:xss` for v0.9.35
### Impact
This XSS vulnerability presents a substantial threat by enabling
an attacker to execute arbitrary JavaScript code within the user's
session context. Potential ramifications include session hijacking,
theft of sensitive data, unauthorized access to user accounts, and
defacement of websites. Any user visiting the compromised page is
susceptible to exploitation. It is critical to promptly address
this vulnerability to mitigate potential harm to users and preserve
the application's integrity.
]]>https://rubysec.com/advisories/CVE-2024-274562024-02-26T00:00:00+00:00https://rubysec.com/advisories/CVE-2024-261462024-02-21T00:00:00+00:00https://rubysec.com/advisories/CVE-2024-261442024-02-21T00:00:00+00:00= 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.
]]>https://rubysec.com/advisories/CVE-2024-261432024-02-21T00:00:00+00:00= 7.0.0
Not affected: < 7.0.0
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.
]]>https://rubysec.com/advisories/CVE-2024-261422024-02-21T00:00:00+00:00= 7.1.0, < 7.1.3.1 Not affected: < 7.1.0 Fixed Versions: 7.1.3.1
# Impact
Carefully crafted Accept headers can cause Accept header parsing in
Action Dispatch to take an unexpected amount of time, possibly resulting in a
DoS vulnerability. All users running an affected release should either upgrade
or use one of the workarounds immediately.
Ruby 3.2 has mitigations for this problem, so Rails 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.
]]>https://rubysec.com/advisories/CVE-2024-261412024-02-21T00:00:00+00:00= 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.
]]>https://rubysec.com/advisories/CVE-2024-251262024-02-21T00:00:00+00:00= 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.
]]>https://rubysec.com/advisories/CVE-2023-514472024-02-20T00:00:00+00:00` if they know how to craft these requests themselves. And then enter the returned blob ID to the form inputs manually by modifying the edit page source.
Therefore, anywhere we display these strings, we should properly escape them.
### Patches
PR #11612 fixes this problem both for 0.28.dev and 0.27.x.
### Workarounds
Disable dynamic uploads for the instance, e.g. from proposals.
### References
OWASP ASVS v4.0.3-5.1.3
### Credits
This issue was discovered in City of Helsinki's security audit against Decidim 0.27 done during September 2023. The security audit was implemented by [Deloitte Finland](https://www2.deloitte.com/fi/fi.html).
]]>https://rubysec.com/advisories/CVE-2023-482202024-02-20T00:00:00+00:00 `invite_for`: The period the generated invitation token is valid. After this period, the invited resource won’t be able to accept the invitation. When `invite_for` is `0` (the default), the invitation won’t expire.
Decidim sets this configuration to `2.weeks` so this configuration should be respected:
https://github.com/decidim/decidim/blob/d2d390578050772d1bdb6d731395f1afc39dcbfc/decidim-core/config/initializers/devise.rb#L134
The bug is in the `devise_invitable` gem and should be fixed there and the dependency should be upgraded in Decidim once the fix becomes available.
### Patches
Update `devise_invitable` to version `2.0.9` or above by running the following command:
```
$ bundle update devise_invitable
```
### Workarounds
The invitations can be cancelled directly from the database by running the following command from the Rails console:
```
> Decidim::User.invitation_not_accepted.update_all(invitation_token: nil)
```
### References
OWASP ASVS V4.0.3-2.3.1
This bug has existed in the `devise_invitable` gem since this commit which was first included in the `v0.4.rc3` release of this gem:
https://github.com/scambra/devise_invitable/commit/94d859c7de0829bf63f679ae5dd3cab2b866a098
All versions since then are affected.
This gem was first introduced at its version `~> 1.7.0` to the `decidim-admin` gem in this commit which was first included in the `v0.0.1.alpha3` release of Decidim:
https://github.com/decidim/decidim/commit/073e60e2e4224dd81815a784002ebba30f2ebb34
It was first introduced at its version `~> 1.7.0` to the `decidim-system` gem in this commit which was also first included in the `v0.0.1.alpha3` release of Decidim:
https://github.com/decidim/decidim/commit/b12800717a689c295a9ea680a38ca9f823d2c454
### Credits
This issue was discovered in City of Helsinki's security audit against Decidim 0.27 done during September 2023. The security audit was implemented by [Deloitte Finland](https://www2.deloitte.com/fi/fi.html).
]]>https://rubysec.com/advisories/CVE-2023-476352024-02-20T00:00:00+00:00