Threat Intelligence Database

MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). From 0.17.0 until 0.22.0, validate_url_for_ssrf resolves the attacker-controlled X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url header host once at middleware time, but the outbound request is built with the raw hostname and resolves it again at connection time with no IP pinning. An attacker-controlled DNS-rebinding name can return a public IP during validation and 169.254.169.254 or another internal IP during connection, enabling unauthenticated server-side requests to cloud metadata or internal services. The flaw spans src/mcp_atlassian/utils/urls.py, src/mcp_atlassian/servers/main.py, and src/mcp_atlassian/servers/dependencies.py; validate_url_for_ssrf returns only a verdict rather than a pinned IP, UserTokenMiddleware processes the attacker-controlled headers before fetcher creation, and the Jira and Confluence fetchers use the raw hostname. This issue is fixed in version 0.22.0.

A vulnerability was detected in GH05TCREW PentestAgent up to cf882dabea3ed91cef016cdd115e5426315665a2. This vulnerability affects the function run_task of the file interface/main.py of the component MCP HTTP Server. Performing a manipulation results in os command injection. The attack is possible to be carried out remotely. The exploit is now public and may be used. This product adopts a rolling release strategy to maintain continuous delivery. Therefore, version details for affected or updated releases cannot be specified. The pull request to fix this issue awaits acceptance.

A vulnerability was found in getzep graphiti up to 0.30.2. Affected is an unknown function of the file server/graph_service/main.py of the component REST API. The manipulation results in improper authentication. The attack can be launched remotely. The pull request to fix this issue awaits acceptance.

A vulnerability was found in getzep graphiti up to 0.30.2. Affected is an unknown function of the file server/graph_service/main.py of the component REST API. The manipulation results in improper authentication. The attack can be launched remotely. The pull request to fix this issue awaits acceptance.

Bulletin ID: 2026-040-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 06/08/2026 11:45 AM PDT Description: The AWS AgentCore CLI (@aws/agentcore) is a developer tool for managing agent infrastructure lifecycle on Amazon Bedrock AgentCore. We identified CVE-2026-11393 in which improper neutralization of triple-quote characters during Python code generation may allow an authenticated user in the same AWS account to inject arbitrary Python code into the source file generated by the "agentcore add agent ‐‐type import" command. Specifically, the collaborationInstruction field of a Bedrock Agent collaborator association was interpolated into a triple-quoted Python docstring using single-quote escaping rather than triple-quote escaping. A user with bedrock:AssociateAgentCollaborator IAM permission could craft a collaborationInstruction value containing """ to break out of the docstring boundary in the generated main.py of the imported agent. If that generated file was subsequently executed - either via agentcore dev on the developer's local machine, or via agentcore deploy followed by agentcore invoke in the AgentCore Runtime environment - the injected Python would run with the credentials available in that context. Impacted versions: - @aws/agentcore >= 0.4.0 AND = 0.3.0-preview.7.0 and <= 1.0.0-preview.8 Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin.

### Summary `set_key()` and `unset_key()` in python-dotenv follow symbolic links when rewriting `.env` files, allowing a local attacker to overwrite arbitrary files via a crafted symlink when a cross-device rename fallback is triggered. ### Details The `rewrite()` context manager in `dotenv/main.py` is used by both `set_key()` and `unset_key()` to safely modify `.env` files. It works by writing to a temporary file (created in the system's default temp directory, typically `/tmp`) and then using `shutil.move()` to replace the original file. When the `.env` path is a symbolic link and the temp directory resides on a different filesystem than the target (a common configuration on Linux systems using tmpfs for `/tmp`), the following sequence occurs: 1. `shutil.move()` first attempts `os.rename()`, which fails with an `OSError` because atomic renames cannot cross device boundaries. 2. On failure, `shutil.move()` falls back to `shutil.copy2()` followed by `os.unlink()`. 3. `shutil.copy2()` calls `shutil.copyfile()` with `follow_symlinks=True` by default. 4. This causes the content to be written to the **symlink target** rather than replacing the symlink itself. An attacker who has write access to the directory containing a `.env` file can pre-place a symlink pointing to any file that the application process has write access to. When the application (or a privileged process such as a deploy script, Docker entrypoint, or CI pipeline) calls `set_key()` or `unset_key()`, the symlink target is overwritten with the new `.env` content. This vulnerability does not require a race condition and is fully deterministic once the preconditions are met. ### Impact The primary impacts are to **integrity** and **availability**: - **File overwrite / destruction (DoS):** An attacker can cause an application or privileged process to corrupt or destroy configuration files, database configs, or other sensitive files it would not normally have access to modify. - **Integrity violation:** The target file's original content is replaced with `.env`-formatted content controlled by the attacker. - **Potential privilege escalation:** In scenarios where a privileged process (running as root or a service account) calls `set_key()`, the attacker can leverage this to write to files beyond their own access level. The scope of impact depends on the application using python-dotenv and the privileges under which it runs. ### Proof of Concept The following script demonstrates the vulnerability. It requires `/tmp` and the user's home directory to reside on different devices (common on systemd-based Linux systems with tmpfs). ```python import os import sys import tempfile from dotenv import set_key # Pre-condition: /tmp must be on a different device than the target directory. tmp_dev = os.stat("/tmp").st_dev home_dev = os.stat(os.path.expanduser("~")).st_dev assert tmp_dev != home_dev, "Skipped: /tmp and ~ are on the same device (no cross-device move)" with tempfile.TemporaryDirectory(dir=os.path.expanduser("~")) as workdir: # File an attacker wants to overwrite target = os.path.join(workdir, "victim_config.txt") with open(target, "w") as f: f.write("DB_PASSWORD=supersecret\n") # Attacker pre-places a symlink at the path the application will use as .env env_symlink = os.path.join(workdir, ".env") os.symlink(target, env_symlink) before = open(target).read() # Application writes a new key -- triggers the cross-device fallback set_key(env_symlink, "INJECTED", "attacker_value") after = open(target).read() print("Before:", repr(before)) print("After: ", repr(after)) print("Symlink target overwritten:", target) ``` **Expected output:** ``` Before: 'DB_PASSWORD=supersecret\n' After: "DB_PASSWORD=supersecret\nINJECTED='attacker_value'\n" Symlink target overwritten: /home/user/tmp806nut2g/victim_config.txt ``` ### Remediation The fix changes the `rewrite()` context manager in the following ways: 1. **Symlinks are no longer followed by default.** When the `.env` path is a symlink, `rewrite()` now resolves it to the real path before proceeding, or (by default) operates on the symlink entry itself rather than the target. 2. **A `follow_symlinks: bool = False` parameter** is added to `set_key()` and `unset_key()` for users who explicitly need the old behavior. 3. **Temp files are written in the same directory** as the target `.env` file (instead of the system temp directory), eliminating the cross-device rename condition entirely. 4. **`os.replace()` is used instead of `shutil.move()`**, providing atomic replacement without symlink-following fallback behavior. Users are advised to upgrade to the patched version as soon as it is available on PyPI. ### Timeline | Date | Event | | ------------ | ---------------

CVE-2026-72581 is a server-side request forgery (SSRF) vulnerability in the duhow/xiaoai-patch project. It allows a remote attacker to make the Xiaomi smart speaker perform HTTP requests to arbitrary internal or external URLs. The vulnerability exists because the /auth endpoint in api/main.py uses a user-supplied URL parameter without validating the destination, enabling potential internal network scanning and access to internal services.

### Summary GHSA-7r34-79r5-rcc9's fix added `validate_url_for_ssrf`, which resolves the attacker-controlled `X-Atlassian-{Jira,Confluence}-Url` header host **once at middleware time** and trusts the result. But the outbound request is later built with the **raw hostname** and **re-resolves at connect time with no IP pinning**. An attacker-controlled rebinding DNS name returns a public IP on the guard's lookup (validation passes) and `169.254.169.254` / an internal IP on the request's lookup (the socket connects there) → unauthenticated SSRF to cloud metadata / internal services on the **patched** build. ### Relationship to CVE-2026-27826 / GHSA-7r34-79r5-rcc9 (incomplete fix — please read first) This is an **incomplete-fix sibling** of the published `GHSA-7r34-79r5-rcc9` (the `X-Atlassian-*-Url` header SSRF). That fix (PR #986/#1005) added a single middleware-time resolve + allowlist DNS-skip, but **does not pin the validated IP to the connection** — the fetcher re-resolves the raw hostname at connect time, so the documented SSRF mitigation is incomplete against DNS-rebinding. The other advisory `GHSA-xjgw-4wvw-rgm4` (file-write) is unrelated. Verified live (2026-06-27): neither advisory, nor any open PR/issue (`rebind`/`TOCTOU`/`getaddrinfo`/`pin` → 0), covers connect-time re-resolution. Filing as an incomplete-fix of GHSA-7r34 (not a standalone fresh SSRF). ### Affected `src/mcp_atlassian/utils/urls.py` + `servers/main.py` + `servers/dependencies.py`, HEAD `ba72540` (PyPI `mcp-atlassian`, patched ≥0.17.0). **CWE-918** (SSRF) via **CWE-367** (TOCTOU). ### Vulnerable code `utils/urls.py` `validate_url_for_ssrf` (≈184-205) resolves + validates, then returns a **string verdict, not a pinned IP**: ```python def validate_url_for_ssrf(url: str) -> str | None: # returns an error string or None — NO IP is pinned ... # resolves the host, checks each resolved IP is global, then DISCARDS the IP ``` `servers/main.py:526,534` calls it once in middleware. `servers/dependencies.py:544-561` then builds the fetcher with `url = <raw header hostname>` (no pinned IP, no custom resolver / cached-getaddrinfo adapter), so the actual request re-resolves the name. ### PoC (executed — boundary demonstration) The PoC loads the **real** `urls.py` by path (`importlib`, `sha256` printed) and drives the genuine `validate_url_for_ssrf`, simulating the two resolutions via `getaddrinfo`: ``` [CHECK ] validate_url_for_ssrf('http://rebind.attacker.example') -> None (getaddrinfo#1 = 93.184.216.34 global -> guard PASSED) [CONNECT] getaddrinfo call #2 returned 169.254.169.254 -> the socket connects HERE [PROOF ] guard validated IP 93.184.216.34 but connection targets 169.254.169.254 => SSRF on the PATCHED build [CONTROL] if guard SAW 169.254.169.254 at check time -> blocks it correctly [PIN ] validate_url_for_ssrf returns a verdict (None), NOT an IP; dependencies.py builds url=raw hostname -> NO pin ALL PoC ASSERTIONS PASSED — DNS-rebind TOCTOU bypass demonstrated. ``` **Honest scope of the PoC:** this is a **boundary** demonstration — it proves the structural TOCTOU (the guard validates an IP it then discards; the connection re-resolves an unpinned hostname). It does **not** demonstrate a live end-to-end SSRF on a running server; that additionally requires an attacker-controlled fast-rebinding authoritative DNS responder winning the resolve→connect window. Flagging this explicitly rather than overclaiming. ### Impact Same as parent GHSA-7r34 (unauth read of cloud-metadata IAM creds / internal-service reach), reachable again on the patched version. The `X-Atlassian-*-Url` headers are processed in `UserTokenMiddleware` before fetcher creation, so an unauthenticated/low-priv caller controls the host. ### Severity **High — CVSS v3.1 `AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N` ≈ 7.x**, aligned to the parent (8.2) with `AC:H` for the rebinding-race precondition. Honest caveat (above): the executed PoC proves the missing IP-pin structurally; a live exploit additionally needs an attacker rebinding-DNS. Not Critical. ### Remediation Pin the connection to the IP that `validate_url_for_ssrf` validated: use a custom resolver / cached-`getaddrinfo` `requests`-adapter (or pass the validated IP with a `Host` header), so the connect cannot re-resolve to a different address. ### Dedup / freshness (re-verified live 2026-06-27) Advisories `GHSA-7r34-79r5-rcc9` (original header SSRF this bypasses) + `GHSA-xjgw-4wvw-rgm4` (file-write, unrelated). Neither covers connect-time re-resolution / rebinding. PR [#986](https://github.com/sooperset/mcp-atlassian/pull/986)/[#1005](https://github.com/sooperset/mcp-atlassian/pull/1005) (the fix) add a single middleware-time resolve + allowlist DNS-skip, no pinning. `gh search prs/issues` for rebind/TOCTOU/getaddrinfo/pin → 0. First-party code. **Fresh** at HEAD `ba72540`.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (11bfe96b56a6615a50639b25de793e14044ea393c2029b26fa4e1b9e3dc5a22f) This package impersonates the Anthropic Claude SDK (name and description claim to be an 'Official Anthropic Claude SDK wrapper', author is 'anthropic-tools') but ships a multi-stage dropper. The package.json declares `postinstall: node lib/cli.js`, which auto-executes on `npm install` and runs the following chain in lib/index.js: 1. Hardcoded C2 over bare IPs: POSTs to four hardcoded IP addresses (107.189.20.82, 107.189.20.146, 104.194.134.33, 104.194.133.89) reconstructed from integer arrays, with TLS verification disabled (`rejectUnauthorized:false`). The JSON response is base64-decoded and written to disk as `main.py`, then executed via a detached Python process. 2. Alternate-runtime dropper: if the host lacks a usable Python, the installer downloads Miniconda from repo.anaconda.com via curl/wget into `~/.local/share/prometheus/miniconda` (Linux), runs `winget install Python.Python.3.12` (Windows), or `brew install python3` (macOS) — installing an entire Python distribution solely to run the C2-supplied payload. 3. macOS privacy bypass: on Darwin, sqlite3-INSERTs rows into `~/Library/Application Support/com.apple.TCC/TCC.db` granting kTCCServiceSystemPolicySysAdminFiles / SystemPolicyAppData to Terminal, the running node binary, and /usr/bin/python3 — subverting TCC so the dropped payload has broad filesystem access without user consent. 4. Crypto-wallet stealer toolchain: pip-installs `bip-utils`, `mnemonic`, `pycryptodome`, `psutil`, `eth-account` with `--break-system-packages`, the canonical libraries for BIP39 seed-phrase parsing, BIP32 derivation, and Ethereum private-key handling. 5. Persistence: writes a `.cs_v2` marker and `main.py` under disguised paths impersonating system directories (`~/.local/share/com.apple.sync` on macOS, `~/.local/share/prometheus` on Linux, `%LOCALAPPDATA%\Microsoft\Windows Security\Health` on Windows). Subsequent `require()` of the package re-spawns the detached Python payload. 6. Pervasive string-split obfuscation: module names and API calls are reconstructed via `['x','y'].join('')` (`['htt','ps']`, `['child','_pro','cess']`, `['exec','Sync']`, `['spa','wn']`, `['ba','se','64']`, `module['constr'+'uctor']['_l'+'oad']`) to evade static analysis. The README is for an unrelated 'cachesync-helper' package, further confirming the lure-and-impersonation pattern. ## Source: ghsa-malware (f1e490682c8dd38fd97c90b365eacf71086d64b57af905f96e58490ec35d5e6c) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it. ## Source: ossf-package-analysis (01d5845e6a8ba2bca29e99aaed593e5c7616c9ff89eb32d3d319dd65cf1839b0) The OpenSSF Package Analysis project identified 'free-anthropic-claude' @ 5.0.0 (npm) as malicious. It is considered malicious because: - The package executes one or more commands associated with malicious behavior.

DeepCode through commit c991dc2 contains a path traversal vulnerability in the SPA catch-all route in new_ui/backend/main.py that allows unauthenticated attackers to read arbitrary files by supplying percent-encoded path segments to the GET /{full_path:path} endpoint. Attackers can bypass Starlette's path normalization by encoding slashes as %2F and dots as %2E%2E, causing the joined path to traverse outside FRONTEND_DIST and exposing sensitive files such as SSH private keys, TLS certificates, and application secrets with a single HTTP request.