deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-wgx6-g857-jjf7
Package: openc3 (RUBYGEMS)
Severity: HIGH (CVSS 8.1)
CWE: CWE-620: Unverified Password Change
Vulnerable versions: < 6.10.5
Patched in: 6.10.5

Summary: OpenC3 COSMOS: Hijacked session token can be used to reset password for persistence

Details:
### Summary
The OpenC3 password change functionality allows a user to change their password without providing the old password, by accepting a valid session token instead. In assumed breach scenarios, this behaviour can be exploited by an attacker who has already obtained a valid session token, to gain persistence in hijacked account (including admin) and prevent legitimate users from accessing the account.

### Details
The design flaw in authentication model ([authentication.rb](https://github.com/OpenC3/cosmos/blob/397abec0d57972881a2e8dc10902d0dce9c27f42/openc3/lib/openc3/utilities/authentication.rb)) allows for interchangeable use of password and session tokens for user authentication As old tokens are not revoked upon password reset, an attacker who has obtained a valid session token can continue to authenticate and change the account’s password even after the victim resets it, thereby maintaining persistent control over the compromised account.

### PoC
1. Attacker is logged in user account with hijacked valid session token, but not knowing the actual password
2. Legitimate user, as preventive action, changes his password (_password123_) using old password (_password_), that he knows, then establishes new session
3. Attacker issues another password change request (in web proxy like Burp) supplying his still valid token as _old_password_, changing it to attacker-password, from this point preventing any other legitimate users from accessing account
<img width="912" height="479" alt="image" src="https://github.com/user-attachments/assets/d27b5980-0326-40f8-bb39-657d7b1c95a0" />
<img width="923" height="423" alt="image" src="https://github.com/user-attachments/assets/060d9fe1-637e-4a2d-9[PII_REDACTED]4ea28" />

### Impact
Persistence of an attacker who obtained valid session token and preventing legitimate users from account access
GitHub Security Advisory: GHSA-3jfp-46x4-xgfj
Package: yard (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.9.42
Patched in: 0.9.42

Summary: yard: Possible arbitrary path traversal and file access via yard server

Details:
### Impact

A path traversal vulnerability was discovered in YARD <= 0.9.41 when using yard server to serve documentation. This bug would allow unsanitized HTTP requests to access arbitrary files on the machine of a yard server host under certain conditions.

The original patch in [GHSA-xfhh-rx56-rxcr](https://github.com/lsegal/yard/security/advisories/GHSA-xfhh-rx56-rxcr) was incorrectly applied.

### Patches

Please upgrade to YARD v0.9.42 immediately if you are relying on yard server to host documentation in any untrusted environments without WEBrick and rely on `--docroot`.

### Workarounds

For users who cannot upgrade, it is possible to perform path sanitization of HTTP requests at your webserver level. WEBrick, for example, can perform such sanitization by default (which you can use via yard server -s webrick), as can certain rules in your webserver configuration.
GitHub Security Advisory: GHSA-6wpv-cj6x-v3jw
Package: http (RUBYGEMS)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 0.6.4
Patched in: 0.6.4

Summary: http vulnerable to Exposure of Sensitive Information to an Unauthorized Actor

Details:
The Ruby http gem before 0.6.4 and 0.7.3 does not verify hostnames in SSL connections, which might allow remote attackers to obtain sensitive information via a man-in-the-middle-attack.
GitHub Security Advisory: GHSA-6wpv-cj6x-v3jw
Package: http (RUBYGEMS)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 0.7.0, < 0.7.3
Patched in: 0.7.3

Summary: http vulnerable to Exposure of Sensitive Information to an Unauthorized Actor

Details:
The Ruby http gem before 0.6.4 and 0.7.3 does not verify hostnames in SSL connections, which might allow remote attackers to obtain sensitive information via a man-in-the-middle-attack.
GitHub Security Advisory: GHSA-g857-hhfv-j68w
Package: zlib (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: < 3.0.1
Patched in: 3.0.1

Summary: Buffer Overflow in Zlib::GzipReader ungetc via large input leads to memory corruption

Details:
### Details

A buffer overflow vulnerability exists in `Zlib::GzipReader`.

The `zstream_buffer_ungets` function prepends caller-provided bytes ahead of previously produced output but fails to guarantee the backing Ruby string has enough capacity before the memmove shifts the existing data. This can lead to memory corruption when the buffer length exceeds capacity.

### Recommended action

We recommend to update the `zlib` gem to version 3.2.3 or later. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead:

* For Ruby 3.2 users: Update to zlib 3.0.1
* For Ruby 3.3 users: Update to zlib 3.1.2

You can use gem update zlib to update it. If you are using bundler, please add `gem "zlib", ">= 3.2.3"` to your Gemfile.

### Affected versions

zlib gem 3.2.2 or lower

### Credits

[calysteon](https://hackerone.com/calysteon)

### References

* https://hackerone.com/reports/3467067
GitHub Security Advisory: GHSA-g857-hhfv-j68w
Package: zlib (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: >= 3.1.0, < 3.1.2
Patched in: 3.1.2

Summary: Buffer Overflow in Zlib::GzipReader ungetc via large input leads to memory corruption

Details:
### Details

A buffer overflow vulnerability exists in `Zlib::GzipReader`.

The `zstream_buffer_ungets` function prepends caller-provided bytes ahead of previously produced output but fails to guarantee the backing Ruby string has enough capacity before the memmove shifts the existing data. This can lead to memory corruption when the buffer length exceeds capacity.

### Recommended action

We recommend to update the `zlib` gem to version 3.2.3 or later. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead:

* For Ruby 3.2 users: Update to zlib 3.0.1
* For Ruby 3.3 users: Update to zlib 3.1.2

You can use gem update zlib to update it. If you are using bundler, please add `gem "zlib", ">= 3.2.3"` to your Gemfile.

### Affected versions

zlib gem 3.2.2 or lower

### Credits

[calysteon](https://hackerone.com/calysteon)

### References

* https://hackerone.com/reports/3467067
GitHub Security Advisory: GHSA-g857-hhfv-j68w
Package: zlib (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: >= 3.2.0, < 3.2.3
Patched in: 3.2.3

Summary: Buffer Overflow in Zlib::GzipReader ungetc via large input leads to memory corruption

Details:
### Details

A buffer overflow vulnerability exists in `Zlib::GzipReader`.

The `zstream_buffer_ungets` function prepends caller-provided bytes ahead of previously produced output but fails to guarantee the backing Ruby string has enough capacity before the memmove shifts the existing data. This can lead to memory corruption when the buffer length exceeds capacity.

### Recommended action

We recommend to update the `zlib` gem to version 3.2.3 or later. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead:

* For Ruby 3.2 users: Update to zlib 3.0.1
* For Ruby 3.3 users: Update to zlib 3.1.2

You can use gem update zlib to update it. If you are using bundler, please add `gem "zlib", ">= 3.2.3"` to your Gemfile.

### Affected versions

zlib gem 3.2.2 or lower

### Credits

[calysteon](https://hackerone.com/calysteon)

### References

* https://hackerone.com/reports/3467067
GitHub Security Advisory: GHSA-ghmh-q25g-gxxx
Package: decidim-api (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 0.0.1, < 0.30.5
Patched in: 0.30.5

Summary: Decidim's comments API allows access to all commentable resources

Details:
### Impact
The root level `commentable` field in the API allows access to all commentable resources within the platform, without any permission checks. All Decidim instances are impacted that have not secured the `/api` endpoint. The `/api` endpoint is publicly available with the default configuration.

### Patches
Not available

### Workarounds
To mitigate the issue, you can limit the scope to only authenticated users by limiting access to the `/api` endpoint. This would require custom code or installing the 3rd party module `Decidim::Apiauth`.

With custom code, the `/api` endpoint can be limited to only authenticated users with the following code (needs to run during application initialization):

```ruby
# Within your application
# config/initializers/limit_api_access.rb

module LimitApiAccess
  extend ActiveSupport::Concern

  included do
    prepend_before_action do |controller|
      unless controller.send(:user_signed_in?)
        render plain: I18n.t("actions.login_before_access", scope: "decidim.core"), status: :unauthorized
      end
    end
  end
end

Rails.application.config.to_prepare do
  Decidim::Api::ApplicationController.include(LimitApiAccess)
end
```

Please note that this would only disable public access to the API and all authenticated users would be still able to exploit the vulnerability. This may be sufficient for some installations, but not for all.

Another workaround is to limit the availability of the `/api` endpoint to only trusted ranges of IPs that need to access the API. The following Nginx configuration would help limiting the API access to only specific IPs:

```
location /api {
  allow 192.168.1.100;
  allow 192.168.1.101;
  deny all;
}
```

The same configuration can be also used without the `allow` statements to disable all traffic to the the `/api` endpoint.

When considering a workaround and the seriousness of the vulnerability, please consider the nature of the platform. If the platform is primarily serving public data, this vulnerability is not serious by its nature. If the platform is protecting some resources, e.g. inside private participation spaces, the vulnerability may expose some data to the attacker that is not meant public.

If you have enabled the organization setting "Force users to authenticate before access organization", the scope of this vulnerability is limited to the users who are allowed to log in to the Decidim platform. This setting was introduced in version 0.19.0 and it was applied to the `/api` endpoint in version 0.22.0.
GitHub Security Advisory: GHSA-ghmh-q25g-gxxx
Package: decidim-comments (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 0.0.1, < 0.30.5
Patched in: 0.30.5

Summary: Decidim's comments API allows access to all commentable resources

Details:
### Impact
The root level `commentable` field in the API allows access to all commentable resources within the platform, without any permission checks. All Decidim instances are impacted that have not secured the `/api` endpoint. The `/api` endpoint is publicly available with the default configuration.

### Patches
Not available

### Workarounds
To mitigate the issue, you can limit the scope to only authenticated users by limiting access to the `/api` endpoint. This would require custom code or installing the 3rd party module `Decidim::Apiauth`.

With custom code, the `/api` endpoint can be limited to only authenticated users with the following code (needs to run during application initialization):

```ruby
# Within your application
# config/initializers/limit_api_access.rb

module LimitApiAccess
  extend ActiveSupport::Concern

  included do
    prepend_before_action do |controller|
      unless controller.send(:user_signed_in?)
        render plain: I18n.t("actions.login_before_access", scope: "decidim.core"), status: :unauthorized
      end
    end
  end
end

Rails.application.config.to_prepare do
  Decidim::Api::ApplicationController.include(LimitApiAccess)
end
```

Please note that this would only disable public access to the API and all authenticated users would be still able to exploit the vulnerability. This may be sufficient for some installations, but not for all.

Another workaround is to limit the availability of the `/api` endpoint to only trusted ranges of IPs that need to access the API. The following Nginx configuration would help limiting the API access to only specific IPs:

```
location /api {
  allow 192.168.1.100;
  allow 192.168.1.101;
  deny all;
}
```

The same configuration can be also used without the `allow` statements to disable all traffic to the the `/api` endpoint.

When considering a workaround and the seriousness of the vulnerability, please consider the nature of the platform. If the platform is primarily serving public data, this vulnerability is not serious by its nature. If the platform is protecting some resources, e.g. inside private participation spaces, the vulnerability may expose some data to the attacker that is not meant public.

If you have enabled the organization setting "Force users to authenticate before access organization", the scope of this vulnerability is limited to the users who are allowed to log in to the Decidim platform. This setting was introduced in version 0.19.0 and it was applied to the `/api` endpoint in version 0.22.0.
GitHub Security Advisory: GHSA-ghmh-q25g-gxxx
Package: decidim-api (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-862: Missing Authorization
Vulnerable versions: > 0.31.0.rc1, < 0.31.1
Patched in: 0.31.1

Summary: Decidim's comments API allows access to all commentable resources

Details:
### Impact
The root level `commentable` field in the API allows access to all commentable resources within the platform, without any permission checks. All Decidim instances are impacted that have not secured the `/api` endpoint. The `/api` endpoint is publicly available with the default configuration.

### Patches
Not available

### Workarounds
To mitigate the issue, you can limit the scope to only authenticated users by limiting access to the `/api` endpoint. This would require custom code or installing the 3rd party module `Decidim::Apiauth`.

With custom code, the `/api` endpoint can be limited to only authenticated users with the following code (needs to run during application initialization):

```ruby
# Within your application
# config/initializers/limit_api_access.rb

module LimitApiAccess
  extend ActiveSupport::Concern

  included do
    prepend_before_action do |controller|
      unless controller.send(:user_signed_in?)
        render plain: I18n.t("actions.login_before_access", scope: "decidim.core"), status: :unauthorized
      end
    end
  end
end

Rails.application.config.to_prepare do
  Decidim::Api::ApplicationController.include(LimitApiAccess)
end
```

Please note that this would only disable public access to the API and all authenticated users would be still able to exploit the vulnerability. This may be sufficient for some installations, but not for all.

Another workaround is to limit the availability of the `/api` endpoint to only trusted ranges of IPs that need to access the API. The following Nginx configuration would help limiting the API access to only specific IPs:

```
location /api {
  allow 192.168.1.100;
  allow 192.168.1.101;
  deny all;
}
```

The same configuration can be also used without the `allow` statements to disable all traffic to the the `/api` endpoint.

When considering a workaround and the seriousness of the vulnerability, please consider the nature of the platform. If the platform is primarily serving public data, this vulnerability is not serious by its nature. If the platform is protecting some resources, e.g. inside private participation spaces, the vulnerability may expose some data to the attacker that is not meant public.

If you have enabled the organization setting "Force users to authenticate before access organization", the scope of this vulnerability is limited to the users who are allowed to log in to the Decidim platform. This setting was introduced in version 0.19.0 and it was applied to the `/api` endpoint in version 0.22.0.
GitHub Security Advisory: GHSA-ghmh-q25g-gxxx
Package: decidim-comments (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-862: Missing Authorization
Vulnerable versions: > 0.31.0.rc1, < 0.31.1
Patched in: 0.31.1

Summary: Decidim's comments API allows access to all commentable resources

Details:
### Impact
The root level `commentable` field in the API allows access to all commentable resources within the platform, without any permission checks. All Decidim instances are impacted that have not secured the `/api` endpoint. The `/api` endpoint is publicly available with the default configuration.

### Patches
Not available

### Workarounds
To mitigate the issue, you can limit the scope to only authenticated users by limiting access to the `/api` endpoint. This would require custom code or installing the 3rd party module `Decidim::Apiauth`.

With custom code, the `/api` endpoint can be limited to only authenticated users with the following code (needs to run during application initialization):

```ruby
# Within your application
# config/initializers/limit_api_access.rb

module LimitApiAccess
  extend ActiveSupport::Concern

  included do
    prepend_before_action do |controller|
      unless controller.send(:user_signed_in?)
        render plain: I18n.t("actions.login_before_access", scope: "decidim.core"), status: :unauthorized
      end
    end
  end
end

Rails.application.config.to_prepare do
  Decidim::Api::ApplicationController.include(LimitApiAccess)
end
```

Please note that this would only disable public access to the API and all authenticated users would be still able to exploit the vulnerability. This may be sufficient for some installations, but not for all.

Another workaround is to limit the availability of the `/api` endpoint to only trusted ranges of IPs that need to access the API. The following Nginx configuration would help limiting the API access to only specific IPs:

```
location /api {
  allow 192.168.1.100;
  allow 192.168.1.101;
  deny all;
}
```

The same configuration can be also used without the `allow` statements to disable all traffic to the the `/api` endpoint.

When considering a workaround and the seriousness of the vulnerability, please consider the nature of the platform. If the platform is primarily serving public data, this vulnerability is not serious by its nature. If the platform is protecting some resources, e.g. inside private participation spaces, the vulnerability may expose some data to the attacker that is not meant public.

If you have enabled the organization setting "Force users to authenticate before access organization", the scope of this vulnerability is limited to the users who are allowed to log in to the Decidim platform. This setting was introduced in version 0.19.0 and it was applied to the `/api` endpoint in version 0.22.0.
GitHub Security Advisory: GHSA-w5xj-99cg-rccm
Package: decidim-core (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-266: Incorrect Privilege Assignment
Vulnerable versions: >= 0.19.0, < 0.30.5
Patched in: 0.30.5

Summary: Decidim amendments can be accepted or rejected by anyone

Details:
### Impact
The vulnerability allows any registered and authenticated user to accept or reject any amendments. The impact is on any users who have created proposals where the amendments feature is enabled. This also elevates the user accepting the amendment as the author of the original proposal as people amending proposals are provided coauthorship on the coauthorable resources.

The only check done when accepting or rejecting amendments is whether the amendment reactions are enabled for the component:
https://github.com/decidim/decidim/blob/9d6c3d2efe5a83bb02e095824ff5998d96a75eb7/decidim-core/app/permissions/decidim/permissions.rb#L107

The permission checks have been changed at 1b99136 which was introduced in released version 0.19.0. I have not investigated whether prior versions are also affected.

### Patches

Not available

### Workarounds
Disable amendment reactions for the amendable component (e.g. proposals).
GitHub Security Advisory: GHSA-w5xj-99cg-rccm
Package: decidim-core (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-266: Incorrect Privilege Assignment
Vulnerable versions: >= 0.31.0.rc1, < 0.31.1
Patched in: 0.31.1

Summary: Decidim amendments can be accepted or rejected by anyone

Details:
### Impact
The vulnerability allows any registered and authenticated user to accept or reject any amendments. The impact is on any users who have created proposals where the amendments feature is enabled. This also elevates the user accepting the amendment as the author of the original proposal as people amending proposals are provided coauthorship on the coauthorable resources.

The only check done when accepting or rejecting amendments is whether the amendment reactions are enabled for the component:
https://github.com/decidim/decidim/blob/9d6c3d2efe5a83bb02e095824ff5998d96a75eb7/decidim-core/app/permissions/decidim/permissions.rb#L107

The permission checks have been changed at 1b99136 which was introduced in released version 0.19.0. I have not investigated whether prior versions are also affected.

### Patches

Not available

### Workarounds
Disable amendment reactions for the amendable component (e.g. proposals).
GitHub Security Advisory: GHSA-9pm8-vwc5-w2hm
Package: fat_free_crm (RUBYGEMS)
Severity: LOW (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 0.26.0
Patched in: 0.26.0

Summary: Fat Free CRM has BOLA in DELETE /emails/:id - Any authenticated user can hit this endpoint and delete emails by ID

Details:
### Impact

Authenticated users can delete emails imported into the system assigned to another user; where the [Email Dropbox](https://github.com/fatfreecrm/fat_free_crm/wiki/Email-Dropbox) is in use.

### Patches

Fixed in v0.26.0

### Workarounds

Disable use of email dropbox.
GitHub Security Advisory: GHSA-fc46-r95f-hq7g
Package: decidim-core (RUBYGEMS)
Severity: CRITICAL (CVSS 8.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.30.5
Patched in: 0.30.5

Summary: Decidim has a cross-site scripting (XSS) in user name

Details:
### Impact
A stored code execution vulnerability in the user name field allows a low-privileged attacker to execute arbitrary code in the context of any user who passively visits a comment page, resulting in high confidentiality and integrity impact across security boundaries.

### Patches
N/A

### Workarounds
Not available

### References
OWASP ASVS v4.0.3-5.1.3

### Credits
This issue was discovered in a security audit organized by [octree](https://octree.ch/) and made by [Secu Labs](https://seculabs.ch/) against Decidim financed by the city of Lausanne (Switzerland).
GitHub Security Advisory: GHSA-fc46-r95f-hq7g
Package: decidim-core (RUBYGEMS)
Severity: CRITICAL (CVSS 8.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 0.31.0.rc1, < 0.31.0
Patched in: 0.31.1

Summary: Decidim has a cross-site scripting (XSS) in user name

Details:
### Impact
A stored code execution vulnerability in the user name field allows a low-privileged attacker to execute arbitrary code in the context of any user who passively visits a comment page, resulting in high confidentiality and integrity impact across security boundaries.

### Patches
N/A

### Workarounds
Not available

### References
OWASP ASVS v4.0.3-5.1.3

### Credits
This issue was discovered in a security audit organized by [octree](https://octree.ch/) and made by [Secu Labs](https://seculabs.ch/) against Decidim financed by the city of Lausanne (Switzerland).