Dungnhvhust

The software fails to fully enforce the `allowAsync: false` option within VM and NodeVM. Although `localPromise.prototype.then` is replaced to prevent asynchronous operations, the sandbox's Promise static methods—specifically `Promise.resolve`, `Promise.all`, `Promise.race`, `Promise.any`, and `Promise.allSettled`—still accept attacker-supplied thenables. This occurs because native promise resolution executes a `PromiseResolveThenableJob` and invokes the `then` method of the sandboxed code in a microtask, bypassing the patched handler. Consequently, a sandboxed script can schedule tasks that execute after `VM.run()` or `NodeVM.run()` has returned and beyond the configured timeout, allowing execution to continue after the host assumes it has finished.

Insufficient validation of the `allow shell` configuration parameter within project config files allows for arbitrary shell command execution. An attacker can achieve this by committing a malicious `.codewhale/config.toml` file to a repository. When a user clones and opens the affected repository, the AI model is granted access to the `exec shell` and `task shell` tools, which enables the execution of arbitrary shell commands on the victim's machine without explicit consent.

Insufficient validation of file paths in the project config instructions field allows for the reading of arbitrary files on a system. An attacker can use a malicious `.codewhale/config.toml` file within a cloned repository to specify paths outside the workspace. These files are then read and injected into the AI system prompt, which can be used for data exfiltration.

The `helmet` middleware in the Fiber web framework fails to set the `Strict-Transport-Security` (HSTS) response header, even when `HSTSMaxAge` is configured. This occurs because the logic in `middleware/helmet/helmet.go` incorrectly uses the `c.Protocol()` function to check for HTTPS connections. The `c.Protocol()` function returns the HTTP protocol version (such as `HTTP/1.1` or `HTTP/2.0`) rather than the URL scheme. Consequently, the condition `c.Protocol() == "https"` always evaluates to false, rendering the HSTS protection inactive. This can leave users susceptible to SSL stripping attacks, protocol downgrades, and cookie theft over HTTP.

Cross-origin postMessage handlers allow for stored XSS and session takeover. The software registers window message listeners—specifically the useTina overlay handler, the OAuth authentication popup handler, and the admin↔preview iframe GraphQL reducer—that process `event.data` without verifying `event.origin` or `event.source`. Additionally, it posts messages using non-specific target origins. A malicious page visited by a victim, or a window in an opener/iframe relationship with a Tina admin, can forge messages to control the editor, inject preview content, or manipulate the OAuth popup channel to hijack an authenticated editing session.

Nodemailer fails to enforce the `disableFileAccess` and `disableUrlAccess` security options during message normalization when using `jsonTransport`. This occurs because the `shared.resolveContent()` function, which is called during serialization, does not check these access control flags. Consequently, an attacker who can control message content fields can bypass intended restrictions to read local files or trigger outbound HTTP(S) requests. This issue is also reachable when `attachDataUrls` is enabled, as it triggers a similar pre-resolution path via the ` convertDataImages()` function. Technical details include: - **API Endpoints:** The issue is triggered when `createTransport()` is configured with `jsonTransport: true`. - **Vulnerable Parameters or Variables:** Attackers can exploit this by supplying `path` or `href` values within message content fields, such as attachments or the `text` field. - **Function Names:** The vulnerability exists within the `shared.resolveContent()` function and is triggered during the `mail.normalize()` process.

Nodemailer fails to sanitize carriage return (CR) and line feed (LF) characters in list comment fields. An attacker who can influence the `list.*.comment` parameters can inject CRLF sequences to create additional headers in generated RFC822 messages. This occurs because the `list.*.comment` field is inserted into prepared header values that bypass the normal header-value sanitizer and are passed to the `mimeFuncs.foldLines()` function. This can alter mail client behavior and message semantics by adding attacker-controlled metadata headers. The affected parameters include `list.help.comment`, `list.unsubscribe.comment`, `list.subscribe.comment`, `list.post.comment`, `list.owner.comment`, `list.archive.comment`, and `list.id.comment`.

The `secure popen()` function in `glances/secure.py` improperly interprets shell-like operators, specifically `>` (file redirection), `|` (pipe), and `&&` (command chaining), within command strings. When Application Monitoring Process (AMP) modules load `command` or `service cmd` configuration values from `glances.conf`, these values are passed to `secure popen()` without sanitization. This allows an attacker who can modify the configuration file to write arbitrary content to any filesystem path, chain arbitrary commands, or pipe output to other programs. Technical details include: - **Vulnerable Function**: `secure popen()` parses the `>` operator to write to files via `open(stdout redirect, "w")` without path validation, and uses `|` and `&&` to execute sequential or piped processes. - **Vulnerable Parameters**: The `command` and `service cmd` configuration values loaded from `[amp <name>]` and `[amp systemv]` sections. The `--disable-config-exec` flag does not mitigate this issue as it only prevents backtick execution in `config.get value()` and does not affect how `secure popen()` processes the resulting strings.