Masamuneee

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.

`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.

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.

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.

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.

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.

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.

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.

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.

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.

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.