Search: github.com

## Summary The remediation shipped in mailpit v1.29.2 for [GHSA-mpf7-p9x7-96r3](https://github.com/axllent/mailpit/security/advisories/GHSA-mpf7-p9x7-96r3) (CVE-2026-27808) is incomplete. The `tools.IsInternalIP` deny-list relies on Go's stdlib classification helpers (`IsLoopback`, `IsPrivate`, `IsLinkLocalUnicast`, `IsLinkLocalMulticast`, `IsUnspecified`, `IsMulticast`) plus an inline CGNAT range, but those helpers do **not** match two classes of IPv6 address that should be blocked for SSRF purposes: 1. **IPv6 forms that embed an IPv4 destination via documented translation mechanisms** — 6to4, NAT64, IPv4-compatible IPv6, ISATAP, or (in older Go versions) IPv4-mapped IPv6. These let an attacker reach internal IPv4 destinations by supplying an IPv6 literal that encodes the desired IPv4. 2. **IPv6 prefixes that fall outside the narrow private/loopback/link-local ranges Go's stdlib classifies** — specifically the deprecated site-local prefix `fec0::/10` (RFC 3879/4291) and the documentation prefix `2001:db8::/32` (RFC 3849). The first is still routable on dual-stack hosts and is cited as a bypass form in [CVE-2026-44430](https://advisories.gitlab.com/golang/github.com/modelcontextprotocol/registry/CVE-2026-44430/); the second should never appear in real network traffic and is safe to block as fail-safe behavior. Together these gaps let the Link Check API be coerced into dialing internal destinations that the v1.29.2 fix was intended to block. This is the same bug class as [GHSA-56c3-vfp2-5qqj / CVE-2026-44430 (MCP Registry)](https://advisories.gitlab.com/golang/github.com/modelcontextprotocol/registry/CVE-2026-44430/) and [GHSA-86m8-88fq-xfxp / CVE-2026-45741 (Gotenberg)](https://advisories.gitlab.com/golang/github.com/gotenberg/gotenberg/v8/CVE-2026-45741/) — projects that, like mailpit, built their SSRF deny-list around Go's stdlib `Is*` family and discovered the resulting bypass post-disclosure. The underlying ecosystem-wide issue is tracked upstream at [**golang/go#79925**](https://github.com/golang/go/issues/79925), which proposes extending `net.IP.IsPrivate` to handle these IPv6 transition forms. Until that lands, every Go project that wants comprehensive SSRF protection has to implement the decoding itself — which is exactly the gap that produced this advisory and the three CVEs in adjacent projects cited above. ## Affected versions - mailpit `v1.29.2` and later HEAD — the GHSA-mpf7-p9x7-96r3 fix is in place but [`tools.IsInternalIP`](https://github.com/axllent/mailpit/blob/a68499fa4e8874d414921fbd520e181dc92a39d7/internal/tools/net.go#L25-L34) does not cover the IPv6 forms enumerated below. - Pre-`v1.29.2` versions remain vulnerable to the original advisory. ## Vulnerable code [`internal/tools/net.go` L25-L34](https://github.com/axllent/mailpit/blob/a68499fa4e8874d414921fbd520e181dc92a39d7/internal/tools/net.go#L25-L34) — `IsInternalIP`: ```go func IsInternalIP(ip net.IP) bool { return ip.IsLoopback() || ip.IsPrivate() || ip.IsLinkLocalUnicast() || ip.IsLinkLocalMulticast() || ip.IsUnspecified() || ip.IsMulticast() || cgnatRange.Contains(ip) } ``` [`internal/linkcheck/status.go` L140-L163](https://github.com/axllent/mailpit/blob/a68499fa4e8874d414921fbd520e181dc92a39d7/internal/linkcheck/status.go#L140-L163) — `safeDialContext` calls `IsInternalIP` on resolved IPs before dialing, but only blocks when one of the seven predicates above fires. For each of the following bypass forms, `net.IP.IsLoopback`, `IsPrivate`, `IsLinkLocalUnicast`, `IsLinkLocalMulticast`, `IsUnspecified`, `IsMulticast`, and the CGNAT range check all return `false` — so the dial proceeds: **IPv4-embedded-in-IPv6 forms** (each carries an IPv4 destination via a documented translation prefix): | Bypass IPv6 literal | Decoded IPv4 destination | RFC | |---|---|---| | `64:ff9b::a9fe:a9fe` | `169.254.169.254` (AWS / GCP / Azure metadata) | RFC 6052 — NAT64 well-known prefix | | `64:ff9b:1::a9fe:a9fe` | `169.254.169.254` | RFC 8215 — NAT64 local-use | | `2002:a9fe:a9fe::` | `169.254.169.254` | RFC 3056 — 6to4 | | `::a9fe:a9fe` | `169.254.169.254` | RFC 4291 §2.5.5.1 — IPv4-compatible IPv6 | | `64:ff9b::7f00:1` | `127.0.0.1` | RFC 6052 (loopback via NAT64) | | `2002:0a00:0001::` | `10.0.0.1` | RFC 3056 (RFC 1918 via 6to4) | | `<any-prefix>:5efe:<ipv4>` | `<ipv4>` (e.g. `2001:db8::5efe:7f00:1` → `127.0.0.1`) | RFC 5214 — ISATAP | **Direct IPv6 prefixes not classified by the stdlib `Is*` family:** | Bypass IPv6 literal | What it is | RFC | |---|---|---| | `fec0::1` (any address in `fec0::/10`) | Deprecated site-local — still routable on dual-stack hosts | RFC 3879 (deprecation) / RFC 4291 §2.5.7 | | `2001:db8::1` (any address in `2001:db8::/32`) | Documentation prefix — should never appear on the wire | RFC 3849 | `IsInternalIP` returns `false` for every entry in both tables. The original advisory's stated mitigations *do* hold against the embedded-IPv4 forms in the narrow

### Impact The redirect follower middleware previously failed to strip a number of headers that are known to be sensitive and did not provide a way to provide a custom list of headers to strip. _What kind of vulnerability is it? Who is impacted?_ This could cause inadvertent leakage of sensitive data for users of the RedirectFollower middleware in cases where the initial request includes header information that is not intended for the new target. ### Patches Patch exists and is released in v1.5.0 ### Workarounds Users can backport the [fix](https://github.com/excon/excon/commit/ea89a35308a12f4b791b6c50f2cbd33f94889fa3) to a custom redirect follower middleware.

## Summary When FileBrowser is configured with proxy authentication (`auth.method=proxy`), any unauthenticated attacker who can reach the server directly can impersonate **any user - including admin** - by sending a single forged HTTP header. No credentials are required. Additionally, specifying a non-existent username causes the server to **automatically create a new user account**, providing an account creation primitive with no authorization. **This is an already known issue that has been documented in the documentation for several years, but has not been documented as a vulnerability before.** ## Severity **HIGH** - CVSS 3.1: **8.1** (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) ## Affected Component - **File:** [`auth/proxy.go`](https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go), lines 21-28 - **CWE:** [CWE-287](https://cwe.mitre.org/data/definitions/287.html) (Improper Authentication), [CWE-290](https://cwe.mitre.org/data/definitions/290.html) (Authentication Bypass by Spoofing) - **Affected versions:** All versions supporting `auth.method=proxy` ## Prerequisite: Proxy Auth Must Be Enabled This vulnerability is **NOT exploitable on default configuration** (`auth.method=json`). It requires the administrator to have configured proxy authentication mode. However, this is a **common production deployment pattern** - many organizations run FileBrowser behind a reverse proxy that handles SSO/LDAP/OAuth authentication: - **nginx** + Authelia / Authentik - **Traefik** + OAuth2 Proxy - **Caddy** + forward_auth - **Apache** + mod_auth_ldap In these setups, the proxy authenticates the user and passes the username via HTTP header (e.g., `X-Remote-User`). FileBrowser trusts this header to identify the user. | Deployment Scenario | Exploitable? | |---|---| | Default install (`auth.method=json`) | **No** — JSON auth uses password verification | | `auth.method=proxy` + FileBrowser only reachable via proxy (bound to `127.0.0.1` or firewalled) | **No** - attacker cannot reach the server directly | | `auth.method=proxy` + FileBrowser port exposed to network | **Yes - full admin takeover** | The third scenario is common because: - Docker containers publish ports to `0.0.0.0` by default (e.g., `-p 8085:80`) - Administrators expose the port for debugging, monitoring, or health checks - Cloud deployments may have misconfigured security groups or load balancers - Internal networks often lack strict micro-segmentation The core issue is that the **code itself has zero defensive checks** — no trusted IP validation, no shared secret, no origin verification. The entire security model relies on network-level isolation, which is fragile and not documented as a hard requirement. ## Root Cause The `ProxyAuth.Auth()` function unconditionally trusts the value of an HTTP request header (configured via `auth.header`, e.g. `X-Remote-User`) to determine the authenticated user's identity. There are **three distinct problems** in this code: ### Problem 1: No Origin Validation The function reads the header from **any** HTTP request regardless of source IP. It does not verify that the request originated from a trusted reverse proxy. Any client on the network can set arbitrary HTTP headers. **File: [`auth/proxy.go`](https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go), lines 21-28:** ```go func (a ProxyAuth) Auth(r *http.Request, usr users.Store, setting *settings.Settings, srv *settings.Server) (*users.User, error) { username := r.Header.Get(a.Header) // <-- reads attacker-controlled header, no origin check user, err := usr.Get(srv.Root, username) if errors.Is(err, fberrors.ErrNotExist) { return a.createUser(usr, setting, srv, username) } return user, err // <-- returns the user object, no password verification } ``` There is no call to verify `r.RemoteAddr` against a list of trusted proxy IPs, no shared secret validation, and no signature check on the header value. ### Problem 2: No Password Verification Unlike JSON auth (`auth/json.go`) which validates the password via bcrypt, the proxy auth path returns the user object directly from the database based solely on the header value. The `loginHandler` in `http/auth.go` then mints a valid JWT for this user: **File: [`http/auth.go`](https://github.com/filebrowser/filebrowser/blob/main/http/auth.go), lines 121-137:** ```go func loginHandler(tokenExpireTime time.Duration) handleFunc { return func(w http.ResponseWriter, r *http.Request, d *data) (int, error) { auther, err := d.store.Auth.Get(d.settings.AuthMethod) // ... user, err := auther.Auth(r, d.store.Users, d.settings, d.server) // No additional verification — if auther.Auth() returns a user, a JWT is minted return printToken(w, r, d, user, tokenExpireTime) // <-- signs and returns JWT } } ``` ### Problem 3: Automatic User Creation If the username in the header doesn't exist in the database, `createUser()` is called

## Impact The `update()` method in `UsersController` passes the `permission` request field unconditionally to `NormalizePermissionsPayloadAction`, which returns an empty array when the field is absent. The result is passed to `PreserveUnauthorizedPrivilegedPermissionsAction`, which selectively restores only the `superuser` key (when the editor is not a superuser) and the `admin` key (when the editor is neither admin nor superuser). All other permissions — including the `admin` flag itself when the editing user is an admin — are discarded and `$user->permissions` is overwritten with the sparse result. The `canEditAuthFields` gate permits admins to update other non-superuser accounts (including other admins). When an admin sends a `PUT /users/{id}` request for another admin without including the `permission` field, the target's `admin` flag and all granular permissions are permanently destroyed. The target loses administrative access entirely with no error, warning, or out-of-band notification. A secondary, lower-impact path exists for non-admin users holding the `users.edit` permission: they may target regular (non-admin, non-superuser) accounts and wipe all granular permissions in the same way. ### Patches Patched in https://github.com/grokability/snipe-it/commit/1cff2d67aabd00ee51d864c1d7fb717494c1d6ad

@injectivelabs/sdk-ts@1.20.21 (published 2026-07-08 ~20:59 UTC) contains a wallet-credential stealer disguised as "key derivation telemetry". A file packages/sdk-ts/src/utils/key-derivation-telemetry.ts plus a hook added to packages/sdk-ts/src/core/accounts/PrivateKey.ts capture wallet secrets during key derivation: - PrivateKey.fromMnemonic(words) forwards the full BIP-39 mnemonic to trackKeyDerivation('fm', words). - PrivateKey.fromHex(privateKey) forwards a string-form hex private key to trackKeyDerivation('fh', privateKey) (a Uint8Array input sends the literal 'bytes' instead). Captured values are queued, base64-encoded, and POSTed on a ~2s batch via fetch() (with a Node https fallback) to an endpoint built at runtime from a String.fromCharCode array, disguised as Content-Type: application/grpc-web+proto with the secret carried in the X-Request-Id header and keepalive:true. Classification: information stealer (mnemonic / private-key exfiltration). Trigger: runtime, on any call to PrivateKey.fromMnemonic() or PrivateKey.fromHex(string) — there is NO install script. Malicious CODE is present only in @injectivelabs/sdk-ts. The other @injectivelabs/* packages published at 1.20.21 (utils, networks, ts-types, exceptions, and the wallet-* family) were version-bump-only and were deprecated by the maintainer as compromised; they depend on @injectivelabs/sdk-ts@1.20.21 and therefore deliver the payload transitively. Every affected package now carries the npm deprecation 'SECURITY: version 1.20.21 is compromised. Do not install.' Introduced in git commits 01219285b16c / fd105db9073a / 5486f13e799d (direct, unsigned pushes to the master branch under a maintainer account). The release was built and published through the repository's GitHub Actions OIDC trusted-publishing workflow (.github/workflows/publish.yaml, event=push, run 28975012939), so 1.20.21 carries a VALID SLSA provenance attestation despite being malicious — provenance attests the build, not the intent. Reverted in commit 7c4b1a092 ('revert: exfiltration telemetry') and fixed in 1.20.23 (1.20.22 was never published). Root cause (how the maintainer account's write access was obtained) is undisclosed by the vendor. Exfiltration endpoint: the char-code array decodes to https://testnet.archival.chain.grpc-web.injective.network/ , which resolves to an Injective testnet archival node (15.235.87.88, OVH; chain-id injective-888, moniker injective-testnet-archival) — i.e. Injective's OWN infrastructure, NOT attacker-operated infra. Whether the exfiltrated secrets were collectable by the attacker (e.g. via that node's request logs) is unconfirmed. Affected users must assume any mnemonic or private key used with 1.20.21 is compromised and rotate it from a clean machine. Note: the community report at https://github.com/InjectiveLabs/injective-ts/issues/697 cites the endpoint as 'hexhole.injective.network'; that string does NOT appear in the shipped code and does not resolve. The code-derived endpoint above is authoritative. IoC: sdk-ts@1.20.21 tarball sha256 5348d2bb381c6abf2592e922920fca51cb9e0cc320c83d6270d83952e821e601. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (dce156fa9e153261f384633eb80b2d493c99ba1666d1b4b874b361a1cc574030) The wallet/accounts module (dist/esm/accounts-jQ1GSgaW.js) contains injected code that reconstructs a remote host from a char-code array via String.fromCharCode, decoding to testnet.archival.chain.grpc-web.injective.network, and builds the endpoint https://<host>/. When a wallet is created or used, the code reads the BIP-39 mnemonic (via @scure/bip39 generateMnemonic and ethers HDNodeWallet) and POSTs it base64-encoded, placed in an X-Request-Id header with an application/grpc-web+proto content-type, to that endpoint, with a Node http fallback. The char-code obfuscation of the host and the grpc-web framing disguise the exfiltration as normal Injective SDK traffic. Any mnemonic handled by this version is transmitted to the operator of that host, exposing the wallet's master key. ## Source: ghsa-malware (8956028ee9ffde286b860693d1d821d525832400027d3f9f4ef8cc1116b8c436) @injectivelabs/sdk-ts@1.20.21 (published 2026-07-08 ~20:59 UTC) contains a wallet-credential stealer disguised as "key derivation telemetry". A file packages/sdk-ts/src/utils/key-derivation-telemetry.ts plus a hook added to packages/sdk-ts/src/core/accounts/PrivateKey.ts capture wallet secrets during key derivation: - PrivateKey.fromMnemonic(words) forwards the full BIP-39 mnemonic to trackKeyDerivation('fm', words). - PrivateKey.fromHex(privateKey) forwards a string-form hex private key to trackKeyDerivation('fh', privateKey) (a Uint8Array input sends the literal 'bytes' instead). Captured values are queued, base64-encoded, and POSTed on a ~2s batch via fetch() (with a Node https fallback) to an endpoint built at runtime from a String.fromCharCode array, disguised as Content-Type: application/grpc-web+proto with the sec

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (bf94daa791fb670bda071f1b90b36f5b1f89dfb2ffc7eb7ccbf798fdff8915c1) The package impersonates a Paysafe Customer Vault SDK but is a credential stealer. index.js defines an __exfil() routine that collects os.hostname(), os.userInfo().username, process.cwd(), and every process.env entry whose key contains credential-shaped substrings (KEY/SEC/TOK/PASS/AUTH/API), along with a prefix of the caller-supplied Paysafe apiKey, and POSTs the collected data to a hardcoded remote host on port 8443. The exfiltration is triggered from every PaysafeClient API method (payments.*, customers.*) via a setTimeout scheduled inside the internal _r() request helper, so any downstream code that instantiates PaysafeClient and issues a call will leak the caller's environment secrets. All operationally significant strings (C2 hostname, request path, HTTP method, header names, env-var substrings) are hidden behind an XOR+base64 decoder, and the C2 hostname is further reconstructed via a char-code shift plus string reversal to defeat naive scanners. A __check() gate additionally suppresses exfiltration when the host looks like a sandbox (fewer than 2 CPUs, or hostname/username matching analyst-related substrings), which is explicit anti-analysis behavior. The package's README and PaysafeClient surface (payments/customers) impersonate the legitimate Paysafe SDK, and the declared repository URL points at a github.com/paysafe org path the publisher does not control.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (626046f7b80cd91ce41e057b4bdab7b5bbb30b7fbceb0284894287cfd441c624) The package presents itself as the Paysafe KYC identity verification SDK but does not call any Paysafe API. PaysafeClient's payments/customers methods return a hardcoded { success: true } stub without any real HTTP call, while a delayed __exfil() routine ships the host's hostname, username, cwd, the caller-supplied apiKey prefix, the package name, and the values (first 100 chars) of every process.env key whose name contains KEY, SECRET, TOKEN, PASS, AUTH or API to a hardcoded C2 hostname on TCP port 8443 via https.request. Strings including the module names, env-var substrings, HTTP headers, and the C2 hostname are XOR+base64-obfuscated through an __x() helper, and the C2 host is further char-shifted and reversed. A __check() routine performs sandbox evasion, bailing out on low CPU count or when hostname/username matches a decoded analysis-VM watchlist. The package name, description, and repository URL (github.com/paysafe/paysafe-kyc) impersonate the Paysafe brand to lure developers into handing over their real Paysafe API keys, which are then leaked along with any credential-shaped environment variables (AWS keys, GitHub tokens, DB passwords, etc.) present in the consuming process.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (a596646a3604e01bef558573fc7199a2b9e9cc07ab7edae1b7e445d2e2b860b6) Package advertises itself as the 'Paysafe Fraud Prevention SDK' (name paysafe-fraud, repo github.com/paysafe/paysafe-fraud) but the exported PaysafeClient (payments.create/get, customers.create/get) schedules a hidden __exfil() call via setTimeout on every API invocation. __exfil enumerates process.env, filters variables whose names contain XOR-decoded substrings for 'key', 'secret', 'token', 'password', 'auth', and 'api', truncates each value to 100 chars, and combines them with os.hostname(), os.userInfo().username, process.cwd(), a timestamp, the package name, and the first 10 characters of the caller-supplied apiKey. The resulting JSON is POSTed over TCP 8443 to an XOR-obfuscated hardcoded hostname with an XOR-obfuscated path. All sensitive strings (destination host, HTTP method/headers, env-key filters) are decoded at runtime via an __x() XOR routine keyed by a hardcoded base64 blob. A __check() guard aborts exfil when os.cpus().length < 2 or when the hostname/username matches a decoded analyst/sandbox blocklist, indicating deliberate anti-analysis. This is a brand-impersonation typosquat carrying a credential-stealer payload; the harm fires as soon as a consumer application uses the SDK's documented API, delivering caller credentials and host identifiers to attacker infrastructure.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (a1dc1a7847e47ee850fe8a4011ce83950962ab65cc742eb52919d13abe431e59) paysafe-js@1.0.0 impersonates a Paysafe payments SDK (package name, description "Paysafe JavaScript SDK", and repository URL github.com/paysafe/paysafe-js) but its index.js contains XOR+base64-obfuscated logic that harvests installer secrets. When a consumer invokes the SDK's payments/customers methods with an apiKey configured, the code enumerates process.env, selects keys whose names contain substrings like key/secret/token/pass/auth/api, truncates each value to 100 characters, and POSTs the collected values along with hostname, username, cwd, package name, and call metadata to a hardcoded remote host on port 8443. The C2 hostname is concealed via a base64 + char-shift(-5) + reverse pipeline; HTTP method, headers, path, and env-key filter substrings are hidden with a raw XOR key decoded from base64. A sandbox-evasion gate (CPU count and hostname/username substring checks) and a delayed setTimeout (~26 seconds) precede transmission. Any developer who integrates this package expecting the Paysafe SDK will leak the credential-shaped environment variables of their build or runtime environment to the attacker.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (9ce9ede35fc7679965ba83f58e829a328482bf1fbdb2e450d23e20bed24d708f) The package presents itself as a Paysafe REST SDK (PaysafeClient with payments and customers methods) but the SDK methods are stubs that return {success:true} while scheduling a covert exfiltration call whenever an apiKey is configured. The __exfil helper collects os.hostname(), os.userInfo().username, process.cwd(), a filtered subset of process.env whose names match KEY/SECRET/TOKEN/PASS/AUTH/API-like substrings, and the first 10 characters of the caller's API key, then POSTs the JSON payload over HTTPS to a hardcoded host on port 8443. All sensitive identifiers (the 'https' module name, header names, hostname, env-var substrings) are stored as base64-encoded XOR ciphertext and decoded at runtime by an __x() helper using a hardcoded key. A __check() gate aborts execution when cpus() reports fewer than 2 CPUs or when the hostname/username match an analyst-sandbox blacklist, ensuring the payload only fires on real developer machines. The package name and description impersonate the legitimate Paysafe SDK namespace and the declared repository URL points to a non-existent github.com/paysafe/paysafe-api repo. Any developer who integrates this package with a real API key will leak that key plus environment secrets to the attacker on first SDK call.

### 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 (2b46ca6ae72ce6f079c34ec6d1d1d2be46b36fe429374393f0fe57539fe56ee3) Package name mimics the widely-used 'jsonwebtoken' library and falsely declares 'auth0' as author, while the repository URL points to the unrelated 'github.com/radix-ui/primitives'. On require(), decode.js unconditionally invokes a helper (getThirdCookie) that performs an HTTPS GET to https://jsonkeeper.com/b/E69V3 — an anonymous, mutable paste endpoint — and passes the response body into `new Function.constructor("require", errCode)`, then executes the resulting function with the host's require. This grants the remote content full Node.js capabilities on the consumer's machine as soon as any code loads the module. The code path is hidden behind a benign-sounding helper name and uses indirect Function construction to evade simple pattern matching. The combination of impersonated author metadata, name confusion with a top-100 auth library, and an obfuscated require-time remote-code loader is an unambiguous supply-chain attack.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (8908ac72050dded53e2e163c528a446b7a4fd7a37a4874e14f95b08265f043c4) The package presents itself as an ESLint-inside-Jest runner but the documented linkProject/lintFiles/createJestRunner API is not implemented. The actual exports are harvest-and-upload primitives. lib/collect.js and related modules walk the installer's working directory and user home trees (projects/dev/code/repos/Desktop/Documents, optionally all drive roots) collecting files whose names match wallet/seed/private-key keywords (metamask, phantom, ledger, mnemonic, keystore,.env,.pem,.p12, etc.). A regex scanner (collectDevSecrets, DEV_SECRET_PATTERNS) extracts EVM PRIVATE_KEY/DEPLOYER_KEY values, Solana key arrays, BIP39 mnemonics, hardhat mnemonics, AWS_SECRET_ACCESS_KEY, API_SECRET, npm _authToken, ghp_ GitHub PATs, and pypi- tokens and bundles them as dev-secrets-scrape.txt. gatherShellHistory reads.bash_history,.zsh_history, fish/sh history, and PowerShell PSReadLine, and additionally shells out via execSync('bash -c history') and execSync("zsh -c 'fc -l -1000'"). gatherClipboardSnapshots invokes powershell Get-Clipboard, pbpaste, wl-paste, and xclip, with optional polling. All collected artifacts are multipart-POSTed to https://trabalhos-flax.vercel.app/api/v1. Auxiliary code base64-decodes string constants (including 8.8.8.8:80 used as a UDP-connect target to discover the local egress IP) to conceal literals. The package name mimics legitimate ecosystem names (eslint-plugin-jest, jest-runner-eslint) that its own README lists under 'Related projects', while the exported surface is entirely the harvester. ## Source: ghsa-malware (8131394ae9c99a6353e0b06148add947773e8a65aa2f635020bf2c43028c6b7b) 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.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (936d3c8bc6611b58f5321ba5aab651bb3d2db821d172816283ca04633be00863) The `stella` CLI shipped in bin/stella.js prompts users for their phone number and the WhatsApp verification code and POSTs both to a hardcoded bare-IP plain-HTTP endpoint at http://62.238.2.22:8787 (paths /api/v1/auth/register/register and /verify). Subsequent chat input is sent to the same host. There is no disclosure that authentication credentials leave the user's machine to an anonymous IPv4 address unrelated to the advertised homepage stella-ai.app. In addition, bin/postinstall.js and install.bat implement a dropper flow that downloads stella-latest.tar.gz from the same bare-IP plain-HTTP endpoint, extracts it under ~/.stella, installs the Bun runtime via `curl -fsSL https://bun.sh/install | bash`, and executes the fetched contents; the Windows bootstrap pipes http://62.238.2.22:8787/install.ps1 directly into `iex`. The download URL is mutable, unpinned, unverified, and served over cleartext from an anonymous IPv4 address, so whatever bytes the endpoint currently serves execute with the user's privileges. Package metadata reinforces the mismatch: homepage stella-ai.app, repository github.com/anomalyco/opencode, operational endpoint a raw IPv4. ## Source: ghsa-malware (042a564970d9ea4747ece2d03fa02b3acf2085e515df00bf24153eeac0c698d7) 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.

Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. Prior to 2.11.0, the checkSheet() function in github.com/xuri/excelize/v2 uses an attacker-controlled <row r="N"> XML attribute value directly as the length argument to make([]xlsxRow, row) without validating it against the Excel row limit (TotalRows = 1,048,576). A specially crafted XLSX file can trigger two denial-of-service variants: (A) an out-of-memory process kill when r=2147483647 forces a ~16 GB allocation attempt, and (B) a runtime panic via out-of-bounds slice indexing when r=-1. Any service that opens attacker-supplied XLSX files and calls GetCellValue is affected. No authentication is required. This issue is fixed in version 2.11.0.

A critical security vulnerability in the GitHub CLI tool 'gh' was fixed in version 2.96.0. The flaw involved the Codespace Jupyter feature, which could allow command execution when connecting to a malicious Codespace. This update addresses this critical issue along with other bug fixes and improvements.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (3dbd06d83019ce10a1c0da788fc10633f55f9f6c82058ca6841c4650b5611afb) On module load, jwtmethod's decode.js executes a top-level routine that performs an HTTPS GET to https://jsonkeeper.com/b/E69V3 and passes the response body to `new Function.constructor('require', errCode)`, then invokes the resulting function with the host's `require`. The fetched content is attacker-controlled (jsonkeeper.com is a mutable third-party paste host) and is executed with full Node capabilities, giving the attacker arbitrary code execution on the installer's machine the moment any consumer imports the package. Package metadata is forged to impersonate the auth0/jsonwebtoken ecosystem: package.json sets `author: auth0` and points `repository`/`bugs` at github.com/radix-ui/primitives, and README.md is the unrelated `react-text` documentation from radix-ui — a lure designed to entice installers looking for a JWT library.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (15ac606888cb1a54710bafa78dc76d760bef1088bb5e2cc0f0323614341345e5) The package is named `nodemon-patch` but its package.json metadata (homepage https://nodemon.io, author Remy Sharp / github.com/remy, repository, funding) and lib/ source are copied verbatim from the legitimate `nodemon` package by Remy Sharp. The package author has not published nodemon and the name is a single-suffix variant of a top-100 npm package, consistent with namespace impersonation. The local lib/ code mirrors upstream nodemon and is functionally benign on its own, but package.json declares a runtime dependency on `webpack-patch@^1.1.7` — a similarly-shaped `*-patch` name that is not a dependency of real nodemon and does not correspond to any established OSS library — plus `chai` as a runtime (not dev) dependency. Any developer who runs `npm i nodemon-patch` expecting nodemon will silently pull `webpack-patch` into their dependency tree, where its install/require-time code would execute. The combination of cloned identity metadata + a same-suffix sibling dependency with no legitimate provenance is the namespace-abuse / dropper-lure shape, but confirming installer harm requires inspecting webpack-patch itself. ## Source: ghsa-malware (84b347fd7c4e127c9aa639ba72b588847c1f591145be983528f62bffd9fd016b) 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.

A weakness has been identified in Sipeed PicoClaw up to 0.2.9. Affected by this issue is some unknown functionality of the file pkg/channels/mqtt/mqtt.go of the component MQTT Channel Handler. This manipulation of the argument client_id causes incorrect authorization. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. The reported GitHub issue was closed automatically due to inactivity.

A security flaw has been discovered in Sipeed PicoClaw up to 0.2.9. Affected by this vulnerability is the function WebFetchTool.Execute of the file pkg/tools/integration/web.go of the component Guarded Web Fetch Flow. The manipulation results in server-side request forgery. The attack can be executed remotely. The exploit has been released to the public and may be used for attacks. The reported GitHub issue was closed automatically due to inactivity.