Search: execu-search.com

The npm package 'habinger' version 2.1.6 contains malicious code executed during its postinstall script. On Linux systems, it adds an attacker-controlled SSH public key to the authorized_keys file and modifies firewall rules to allow SSH access, enabling persistent remote access. Additionally, it searches for sensitive files such as Solana CLI keypairs and environment configuration files, uploading them to an attacker-controlled server. It also downloads scanning patterns to recursively search and exfiltrate matching files from the user's home directory or all logical drives on Windows. This behavior compromises system confidentiality and integrity.

CVE-2026-61162 is a high-severity vulnerability affecting Oracle Commerce Guided Search / Oracle Commerce Experience Manager version 11.4.0. It allows a low privileged attacker with logon access to the infrastructure to compromise the product, potentially leading to unauthorized creation, deletion, or modification of critical data. The vulnerability impacts confidentiality and integrity but does not affect availability. No official patch or remediation level has been confirmed yet by Oracle. The vendor advisory recommends applying security patches promptly but does not specify a fix for this vulnerability at this time.

CVE-2026-61147 is a vulnerability in Oracle Commerce Guided Search / Oracle Commerce Experience Manager version 11.4.0. It allows an unauthenticated attacker with logon access to the infrastructure to cause a hang or repeated crash, resulting in a denial of service. The vulnerability impacts availability but does not affect confidentiality or integrity. The CVSS 3.1 base score is 6.2, indicating a medium severity. No official patch or remediation level is currently confirmed in the vendor advisory.

CVE-2026-54159 is a critical vulnerability in the PrestaShop ps_facetedsearch module versions 3.0.0 up to but not including 4.0.4. The module improperly handles slider filter values from the URL without sufficient validation, leading to unsafe deserialization of user-controlled data. This allows an unauthenticated attacker to inject a malicious serialized PHP object into the internal cache, which upon deserialization writes an arbitrary PHP file to the server. The malicious file can be used as a webshell to execute commands remotely. The issue is fixed in version 4.0.4.

A flaw was found in PipeWire, a multimedia server. This vulnerability allows an attacker to escape sandboxed applications, such as Flatpak, by exploiting PipeWire's PulseAudio compatibility layer. An attacker with minimal permissions within a sandboxed environment can load a malicious library, leading to arbitrary code execution outside the sandbox and potential compromise of the user's system.

The Product Feed Manager For WooCommerce – Sell on 200+ Online Marketplaces plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via 's' Search Parameter in all versions up to, and including, 7.6.1 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.

WWBN AVideo is an open source video platform. Versions prior to 29.0 contain an unauthenticated Reflected XSS vulnerability through AVideo YouTubeAPI Gallery Pagination. The $_GET['search'] query parameter is concatenated directly into the href attribute of two pagination links in plugin/YouTubeAPI/gallerySection.php (lines 67 and 74) with no htmlspecialchars, no urlencode, and no allow-list check. An injected <script> element is then extracted by the AVideo Layout plugin and concatenated into a single trailing inline script block at the bottom of the page, where the browser executes it. Any unauthenticated attacker can lure a victim into following a crafted URL to execute arbitrary JavaScript under the AVideo origin, which can read non-HttpOnly cookies and issue authenticated AJAX requests as the victim, and when the victim is an administrator, it can perform any cookie-authenticated admin action (create user, promote to admin, change configuration, install plugin), escalating a single click into full administrative takeover. This issue has been patched by this commit: https://github.com/WWBN/AVideo/commit/f50fc033b7adb36f1ffd6640e7826468bdafdec3.

Cherry Studio versions 1.2.2 through 1.9.12, fixed in commit 1518530, contain a remote code execution vulnerability in SearchService that allows remote attackers to execute arbitrary code by delivering malicious JavaScript through controlled search provider content loaded into an Electron BrowserWindow configured with nodeIntegration enabled and contextIsolation disabled. Attackers who control a search engine provider, individual search result pages, or provider settings pages can execute JavaScript with full Node.js privileges, gaining access to fs, child_process, os, and process.env under the operating-system account of the Cherry Studio process.

CAI Content Credentials is affected by an Untrusted Search Path vulnerability that could result in arbitrary code execution in the context of the current user. Exploit depends on conditions beyond the attacker's control. Exploitation of this issue requires user interaction in that a victim must visit a maliciously crafted URL or interact with a compromised web page. Scope is changed.

polymarket-mcp-v2 is an information stealer and remote-access backdoor that runs automatically on `npm install`. It steals Solana keypairs, `.env` secrets and other credential files, and installs an attacker-controlled SSH key into `~/.ssh/authorized_keys`, then opens port 22 for persistent access. Any host that installed it should be treated as compromised: check `~/.ssh/authorized_keys` for an unrecognized key, check the firewall for a newly opened port 22, and rotate Solana keypairs, SSH keys and any secrets in reachable `.env` files. The payload is a redeployment of the levex-refa/lint-builder toolkit documented in the February 2026 dev-protocol GitHub organization compromise, against new C2 infrastructure. A postinstall hook (`node test.js`) requires index.js and calls two functions with no installer action. from_str_2 collects host identifiers, appends the attacker key to `~/.ssh/authorized_keys`, runs `sudo chown -R <user>:<user> ~/.ssh`, `sudo ufw enable`, `sudo ufw allow 22/tcp`, then recurses the filesystem for patterns fetched live from the C2 (`/api/scan-patterns`, `/api/block-patterns`) and uploads matches to `/api/v1`. from_str_1 does a narrower hardcoded search for id.json (Solana keypairs), config.toml and .env. The C2 (170.205.31.203:3001) served a Next.js panel titled "ENV Bot - HYPE"; a dev-mode error disclosed the operator path `C:\1\anti-server\bot-wallet-management-v1\`. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (cbccd8ee43d5fefa17eb83c5528b66a52315351a404aa54c4a32d1af0dbf238e) The package's postinstall hook loads index.js and executes routines that (1) recursively scan the install directory for id.json,.env, env, config.toml and Config.toml and POST their contents to http://170.205.31.203:3001/api/v1; (2) fetch an attacker-supplied SSH public key from http://170.205.31.203:3001/api/ssh-key, append it to ~/.ssh/authorized_keys, chown the.ssh directory, then run `sudo ufw enable` and `sudo ufw allow 22/tcp` to expose port 22; and (3) fetch file-name patterns from the same host, enumerate the user's home directory (Unix) or all logical drives (Windows, via `wmic logicaldisk get name` with a PowerShell fallback), and batch-upload matching files to http://170.205.31.203:3001/api/v1 with username and platform metadata. Module names, endpoint URLs, and API paths are hidden behind \u00xx unicode escapes and reversed-string constructions to evade static review. The behavior combines install-time credential/file exfiltration with a persistent SSH remote-access backdoor.

Dify before 1.16.0-rc1 contains a SQL injection vulnerability in the MyScale vector store backend that allows attackers to execute arbitrary SQL by supplying unsanitized search parameters to the search_by_full_text method without escaping or parameterization. Attackers can inject malicious SQL through the search parameters to read, modify, or delete data in the underlying ClickHouse database.

### 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`.

Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel Lucene Component. The camel-lucene producer reads the search phrase from an Exchange header (LuceneConstants.HEADER_QUERY) whose value was the plain string QUERY (and RETURN_LUCENE_DOCS for HEADER_RETURN_LUCENE_DOCS). Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that exposes a Lucene query operation behind an HTTP consumer (for example platform-http), any HTTP client could therefore set the QUERY header and have its value executed against the full-text index, overriding the query the route intended to run. Depending on what is indexed, this allows reading documents the request should not have access to (for example a match-all query returns the entire index, or the route's intended per-user filter can be replaced), and expensive regular-expression queries can consume significant CPU. No credentials are required when the HTTP consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set the query via the raw header name must use CamelLuceneQuery (and CamelLuceneReturnLuceneDocs) instead of QUERY / RETURN_LUCENE_DOCS. For deployments that cannot upgrade immediately, strip the attacker-controllable headers before the Lucene producer and set the query from a trusted source (for example removeHeader('QUERY') and removeHeader('RETURN_LUCENE_DOCS'), then setHeader('QUERY', constant(...)) at the start of the route).

A flaw has been found in zcaceres markdownify-mcp up to 1.1.0. This impacts the function saveToTempFile of the file src/Markdownify.ts of the component webpage-to-markdown/youtube-to-markdown/bing-search-to-markdown. This manipulation causes insufficiently random values. The attack is restricted to local execution. A high degree of complexity is needed for the attack. The exploitability is said to be difficult. The exploit has been published and may be used. The pull request to fix this issue awaits acceptance.

A vulnerability was determined in 666ghj BettaFish up to 1.2.1. Impacted is the function _deduplicate_results of the file InsightEngine/agent.py of the component InsightEngine search-result Deduplication. Executing a manipulation can lead to partial string comparison. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. The pull request to fix this issue awaits acceptance.

electron-updater allows for automatic updates for Electron apps. Prior to 26.15.0, AppImage targets built by app-builder-lib could use an empty path component when setting the LD_LIBRARY_PATH environment variable at runtime. This causes the current working directory to be added to the dynamic linker search path, which may allow an attacker to execute arbitrary code by placing a malicious shared library in the directory from which the AppImage is launched. This issue has been fixed in version 26.15.0.

In July 2025, threat actors compromised organizations through SEO poisoning campaigns targeting users searching for legitimate IT management tools. Users downloading trojanized installers for ManageEngine OpManager received Bumblebee malware, granting initial access. The attackers exploited the fact that users executing these IT tools were privileged administrators, enabling rapid lateral movement to domain controllers. They dumped credentials using wbadmin, created backdoor accounts with enterprise admin privileges, and installed RustDesk for persistent access. AdaptixC2 beacons were deployed for command and control. The threat actors conducted extensive reconnaissance, dumped LSASS memory across multiple systems, attempted Veeam credential theft, and exfiltrated data via SFTP using FileZilla. The intrusion culminated in Akira ransomware deployment across both root and child domains within 44 hours, with subsequent re-encryption two days later affecting the child domain.

PBackupVSS.exe in Matrix42 Empirum before 25.5 and 26.x before 26.2 creates a named pipe (\\.\pipe\PBackupVSS) with a DACL that grants GENERIC_READ and GENERIC_WRITE permissions to all authenticated users. A low-privileged local attacker can connect to this pipe and send crafted IPC messages to trigger execution of arbitrary commands with SYSTEM privileges via an untrusted search path. This allows privilege escalation by placing a malicious shadow.exe in a controlled working directory.

The Dokan: AI Powered WooCommerce Multivendor Marketplace Solution – Build Your Own Amazon, eBay, Etsy plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Product SKU in all versions up to, and including, 5.0.4 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with custom-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The malicious payload is delivered to site visitors — including unauthenticated users — when the store search widget inserts the unescaped AJAX response HTML into the DOM via jQuery's .html() method.

### Summary The `ExpressionDepthLimit` parser guard in Scriban does not actually stop parsing — it only logs a non-fatal error and lets recursive descent continue. As a result, a template containing a deeply nested expression (parentheses, array initializers, object initializers, or unary operators) drives the recursive-descent parser into a native stack overflow. The resulting `StackOverflowException` is **uncatchable** in .NET and **immediately terminates the host process**. Any application that parses an attacker-influenced template — or that passes attacker-controlled strings to `object.eval` / `object.eval_template` — can be crashed by a single small request (roughly an 8 KB payload). This is a denial-of-service. It affects both Scriban-native (`Template.Parse`) and Liquid (`Template.ParseLiquid`) syntax modes, which share the same expression parser. This re-opens two advisories that were reported as fixed: **GHSA-wgh7-7m3c-fx25** ("Uncontrolled recursion in parser → StackOverflow", reported fixed in 6.6.0) and **GHSA-p6q4-fgr8-vx4p** ("StackOverflow via nested array initializers bypasses ExpressionDepthLimit", reported fixed in 7.0.0). Both fixes are incomplete: the limit they rely on never halts recursion. **All releases 6.6.0 through 7.2.0 (current) are affected.** ### Details The depth guard is `EnterExpression()` in `src/Scriban/Parsing/Parser.Expressions.cs`: ```csharp // src/Scriban/Parsing/Parser.Expressions.cs:1209-1218 private void EnterExpression() { _expressionDepth++; var limit = Options.ExpressionDepthLimit; if (limit > 0 && !_isExpressionDepthLimitReached && _expressionDepth > limit) { LogError(GetSpanForToken(Previous), $"The statement depth limit `{limit}` was reached when parsing this statement"); _isExpressionDepthLimitReached = true; } } ``` When the limit is exceeded it calls `LogError(...)` and sets a flag. It does **not** throw, does **not** return a sentinel, and does **not** unwind the parse. `LogError` here uses the default `isFatal: false`, so it merely appends a message and sets `HasErrors` — parsing proceeds: ```csharp // src/Scriban/Parsing/Parser.cs:476-488 private void Log(LogMessage logMessage, bool isFatal = false) { Messages.Add(logMessage); if (logMessage.Type == ParserMessageType.Error) { HasErrors = true; if (isFatal) _hasFatalError = true; // not set on the depth-limit path } } ``` The flag `_isExpressionDepthLimitReached` is consulted **only** to avoid logging the same error more than once — no code path uses it to stop descending. Confirmed by full-repo search (`grep -rn "_isExpressionDepthLimitReached" src/`): it appears in exactly four places — the field declaration (`Parser.cs:40`), a reset to `false` (`Parser.cs:106`), and within `EnterExpression` the dedup test (`Parser.Expressions.cs:1213`) and its assignment to `true` (`:1216`). The only *read* is the dedup test on line 1213; nothing else reads it. `ParseExpression` calls `EnterExpression()` and then continues straight into the token switch with no flag check: ```csharp // src/Scriban/Parsing/Parser.Expressions.cs:113 + 181-182 EnterExpression(); try { ... case TokenType.OpenParen: leftOperand = ParseParenthesis(); // recurses back into ParseExpression ``` ```csharp // src/Scriban/Parsing/Parser.Expressions.cs:984-1001 private ScriptExpression ParseParenthesis() { var expression = Open<ScriptNestedExpression>(); ExpectAndParseTokenTo(expression.OpenParen, TokenType.OpenParen); expression.Expression = ExpectAndParseExpression(expression); // -> ParseExpression -> ParseParenthesis -> ... ... } ``` Both `Template.Parse` (Scriban-native) and `Template.ParseLiquid` (Liquid-compatibility) front-ends share this same expression parser, so both entry points are affected. So for input nested N levels deep, the parser recurses N levels deep regardless of `ExpressionDepthLimit`. There is no `RuntimeHelpers.EnsureSufficientExecutionStack()` call and no absolute recursion cap anywhere in the parser. Once the native thread stack is exhausted, the runtime raises `StackOverflowException`, which .NET does not allow to be caught and which tears down the entire process. The number of nesting levels required to overflow depends on the platform's thread-stack size (empirically around 4,000 levels on a default 1 MB stack); it is not a configurable mitigation. The same defective guard is what makes the array-initializer fix for GHSA-p6q4-fgr8-vx4p ineffective: `ParseArrayInitializer` was wrapped in `EnterExpression()/LeaveExpression()`, but because `EnterExpression()` only logs, the array path still overflows. The existing regression tests only assert `HasErrors == true` at a nesting depth of ~20 with a limit of 10 (`src/Scriban.Tests/TestParser.cs`); they never use a depth large enough to overflow the stack, so they pass while the protection does nothing against the actual DoS. **Runtime reachability without