deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-4cx3-3c38-j9vv
Package: katalyst-koi (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: < 4.20.0
Patched in: 4.20.0

Summary: katalyst-koi: Session cookies can be replayed after user logout

Details:
### Impact

Admin session cookies were not invalidated when an admin user logged out. An attacker with access to a valid admin session cookie could continue to access admin functionality after logout, until the cookie expired or session secrets were rotated.

This affects applications using Koi admin authentication where an admin session cookie may have been exposed, cached, intercepted, or otherwise retained after logout.

### Patches

The issue has been patched by recording admin logout time and rejecting any admin session cookie created before the user’s most recent logout.

Users should upgrade to the patched Koi releases once available.

### Workarounds

Katalyst Koi recommends upgrading to the latest available version, or back porting the changes released in 5.6.0/4.20.0

### Resources

This is an application of https://guides.rubyonrails.org/v5.2.0/security.html#replay-attacks-for-cookiestore-sessions
GitHub Security Advisory: GHSA-v2fc-qm4h-8hqv
Package: nokogiri (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-401: Missing Release of Memory after Effective Lifetime
Vulnerable versions: < 1.19.3
Patched in: 1.19.3

Summary: Nokogiri XSLT transform has a memory leak

Details:
## Summary

Nokogiri's `Nokogiri::XSLT::Stylesheet#transform` leaks a small heap allocation when passed a Ruby string parameter containing a null byte.

For applications that pass attacker-controlled input through `XSLT.transform` parameters, this may be a vector for a denial of service attack against long-running processes.


## Mitigation

Upgrade to Nokogiri `>= 1.19.3`.

Users may also be able to mitigate this issue without upgrading by validating untrusted transform parameters before passing them to `Nokogiri::XSLT::Stylesheet#transform`.


## Severity

The Nokogiri maintainers have evaluated this as **Moderate Severity**, CVSS 5.3.

Each leaked allocation is approximately 24–32 bytes, so meaningful memory growth requires sustained attacker-controlled traffic at high call rates. The bug does not cause memory corruption, information disclosure, or any change in the behavior of the transform itself, and the string-handling exception is raised as expected.

Applications that do not pass raw attacker-controlled bytes to XSLT parameters are unlikely to be affected in practice.


## Resources

- [CWE-401: Missing Release of Memory after Effective Lifetime](https://cwe.mitre.org/data/definitions/401.html)


## Credit

This vulnerability was responsibly reported by @Captainjack-kor.
GitHub Security Advisory: GHSA-c4rq-3m3g-8wgx
Package: nokogiri (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 1.19.3
Patched in: 1.19.3

Summary: Nokogiri CSS selector tokenizer has regular expression backtracking

Details:
## Summary

Nokogiri's CSS selector tokenizer contains regular expressions whose construction may result in exponential regex backtracking on adversarial selectors. Three ReDoS vectors are addressed in this release:

1. String-literal tokenization on certain unterminated quoted-string input.
2. String-literal tokenization on a separate class of hex-escape-rich input.
3. Identifier tokenization on hex-escape-rich input.

The public CSS selector methods that funnel through the affected tokenizer are `Nokogiri::CSS.xpath_for`, `Node#css`, `Node#at_css`, `Searchable#search`, and `CSS::Parser#parse`.


## Mitigation

Upgrade to Nokogiri `>= 1.19.3`.

If users are unable to upgrade, two options are available:

- Avoid the use of attacker-controlled text in CSS selectors. Applications that only pass developer-authored selectors to Nokogiri are not directly exposed.
- Set global `Regexp.timeout` (Ruby 3.2+, JRuby 9.4+) to bound parse time.

## Severity

The Nokogiri maintainers have evaluated this as **High Severity** (CVSS 7.5, `AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`).

An attacker able to inject user-supplied text into a CSS selector parse method can cause exponential backtracking, resulting in a potential denial of service.


## Resources

- [CWE-1333: Inefficient Regular Expression Complexity](https://cwe.mitre.org/data/definitions/1333.html)


## Credit

Vector 1 was responsibly reported by @colby-swandale. Vectors 2 and 3 were discovered by @flavorjones during the response to the original report.
GitHub Security Advisory: GHSA-3h96-34p3-xm76
Package: graphql (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 2.3.1, < 2.3.23
Patched in: 2.3.23

Summary: GraphQL-Ruby's Ruby lexer does not count comment tokens for the purposes of max_query_string_tokens

Details:
GraphQL-Ruby's `max_query_string_tokens` configuration didn't count comment tokens against the limit, allowing strings to be processed even after the configured maximum had actually been reached. 

In patched versions, the Ruby lexer does count these tokens. 

GraphQL-CParser is not affected by this problem. 

`max_query_string_tokens` was introduced in v2.3.1. Each 2.x version has received a new patch release for including a fix.
GitHub Security Advisory: GHSA-3h96-34p3-xm76
Package: graphql (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 2.4.0, < 2.4.18
Patched in: 2.4.18

Summary: GraphQL-Ruby's Ruby lexer does not count comment tokens for the purposes of max_query_string_tokens

Details:
GraphQL-Ruby's `max_query_string_tokens` configuration didn't count comment tokens against the limit, allowing strings to be processed even after the configured maximum had actually been reached. 

In patched versions, the Ruby lexer does count these tokens. 

GraphQL-CParser is not affected by this problem. 

`max_query_string_tokens` was introduced in v2.3.1. Each 2.x version has received a new patch release for including a fix.
GitHub Security Advisory: GHSA-3h96-34p3-xm76
Package: graphql (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 2.5.0, < 2.5.26
Patched in: 2.5.26

Summary: GraphQL-Ruby's Ruby lexer does not count comment tokens for the purposes of max_query_string_tokens

Details:
GraphQL-Ruby's `max_query_string_tokens` configuration didn't count comment tokens against the limit, allowing strings to be processed even after the configured maximum had actually been reached. 

In patched versions, the Ruby lexer does count these tokens. 

GraphQL-CParser is not affected by this problem. 

`max_query_string_tokens` was introduced in v2.3.1. Each 2.x version has received a new patch release for including a fix.
GitHub Security Advisory: GHSA-3h96-34p3-xm76
Package: graphql (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: = 2.6.0
Patched in: 2.6.1

Summary: GraphQL-Ruby's Ruby lexer does not count comment tokens for the purposes of max_query_string_tokens

Details:
GraphQL-Ruby's `max_query_string_tokens` configuration didn't count comment tokens against the limit, allowing strings to be processed even after the configured maximum had actually been reached. 

In patched versions, the Ruby lexer does count these tokens. 

GraphQL-CParser is not affected by this problem. 

`max_query_string_tokens` was introduced in v2.3.1. Each 2.x version has received a new patch release for including a fix.
GitHub Security Advisory: GHSA-75xq-5h9v-w6px
Package: net-imap (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection'), CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
Vulnerable versions: >= 0, <= 0.4.23
Patched in: 0.4.24

Summary: net-imap vulnerable to command Injection via unvalidated Symbol inputs

Details:
### Summary

Symbol arguments to commands are vulnerable to a CRLF Injection / IMAP Command injection via Symbol arguments passed to IMAP commands.

### Details

Symbol arguments represent IMAP "system flags", which are formatted as "atoms" (with no quoting) with a `"\"` prefix.  Vulnerable versions of Net::IMAP sends the symbol name directly to the socket, with no validation.

Because the Symbol input is unvalidated, it could contain invalid `flag` characters, including `SP` and `CRLF`, which could be used to finish the current command and inject new commands.

Although IMAP `flag` arguments are only valid input for a few IMAP commands, most Net::IMAP commands use generic argument handling, and will allow Symbol (`flag`) inputs.

Note also that the list of valid symbol inputs should be restricted to an enumerated set of standard RFC defined flag types, which have each been given specific defined semantics.  Any user-provided values outside of that list of standard "system flags" needs to use the IMAP `keyword` syntax, which are sent as atoms, i.e: string inputs. Under no circumstances should `#to_sym` ever be called on unvetted user-provided input: that will always be a bug in the calling code for the simple reason that `user_input_atom` is  as `\user_input_atom`.

For forward compatibility with future IMAP extentions, Net::IMAP, does not restrict flag inputs to an enumerated list.  That is the responsibility of the calling application code, which knows which flag semantics are valid for its context.

### Impact

If a developer passes user-controlled input as a Symbol to most Net::IMAP commands, an attacker can append CRLF sequence followed by a new IMAP command (like `DELETE mailbox`).

### Mitigation
* Upgrade to a version of Net::IMAP that validates Symbols are valid as an IMAP `flag`.
* User-provided input should never be able to control calling `#to_sym` on string arguments.

  For example, do not unsafely serialize and deserialize command arguments (e.g. with YAML or Marshal) in a way that could create unvetted Symbol arguments.
* For the few IMAP commands which do allow `flag` arguments, it may be appropriate to hard-code Symbol arguments or restrict them to an enumerated list which is valid for the calling application.
GitHub Security Advisory: GHSA-75xq-5h9v-w6px
Package: net-imap (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection'), CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
Vulnerable versions: >= 0.5.0, <= 0.5.13
Patched in: 0.5.14

Summary: net-imap vulnerable to command Injection via unvalidated Symbol inputs

Details:
### Summary

Symbol arguments to commands are vulnerable to a CRLF Injection / IMAP Command injection via Symbol arguments passed to IMAP commands.

### Details

Symbol arguments represent IMAP "system flags", which are formatted as "atoms" (with no quoting) with a `"\"` prefix.  Vulnerable versions of Net::IMAP sends the symbol name directly to the socket, with no validation.

Because the Symbol input is unvalidated, it could contain invalid `flag` characters, including `SP` and `CRLF`, which could be used to finish the current command and inject new commands.

Although IMAP `flag` arguments are only valid input for a few IMAP commands, most Net::IMAP commands use generic argument handling, and will allow Symbol (`flag`) inputs.

Note also that the list of valid symbol inputs should be restricted to an enumerated set of standard RFC defined flag types, which have each been given specific defined semantics.  Any user-provided values outside of that list of standard "system flags" needs to use the IMAP `keyword` syntax, which are sent as atoms, i.e: string inputs. Under no circumstances should `#to_sym` ever be called on unvetted user-provided input: that will always be a bug in the calling code for the simple reason that `user_input_atom` is  as `\user_input_atom`.

For forward compatibility with future IMAP extentions, Net::IMAP, does not restrict flag inputs to an enumerated list.  That is the responsibility of the calling application code, which knows which flag semantics are valid for its context.

### Impact

If a developer passes user-controlled input as a Symbol to most Net::IMAP commands, an attacker can append CRLF sequence followed by a new IMAP command (like `DELETE mailbox`).

### Mitigation
* Upgrade to a version of Net::IMAP that validates Symbols are valid as an IMAP `flag`.
* User-provided input should never be able to control calling `#to_sym` on string arguments.

  For example, do not unsafely serialize and deserialize command arguments (e.g. with YAML or Marshal) in a way that could create unvetted Symbol arguments.
* For the few IMAP commands which do allow `flag` arguments, it may be appropriate to hard-code Symbol arguments or restrict them to an enumerated list which is valid for the calling application.
GitHub Security Advisory: GHSA-75xq-5h9v-w6px
Package: net-imap (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection'), CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
Vulnerable versions: >= 0.6.0, <= 0.6.3
Patched in: 0.6.4

Summary: net-imap vulnerable to command Injection via unvalidated Symbol inputs

Details:
### Summary

Symbol arguments to commands are vulnerable to a CRLF Injection / IMAP Command injection via Symbol arguments passed to IMAP commands.

### Details

Symbol arguments represent IMAP "system flags", which are formatted as "atoms" (with no quoting) with a `"\"` prefix.  Vulnerable versions of Net::IMAP sends the symbol name directly to the socket, with no validation.

Because the Symbol input is unvalidated, it could contain invalid `flag` characters, including `SP` and `CRLF`, which could be used to finish the current command and inject new commands.

Although IMAP `flag` arguments are only valid input for a few IMAP commands, most Net::IMAP commands use generic argument handling, and will allow Symbol (`flag`) inputs.

Note also that the list of valid symbol inputs should be restricted to an enumerated set of standard RFC defined flag types, which have each been given specific defined semantics.  Any user-provided values outside of that list of standard "system flags" needs to use the IMAP `keyword` syntax, which are sent as atoms, i.e: string inputs. Under no circumstances should `#to_sym` ever be called on unvetted user-provided input: that will always be a bug in the calling code for the simple reason that `user_input_atom` is  as `\user_input_atom`.

For forward compatibility with future IMAP extentions, Net::IMAP, does not restrict flag inputs to an enumerated list.  That is the responsibility of the calling application code, which knows which flag semantics are valid for its context.

### Impact

If a developer passes user-controlled input as a Symbol to most Net::IMAP commands, an attacker can append CRLF sequence followed by a new IMAP command (like `DELETE mailbox`).

### Mitigation
* Upgrade to a version of Net::IMAP that validates Symbols are valid as an IMAP `flag`.
* User-provided input should never be able to control calling `#to_sym` on string arguments.

  For example, do not unsafely serialize and deserialize command arguments (e.g. with YAML or Marshal) in a way that could create unvetted Symbol arguments.
* For the few IMAP commands which do allow `flag` arguments, it may be appropriate to hard-code Symbol arguments or restrict them to an enumerated list which is valid for the calling application.
GitHub Security Advisory: GHSA-87pf-fpwv-p7m7
Package: net-imap (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-1322: Use of Blocking Code in Single-threaded, Non-blocking Context
Vulnerable versions: >= 0.4.0, <= 0.4.23
Patched in: 0.4.24

Summary: net-imap vulnerable to denial of service via high iteration count for `SCRAM-*` authentication

Details:
### Summary

When authenticating a connection with `SCRAM-SHA1` or `SCRAM-SHA256`, a hostile server can perform a computational denial-of-service attack on the client process by sending a big iteration count value.

### Details

A hostile IMAP server can send an arbitrarily large PBKDF2 iteration count in the SCRAM server-first-message, causing the client to perform an expensive `OpenSSL::KDF.pbkdf2_hmac` call.   Because the PBKDF2 function is a blocking C extension and holds onto Ruby’s Global VM Lock, it can freeze the entire Ruby VM for the duration of the computation.

OpenSSL enforces an effective maximum by using a 32-bit signed integer for the iteration count,  Depending on hardware capabilities and OpenSSL version, this iteration count may be sufficient for to block all Ruby threads in the process for over seven minutes.

This is listed as one of the "Security Considerations", in [RFC 7804](https://www.rfc-editor.org/rfc/rfc7804.html#page-15):
>   A hostile server can perform a computational denial-of-service attack on clients by sending a big iteration count value.  In order to defend against that, a client implementation can pick a maximum iteration count that it is willing to use and reject any values that exceed that threshold (in such cases, the client, of course, has to fail the authentication).

### Impact

During SCRAM authentication to a hostile server, the entire Ruby VM will be locked for the duration of the computation.  Depending on hardware capabilities and OpenSSL version, this may take many minutes.

`OpenSSL::KDF.pbkdf2_hmac` is a blocking C function, so `Timeout` cannot be used to guard against this.  And it retains the Global VM lock, so other ruby threads will also be unable to run.

### Mitigation

* Upgrade to a patched version of `net-imap` that adds the `max_iterations` option to the `SASL-*` authenticators, and call `Net::IMAP#authenticate` with a `max_iterations` keyword argument. 

  **NOTE:** The default `max_iterations` is `2³¹ - 1`, the maximum signed 32 bit integer, the maximum allowed by OpenSSL.
  _To prevent a denial of service attack,_ this must be set to a safe value, depending on hardware and version of OpenSSL.
  _It is the user's responsibility_ to enforce minimum and maximum iteration counts that are appropriate for their security context.
* Alternatively, avoid `SCRAM-*` mechanisms when authenticating to untrusted servers.
GitHub Security Advisory: GHSA-87pf-fpwv-p7m7
Package: net-imap (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-1322: Use of Blocking Code in Single-threaded, Non-blocking Context
Vulnerable versions: >= 0.5.0, <= 0.5.13
Patched in: 0.5.14

Summary: net-imap vulnerable to denial of service via high iteration count for `SCRAM-*` authentication

Details:
### Summary

When authenticating a connection with `SCRAM-SHA1` or `SCRAM-SHA256`, a hostile server can perform a computational denial-of-service attack on the client process by sending a big iteration count value.

### Details

A hostile IMAP server can send an arbitrarily large PBKDF2 iteration count in the SCRAM server-first-message, causing the client to perform an expensive `OpenSSL::KDF.pbkdf2_hmac` call.   Because the PBKDF2 function is a blocking C extension and holds onto Ruby’s Global VM Lock, it can freeze the entire Ruby VM for the duration of the computation.

OpenSSL enforces an effective maximum by using a 32-bit signed integer for the iteration count,  Depending on hardware capabilities and OpenSSL version, this iteration count may be sufficient for to block all Ruby threads in the process for over seven minutes.

This is listed as one of the "Security Considerations", in [RFC 7804](https://www.rfc-editor.org/rfc/rfc7804.html#page-15):
>   A hostile server can perform a computational denial-of-service attack on clients by sending a big iteration count value.  In order to defend against that, a client implementation can pick a maximum iteration count that it is willing to use and reject any values that exceed that threshold (in such cases, the client, of course, has to fail the authentication).

### Impact

During SCRAM authentication to a hostile server, the entire Ruby VM will be locked for the duration of the computation.  Depending on hardware capabilities and OpenSSL version, this may take many minutes.

`OpenSSL::KDF.pbkdf2_hmac` is a blocking C function, so `Timeout` cannot be used to guard against this.  And it retains the Global VM lock, so other ruby threads will also be unable to run.

### Mitigation

* Upgrade to a patched version of `net-imap` that adds the `max_iterations` option to the `SASL-*` authenticators, and call `Net::IMAP#authenticate` with a `max_iterations` keyword argument. 

  **NOTE:** The default `max_iterations` is `2³¹ - 1`, the maximum signed 32 bit integer, the maximum allowed by OpenSSL.
  _To prevent a denial of service attack,_ this must be set to a safe value, depending on hardware and version of OpenSSL.
  _It is the user's responsibility_ to enforce minimum and maximum iteration counts that are appropriate for their security context.
* Alternatively, avoid `SCRAM-*` mechanisms when authenticating to untrusted servers.
GitHub Security Advisory: GHSA-87pf-fpwv-p7m7
Package: net-imap (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling, CWE-1322: Use of Blocking Code in Single-threaded, Non-blocking Context
Vulnerable versions: >= 0.6.0, <= 0.6.3
Patched in: 0.6.4

Summary: net-imap vulnerable to denial of service via high iteration count for `SCRAM-*` authentication

Details:
### Summary

When authenticating a connection with `SCRAM-SHA1` or `SCRAM-SHA256`, a hostile server can perform a computational denial-of-service attack on the client process by sending a big iteration count value.

### Details

A hostile IMAP server can send an arbitrarily large PBKDF2 iteration count in the SCRAM server-first-message, causing the client to perform an expensive `OpenSSL::KDF.pbkdf2_hmac` call.   Because the PBKDF2 function is a blocking C extension and holds onto Ruby’s Global VM Lock, it can freeze the entire Ruby VM for the duration of the computation.

OpenSSL enforces an effective maximum by using a 32-bit signed integer for the iteration count,  Depending on hardware capabilities and OpenSSL version, this iteration count may be sufficient for to block all Ruby threads in the process for over seven minutes.

This is listed as one of the "Security Considerations", in [RFC 7804](https://www.rfc-editor.org/rfc/rfc7804.html#page-15):
>   A hostile server can perform a computational denial-of-service attack on clients by sending a big iteration count value.  In order to defend against that, a client implementation can pick a maximum iteration count that it is willing to use and reject any values that exceed that threshold (in such cases, the client, of course, has to fail the authentication).

### Impact

During SCRAM authentication to a hostile server, the entire Ruby VM will be locked for the duration of the computation.  Depending on hardware capabilities and OpenSSL version, this may take many minutes.

`OpenSSL::KDF.pbkdf2_hmac` is a blocking C function, so `Timeout` cannot be used to guard against this.  And it retains the Global VM lock, so other ruby threads will also be unable to run.

### Mitigation

* Upgrade to a patched version of `net-imap` that adds the `max_iterations` option to the `SASL-*` authenticators, and call `Net::IMAP#authenticate` with a `max_iterations` keyword argument. 

  **NOTE:** The default `max_iterations` is `2³¹ - 1`, the maximum signed 32 bit integer, the maximum allowed by OpenSSL.
  _To prevent a denial of service attack,_ this must be set to a safe value, depending on hardware and version of OpenSSL.
  _It is the user's responsibility_ to enforce minimum and maximum iteration counts that are appropriate for their security context.
* Alternatively, avoid `SCRAM-*` mechanisms when authenticating to untrusted servers.