deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-gmg5-r3c4-3fm9
Package: fat_free_crm (RUBYGEMS)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 0.19.0
Patched in: unpatched

Summary: Withdrawn Advisory: Fat Free CRM Cross-site Scripting vulnerability

Details:
## Withdrawn
This advisory has been withdrawn because the CVE has been disputed and the underlying vulnerability is likely invalid. This link is maintained to preserve external references.

[According to maintainers of Fat Free CRM](https://github.com/github/advisory-database/pull/3599), the CRM comment feature allows certain HTML markup, but santizes the output when rendered to page. This allows safe tags (such as `<h1>` which the author tested and reported as a vulnerability) but correctly disallows `<script>` tags and other dangerous entities.

## Original Description
HTML Injection has been discovered in the v0.19.0 version of the Fat Free CRM product via an authenticated request to the /comments URI.
GitHub Security Advisory: GHSA-9w99-78rj-hmxq
Package: decidim-core (RUBYGEMS)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 0.27.0, < 0.27.5
Patched in: 0.27.5

Summary: Cross-site scripting (XSS) in the dynamic file uploads

Details:
### Impact
The dynamic file upload feature is subject to potential XSS attach in case the attacker manages to modify the file names of the records being uploaded to the server.

This appears in sections where the user controls the file upload dialogs themselves and has the technical knowledge to change the file names through the dynamic upload endpoint. Therefore I believe it would require the attacker to control the whole session of the particular user but in any case, this needs to be fixed.

Successful exploit of this vulneratibility would require the user to have successfully uploaded a file blob to the server with a malicious file name and then have the possibility to direct the other user to the edit page of the record where the attachment is attached.

The users are able to craft the direct upload requests themselves controlling the file name that gets stored to the database as shown here:
https://github.com/rails/rails/blob/a967d355c6fee9ad9b8bd115d43bc8b0fc207e7e/activestorage/app/controllers/active_storage/direct_uploads_controller.rb#L14

The attacker is able to change the filename e.g. to `<svg onload=alert('XSS')>` 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).
GitHub Security Advisory: GHSA-9w99-78rj-hmxq
Package: decidim (RUBYGEMS)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 0.27.0, < 0.27.5
Patched in: 0.27.5

Summary: Cross-site scripting (XSS) in the dynamic file uploads

Details:
### Impact
The dynamic file upload feature is subject to potential XSS attach in case the attacker manages to modify the file names of the records being uploaded to the server.

This appears in sections where the user controls the file upload dialogs themselves and has the technical knowledge to change the file names through the dynamic upload endpoint. Therefore I believe it would require the attacker to control the whole session of the particular user but in any case, this needs to be fixed.

Successful exploit of this vulneratibility would require the user to have successfully uploaded a file blob to the server with a malicious file name and then have the possibility to direct the other user to the edit page of the record where the attachment is attached.

The users are able to craft the direct upload requests themselves controlling the file name that gets stored to the database as shown here:
https://github.com/rails/rails/blob/a967d355c6fee9ad9b8bd115d43bc8b0fc207e7e/activestorage/app/controllers/active_storage/direct_uploads_controller.rb#L14

The attacker is able to change the filename e.g. to `<svg onload=alert('XSS')>` 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).
GitHub Security Advisory: GHSA-w3q8-m492-4pwp
Package: decidim-system (RUBYGEMS)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: >= 0.27.0, < 0.27.5
Patched in: 0.27.5

Summary: Possibility to circumvent the invitation token expiry period

Details:
### Impact
The invites feature allows users to accept the invitation for an unlimited amount of time through the password reset functionality.

When using the password reset functionality, the `devise_invitable` gem always accepts the pending invitation if the user has been invited as shown in this piece of code within the `devise_invitable` gem:
https://github.com/scambra/devise_invitable/blob/41f58970ff76fb64382a9b9ea1bd530f7c3adab2/lib/devise_invitable/models.rb#L198

The only check done here is if the user has been invited but the code does not ensure that the pending invitation is still valid as defined by the `invite_for` expiry period as explained in the gem's documentation:
https://github.com/scambra/devise_invitable#model-configuration-

> `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/d2d[PII_REDACTED]72d1bdb6d731395f1afc39dcbfc/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).
GitHub Security Advisory: GHSA-w3q8-m492-4pwp
Package: decidim-admin (RUBYGEMS)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: >= 0.27.0, < 0.27.5
Patched in: 0.27.5

Summary: Possibility to circumvent the invitation token expiry period

Details:
### Impact
The invites feature allows users to accept the invitation for an unlimited amount of time through the password reset functionality.

When using the password reset functionality, the `devise_invitable` gem always accepts the pending invitation if the user has been invited as shown in this piece of code within the `devise_invitable` gem:
https://github.com/scambra/devise_invitable/blob/41f58970ff76fb64382a9b9ea1bd530f7c3adab2/lib/devise_invitable/models.rb#L198

The only check done here is if the user has been invited but the code does not ensure that the pending invitation is still valid as defined by the `invite_for` expiry period as explained in the gem's documentation:
https://github.com/scambra/devise_invitable#model-configuration-

> `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/d2d[PII_REDACTED]72d1bdb6d731395f1afc39dcbfc/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).
GitHub Security Advisory: GHSA-w3q8-m492-4pwp
Package: decidim (RUBYGEMS)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: >= 0.27.0, < 0.27.5
Patched in: 0.27.5

Summary: Possibility to circumvent the invitation token expiry period

Details:
### Impact
The invites feature allows users to accept the invitation for an unlimited amount of time through the password reset functionality.

When using the password reset functionality, the `devise_invitable` gem always accepts the pending invitation if the user has been invited as shown in this piece of code within the `devise_invitable` gem:
https://github.com/scambra/devise_invitable/blob/41f58970ff76fb64382a9b9ea1bd530f7c3adab2/lib/devise_invitable/models.rb#L198

The only check done here is if the user has been invited but the code does not ensure that the pending invitation is still valid as defined by the `invite_for` expiry period as explained in the gem's documentation:
https://github.com/scambra/devise_invitable#model-configuration-

> `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/d2d[PII_REDACTED]72d1bdb6d731395f1afc39dcbfc/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).
GitHub Security Advisory: GHSA-w3q8-m492-4pwp
Package: devise_invitable (RUBYGEMS)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: >= 0.4.rc3, < 2.0.9
Patched in: 2.0.9

Summary: Possibility to circumvent the invitation token expiry period

Details:
### Impact
The invites feature allows users to accept the invitation for an unlimited amount of time through the password reset functionality.

When using the password reset functionality, the `devise_invitable` gem always accepts the pending invitation if the user has been invited as shown in this piece of code within the `devise_invitable` gem:
https://github.com/scambra/devise_invitable/blob/41f58970ff76fb64382a9b9ea1bd530f7c3adab2/lib/devise_invitable/models.rb#L198

The only check done here is if the user has been invited but the code does not ensure that the pending invitation is still valid as defined by the `invite_for` expiry period as explained in the gem's documentation:
https://github.com/scambra/devise_invitable#model-configuration-

> `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/d2d[PII_REDACTED]72d1bdb6d731395f1afc39dcbfc/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).
GitHub Security Advisory: GHSA-w3q8-m492-4pwp
Package: decidim-system (RUBYGEMS)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: >= 0.0.1.alpha3, < 0.26.9
Patched in: 0.26.9

Summary: Possibility to circumvent the invitation token expiry period

Details:
### Impact
The invites feature allows users to accept the invitation for an unlimited amount of time through the password reset functionality.

When using the password reset functionality, the `devise_invitable` gem always accepts the pending invitation if the user has been invited as shown in this piece of code within the `devise_invitable` gem:
https://github.com/scambra/devise_invitable/blob/41f58970ff76fb64382a9b9ea1bd530f7c3adab2/lib/devise_invitable/models.rb#L198

The only check done here is if the user has been invited but the code does not ensure that the pending invitation is still valid as defined by the `invite_for` expiry period as explained in the gem's documentation:
https://github.com/scambra/devise_invitable#model-configuration-

> `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/d2d[PII_REDACTED]72d1bdb6d731395f1afc39dcbfc/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).
GitHub Security Advisory: GHSA-w3q8-m492-4pwp
Package: decidim-admin (RUBYGEMS)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: >= 0.0.1.alpha3, < 0.26.9
Patched in: 0.26.9

Summary: Possibility to circumvent the invitation token expiry period

Details:
### Impact
The invites feature allows users to accept the invitation for an unlimited amount of time through the password reset functionality.

When using the password reset functionality, the `devise_invitable` gem always accepts the pending invitation if the user has been invited as shown in this piece of code within the `devise_invitable` gem:
https://github.com/scambra/devise_invitable/blob/41f58970ff76fb64382a9b9ea1bd530f7c3adab2/lib/devise_invitable/models.rb#L198

The only check done here is if the user has been invited but the code does not ensure that the pending invitation is still valid as defined by the `invite_for` expiry period as explained in the gem's documentation:
https://github.com/scambra/devise_invitable#model-configuration-

> `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/d2d[PII_REDACTED]72d1bdb6d731395f1afc39dcbfc/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).