deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-q2mw-fvj9-vvcw
Package: net-imap (RUBYGEMS)
Severity: LOW (CVSS 0.0)
CWE: CWE-407: Inefficient Algorithmic Complexity
Vulnerable versions: >= 0, <= 0.4.23
Patched in: 0.4.24

Summary: net-imap has quadratic complexity when reading response literals

Details:
### Summary

`Net::IMAP::ResponseReader` has quadratic time complexity when reading large responses containing many string literals.  A hostile server can send responses which are crafted to exhaust the client's CPU for a denial of service attack.

### Details

For each literal in a response, `ResponseReader` rescans the entire growing response buffer.  The regular expression that is used to scan the response buffer runs in linear time.  With many literals, this becomes O(n²) total work.  The regular expression should run in constant time: it is anchored to the end and only the last 23 bytes of the buffer are relevant.

Because the algorithmic complexity is super-linear, this bypasses protection from `max_response_size`: a response can stay well below the default size limit while still causing very large CPU cost.

`Net::IMAP::ResponseReader` runs continuously in the receiver thread until the connection closes.

### Impact

This consumes disproportionate CPU time in the client's receiver thread.  A hostile server could use this to exhaust the client's CPU for a denial of service attack.

For a response near the default `max_response_size`, each individual regexp scan could take between 100 to 200ms on common modern hardware, and this may be repeated 200k times per megabyte of response.  While the regexp is scanning, it retains the Global VM lock, preventing other threads from running.

Although other threads should not be _completely_ blocked, their run time will be significantly impacted.

### Mitigation

* Upgrade to a patched version of net-imap that reads responses more efficiently.
* Do not connect to untrusted IMAP servers.
* When connecting to untrusted servers, a _much_ smaller `max_response_size` (for example: 8KiB) will limit the impact.  Although this is too small for fetching unpaginated message bodies, it should be enough for most other operations.
GitHub Security Advisory: GHSA-q2mw-fvj9-vvcw
Package: net-imap (RUBYGEMS)
Severity: LOW (CVSS 0.0)
CWE: CWE-407: Inefficient Algorithmic Complexity
Vulnerable versions: >= 0.5.0, <= 0.5.13
Patched in: 0.5.14

Summary: net-imap has quadratic complexity when reading response literals

Details:
### Summary

`Net::IMAP::ResponseReader` has quadratic time complexity when reading large responses containing many string literals.  A hostile server can send responses which are crafted to exhaust the client's CPU for a denial of service attack.

### Details

For each literal in a response, `ResponseReader` rescans the entire growing response buffer.  The regular expression that is used to scan the response buffer runs in linear time.  With many literals, this becomes O(n²) total work.  The regular expression should run in constant time: it is anchored to the end and only the last 23 bytes of the buffer are relevant.

Because the algorithmic complexity is super-linear, this bypasses protection from `max_response_size`: a response can stay well below the default size limit while still causing very large CPU cost.

`Net::IMAP::ResponseReader` runs continuously in the receiver thread until the connection closes.

### Impact

This consumes disproportionate CPU time in the client's receiver thread.  A hostile server could use this to exhaust the client's CPU for a denial of service attack.

For a response near the default `max_response_size`, each individual regexp scan could take between 100 to 200ms on common modern hardware, and this may be repeated 200k times per megabyte of response.  While the regexp is scanning, it retains the Global VM lock, preventing other threads from running.

Although other threads should not be _completely_ blocked, their run time will be significantly impacted.

### Mitigation

* Upgrade to a patched version of net-imap that reads responses more efficiently.
* Do not connect to untrusted IMAP servers.
* When connecting to untrusted servers, a _much_ smaller `max_response_size` (for example: 8KiB) will limit the impact.  Although this is too small for fetching unpaginated message bodies, it should be enough for most other operations.
GitHub Security Advisory: GHSA-q2mw-fvj9-vvcw
Package: net-imap (RUBYGEMS)
Severity: LOW (CVSS 0.0)
CWE: CWE-407: Inefficient Algorithmic Complexity
Vulnerable versions: >= 0.6.0, <= 0.6.3
Patched in: 0.6.4

Summary: net-imap has quadratic complexity when reading response literals

Details:
### Summary

`Net::IMAP::ResponseReader` has quadratic time complexity when reading large responses containing many string literals.  A hostile server can send responses which are crafted to exhaust the client's CPU for a denial of service attack.

### Details

For each literal in a response, `ResponseReader` rescans the entire growing response buffer.  The regular expression that is used to scan the response buffer runs in linear time.  With many literals, this becomes O(n²) total work.  The regular expression should run in constant time: it is anchored to the end and only the last 23 bytes of the buffer are relevant.

Because the algorithmic complexity is super-linear, this bypasses protection from `max_response_size`: a response can stay well below the default size limit while still causing very large CPU cost.

`Net::IMAP::ResponseReader` runs continuously in the receiver thread until the connection closes.

### Impact

This consumes disproportionate CPU time in the client's receiver thread.  A hostile server could use this to exhaust the client's CPU for a denial of service attack.

For a response near the default `max_response_size`, each individual regexp scan could take between 100 to 200ms on common modern hardware, and this may be repeated 200k times per megabyte of response.  While the regexp is scanning, it retains the Global VM lock, preventing other threads from running.

Although other threads should not be _completely_ blocked, their run time will be significantly impacted.

### Mitigation

* Upgrade to a patched version of net-imap that reads responses more efficiently.
* Do not connect to untrusted IMAP servers.
* When connecting to untrusted servers, a _much_ smaller `max_response_size` (for example: 8KiB) will limit the impact.  Although this is too small for fetching unpaginated message bodies, it should be enough for most other operations.
GitHub Security Advisory: GHSA-vcgp-9326-pqcp
Package: net-imap (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-392: Missing Report of Error Condition, CWE-393: Return of Wrong Status Code, CWE-636: Not Failing Securely ('Failing Open'), CWE-754: Improper Check for Unusual or Exceptional Conditions, CWE-841: Improper Enforcement of Behavioral Workflow
Vulnerable versions: >= 0, <= 0.3.9
Patched in: 0.3.10

Summary: net-imap vulnerable to STARTTLS stripping via invalid response timing

Details:
### Summary

A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return "successfully", without starting TLS.

### Details

When using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag.  By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered.  This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.

This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.

### Impact

TLS bypass, leading to cleartext transmission of sensitive information.

### Mitigation

* Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS.
* Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port.
  This is strongly recommended anyway:
  * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
  * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context
* Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connection after `#starttls`.
GitHub Security Advisory: GHSA-vcgp-9326-pqcp
Package: net-imap (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-392: Missing Report of Error Condition, CWE-393: Return of Wrong Status Code, CWE-636: Not Failing Securely ('Failing Open'), CWE-754: Improper Check for Unusual or Exceptional Conditions, CWE-841: Improper Enforcement of Behavioral Workflow
Vulnerable versions: >= 0.4.0, <= 0.4.23
Patched in: 0.4.24

Summary: net-imap vulnerable to STARTTLS stripping via invalid response timing

Details:
### Summary

A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return "successfully", without starting TLS.

### Details

When using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag.  By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered.  This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.

This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.

### Impact

TLS bypass, leading to cleartext transmission of sensitive information.

### Mitigation

* Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS.
* Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port.
  This is strongly recommended anyway:
  * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
  * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context
* Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connection after `#starttls`.
GitHub Security Advisory: GHSA-vcgp-9326-pqcp
Package: net-imap (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-392: Missing Report of Error Condition, CWE-393: Return of Wrong Status Code, CWE-636: Not Failing Securely ('Failing Open'), CWE-754: Improper Check for Unusual or Exceptional Conditions, CWE-841: Improper Enforcement of Behavioral Workflow
Vulnerable versions: >= 0.5.0, <= 0.5.13
Patched in: 0.5.14

Summary: net-imap vulnerable to STARTTLS stripping via invalid response timing

Details:
### Summary

A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return "successfully", without starting TLS.

### Details

When using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag.  By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered.  This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.

This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.

### Impact

TLS bypass, leading to cleartext transmission of sensitive information.

### Mitigation

* Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS.
* Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port.
  This is strongly recommended anyway:
  * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
  * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context
* Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connection after `#starttls`.
GitHub Security Advisory: GHSA-vcgp-9326-pqcp
Package: net-imap (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-392: Missing Report of Error Condition, CWE-393: Return of Wrong Status Code, CWE-636: Not Failing Securely ('Failing Open'), CWE-754: Improper Check for Unusual or Exceptional Conditions, CWE-841: Improper Enforcement of Behavioral Workflow
Vulnerable versions: >= 0.6.0, <= 0.6.3
Patched in: 0.6.4

Summary: net-imap vulnerable to STARTTLS stripping via invalid response timing

Details:
### Summary

A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return "successfully", without starting TLS.

### Details

When using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag.  By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered.  This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.

This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.

### Impact

TLS bypass, leading to cleartext transmission of sensitive information.

### Mitigation

* Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS.
* Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port.
  This is strongly recommended anyway:
  * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
  * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context
* Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connection after `#starttls`.
GitHub Security Advisory: GHSA-ffq5-qpvf-xq7x
Package: openc3 (RUBYGEMS)
Severity: MODERATE (CVSS 4.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 7.0.0
Patched in: 7.0.0

Summary: OpenC3 COSMOS is Vulnerable to Self-XSS Through the Command Sender

Details:
### Summary
The Command Sender UI uses an unsafe `eval()` function on array-like command parameters, which allows a user-supplied payload to execute in the browser when sending a command. This creates a self-XSS risk because an attacker can trigger their own script execution in the victim’s session, if allowed to influence the array parameter input, for example via phishing. If successful, an attacker may read or modify data in the authenticated browser context, including session tokens in local storage.

### Details
The unsafe `eval()`  usage on user-supplied ARRAY parameters happens in `convertToValue` method in [CommandSender.vue](https://github.com/OpenC3/cosmos/blob/main/openc3-cosmos-init/plugins/packages/openc3-cosmos-tool-cmdsender/src/tools/CommandSender/CommandSender.vue)

### PoC
1.	Using a drop-down form, choose any command that supports ARRAY parameters,
2.	Inside square brackets “[…]” place a JavaScript code to be executed
3.	Send command to CmdTlmServer using dedicated “Send” button 
4.	Observe JavaScript code being executed in the current browser session context

Below example uses `INST ARYCMD` to execute simple JavaScript code snippet `alert(“XSS”)`.
<img width="947" height="356" alt="image" src="https://github.com/user-attachments/assets/6fbdb6c9-616a-4268-bbb8-a8a1044437ad" />

<img width="942" height="545" alt="image" src="https://github.com/user-attachments/assets/4df24353-aea0-4aa0-adcf-b7c7e387dc83" />

### Impact
Local JavaScript execution in the user's browser
GitHub Security Advisory: GHSA-4jvx-93h3-f45h
Package: openc3 (RUBYGEMS)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-23: Relative Path Traversal
Vulnerable versions: >= 7.0.0.pre.rc1, < 7.0.0-rc3
Patched in: 7.0.0-rc3

Summary: OpenC3 COSMOS allows arbitrary writes to plugins directory via path-traversed config filenames

Details:
### Summary
OpenC3 COSMOS contains a design flaw in the `save_tool_config()` function that allows saving tool configuration files at arbitrary locations inside the shared `/plugins` directory tree by supplying crafted configuration filenames. Although the implementation sufficiently mitigates standard path traversal attacks, by canonicalizing filename to an absolute path, all plugins share this same root directory. That enables users to create arbitrary file structures and overwrite existing configuration files within the shared `/plugins` directory.

### Details
In function `save_tool_config()` ([local_mode.rb](https://github.com/OpenC3/cosmos/blob/397abec0d57972881a2e8dc10902d0dce9c27f42/openc3/lib/openc3/utilities/local_mode.rb#L452))  responsible for saving user-supplied tool configuration, the desired saving directory is not sufficiently enforced, instead allowing writes inside entire `OPENC3_LOCAL_MODE_PATH`.

### PoC
1.	Navigate to any tool that enables “Save Configuration” option in left-hand drop-down menu (here Limits Monitor as an example)
2.	Save a new config with path traversal name using “../” sequences to escape desired directory (up to 3 levels high)
3.	Observe new files created in /plugins directory by inspecting docker container directly (`openc3-COSMOS-cmd-tlm-api`) or using Bucket Explorer (`plugin_default`)

<img width="811" height="584" alt="image" src="https://github.com/user-attachments/assets/015a59b4-8b18-4801-aef0-df4831d5c1c3" />
<img width="720" height="664" alt="image" src="https://github.com/user-attachments/assets/8ca4a5b7-ee45-4c3b-99f6-f41f974a74a7" />

### Impact
Modifying the data of other plugins
GitHub Security Advisory: GHSA-4jvx-93h3-f45h
Package: openc3 (RUBYGEMS)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-23: Relative Path Traversal
Vulnerable versions: < 6.10.5
Patched in: 6.10.5

Summary: OpenC3 COSMOS allows arbitrary writes to plugins directory via path-traversed config filenames

Details:
### Summary
OpenC3 COSMOS contains a design flaw in the `save_tool_config()` function that allows saving tool configuration files at arbitrary locations inside the shared `/plugins` directory tree by supplying crafted configuration filenames. Although the implementation sufficiently mitigates standard path traversal attacks, by canonicalizing filename to an absolute path, all plugins share this same root directory. That enables users to create arbitrary file structures and overwrite existing configuration files within the shared `/plugins` directory.

### Details
In function `save_tool_config()` ([local_mode.rb](https://github.com/OpenC3/cosmos/blob/397abec0d57972881a2e8dc10902d0dce9c27f42/openc3/lib/openc3/utilities/local_mode.rb#L452))  responsible for saving user-supplied tool configuration, the desired saving directory is not sufficiently enforced, instead allowing writes inside entire `OPENC3_LOCAL_MODE_PATH`.

### PoC
1.	Navigate to any tool that enables “Save Configuration” option in left-hand drop-down menu (here Limits Monitor as an example)
2.	Save a new config with path traversal name using “../” sequences to escape desired directory (up to 3 levels high)
3.	Observe new files created in /plugins directory by inspecting docker container directly (`openc3-COSMOS-cmd-tlm-api`) or using Bucket Explorer (`plugin_default`)

<img width="811" height="584" alt="image" src="https://github.com/user-attachments/assets/015a59b4-8b18-4801-aef0-df4831d5c1c3" />
<img width="720" height="664" alt="image" src="https://github.com/user-attachments/assets/8ca4a5b7-ee45-4c3b-99f6-f41f974a74a7" />

### Impact
Modifying the data of other plugins
GitHub Security Advisory: GHSA-wgx6-g857-jjf7
Package: openc3 (RUBYGEMS)
Severity: HIGH (CVSS 8.1)
CWE: CWE-620: Unverified Password Change
Vulnerable versions: >= 7.0.0.pre.rc1, < 7.0.0-rc3
Patched in: 7.0.0-rc3

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