Threats affecting pkg:npm/@fastify/middie

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (b0a88993bf967d1bbbc61cb5f43b4d9af5d9ef74b920e70d828b4a52bf880979) The package advertises itself as 'Cache utilities' but ships no source, no binding.gyp, and no build configuration — only two prebuilt native addons (addon.node ELF for Linux, addon_win.node PE for Windows) and a 4,164,844-byte opaque, high-entropy file named.napi_cache with no readable strings and no magic header. The package.json postinstall hook runs `node -e "try{require(process.platform==='win32'?'./addon_win.node':'./addon.node').init()}catch(e){}"`, loading the platform-specific native binary and invoking init() on every install, with the error swallowed to suppress install-time noise. The Linux addon contains the format string '%s/.napi_cache' alongside fopen64/fread, references a '/tmp/.%u' staging path, and uses fork, setsid, execlp, chmod and _exit primitives — the shape of a drop-and-detach loader that reads the bundled.napi_cache blob, writes it to a hidden /tmp path, chmods it executable and runs it as a detached process. The addon also encodes an extensive evasion suite: environment checks for GITHUB_ACTIONS, GITLAB_CI, TRAVIS, CIRCLECI, JENKINS_URL, BUILDKITE, CODEBUILD_BUILD_ID, APPVEYOR, SEMAPHORE, TEAMCITY_VERSION, BITBUCKET_BUILD_NUMBER, NETLIFY, VERCEL, CF_BUILD_ID and SANDBOX; container probes against /proc/1/cgroup, docker, containerd, kubepod and podman; a TracerPid: debugger check via /proc/self/status; and host fingerprinting through /proc/meminfo, /proc/cpuinfo and /proc/self/maps. The combination — hollow self-description, source-less native binaries, lifecycle-hook execution of a staged opaque payload, and CI/sandbox/debugger gating — has no overlap with any legitimate cache library and is the fingerprint of an install-time dropper for attacker-controlled code. ## Source: ghsa-malware (529f7b16fb0c62ee71033377d3aebf3048f045e18f982b99224a584be9c264f6) 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.

CVE-2026-115905 is a critical vulnerability in the zip-rs zip2 Rust library affecting versions prior to 9.0.5. The flaw arises from inconsistent handling of filenames between the Central Directory File Header and the Local File Header during ZIP archive extraction. This discrepancy allows a crafted archive to appear safe when inspected via the central directory but to cause a streaming extractor to write files to attacker-chosen paths, potentially overwriting important files used by downstream services. The issue is fixed in version 9.0.5.

CVE-2026-71456 is a vulnerability in Johnson Controls Kantech Entrapass before version 9.20 involving the use of a hard-coded cryptographic key. This flaw enables a Padding Oracle Crypto Attack, compromising cryptographic security. The issue is fixed in version 9.20.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (21c91b39929f03c30e501726fc2d1c1fa43f17bf2ed77bda52380e563c1171e0) The package advertises itself as a zero-runtime CSS theming kit but on require/import executes a chain of obfuscated JavaScript modules. lib.mjs imports tokens.mjs, which top-level imports cache-warm.mjs — a ~279KB single-line file consisting of a hex-named string array of XOR/base64-encoded blobs decoded at runtime. Three additional sibling modules of the same shape (build-cache.mjs ~203KB, cache-sweep.mjs ~295KB, workspaces.js ~290KB) are shipped and listed in the published files manifest. Alongside the JavaScript loader, the tarball bundles prebuilt N-API native binaries at native/{linux,darwin,win32}/{arm64,x64}/cache-probe.node whose exported symbols implement extensive hypervisor, container, and sandbox detection (VMDetect/VMDetector classes, hypervisor_bit, qemu_fw_cfg, systemd_virt, dockerenv, bluestacks, vbox_module, podman_file, wsl_proc_subdir, amd_sev_msr, azure, chassis_vendor, mac_address_check, is_x86_process_on_arm). None of this has any role in CSS custom-property emission. The README instructs installation as `npm install -D tailwindcss@npm:postcss-semantic-themes`, aliasing the legitimate tailwindcss name onto this package so existing `import 'tailwindcss'` call sites resolve to the obfuscated loader. The combination of an import-time obfuscated loader, multiple additional staged obfuscated payloads, environment-fingerprinting native code to gate execution to non-analyst hosts, and a brandjacking install instruction is the structural shape of a staged supply-chain payload rather than a theming plugin. ## Source: ghsa-malware (d188bb5d3c330ed5c438865b3787cca124861eefe2c8e094e58511bbca437e09) 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 (22815f068ecaf85065c389553848537859f9e37623285a9e71b3e81ee9e9b685) Package advertises itself as a zero-runtime CSS theme kit and instructs installation as a Tailwind name-overlay (`npm install -D tailwindcss@npm:birch-css-utils`), but the published tarball contains ~760KB of heavily obfuscated JS (`build-cache.mjs`, `cache-sweep.mjs`, `cache-warm.mjs`) hidden behind a `tailwindcss-theme-kit build cache manifest` cover comment. The declared `./tokens` export (`tokens.mjs`) top-level-imports `cache-warm.mjs`, so consumers that import `birch-css-utils/tokens` execute the obfuscated code on module load. The bundles use a hex-named XOR-encoded string array; decoding with key 0xED reveals AWS Sigv4 signing primitives (`AWS4-HMAC-SHA256#Credential=`), an AWS Access Key ID regex (`^(?:AKIA|ASIA|ABIA|ACCA)[A-Z0-9]{16}$`), and git identity env var names (`GIT_AUTHOR_NAME`, `GIT_AUTHOR_DATE`) embedded in the string array. A CSS custom-properties package has no legitimate use for AWS v4 signing material or an AWS key-ID matcher. The combination of Tailwind name-overlay install instructions, a README denying runtime JS, obfuscated executable bundles reachable from a public export, and decoded AWS credential-harvesting primitives constitutes a Tailwind imposter that steals AWS credentials from importing consumers. ## Source: ghsa-malware (55ac470ab3260611fd8b69f59b1d1faae26e80e1c7e9c243cb0b65db56d5c231) 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: ghsa-malware (8b980eedd59eb558f39a2675ea8570fe97d02c7b586e2a5c7f980e058d313601) 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.

CVE-2026-71455 is a vulnerability in Johnson Controls Kantech Entrapass before version 9.20 that involves cleartext storage of sensitive information in memory. This flaw allows retrieval of embedded sensitive data, potentially exposing confidential information. The vulnerability has a medium severity rating with a CVSS score of 5.3. A fix is available in version 9.20.

Pyrus Sync for Windows has a local privilege escalation vulnerability due to missing authorization controls in its PyrusSyncService Windows service. This flaw allows an attacker with unprivileged access to create files via the ISyncService contract, potentially escalating their privileges on the affected system. The vulnerability affects versions prior to 1.8.745.0, which contains the fix.

CVE-2026-116370 is a type confusion vulnerability in the loadstring function of the Lua sandbox component in 2K Games Sid Meier's Civilization IV version 1.0.12.68. This flaw can be exploited remotely and has publicly available exploit code. The vulnerability has a medium severity rating with a CVSS score of 5.3.

This report summarizes multiple cyber threats and incidents observed in late October 2026, including large-scale breaches, supply-chain attacks, AI-enabled cybercrime tools, and critical software vulnerabilities. Notable incidents include a cyberattack on Japanese cloud provider Onamae Desktop Cloud affecting over 26,000 servers, a data breach at India's State Bank of India exposing nearly 3,900 customer records, and a supply-chain compromise of the LiteLLM AI gateway. AI-enabled tools are facilitating large-scale fraud and ransomware attacks targeting critical sectors in the United States. Critical PHP vulnerabilities enabling remote code execution are being widely exploited, with most instances unpatched. Oracle and GitLab have released patches for numerous critical vulnerabilities, including a critical remote code execution flaw in GitLab and a privilege escalation vulnerability in Arista VeloCloud Orchestrator that has been exploited in the wild.

The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API — it hands out up to CONFIG_ESP32_CRYPTO_AES_SESSIONS_MAX (default 4) independent sessions, each carrying its own key and direction. The AES peripheral, however, has a single chip-global set of key and mode registers, and aes_begin_session() programmed them exactly once, at session start, outside the aes_lock mutex that serialises the transforms. The per-operation handlers aes_ecb_op(), aes_cbc_op() and aes_ctr_op() then ran aes_hal_transform_block() against whatever key and direction the registers happened to hold. As a result, once a second session is opened with a different key, every subsequent operation on the first session silently uses the second session's key and direction, and no error is reported. Because the key programming happened outside the lock, the correct usage pattern of "each thread does begin, then op, then free on its own session" also races: a second thread's cipher_begin_session() landing between the first thread's begin and its operation makes that operation run under the second thread's key. An attacker who can induce session creation on the device — for example a protocol peer whose connection causes a session key to be installed — can influence which key is resident when a victim operation runs. The impact is a cryptographic failure rather than memory corruption: data the application believed it was protecting under one key is encrypted or decrypted under another. Where the resident key is one the attacker knows or supplied, the affected plaintext becomes recoverable by that attacker, and the operation's direction (encrypt versus decrypt) can likewise be inverted. Exposure requires an application that holds two or more concurrent sessions with different keys against this driver; no in-tree Zephyr subsystem does so today (the 802.15.4 security layer, which does open two sessions, uses CCM mode, which this driver rejects), so the risk falls on application code that uses the documented multi-session API. The fix removes all hardware access from aes_begin_session() and reprograms the key and direction at the top of every operation, inside aes_lock, so the chip-global registers can no longer be observed stale by another session.

In the Bluetooth Classic Hands-Free Profile Audio Gateway role, hfp_ag_create() in subsys/bluetooth/host/classic/hfp_ag.c starts an SDP discovery toward the peer, which links the embedded ag->sdp_param._node into the SDP client's pending request list in subsys/bluetooth/host/classic/sdp.c. If the subsequent bt_rfcomm_dlc_connect() call fails, bt_hfp_ag_connect() cleaned up by memset()-ing the entire AG object while that node was still linked, and while ag->slc_work could still be queued on the system work queue. An in-flight SDP discovery cannot be cancelled — bt_sdp_discover_cancel() is declared in the public header but has no implementation — so the request stays in the list with its func, pool and uuid pointers zeroed. The RFCOMM channel passed to bt_hfp_ag_connect() is taken from the peer's own SDP Hands-Free service record in the normal AG flow (bt_sdp_get_proto_param() performs no range validation, and samples/bluetooth/classic/handsfree_ag feeds the value straight through), so a remote BR/EDR device in radio range that advertises an RFCOMM channel outside the valid range 0x01..0x1e deterministically forces bt_rfcomm_dlc_connect() to fail and reach the wipe. Reading the peer's SDP record requires no pairing, and the peer can also trigger the failure by dropping the ACL or racing an RFCOMM DLC on the same DLCI at the right moment. When the SDP client next advances its request list, sdp_client_discover() dereferences the zeroed parameters — net_buf_alloc(param->pool, …) with a NULL pool and param->uuid->type — and the result-notification paths call through the NULL params->func. Zeroing a linked node also truncates the request list behind a stale tail pointer, and re-arming the freed AG slot re-appends the same node and can produce a self-looping list that hangs the Bluetooth RX thread. The impact is a crash or hang of the Bluetooth stack; the written value is a constant zero at a fixed static address, so no attacker-controlled write is available. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_AG that use the Audio Gateway role are affected.

bt_hfp_hf_connect() in subsys/bluetooth/host/classic/hfp_hf.c allocates the per-connection HFP Hands-Free object with hfp_hf_create(), which starts an SDP discovery by passing the object's embedded hf->sdp_param to bt_sdp_discover(). That call links the caller-owned parameter block into the SDP client's request list (session->reqs in subsys/bluetooth/host/classic/sdp.c). If the subsequent bt_rfcomm_dlc_connect() then failed, the affected code wiped the entire object with (void)memset(new_hf, 0, sizeof(*new_hf)) while that discovery was still outstanding, zeroing the sys_snode_t _node that is still linked in the SDP client's list along with the request's func, uuid and pool pointers, and zeroing the hf->slc_work work item that may already be queued on the system workqueue. The discovery could not be retracted instead: bt_sdp_discover_cancel() is declared in include/zephyr/bluetooth/classic/sdp.h but has no implementation. The failing branch is reachable with peer-supplied input. The documented use of bt_hfp_hf_connect() is to pass the RFCOMM channel read out of the remote Audio Gateway's SDP record; neither bt_sdp_get_proto_param() nor bt_hfp_hf_connect() range-checks that value, so a remote device advertising an HFP AG record with an RFCOMM channel outside 1-30 makes bt_rfcomm_dlc_connect() return -EINVAL and drives the local device into the wipe. The same branch is reached without any application misuse when the remote peer controls connection timing, for example when the RFCOMM session is in BT_RFCOMM_STATE_DISCONNECTING or the ACL is dropped between object creation and the RFCOMM call. Once the object has been wiped, the Bluetooth host continues to use it: sdp_client_alloc_buf() dereferences session->param->pool, which is now NULL, and the SDP receive paths call session->param->func() through a null function pointer, neither of which is NULL-checked. Because the wipe also clears hf->acl, the pool slot is considered free and a retry or an incoming HFP connection re-appends the same still-linked list node, turning session->reqs into a self-referential list that the host's list walkers never leave. The result is a fault or an unrecoverable hang in the Bluetooth host thread; the stray indirect call is through an all-zero pointer whose target the attacker does not control, so the practical impact is denial of service. The fix keeps the object allocated and marks it with a new BT_HFP_HF_FLAG_RELEASING flag, letting bt_hfp_hf_discover_cb() release it once the discovery completes instead of destroying it under the SDP client. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_HF enabled are affected.

The IPv6 stack derived the long-lived secret key used to compute RFC 7217 stable interface identifiers (gen_stable_iid() in subsys/net/ip/ipv6.c) and RFC 8981 temporary interface identifiers (gen_temporary_iid() in subsys/net/ip/ipv6_pe.c) with sys_rand_get(). That API is documented as not cryptographically secure, while both RFCs require this key to be an unpredictable random value of at least 128 bits — the unpredictability of every generated IID rests entirely on it. Depending on the platform, sys_rand_get() resolves either to a hardware entropy device or, on boards whose entropy driver sets CONFIG_ENTROPY_NEEDS_PRNG, to the non-cryptographic xoshiro128++ generator in subsys/random/random_xoshiro128.c, which keeps a single global 128-bit state shared with every other sys_rand_get() consumer. Many of those consumers put their output directly on the wire (ephemeral source ports, DNS query IDs, CoAP message IDs and tokens, DHCPv6 transaction IDs, WebSocket masking keys), and the xoshiro state transition is invertible, so an observer of a device's traffic can recover the generator state and reconstruct the IID secret key. Additionally, with the entropy-device backend sys_rand_get() silently falls back to k_cycle_get_32() samples when the entropy driver fails, and returns no error, so the key could be derived from the cycle counter without the caller noticing. With the key known, stable IIDs become directly computable for any prefix (the remaining HMAC inputs — prefix, interface index, interface name, DAD counter — are guessable), and temporary IIDs become linkable after a cheap search over the mixed-in k_uptime_get_32() value. This defeats the properties both features exist to provide: an attacker can track a device across networks and prefixes, and can predict its address inside a /64 without scanning, removing the usual barrier to directly targeting the host. There is no memory-safety, integrity, or availability impact. The fix generates the key with sys_csrand_get() and aborts IID generation with -EIO when no cryptographic randomness is available, instead of silently deriving addresses from a predictable key. Both CONFIG_NET_IPV6_IID_STABLE and CONFIG_NET_IPV6_PE are experimental and disabled by default; builds using CONFIG_TEST_RANDOM_GENERATOR remain predictable by design, as sys_csrand_get() is deliberately routed back to the test generator there.

The Object Transfer Service server builds its Object Action Control Point (OACP) response indication in oacp_ind_send() (subsys/bluetooth/services/ots/ots_oacp.c). Before this fix the four-byte Checksum Value field was appended whenever the requested op code was BT_GATT_OTS_OACP_PROC_CHECKSUM_CALC, regardless of the result code. The response payload is a bare, uninitialized four-byte stack buffer declared with NET_BUF_SIMPLE_DEFINE(resp_param, sizeof(uint32_t)) in bt_gatt_ots_oacp_write(), and it is filled only on the success path of oacp_checksum_proc_validate(). On every failure path the buffer is still empty, so net_buf_simple_pull_le32() was invoked on a zero-length buffer. The OACP characteristic and its client characteristic configuration descriptor are declared with BT_GATT_PERM_WRITE and BT_GATT_PERM_READ | BT_GATT_PERM_WRITE, so no pairing, encryption, or authentication is required. Any peer within radio range that can connect to a device running the OTS server can enable OACP indications and write a nine-byte Calculate Checksum command that fails validation — for example by issuing it with no object selected, which returns BT_GATT_OTS_OACP_RES_INV_OBJ. Because oacp_command_decode() accepts the Calculate Checksum op code unconditionally (it is not guarded by CONFIG_BT_OTS_OACP_CHECKSUM_SUPPORT), builds without checksum support are reachable too: they answer BT_GATT_OTS_OACP_RES_OPCODE_NOT_SUP and take the same bad path. On builds with CONFIG_ASSERT enabled, the zero-length pull trips the assertion inside net_buf_simple_pull_mem() and panics the device, giving a remotely triggered denial of service. On builds with assertions disabled there is no check: the pull returns the untouched stack array and four bytes of uninitialized stack memory are copied into the indication and transmitted to the peer, repeatable on every request. The disclosure is bounded to four bytes per request and the write stays inside the seven-byte res indication buffer, so there is no memory corruption; the impact is uninitialized-memory disclosure plus an availability loss in assertion-enabled configurations.

The Bluetooth host pre-allocates a bt_conn object (a "reservation") from the fixed acl_conns[] pool for every connectable advertising set it starts, in le_adv_start_add_conn() in subsys/bluetooth/host/adv.c. When an incoming peripheral connection completes, find_pending_connect() in subsys/bluetooth/host/hci_core.c looked that reservation up using only the identity and the peer address, with a directed-then-undirected fallback, and had no knowledge of which advertising set actually terminated. With CONFIG_BT_EXT_ADV_MAX_ADV_SET > 1, where the LE Enhanced Connection Complete event is cached until the LE Advertising Set Terminated event identifies the set, this lookup can return the reservation belonging to a different, still-running advertising set. The defect is reachable over the air by any adjacent device. If an application runs two connectable extended advertising sets on the same identity — one undirected and one directed at a peer P (the common "directed reconnect to a bonded central while still accepting new centrals" pattern) — a remote initiator whose address maps to P connecting on the undirected set causes the directed set's reservation to be consumed instead. The initiator address is chosen freely by the remote device and is not authenticated at link establishment, so no bonding, pairing or prior relationship is required to trigger the mis-attribution. The undirected set's own reservation is then stranded: its BT_ADV_ENABLED flag has already been cleared, and le_adv_stop_free_conn() — the only path that returns a reservation to the pool — is reached only for sets that are still enabled, so bt_le_ext_adv_stop() returns early and the object is never released. Each occurrence permanently consumes one CONFIG_BT_MAX_CONN slot until bt_disable() or reboot. In application patterns that restart the directed advertising set after each disconnect, an attacker can repeat the sequence until the pool is exhausted, after which connectable advertising fails with -ENOMEM and the device can no longer accept connections. As a side effect the directed set keeps advertising without a reservation, so a genuine connection on it is dropped by bt_hci_disconnect(). The impact is availability only; no memory corruption or information disclosure results, and configurations with a single advertising set are unaffected.

CVE-2026-116369 is an OS command injection vulnerability in Sunwood-ai-labs github-kanban-mcp-server versions up to 0.4.0. The flaw exists in the handleListIssues function of src/handlers/issue-handlers.ts, where manipulation of the state or labels argument can lead to command injection. The vulnerability can be exploited remotely. Upgrading to version 0.4.1 addresses this issue.

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in Magepeople inc. WpEvently mage-eventpress allows Code Injection.This issue affects WpEvently: from n/a through 5.7.9.

Mattermost versions 11.7.0 through 11.7.10 contain an authorization flaw where the API does not properly restrict which built-in roles a team admin can assign to team members. This allows a team admin to grant permissions beyond the configured permission scheme via the update-team-member-roles REST API endpoint. The vulnerability has a low severity rating with limited impact on confidentiality and integrity.

Syncplify Server! versions prior to 8.8.0 contain a path traversal vulnerability due to improper link resolution before file access. This flaw allows attackers who can place symbolic links or directory junctions inside a user's home folder to access files outside the intended virtual filesystem root. The vulnerability arises because confinement checks are performed on the requested path rather than the actual on-disk target of the link, enabling unauthorized file access beyond the home-folder boundary.