| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Daytona is a secure and elastic infrastructure runtime for AI-generated code execution and agent workflows. Prior to 0.186, a sandbox volume reference (volumeId, which may also be a volume name) was forwarded to the runner and used to build the host bind-mount source path without confinement. A reference containing path-traversal sequences could in principle resolve the mount source outside the intended per-volume base directory. This vulnerability is fixed in 0.186. |
| Daytona is a secure and elastic infrastructure runtime for AI-generated code execution and agent workflows. From 0.101.0 until 0.184.0, sandbox previews that were switched from public to private could remain reachable without authentication for a short period after the change, due to a cached visibility state that was not invalidated when the sandbox's visibility changed. This vulnerability is fixed in 0.184.0. |
| Daytona is a secure and elastic infrastructure runtime for AI-generated code execution and agent workflows. Prior to 0.184.0, organization invitations could be accepted (and declined) by a user whose email matched the invitation but had not been verified. Daytona authenticates users via OIDC and matches an invitation's target email against the email in the caller's token, but the invitation accept and decline paths did not require that email to be verified, unlike organization creation, which already enforced verification. On identity providers that allow self-service signup and issue a session before the email is verified, an actor could register an address matching a pending invitation, leave it unverified, and accept the invitation, joining the target organization with the role the invitation carried (up to Owner). This vulnerability is fixed in 0.184.0. |
| @rtk-ai/rtk-rewrite transparently rewrites shell commands executed via OpenClaw's exec tool to their RTK equivalents. In 1.0.0, the @rtk-ai/rtk-rewrite OpenClaw plugin passes attacker-controlled input directly into a shell-backed execSync() template string without shell-safe escaping. JSON.stringify() wraps the value in double quotes and escapes inner double-quotes and backslashes, but leaves $() and backtick shell metacharacters untouched. Because execSync delegates execution to /bin/sh -c, the shell expands $(...) substitutions even inside double-quoted strings, causing the injected subcommand to execute before rtk is invoked. An attacker who can influence the exec tool's command parameter (e.g., via an LLM agent prompt or gateway/tool-call input) achieves arbitrary OS command execution with the privileges of the plugin/gateway process. |
| rtk filters and compresses command outputs before they reach your LLM context. Prior to 0.32.0, RTK (Rust Token Killer) improperly trusts project-local configuration files. RTK automatically loads .rtk/filters.toml from the working directory with highest priority and without user notification. An attacker can place a malicious filter file in a repository to apply regex-based modifications (e.g., strip_lines_matching) to shell command output before it is shown to the LLM, without any indication that the output has been modified. This allows attackers to selectively suppress or alter command output (including file contents, diffs, and security scan results) without detection, potentially concealing malicious code during AI-assisted development or review. This vulnerability is fixed in 0.32.0. |
| rtk filters and compresses command outputs before they reach your LLM context. Prior to 0.42.2, the permission splitter did not conservatively split or reject several shell constructs that Bash treats as command execution boundaries or nested execution. As a result, a command beginning with an allowed prefix such as git could hide a second command behind one of these constructs. rtk rewrite returned exit code 0, causing the Claude hook to emit permissionDecision: "allow". The rewritten command still contained the hidden command, so it ran without the user confirmation or denial that the permission rules were intended to enforce. This vulnerability is fixed in 0.42.2. |
| Pi is a minimal terminal coding harness. Pi before 0.79.0 loaded project-local configuration and resources from a repository's .pi directory without first asking the user to trust that repository. This included project-local extensions, which are executable TypeScript or JavaScript modules loaded into the Pi process. An attacker who controls a repository could place Pi-specific project resources in that repository. If a user then started Pi from that working tree, the project-local extension code could run with the same privileges as the local Pi process without the user having a convenient way to make a trust decision. This vulnerability is fixed in 0.79.0. |
| Pi is a minimal terminal coding harness. From 0.74.0 until 0.78.1, Pi versions with temporary npm or git extension package installs used predictable paths under the operating system temporary directory. On Linux-based multi-user systems, a local attacker who can write to the shared temporary directory could prepare the expected package location before another user runs pi with a temporary extension package source. Pi could then load attacker-controlled extension code in the victim user's process. This vulnerability is fixed in 0.78.1. |
| Pi is a minimal terminal coding harness. From 0.74.0 until 0.78.1, Pi HTML exports render session Markdown into a static HTML file. It did not consistently reject unsafe Markdown link and image URL schemes. In versions with scheme filtering, C0 control characters in the URL scheme could bypass the check because browsers normalize those characters before navigation. This vulnerability is fixed in 0.78.1. |
| Pi is a minimal terminal coding harness. From 0.74.0 until 0.78.1, Pi stored API keys and OAuth credentials in auth.json. A race condition in the file write path could briefly create or rewrite this file with permissions derived from the process umask before tightening the file to owner-only permissions. This vulnerability is fixed in 0.78.1. |
| Module: plugins/modules/keyring_info.py
CVSS 3.1: 5.5 MEDIUM — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Issue: The module retrieves a passphrase from the OS native keyring (GNOME Keyring, macOS Keychain, Windows Credential Manager) and places it directly into result["passphrase"] with no output suppression, no no_log protection, and no documentation warning.
Root Cause:
Line 105 (protected): keyring_password=dict(type="str", required=True, no_log=True)
Line 127 (NOT protected): result["passphrase"] = passphrase
Observed Output:
{
"changed": false,
"passphrase": "MyMasterP@ssw0rd!SSH_Key_Secret"
}
Visible via register + debug:
{
"keyring_result": {
"changed": false,
"passphrase": "MyMasterP@ssw0rd!SSH_Key_Secret"
}
}
Impact:
Master passwords, SSH key passphrases and service credentials appear in all Ansible output
register: keyring_result followed by debug: var=keyring_result prints passphrase in full
Ansible fact caching backends (Redis, JSON file, memcached) may persist the passphrase
AWX/Tower job logs silently store the live credential
Fix:
module.exit_json(changed=False, passphrase=passphrase, _ansible_no_log=True)
Also add a documentation warning requiring callers to use no_log: true at the task level.
PoCs
Fig 1: PoC execution showing passphrase in plaintext output
Fig 2: Source code showing no_log=True on input (line 105) vs unprotected output (line 127) |
| Module: plugins/modules/nexmo.py
CVSS 3.1: 6.5 MEDIUM — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Issue: api_key and api_secret are declared no_log=True at the input level, but both credentials are immediately URL-encoded into a GET request as query parameters, bypassing all no_log protection.
Vulnerable Code (lines 82-93):
msg = {
"api_key": module.params.get("api_key"),
"api_secret": module.params.get("api_secret"),
"from": module.params.get("src"),
"text": module.params.get("msg"),
}
url = f"{NEXMO_API}?{urlencode(msg)}"
response, info = fetch_url(module, url, headers=headers)
Observed Output:
https://rest.nexmo.com/sms/json?api_key=a1b2c3d4&api_secret=MyS3cr3tK3y!!&from=AnsibleBot&to=15551234567&text=Hello
Exposure Vectors:
Ansible verbose output (-vvv) logs the full request URL
Vonage/Nexmo server access logs record credentials in query string
HTTP proxies, SIEM, and network inspection tools capture the full URL
AWX/Automation Controller network debug logs
Fix: Switch to POST with credentials in the request body:
data = urlencode({"api_key": api_key, "api_secret": api_secret,
"from": src, "to": number, "text": msg})
fetch_url(module, NEXMO_API, data=data, method="POST",
headers={"Content-Type": "application/x-www-form-urlencoded"}) |
| A flaw was found in the GStreamer gst-plugins-bad package. When processing a malformed H.266/VVC video stream with a crafted aspect ratio indicator value, the H.266 parser performs an out-of-bounds read of up to 8 bytes from adjacent memory. This flaw allows an attacker to craft a malicious H.266 video file or stream that, when processed by a GStreamer-based application, could leak limited memory contents through video metadata, potentially exposing sensitive information from the application's address space. |
| A flaw was found in GStreamer's gst-plugins-bad package. When processing a specially crafted H.264 video file containing malformed MVC or SVC extension slice NAL units, a 1-byte heap out-of-bounds read can occur during parsing. This happens when the parser attempts to check slice boundary information without first verifying that the NAL unit contains enough data beyond the extension header. An attacker could exploit this by tricking a user into opening a malicious H.264 video file, potentially causing the application to crash or leak a single byte of heap memory. |
| Spring Statemachine's Kryo-based persistence backends (JPA, MongoDB, Redis and ZooKeeper) deserialise persisted state-machine contexts without enforcing a class allowlist (CWE-502, deserialisation of untrusted data), which can lead to remote code execution inside the application JVM.
Affected versions:
Spring Statemachine 4.0.0 through 4.0.1
Spring Statemachine 3.2.0 through 3.2.4 |
| Fortra File Integrity Monitoring (FIM), formerly Tripwire Enterprise, versions prior to 9.4.0.1 contain a stored cross-site scripting (XSS) vulnerability in the Asset View UI component. An authenticated user with sufficient privileges to create or modify affected node or database configuration fields could store script content that may be rendered as HTML instead of safely escaped text when the affected Asset View UI content is displayed. |
| Poweradmin is a web-based DNS administration tool for PowerDNS server. Versions prior to 4.2.4 and 4.3.3 are vulnerable to CSV Injection (Formula Injection) in its log export functionality. User-controlled data — specifically the username field — is written to exported CSV files without sanitizing formula trigger characters (=, +, -, @). When an administrator exports activity logs and opens the resulting CSV in a spreadsheet application (Microsoft Excel, LibreOffice Calc, Google Sheets), any formula stored in a username is executed by the application. This can be used for phishing attacks against administrators or data exfiltration. Versions 4.2.4 and 4.3.3 patch the issue. |
| Poweradmin is a web-based DNS administration tool for PowerDNS server. Versions prior to 4.2.4 and 4.3.3 use the attacker-controlled `HTTP_HOST` request header as the authoritative source for building callback URLs in its OIDC, SAML, and logout authentication flows without any validation. An unauthenticated attacker can poison the `redirect_uri` sent to the Identity Provider, causing the IdP to redirect the victim's authorization code to an attacker-controlled server - resulting in full account takeover with no credentials required. Versions 4.2.4 and 4.3.3 patch the issue. |
| Fortra File Integrity Monitoring (FIM), formerly Tripwire Enterprise, versions prior to 9.4.0 may assign incorrect or elevated effective permissions to users created by the tetool import command while FIM is running, particularly when the import also creates or changes roles or role-permission relationships. |
| Missing cryptographic step in Caliptra Core Firmware (aes_256_gcm_update module) results in an incorrect GCM authentication tag. When the streaming AES-256-GCM API is used with empty AAD, the hardware GHASH accumulator state is not saved after the first update call, causing the final tag to exclude the first batch of processed ciphertext. Ciphertext produced by that call may be modified without the tag reflecting the change.
This issue affects Core Runtime Firmware: from 2.0.0 through 2.0.1, 2.1.0. |
