Search: development.we

A security vulnerability has been detected in Webkul Bagisto up to 2.4.4. This vulnerability affects unknown code of the file /admin/reporting/sales/ of the component Backend Reporting Endpoint. The manipulation leads to authorization bypass. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. The vendor confirms: "The reported issues were already identified through our internal security assessment process prior to this notification and are being handled through our established internal security and development lifecycle. Some of these items have already been addressed, while the remaining items are planned for resolution in upcoming product releases."

A weakness has been identified in Webkul Bagisto up to 2.4.4. This affects an unknown part of the file /admin/customers/search of the component Customer Search. Executing a manipulation of the argument Query can lead to information disclosure. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor confirms: "The reported issues were already identified through our internal security assessment process prior to this notification and are being handled through our established internal security and development lifecycle. Some of these items have already been addressed, while the remaining items are planned for resolution in upcoming product releases."

A security flaw has been discovered in Webkul Bagisto up to 2.4.4. Affected by this issue is some unknown functionality of the file /admin/customers/view of the component Backend Customer Detail Feature. Performing a manipulation of the argument ID results in authorization bypass. The attack may be initiated remotely. The exploit has been released to the public and may be used for attacks. The vendor confirms: "The reported issues were already identified through our internal security assessment process prior to this notification and are being handled through our established internal security and development lifecycle. Some of these items have already been addressed, while the remaining items are planned for resolution in upcoming product releases."

A vulnerability was identified in Webkul Bagisto up to 2.4.4. Affected by this vulnerability is an unknown functionality of the component Customer Item Deletion Endpoint. Such manipulation leads to improper access controls. The attack can be launched remotely. The exploit is publicly available and might be used. The vendor confirms: "The reported issues were already identified through our internal security assessment process prior to this notification and are being handled through our established internal security and development lifecycle. Some of these items have already been addressed, while the remaining items are planned for resolution in upcoming product releases."

A vulnerability was determined in Webkul Bagisto up to 2.4.4. Affected is an unknown function of the file /admin/customers/login-as-customer/ of the component Admin Customer Impersonation Feature. This manipulation of the argument ID causes authorization bypass. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. The vendor confirms: "The reported issues were already identified through our internal security assessment process prior to this notification and are being handled through our established internal security and development lifecycle. Some of these items have already been addressed, while the remaining items are planned for resolution in upcoming product releases."

Vite development server versions from 2.5.1 up to but not including 6.0.9 have a vulnerability that allows any website to send requests to the dev server and read responses due to permissive default CORS settings and lack of Origin header validation on WebSocket connections. This affects even local-only dev servers. The vulnerability can expose sensitive development files to malicious websites. A fix is available in newer Vite versions. Mitigations include configuring CORS origins, allowed hosts, and using HTTPS or updated browsers. Some mitigations are not possible without upgrading.

A signature verification bypass vulnerability exists in the OpenClaw CLI's Twilio voice-call webhook extension when the ngrok free-tier loopback compatibility option is enabled. This optional voice-call extension is disabled by default, and the bypass only occurs if the specific configuration option 'tunnel.allowNgrokFreeTierLoopbackBypass' is explicitly enabled. Exploitation requires the webhook endpoint to be publicly reachable, typically via a public ngrok URL used during development. An attacker could send forged webhook requests without a valid Twilio signature, potentially causing unauthorized webhook event handling and request flooding. The issue affects OpenClaw CLI versions from 2026.1.29 up to but not including 2026.2.14. A fix is available in version 2026.2.14, which removes the signature verification bypass while preserving trusted forwarded headers for correct signature validation.

Jewelbug is a China-based threat actor conducting dual operations: espionage campaigns targeting foreign governments and militaries, alongside a for-profit cryptocurrency fraud business administered from the same control panel. Operating as a small development team with role-based access controls and documented roadmaps, the group recorded over one million implant check-ins, 580,000+ stolen browser cookies, and 2,300+ exfiltrated emails between February and May 2026. Espionage attacks targeted government entities in the Middle East, Southeast Asia, and South Asia with confirmed intrusions. The group deploys the Antino backdoor, a malicious Chrome/Firefox extension called 'PDF Viewer,' and a Linux implant named ClientKing targeting servers and routers. The financially motivated arm operates as a registered Hunan company running industrial-scale SEO poisoning funneling Chinese-speaking victims to fake cryptocurrency exchange sites.

Malware#china-based#government espionageUnited States

**CVE:** This vulnerability corresponds to [CVE-2026-72792](https://nvd.nist.gov/vuln/detail/CVE-2026-72792). ### Summary `/api/tag/getTag` filters its results for reader roles through `FilterTagsByPublishIgnore`, which checks only the *visible* publish tier. Documents that are published but password-protected pass that check, so a reader who has never entered a document's publish password receives every tag label used inside it, together with occurrence counts. The project has already treated this exact tier mismatch as a vulnerability on a sibling path: commit `82e9ded42` ("Enforce publish access for graph nodes") moved the graph endpoint off the visible-only filter and onto a password-aware one. `FilterTagsByPublishIgnore` was not upgraded alongside it. ### Details | Item | Detail | |---|---| | Route | `kernel/api/router.go:194` `POST /api/tag/getTag` → `model.CheckAuth` → `getTag` | | Middleware | `CheckAuth` only: no `CheckReadonly`, no `CheckAdminRole` | | Guard | Present but at the wrong tier: visible-only, no password check | | Exposed | Every tag label (`#label#` text) and its occurrence count inside password-protected but visible documents | **The tier mismatch.** For reader roles, `getTag` filters via: ```go publishIgnore := GetInvisiblePublishAccess(publishAccess) tags = FilterTagsByPublishIgnore(publishIgnore, tags) ``` `FilterTagsByPublishIgnore` counts a label if `CheckPathAccessableByPublishIgnore(span.Box, span.Path, publishIgnore)` holds, then reads `label := util.UnescapeHTML(span.Content)`. `CheckPathAccessableByPublishIgnore` (`kernel/model/publish_access.go:183`) consults the invisible set only. It returns true for any visible document, including one carrying a publish password. The project's complete gate is `checkBlockTreeAccessableByPublishAccess` (`kernel/model/publish_access.go:225`), which ANDs that same visibility test with `password == "" || CheckPublishAuthCookie(...)`. The tag filter implements the first half and omits the second. The disclosed value is user-authored content, not a structural identifier: `span.Content` is the tag text an author wrote inside the document project codenames, personal names, client names, subject matter and the accompanying count reveals how heavily each appears. **Established as a defect by the project's own remediation.** Commit `82e9ded42` replaced the graph endpoint's visible-only `FilterGraphByPublishIgnore` with a filter that additionally resolves the document's publish password and validates `CheckPublishAuthCookie`. The reasoning that motivated that change applies unchanged here: same input shape, same visible-only body, same class of leaked material. `FilterTagsByPublishIgnore` retains the pre-fix pattern. **Verified unfixed.** At `v3.7.4-alpha.1`, `getTag` still calls `FilterTagsByPublishIgnore`, and that function's body still tests only `CheckPathAccessableByPublishIgnore`. No commit on the development branch touches `kernel/api/tag.go` or the tag filter (`git log` and `git log -S` both empty over that range). **Scope note on the remaining visible-only call sites.** Two further consumers of the `*ByPublishIgnore` tier were reviewed and are not claimed as vulnerabilities in this report: `listDocsByPath` (`kernel/model/filetree.go:1160`), which exposes document titles and is plausibly intentional for navigation, and the identifier-only filter, which returns no authored content. They are noted because the visible-only tier is now a repeated source of defects, and an audit of every `*ByPublishIgnore` call site is the durable remedy rather than a third individual patch. ### Proof of Concept Precondition: publish mode enabled (default port 6808); a published document that carries a publish password and contains at least one tag; a reader session that has not authenticated to that document. ``` POST http://127.0.0.1:6808/api/tag/getTag {} → 200 The returned tag tree includes labels sourced from the password-protected document, with counts, despite the session holding no publish auth cookie for it. ``` Differential check: request the document itself through a password-gated endpoint with the same session and observe that access is refused, while its tag labels remain present in the `getTag` response. ### Impact An anonymous reader in publish mode or any publish `RoleReader` enumerates the tag vocabulary of documents they are not authorized to open, along with usage counts. Tags are author-written free text, so this discloses subject matter, names and internal terminology from documents whose contents the publish password was configured to protect. Confidentiality-only. ### Suggested fix Replace `FilterTagsByPublishIgnore` with a password-aware filter mirroring the one introduced in `82e9ded42` for graph nodes: resolve each span's document password via `GetPathPasswordByPublishAccess` and require `CheckPublishAuthCookie` before the label is counted, in addition to the existing visibility test. More durably, audit

Multiple Use-After-Free vulnerabilities were found in the add_archive_element function in ld/ldmain.c of the GNU linker (ld), a component of binutils. The root cause is that plugin_maybe_claim() in ld/plugin.c frees the original BFD object via bfd_close/_bfd_delete_bfd when entry->the_bfd->my_archive == NULL, but the caller retains both the original abfd parameter and a shallow copy (orig_input.the_bfd) as dangling pointers. These dangling pointers are subsequently dereferenced at three distinct locations in add_archive_element: 1. Line ~1442: accessing abfd->my_archive via bfd_usrdata(abfd->my_archive) 2. Line ~1493: multiple accesses to abfd and abfd->my_archive in a conditional check and bfd_get_filename call 3. Line ~1525: dereferencing the shallow copy orig_input.the_bfd->my_archive in trace/verbose logging The vulnerability is triggered when LTO plugins are active (link_info.lto_plugin_active is true) and the input object has abfd->my_archive == NULL, which is a valid state for standalone object files. Red Hat builds binutils with --enable-plugins and --enable-lto, confirming the vulnerable code path is compiled in and reachable. An attacker who can supply a crafted object or archive file to a build process using LTO-enabled linking could exploit this flaw to cause a denial of service (linker crash via segmentation fault). Arbitrary code execution is theoretically possible through heap manipulation but is substantially mitigated by hardening measures including stack protector, FORTIFY_SOURCE, ASLR, and PIE. The attack surface is limited to build-time environments — the linker is a development tool not exposed in production runtime. The most realistic exploitation scenario is a supply chain attack introducing a crafted object file as a build dependency in CI/CD pipelines or development environments.

Yuxi is a large-model-based intelligent knowledge base and knowledge graph agent development platform. Prior to version 0.6.2, the project's authentication mechanism contains a flaw. In affected versions, the system does not sufficiently validate the identity token in the Authorization header — only performing a validity check. This allows an administrator token generated in another deployment instance or local testing environment to be used to access the backend management interfaces of a different affected instance. An attacker who obtains or constructs an acceptable administrator Authorization token may bypass normal login authentication and gain administrator privileges. This vulnerability could allow an attacker to access system configurations, invoke backend management APIs, create administrator accounts, and ultimately take over the system backend. This issue has been fixed in version 0.6.2. Before upgrading, users are advised to implement the following temporary measures: Set the environment variable `JWT_SECRET_KEY` to a non-default value, and configure a unique, sufficiently strong JWT/authentication key for each deployment instance; and/or avoid exposing backend management interfaces directly to the public network.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-7c4v-fwgw-9rf7. This link is maintained to preserve external references. ## Original Description Nuxt versions >= 4.4.7 and < 4.5.1, and >= 3.21.7 and < 3.21.10, contain an information disclosure vulnerability in the development server's Chrome DevTools workspace endpoint (GET /.well-known/appspecific/com.chrome.devtools.json). The endpoint's local-request gate (isLocalDevRequest) is header-based and trusts the attacker-supplied Host header rather than the connected peer address. When the dev server is bound to a network-reachable interface (e.g. nuxt dev --host) and experimental.chromeDevtoolsProjectSettings is enabled (the default), an unauthenticated attacker on the LAN can send a request with a spoofed Host header and no browser-specific headers (Sec-Fetch-Site, Origin, Referer) to retrieve the project's absolute filesystem root path (rootDir) and a persistent per-project workspace UUID. Production builds are unaffected. Fixed in 4.5.1 and 3.21.10.

The Head Mare APT group exploited a chain of vulnerabilities in TrueConf video conferencing servers to deploy PhantomCore and PhantomGraph backdoors. Attackers connected to unpatched TrueConf servers via port 4307/TCP without authorization, using vulnerabilities KLCERT-26-057 and KLCERT-26-058 to execute arbitrary code with NT AUTHORITY\SYSTEM privileges. They replaced legitimate TrueConf client installers with infected versions containing PhantomCore, and deployed a web shell for persistent access. The PhantomGraph backdoor utilized Microsoft OneDrive as command-and-control infrastructure. Affected TrueConf versions included 5.3.X through 5.3.9, 5.4.X through 5.4.9, and 5.5.X through 5.5.5. Multiple Russian organizations across various industries were targeted, including instrument manufacturing, electronics, transportation, energy, IT, and software development. The vulnerabilities were patched in June 2026.

Malware#arcbridge#bridgeheadBelarus+1

SAP ABAP Development Tools does not perform necessary authorization checks for certain functionality, allowing an attacker with low privileges to execute unauthorized database operations against SAP NetWeaver AS ABAP. Successful exploitation could allow the attacker to read sensitive data, modify application data, and disrupt access for legitimate users, resulting in high impact on confidentiality, integrity, and availability.

@aerodrome-finance/contracts is a malicious npm package that impersonates Aerodrome Finance. It carries no legitimate functionality; the published tarball contains only a package.json and an install-time payload (index.js). Both `preinstall` and `postinstall` run `node index.js || true`, so the code executes automatically when the package is installed. Version 1.0.0 harvests environment variables whose names match `KEY|TOKEN|SECRET|PASS|PRIVATE|MNEMONIC|RPC|AWS|GITHUB|NPM|KUBE|VAULT|AUTH|PGP|GPG|SEED|WALLET`, the contents of `~/.npmrc` and `~/.gitconfig`, and directory listings of `~/.ssh`, `~/.foundry/keystores`, `~/.config/hardhat`, and `~/.config/gcloud`, along with the hostname, username, working directory, and platform. The collected JSON is exfiltrated via an HTTPS POST to `https://webhook.site/326b0891-2093-4800-a4c1-686ce3e07b09`. Errors are swallowed so the install never visibly fails. Version 1.1.0, published roughly 2.5 hours after 1.0.0 for all six packages within the same ~9-second window, reads full file contents (up to 4000 bytes) instead of just listing them. New targets include `.aws/credentials`, `.aws/config`, `.ssh/id_rsa`, `.ssh/id_ed25519`, `.ssh/config`, `.kube/config`, `.docker/config.json`, `.netrc`, `.pgpass`, `.pypirc`, `.git-credentials`, and two GCP credential files (`application_default_credentials.json` and `legacy_credentials`) — the `~/.config/gcloud` directory listing is still collected too. It also reads local `.env`, `.env.local`, `.env.production`, `.env.development`, and `secrets.env` files from the working directory, and adds cryptocurrency wallet theft: key files from Solana, Anchor, NEAR, and Sui wallet paths, plus the first three files under `~/.foundry/keystores`. The credential regex gains BEARER, API, INFURA, ALCHEMY, HELIUS, QUICKNODE, ANKR, and PRIVATE_KEY to catch RPC and API provider tokens. Both versions exfiltrate to the same webhook.site endpoint. In 1.0.0, index.js opens with a fake comment claiming it is `@plumenetwork/nest-artifacts`, an unrelated install-time shim — `@plumenetwork/nest-artifacts` is not itself a malicious package, just a leftover label from whatever template the attacker reused across this batch, published by npm account `mssjeep843`. The fake comment was removed in 1.1.0. Five sibling packages from the same account impersonate Euler's EVC, Aerodrome Finance, Camelot AMM, and the BoringVault pattern, sharing this same webhook.site endpoint, byte-identical payload template, and 1.0.0-to-1.1.0 escalation. Two further packages from the same account (PyPI `dlmm` and `dlmm-sdk`, impersonating Meteora's DLMM SDK) ran an equivalent harvester and are tracked separately as MAL-2026-13728 and MAL-2026-13729. Any environment that installed either version should rotate the exposed secrets and treat harvested keys as compromised, prioritizing wallet private keys and RPC/API tokens if 1.1.0 was installed. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (2c46806c21e6a0f5a5593eca11bbd822991f566dc05eb50c7ec56f88b649c3be) Package name typosquats the legitimate @aerodrome-finance scope. Lifecycle hooks auto-execute index.js on npm install, which reads installer secrets from ~/.aws/, ~/.ssh/, ~/.kube/, ~/.docker/, ~/.netrc, ~/.npmrc, ~/.pypirc, ~/.git-credentials, gcloud/solana/anchor/sui key directories, Foundry keystores, and.env files, and scrapes process.env for keys matching KEY|TOKEN|SECRET|PASS|PRIVATE|MNEMONIC|AWS|GITHUB|NPM|WALLET|SEED. The collected data is POSTed to a hardcoded webhook.site endpoint via https.request from a detached child process (spawn(process.execPath, ['-e', src], {detached:true, stdio:'ignore'})) that sleeps 60-240 seconds before sending, to outlive install and scan windows. Sandbox/honeypot evasion is present: host regex checks for scan-/detonation/sandbox/ubuntu-fc-uvm prefixes, non-root/sandbox user checks, canarytoken/honey env checks, and a check for npm mirror registries. Static evidence confirms co-use of child_process, https, os, and fs, with os.hostname() and a POST to https.request in index.js.

@aerodrome-finance/slipstream is a malicious npm package that impersonates Aerodrome Finance's Slipstream concentrated-liquidity AMM. It carries no legitimate functionality; the published tarball contains only a package.json and an install-time payload (index.js). Both `preinstall` and `postinstall` run `node index.js || true`, so the code executes automatically when the package is installed. Version 1.0.0 harvests environment variables whose names match `KEY|TOKEN|SECRET|PASS|PRIVATE|MNEMONIC|RPC|AWS|GITHUB|NPM|KUBE|VAULT|AUTH|PGP|GPG|SEED|WALLET`, the contents of `~/.npmrc` and `~/.gitconfig`, and directory listings of `~/.ssh`, `~/.foundry/keystores`, `~/.config/hardhat`, and `~/.config/gcloud`, along with the hostname, username, working directory, and platform. The collected JSON is exfiltrated via an HTTPS POST to `https://webhook.site/326b0891-2093-4800-a4c1-686ce3e07b09`. Errors are swallowed so the install never visibly fails. Version 1.1.0, published roughly 2.5 hours after 1.0.0 for all six packages within the same ~9-second window, reads full file contents (up to 4000 bytes) instead of just listing them. New targets include `.aws/credentials`, `.aws/config`, `.ssh/id_rsa`, `.ssh/id_ed25519`, `.ssh/config`, `.kube/config`, `.docker/config.json`, `.netrc`, `.pgpass`, `.pypirc`, `.git-credentials`, and two GCP credential files (`application_default_credentials.json` and `legacy_credentials`) — the `~/.config/gcloud` directory listing is still collected too. It also reads local `.env`, `.env.local`, `.env.production`, `.env.development`, and `secrets.env` files from the working directory, and adds cryptocurrency wallet theft: key files from Solana, Anchor, NEAR, and Sui wallet paths, plus the first three files under `~/.foundry/keystores`. The credential regex gains BEARER, API, INFURA, ALCHEMY, HELIUS, QUICKNODE, ANKR, and PRIVATE_KEY to catch RPC and API provider tokens. Both versions exfiltrate to the same webhook.site endpoint. In 1.0.0, index.js opens with a fake comment claiming it is `@plumenetwork/nest-artifacts`, an unrelated install-time shim — `@plumenetwork/nest-artifacts` is not itself a malicious package, just a leftover label from whatever template the attacker reused across this batch, published by npm account `mssjeep843`. The fake comment was removed in 1.1.0. Five sibling packages from the same account impersonate Euler's EVC, Aerodrome Finance, Camelot AMM, and the BoringVault pattern, sharing this same webhook.site endpoint, byte-identical payload template, and 1.0.0-to-1.1.0 escalation. Two further packages from the same account (PyPI `dlmm` and `dlmm-sdk`, impersonating Meteora's DLMM SDK) ran an equivalent harvester and are tracked separately as MAL-2026-13728 and MAL-2026-13729. Any environment that installed either version should rotate the exposed secrets and treat harvested keys as compromised, prioritizing wallet private keys and RPC/API tokens if 1.1.0 was installed. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (d9834357b7108ed122b3c272b3f913e0d2e931ab3629e94227b61f787fbe2525) Package published as @aerodrome-finance/slipstream advertises 'Aerodrome Slipstream AMM contracts and ABIs' but ships only index.js, which is executed via preinstall and postinstall lifecycle hooks. On install, index.js enumerates process.env filtering keys matching a credential regex (KEY|TOKEN|SECRET|PASS|PRIVATE|MNEMONIC|AWS|GITHUB|NPM|WALLET|SEED|...), reads installer-side secret files including ~/.aws/credentials, ~/.ssh/id_rsa and id_ed25519, ~/.npmrc, ~/.netrc, ~/.docker, ~/.foundry/keystores, Solana/Sui key material, and.env files, serializes the collected data, and hands it off to a detached Node subprocess (spawn(process.execPath, ['-e', src], {detached:true, stdio:'ignore'}); ch.unref()) that sleeps 60-240 seconds before POSTing the JSON payload to https://webhook.site/326b0891-2093-4800-a4c1-686ce3e07b09. The code also bails out when hostname/user match sandbox indicators (scan-, detonation, sandbox, ubuntu-fc-uvm, honey, canarytokens, npmmirror), evading install-time sandbox observation. The package name impersonates the Aerodrome Finance DeFi project and the harvest list targets crypto/DeFi developers (wallet keystores, RPC provider tokens, Foundry/Solana/Sui keys).

ethereum-vault-connector is a malicious npm package that impersonates Euler's Ethereum Vault Connector (EVC) protocol. It carries no legitimate functionality; the published tarball contains only a package.json and an install-time payload (index.js). Both `preinstall` and `postinstall` run `node index.js || true`, so the code executes automatically when the package is installed. Version 1.0.0 harvests environment variables whose names match `KEY|TOKEN|SECRET|PASS|PRIVATE|MNEMONIC|RPC|AWS|GITHUB|NPM|KUBE|VAULT|AUTH|PGP|GPG|SEED|WALLET`, the contents of `~/.npmrc` and `~/.gitconfig`, and directory listings of `~/.ssh`, `~/.foundry/keystores`, `~/.config/hardhat`, and `~/.config/gcloud`, along with the hostname, username, working directory, and platform. The collected JSON is exfiltrated via an HTTPS POST to `https://webhook.site/326b0891-2093-4800-a4c1-686ce3e07b09`. Errors are swallowed so the install never visibly fails. Version 1.1.0, published roughly 2.5 hours after 1.0.0 for all six packages within the same ~9-second window, reads full file contents (up to 4000 bytes) instead of just listing them. New targets include `.aws/credentials`, `.aws/config`, `.ssh/id_rsa`, `.ssh/id_ed25519`, `.ssh/config`, `.kube/config`, `.docker/config.json`, `.netrc`, `.pgpass`, `.pypirc`, `.git-credentials`, and two GCP credential files (`application_default_credentials.json` and `legacy_credentials`) — the `~/.config/gcloud` directory listing is still collected too. It also reads local `.env`, `.env.local`, `.env.production`, `.env.development`, and `secrets.env` files from the working directory, and adds cryptocurrency wallet theft: key files from Solana, Anchor, NEAR, and Sui wallet paths, plus the first three files under `~/.foundry/keystores`. The credential regex gains BEARER, API, INFURA, ALCHEMY, HELIUS, QUICKNODE, ANKR, and PRIVATE_KEY to catch RPC and API provider tokens. Both versions exfiltrate to the same webhook.site endpoint. In 1.0.0, index.js opens with a fake comment claiming it is `@plumenetwork/nest-artifacts`, an unrelated install-time shim — `@plumenetwork/nest-artifacts` is not itself a malicious package, just a leftover label from whatever template the attacker reused across this batch, published by npm account `mssjeep843`. The fake comment was removed in 1.1.0. Five sibling packages from the same account impersonate Euler's EVC, Aerodrome Finance, Camelot AMM, and the BoringVault pattern, sharing this same webhook.site endpoint, byte-identical payload template, and 1.0.0-to-1.1.0 escalation. Two further packages from the same account (PyPI `dlmm` and `dlmm-sdk`, impersonating Meteora's DLMM SDK) ran an equivalent harvester and are tracked separately as MAL-2026-13728 and MAL-2026-13729. Any environment that installed either version should rotate the exposed secrets and treat harvested keys as compromised, prioritizing wallet private keys and RPC/API tokens if 1.1.0 was installed. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (e356d2defccd58232dcae91909871df86b18c3ba9adcaf07e0d754a57cf390fc) Package impersonates Euler Labs' 'Ethereum Vault Connector' Solidity project but ships a Node.js credential stealer as index.js, invoked automatically via preinstall and postinstall lifecycle hooks. On install, index.js filters process.env for keys matching KEY/TOKEN/SECRET/PASS/PRIVATE/MNEMONIC/AWS/GITHUB/NPM/WALLET and reads standard installer credential paths (~/.aws/credentials, ~/.ssh/id_rsa, ~/.ssh/id_ed25519, ~/.kube/config, ~/.docker/config.json, ~/.netrc, ~/.npmrc, ~/.git-credentials, ~/.config/gcloud, Solana/Sui/Anchor keys, ~/.foundry/keystores) and local.env files. Collected data is exfiltrated via a detached child node process that sleeps 60-240 seconds (to outlive the install sandbox) and POSTs a JSON body to https://webhook.site/326b0891-2093-4800-a4c1-686ce3e07b09. The script also bails out when hostname matches scan-/detonation/sandbox/ubuntu-fc-uvm patterns, username is scan/nonroot/sandbox, environment contains honey/canarytokens markers, or the npm registry is a known mirror — sandbox-evasion behavior confirming hostile intent.

In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.

Node.js is a software development platform for building fast and scalable network applications in the JavaScript programming language. Security Fix(es): * ip-address: ip-address: Cross-site scripting via improper HTML escaping of untrusted input (CVE-2026-42338) * undici: undici: Denial of Service due to unbounded memory growth via WebSocket frames (CVE-2026-12151) * nodejs: Node.js WebCrypto: Denial of Service via large input to subtle.encrypt() (CVE-2026-48933) * nodejs: Node.js: Information disclosure of proxy credentials via proxy tunnel error handling (CVE-2026-48615) * nodejs: Node.js: Authentication bypass due to TLS hostname handling and unicode dot separator mismatch (CVE-2026-48618) * brace-expansion: Brace-expansion: Denial of Service due to exponential-time complexity (CVE-2026-13149) * tar: Node-tar: Denial of Service via malformed tar archive header (CVE-2026-59874) * tar: node-tar: Denial of Service via crafted gzip bomb (CVE-2026-59873) 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.

### Impact When a Nuxt dev server is bound to a network-reachable interface (for example `nuxt dev --host` for on-device testing), the default-enabled Chrome DevTools workspace endpoint `GET /.well-known/appspecific/com.chrome.devtools.json` returns the absolute project root (`workspace.root`, i.e. `rootDir`) and a persistent per-project workspace UUID. `GHSA-rq7w-g337-39qq` added a gate (`isLocalDevRequest`) intended to restrict this endpoint to local requests, but that gate is header-based: it trusts request metadata rather than the connected peer address. A request with no `Sec-Fetch-Site`, `Origin`, and `Referer` headers (normal for a non-browser client such as `curl`) is treated as local, and the `Host` allow-list is compared against the attacker-supplied `Host` header. As a result, any unauthenticated host that can reach the dev server on the LAN can retrieve the project's absolute filesystem path and workspace UUID, for example with `curl -H 'Host: localhost' http://<dev-host-lan-ip>:3000/.well-known/appspecific/com.chrome.devtools.json`. This is information disclosure only: there is no file read, file write, or code execution reachable from the endpoint. It requires the dev server to be reachable beyond loopback and `experimental.chromeDevtoolsProjectSettings` to be enabled (it defaults to `true`). Production builds are unaffected, because the endpoint is registered only as a development handler. ### Patches Fixed in `nuxt@4.5.1` and `nuxt@3.21.10`. The endpoint now additionally requires the connected TCP peer to be a loopback address, verified from the socket rather than from request headers, so a non-loopback LAN client is rejected regardless of the `Host`, `Origin`, `Referer`, or `Sec-Fetch-*` headers it sends. The shared header-based check is left unchanged, so the CSRF / same-origin behaviour that other dev handlers rely on is preserved. After this fix, Chrome DevTools workspace auto-mapping only works when the browser reaches the dev server over loopback (`localhost` / `127.0.0.1` / `::1`), which matches the feature's intent (the browser and dev server sharing a filesystem). ### Workarounds - Do not bind the dev server to a non-loopback interface on an untrusted network, or restrict access to the dev port with a firewall. - Disable the feature by setting `experimental.chromeDevtoolsProjectSettings: false` in `nuxt.config`.