@greenlake/common-context is a dependency-confusion package: it is described as a "Compatibility shim", uses inflated version numbers, and its README calls it an "authorized dependency-confusion test". Each listed version (99.0.1, 3.0.0) has a postinstall script that runs `node beacon.cjs` on npm install, and index.js calls the same code when the package is imported; it POSTs the hostname, install path and current working directory over plain HTTP to `http://185.158.107.175:8787/_ah/dc`, and index.js exports a Proxy that returns no-op functions so builds importing the real package keep running. The npm account wiseke published 14 such packages under the @greenlake, @sxm-web, @drone-js-ext and @ppa-web-components scopes between 2026-10-23 21:23 and 2026-10-25 14:28 UTC; index.js is byte-identical to that of ph-common (MAL-2026-1809), which sends to the same endpoint.
---
_-= Per source details. Do not edit below this line.=-_
## Source: amazon-inspector (8ee1e5c23e641cce920808500ad850f4965adeb982b4c14233901c80c2cfb039)
The package self-describes as a 'Compatibility shim' and exports an inert Proxy that returns no-op functions for every property, providing no functional API. Its only runtime behavior is a beacon in beacon.cjs that fires both from the npm postinstall lifecycle hook and on require() via index.js. The beacon collects the installer's OS hostname, __dirname install path, and process.cwd() (which commonly embed the Unix username and internal project/repo names) along with Node version, and POSTs them as JSON to the hardcoded plaintext bare-IP endpoint http://185.158.107.175:8787/_ah/dc with an x-beacon-package header identifying the resolving package. The scoped name @greenlake/* mimicking an internal namespace, the inert public API, and the automatic callback to a hardcoded bare-IP operator on install and import together match the shape of a dependency-confusion probe: resolving this package on an installer's machine silently discloses internal host, user, path, and namespace information to an external operator the installer did not opt into.
## Source: ghsa-malware (09b757ef91607a1bfe1b7e02eb0fc5e2d2647503898e30d04769ac1a5fc5385b)
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.
@greenlake/auth is a dependency-confusion package: it is described as a "Compatibility shim", uses inflated version numbers, and its README calls it an "authorized dependency-confusion test". Each listed version (3.0.0) has a postinstall script that runs `node beacon.cjs` on npm install, and index.js calls the same code when the package is imported; it POSTs the hostname, install path and current working directory over plain HTTP to `http://185.158.107.175:8787/_ah/dc`, and index.js exports a Proxy that returns no-op functions so builds importing the real package keep running. The npm account wiseke published 14 such packages under the @greenlake, @sxm-web, @drone-js-ext and @ppa-web-components scopes between 2026-10-23 21:23 and 2026-10-25 14:28 UTC; index.js is byte-identical to that of ph-common (MAL-2026-1809), which sends to the same endpoint.
---
_-= Per source details. Do not edit below this line.=-_
## Source: amazon-inspector (d51386d7bf7b3357a9ea920b99fa08f3c2d37532e877f33a5d8d0a78c12702b5)
The package declares `postinstall: node beacon.cjs` and additionally fires the same beacon from `index.js` on require(). The beacon POSTs a JSON payload containing `os.hostname()`, `__dirname` (install path), `process.cwd()`, and the Node version to the hardcoded plain-HTTP bare-IP endpoint `http://185.158.107.175:8787/_ah/dc`, which is unrelated to any `@greenlake` publisher infrastructure. The package otherwise ships no functional code: `index.js` self-describes as a 'Compatibility shim' and exports a Proxy whose `get` trap returns a no-op for every property access. The shape — a `@scope/<name>` no-op shim whose only behavior is identifying the installing host to an attacker-controlled IP on `npm install` — matches the dependency-confusion probe pattern, where a public package is published under an internal scope name to map which corporate installers resolve to the public registry.
## Source: ghsa-malware (e39ad6eeb6fd18f5aeff7b616ce8bfeb8f75d50f2ac28bca24a594dfa83b1510)
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.
In the Linux kernel, the following vulnerability has been resolved:
ipv4: stop PMTU walk when nexthop group shrinks
Commit 7d3f3b4367f3 ("net: ipv4: Cache pmtu for all packet paths if
multipath enabled") made __ip_rt_update_pmtu() update every path.
For nexthop objects, fib_info_num_path() and fib_info_nhc()
independently load nh->nh_grp. RCU protects each group's lifetime but
does not make the loads observe the same group. If replacement shrinks
the group after the loop accepts an index, fib_info_nhc() returns NULL
and update_or_create_fnhe() dereferences it.
A deterministic probe only widened the existing window between the real
operations. On v7.2, an RTM_NEWNEXTHOP replacement published a
one-member group after the PMTU reader accepted index 1 from a two-member
group, producing:
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: update_or_create_fnhe+0x45/0x15b0
Stop when the indexed path is absent. Groups are dense, so no later
index exists in that snapshot. The same real-writer window completed
114,423 PMTU iterations without an oops with this check. A reproducer
is available on request.
Replacement requires CAP_NET_ADMIN in the network namespace. Where
unprivileged user namespaces are permitted, a local user can obtain it
in a new user and network namespace.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7603: initialize global station WCID
mt7603 uses a driver-private global station WCID for frames that have
neither a station nor a vif, including frames injected through a monitor
interface. Unlike the core global WCID initialized by
mt76_register_device(), this WCID is published without ever being passed
to mt76_wcid_init().
Since commit 0335c034e726 ("wifi: mt76: fix race condition related to
checking tx queue fill status"), mt76_tx() queues every such frame on the
WCID's tx_pending or tx_offchannel queue and links its tx_list. The first
injected frame therefore reaches __skb_queue_tail() with an uninitialized
sk_buff_head and dereferences a NULL prev pointer.
Initialize the WCID before publishing it.
The fix was tested on an MT7603 PCIe device. Three wildcard probe requests
were injected through a monitor interface. The hardware queue head and tail
advanced from 0 to 3 and a second radio captured the third request over the
air. No oops or reset occurred. After restoring AP mode, a 150 MB transfer
also completed without a reset.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: disable rx napi when removing device
Unloading the mt7915e module with a MT7916 triggers multiples WARN in
__netif_napi_del_locked() and in page_pool_disable_direct_recycling()
because the driver does not disable the napi before destroying it.
This is troublesome since on MT7916 it is required to unload the module
and reinsert it with a different enable_6ghz parameter to change the
frequency. The system generally becomes unstable after reinserting the
module.
Fix it by disabling rx napi inside mt7915e itself, even through napi rx is
enabled in the mt76 generic code. Disabling it in the mt76 generic code
was previously attempted and reverted because napi was disabled too
late and rx handlers could access freed structures. Note that the tx
side is enabled and disabled by the mt76 generic code.
It is disabled in mt7915_stop_hardware() since, unlike
mt7915_unregister_device(), is it also called in the probe path if an
error happens after rx napi is enabled.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: lpass-cpu: use DAI table index for playback constraints
The DAI ID is a hardware port ID and is not necessarily the index of
the corresponding entry in variant->dai_driver.
When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code
currently uses dai_id to index variant->dai_driver. This is incorrect
for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S
DAI has ID 4 while it is the only entry in the DAI driver table. If
that DAI is configured for QUAD01 and probe reaches this branch, the
code writes beyond that single entry via dai_driver[4] instead of
updating the DAI being processed.
Use the loop index i when updating the current DAI's playback channel
constraints, while retaining dai_id for indexing the hardware-port
specific playback SD-line mode array.
This fixes the incorrect DAI table access for platforms where the DAI
ID does not match its position in the driver table.
A vulnerability in the Linux kernel's sdhci-sprd driver involves improper handling of runtime power management (PM) during device removal. The driver enables runtime PM on probe but does not correctly disable it on removal, potentially leading to clock management issues if the device is runtime suspended. The issue was identified through manual code inspection and has been fixed in specific commits.
CVE-2026-98909 is a Linux kernel vulnerability affecting version 5.5 where the devlink instance is not properly unregistered if port registration fails during CPSW probe. This results in leftover devlink registrations after a failed probe. The issue has been fixed by adding proper devlink cleanup on failure paths.
A vulnerability in the Linux kernel's imx mailbox driver was addressed by changing the power management runtime enablement sequence. The issue involved early usage of the device before probe completion, which could cause improper device removal and shutdown sequences. The fix delays pm_runtime_enable() to the removal path and adjusts the order of mailbox controller registration and power management handling to ensure correct device lifecycle management.
CVE-2026-98889 is a high-severity vulnerability in the Linux kernel's iwlwifi driver affecting version 5.11. The flaw involves improper sizing of Information Elements (IEs) during scheduled Wi-Fi scans, where oversized IEs could be copied into a fixed buffer before length validation, potentially leading to memory corruption. The issue is addressed by reordering the scan probe building process and properly advertising maximum IE lengths to userspace. A fix has been implemented in specific Linux kernel commits.
A vulnerability in the Linux kernel's 8250 serial driver was addressed by recognizing the UPIO_AU UART type to prevent warnings during driver probe on MIPS Alchemy systems. The fix involves handling UART type 4 without changes since parameters are already set by platform-specific setup code.
Incus 6.0.5 before 6.0.7, 6.12.0 before 7.0.2, and 7.1.0 before 7.5.0 contains a restriction bypass vulnerability that allows restricted project users to use pull mode migration via clustered refresh requests. Attackers with instance creation rights can send a refresh migration request for an existing instance to make the server open outbound TLS websocket connections and probe reachable services.
Trigger.dev before 4.5.2 contains a blind server-side request forgery vulnerability that allows authenticated project members to make the server send requests by setting unvalidated alert-channel webhook URLs. Attackers can create alert channels pointing to loopback, internal, or cloud metadata addresses, then trigger alerts to probe internal service reachability and send signed POST requests.
This vulnerability involves the ALSA caiaq driver failing to unregister the input device when the probe process fails. The issue is identified in version 3.0 of the affected Microsoft product. No CVSS score or detailed impact information is provided.
This vulnerability involves the MediaTek Ethernet SoC driver (mtk_eth_soc) in Microsoft software, where net_devices are not properly unregistered in case of probe failure. The issue affects specific versions 3.0 and 4.0 of the Microsoft product. No CVSS score or detailed impact information is provided, and no known exploits are reported in the wild.
This vulnerability involves a use-after-free issue in the clock provider component of the rtc: ac100 driver, triggered on probe failure. It affects Microsoft products with versions 3.0 and 4.0. No CVSS score or detailed impact information is provided, and no known exploits are reported in the wild.
CVE-2026-98825 is a vulnerability in Microsoft software involving an unchecked error pointer from the devm_clk_get() function in the probe() routine. The issue relates to improper error handling during device clock retrieval, which could potentially lead to stability or security issues. The affected versions are exactly 3.0 and 4.0. No CVSS score or detailed impact information is provided, and no known exploits are reported in the wild.