Masamuneee

**Name of the Vulnerable Software and Affected Versions** Argo Workflows versions 4.0.0 through 4.0.4 **Description** The workflow executor logs artifact repository credentials in plaintext during artifact operations. This occurs because the logging driver passes the entire `ArtifactDriver` struct to the structured logger, exposing sensitive fields such as `AccessKey`, `SecretKey`, `SessionToken`, and `ServerSideCustomerKey` for S3, `AccessKey`, `SecretKey`, and `SecurityToken` for OSS, and `ServiceAccountKey` for GCS. Any user with Kubernetes RBAC permissions to read workflow pod logs can extract these credentials. **Recommendations** Update to version 4.0.5.

**Name of the Vulnerable Software and Affected Versions** Net::IMAP (affected versions not specified) **Description** `Net::IMAP::ResponseReader` exhibits quadratic time complexity when processing large responses containing numerous string literals. A hostile server can send specially crafted responses that force the `ResponseReader` to rescan the entire growing response buffer for each literal, leading to excessive CPU consumption and a denial of service. This algorithmic complexity allows the issue to bypass `max response size` protections, as a response can remain below the size limit while still incurring high CPU costs. Because the process retains the Global VM lock during scanning, other threads are significantly impacted. **Recommendations** Upgrade to a patched version of net-imap. Avoid connecting to untrusted IMAP servers. When connecting to untrusted servers, reduce `max response size` to a much smaller value, such as 8KiB, to limit the impact.

**Name of the Vulnerable Software and Affected Versions** Argo Workflows versions prior to 4.0.2 and 3.7.11 **Description** Argo Workflows, an open source container-native workflow engine for Kubernetes, has an issue where Workflow templates endpoints allow any client to retrieve WorkflowTemplates and ClusterWorkflowTemplates. A request with an `Authorization: Bearer nothing` token can expose sensitive template content, including embedded Secret manifests. The issue stems from how informers use the server’s rest config, reading using server service account privileges. A proof-of-concept demonstrates the ability to leak template data, including secrets, artifact locations, service account usage, environment variables, and resource manifests. **Recommendations** Update to Argo Workflows version 4.0.2 or 3.7.11.

**Name of the Vulnerable Software and Affected Versions** Argo Workflows versions prior to 3.6.17 and prior to 3.7.8 **Description** Argo Workflows contains a stored cross-site scripting (XSS) issue in the artifact directory listing. This allows a workflow author to execute arbitrary JavaScript in another user’s browser under the Argo Server origin, potentially enabling API actions with the victim’s privileges. The issue stems from the directory listing response in `server/artifacts/artifact server.go` rendering object names directly into HTML without proper escaping. Object names are attacker-controlled when a workflow writes files into an output artifact directory. The vulnerable code is located at `fmt.Fprintf` within the specified file. An attacker can create a malicious workflow that produces a crafted HTML artifact containing a script. By sending a deep-link to this artifact to a victim, the attacker can execute the script in the victim's browser, potentially allowing the attacker to perform actions on the Argo Server API with the victim’s permissions, such as reading workflow information or creating/deleting workflows. **Recommendations** Argo Workflows versions prior to 3.6.17 should be updated to version 3.6.17 or later. Argo Workflows versions prior to 3.7.8 should be updated to version 3.7.8 or later.

**Name of the Vulnerable Software and Affected Versions** Rack versions prior to 2.2.22 Rack versions prior to 3.1.20 Rack versions prior to 3.2.5 **Description** The `Rack::Directory` component had a path check that used a string prefix match on the expanded path. A crafted request, such as `/../root example/`, could bypass the configured root if the target path shared a prefix with the root string, potentially enabling directory listing outside the intended root. This occurs because the check `File.expand path(File.join(root, path info)).start with?(root)` does not enforce a path boundary. For example, if the server root is `/var/www/root`, a path like `/var/www/root backup` could pass the check. This could lead to information disclosure via directory listing when `Rack::Directory` is exposed to untrusted clients and a directory shares the root prefix. **Recommendations** Update Rack to version 2.2.22 or later. Update Rack to version 3.1.20 or later. Update Rack to version 3.2.5 or later. Avoid naming directories with the same prefix as those exposed via `Rack::Directory`.

**Name of the Vulnerable Software and Affected Versions** net-imap (affected versions not specified) **Description** A hostile IMAP server can trigger a computational denial-of-service attack on the client process during authentication using `SCRAM-SHA1` or `SCRAM-SHA256`. By sending an arbitrarily large PBKDF2 iteration count in the server-first-message, the server forces the client to execute an expensive `OpenSSL::KDF.pbkdf2 hmac()` call. Since this function is a blocking C extension that holds the Ruby Global VM Lock (a mechanism that ensures only one thread executes Ruby code at a time), it can freeze the entire Ruby VM and block all threads for several minutes, depending on the hardware and OpenSSL version. **Recommendations** Upgrade to a patched version of net-imap and call `Net::IMAP#authenticate` using a `max iterations` keyword argument set to a safe value appropriate for the security context. Avoid using `SCRAM-*` mechanisms when authenticating to untrusted servers.

**Name of the Vulnerable Software and Affected Versions** Net::IMAP versions prior to 0.3.10 Net::IMAP versions prior to 0.4.24 Net::IMAP versions prior to 0.5.14 Net::IMAP versions prior to 0.6.4 **Description** A man-in-the-middle attacker can cause the `starttls()` function to return successfully without actually establishing a TLS connection. This occurs when an attacker injects a tagged OK response with a predictable tag before the client finishes sending the command, causing the command to complete before the response handler is registered. This results in a STARTTLS stripping attack, where the socket remains unencrypted, leading to the cleartext transmission of sensitive information. **Recommendations** Update to version 0.3.10. Update to version 0.4.24. Update to version 0.5.14. Update to version 0.6.4. Connect to an implicit TLS port instead of using STARTTLS with a cleartext port. Explicitly verify that `tls verified?` is true before using the connection after calling `starttls()`.

**Name of the Vulnerable Software and Affected Versions** Net::IMAP versions prior to 0.5.7, 0.4.20, 0.3.9, and 0.2.5 **Description** The issue allows for denial of service by memory exhaustion when Net::IMAP reads server responses. A malicious server can send a "literal" byte count, which is automatically read by the client's receiver thread, causing the response reader to allocate memory for the number of bytes indicated by the server response. This can affect insecure connections and buggy, untrusted, or compromised servers. **Recommendations** For versions prior to 0.5.7, update to version 0.5.7 or later. For versions prior to 0.4.20, update to version 0.4.20 or later. For versions prior to 0.3.9, update to version 0.3.9 or later. For versions prior to 0.2.5, update to version 0.2.5 or later. As a temporary workaround, consider restricting connections to trusted IMAP servers to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Rack versions prior to 2.2.13 Rack versions prior to 3.0.14 Rack versions prior to 3.1.12 **Description** The issue arises from the `Rack::Static` component not properly sanitizing user-supplied paths before serving files, allowing encoded path traversal sequences to be used for accessing files outside the designated static file directory. This can lead to exposure of files under the specified `root:` directory. **Recommendations** For versions prior to 2.2.13, update to version 2.2.13 or later. For versions prior to 3.0.14, update to version 3.0.14 or later. For versions prior to 3.1.12, update to version 3.1.12 or later. As a temporary workaround, consider removing usage of `Rack::Static`, or ensure that `root:` points to a directory path which only contains files that should be accessed publicly.

**Name of the Vulnerable Software and Affected Versions** Rack versions prior to 2.2.12 Rack versions prior to 3.0.13 Rack versions prior to 3.1.11 **Description** The issue concerns the Rack::Sendfile middleware, which logs unsanitised header values from the X-Sendfile-Type header. An attacker can exploit this by injecting escape sequences, such as newline characters, into the header, resulting in log injection. **Recommendations** For versions prior to 2.2.12, update to version 2.2.12 or later. For versions prior to 3.0.13, update to version 3.0.13 or later. For versions prior to 3.1.11, update to version 3.1.11 or later.

**Name of the Vulnerable Software and Affected Versions** code-projects Point of Sales and Inventory Management System version 1.0 **Description** A critical issue affects the processing of the file /user/add cart.php, where the manipulation of the argument `id/qty` leads to SQL injection. The attack may be initiated remotely. **Recommendations** For version 1.0, consider disabling the `/user/add cart.php` file or restricting access to it until a patch is available. Avoid using the `id/qty` argument in the affected file to minimize the risk of exploitation.