Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The email channel authorizes senders based on the parsed From header identity only. If upstream email authentication/enforcement is weak (for example, relaxed SPF/DKIM/DMARC handling), an attacker can spoof an allowlisted sender address and have the message treated as trusted input. Details Relevant code paths: - src/channels/emailchannel.rs:311 extracts sender identity from parsed message headers: - let from = parsed.from() ... a.address() ... - src/channels/emailchannel.rs:328 authorizes using that from value: - if !self.issenderallowed(&from) { ... } - src/channels/emailchannel.rs:87 onward (issenderallowed) performs allowlist/domain matching against the same header-derived value. - There is no in-channel validation of sender authenticity indicators such as SPF/DKIM/DMARC results before allowlist trust decisions. Result: - Trust decision is based on a potentially spoofable header field unless mailbox/provider-side anti-spoofing controls are strong and enforced. PoC 1.…
Recommended action: Upgrade to 0.7.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Workspace boundary enforcement currently has three related bypass risks. This issue tracks fixing all three in one pull request. Details R1 - Dangling Symlink Component Bypass - What happens: Path validation can miss dangling symlink components during traversal checks. - Why it matters: A symlink that is unresolved at validation time can later resolve to an external location. - Impact: Read and write operations may escape workspace boundaries. - Affected area: src/security/path.rs (checksymlinkescape). R2 - TOCTOU Between Validation and Use - What happens: The path is validated first, then used later for filesystem operations. - Why it matters: A concurrent filesystem change can swap path components after validation but before open/write. - Impact: Race-based workspace escape is possible. - Affected area: Filesystem and file-consuming tools that call validatepathinworkspace before I/O. R3 - Hardlink Alias Bypass - What happens: A file inside workspace can be a hardlink to an…
Recommended action: Upgrade to 0.7.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The generic webhook channel trusts caller-supplied identity fields (sender, chatid) from the request body and applies authorization checks to those untrusted values. Because authentication is optional and defaults to disabled (authtoken: None), an attacker who can reach POST /webhook can spoof an allowlisted sender and choose arbitrary chatid values, enabling high-risk message spoofing and potential IDOR-style session/chat routing abuse. Details Relevant code paths: - src/channels/webhook.rs:121 sets runtime default authtoken: None. - src/config/types.rs:910 also defaults webhook config authtoken to None. - src/channels/webhook.rs:224 (validateauth) explicitly allows requests when no token is configured. - src/channels/webhook.rs:128 defines WebhookPayload with identity fields fully controlled by caller input: - sender: String - chatid: String - src/channels/webhook.rs:421 performs allowlist authorization using payload.sender. - src/channels/webhook.rs:433 and…
Recommended action: Upgrade to 0.7.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
zeptoclaw implements a allowlist combined with a blocklist to prevent malicious shell commands in src/security/shell.rs. However, even in the Strict mode, attackers can completely bypass all the guards from allowlist and blocklist: - to bypass the allowlist, command injection is enough, such as ;, $() etc. - to bypass the REGEXBLOCKEDPATTERNS, argument injection is enough, such as the python3 -P -c "..." - to bypass the LITERALBLOCKEDPATTERNS, file name wildcards can do the work, such as cat /etc/pass[w]d Details In code src/security/shell.rs#L218-L243, one can see the allowlist only checks the first token and thus makes command injection possible. !self.allowlist.isempty() makes the empty allowlist overlook the allowlist check, if it is in ShellAllowlistMode::Strict mode, empty allowlist should direct reject all the commands. As the code in src/security/shell.rs#L18-L70, we can find the REGEXBLOCKEDPATTERNS only apply \s+ in between the command and arguments, making argument…
Recommended action: Upgrade to 0.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
zeptoclaw implements a blocklist to prevent dangerous commands running in android device shell, but this blocklist has several blocked commands with argements in the pattern literal, such as rm -f and rm -rf, this can be simply bypassed by using different orders for these arguments, such as rm -r -f or rm -fr etc. Details As in code src/tools/android/actions.rs#L413-L424, we can see the rm -f and rm -rf are hard coded and thus can be simply bypassed via rm -r -f or rm -fr etc. PoC Set up zeptoclaw with an Android tool and then run the command rm -f -r etc. Impact Unauthorized command executed in Android device. Credit @zpbrent
Recommended action: Upgrade to 0.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.