Search: h-w-g.com

CVE-2026-77310 is a Server-Side Request Forgery (SSRF) vulnerability in the jackson-databind library's deserialization of java.net.InetAddress. Unlike the previously fixed InetSocketAddress deserialization which avoids DNS resolution, the InetAddress deserialization still performs eager DNS lookups on attacker-controlled input. This can lead to DNS-based SSRF allowing out-of-band interaction or internal host enumeration via DNS queries during JSON deserialization.

A critical authorization bypass vulnerability (CVE-2026-77995) exists in the miniOrange OAuth Client (free) extension for Joomla. Versions prior to 3.2.0 for miniOrange OAuth Client and prior to 1.2.2 for related OAuth Single Sign-On extensions are affected. The flaw allows an attacker to manipulate a cookie value to log in as arbitrary users, including administrators, leading to arbitrary account takeover.

OffSeq Mirage honeypot sensors detected the URL www.google.com being used as an attacker callback or command-and-control (C2) endpoint 220 times between August 24, 2026, and September 24, 2026. The observed technique corresponds to T1071.004, which involves application layer protocol communication for C2. The activity originated from attacker infrastructure located in Nigeria and the United States. This URL is flagged as an indicator of compromise (IOC) for monitoring and blocking in network defenses.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (abfe2a5c5b34e28b415fb39f20acea1ec320ef85aeb9577c9a52153630f964fc) The package's postinstall script runs automatically on `npm install` and collects host identifiers (hostname, username, cwd, platform, arch) from the installer, then transmits them off-host through two channels to a hardcoded Burp Collaborator subdomain `k5qrs9i96xtw61nb3bbwwualqcw3kt8i.oastify.com`: (1) an HTTPS GET carrying a base64-encoded payload in the query string, and (2) a DNS lookup where the fingerprint is hex-encoded and split into <=60-char labels prepended to the callback host, providing a covert channel that works even when outbound HTTP egress is blocked. The version number 3.999.999 published to the public `@opap` scope is the canonical shape of a dependency-confusion attack targeting a private internal scope of the same name. ## Source: ghsa-malware (ebbe49c2623d54fed28386f226aefa5f14ccdf94caee07543ae5251beffd13fc) 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 (98e627cea85331a67652aa65927058579efe7046253a9ef22cb70b1d73916885) The OpenSSF Package Analysis project identified '@opap/player-kyc-widget' @ 3.999.999 (npm) as malicious. It is considered malicious because: - The package communicates with a domain associated with malicious activity.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (3e2d548769641b2114a424739448d9df85d67cc176e694c6ff34ede446082b76) This package publishes a MetaMask snap that derives BIP44 entropy for coinType 60 (Ethereum) and transmits the resulting privateKey, publicKey and chainCode to a hardcoded remote endpoint at https://chainvista-api.onrender.com/api. Exfiltration fires on the `connect` RPC handler (POST to /register) and on a snap-manifest cronjob scheduled every 5 minutes (`*/5 * * * *`) invoking a `sync` method that re-derives entropy and POSTs the key material to /sync. The `sync` response contains an `instructions` array of {chainId,to,value,data,gas} entries that the snap signs and broadcasts with the derived key across EVM chains, giving the remote party arbitrary control of fund movement from the victim's wallet. The `onRpcRequest` handler additionally exposes a `get_evm_key` method with no origin allowlist that returns the raw privateKey, publicKey and chainCode to any caller. A code comment self-identifies the destination as a `drainer backend`. ## Source: ghsa-malware (0888334d7b507e01f9f1b86841261daf6b5acd2b599fb0af487d99c26d3acb2a) 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 (deb78208f7aa932298e92a8c241ed970296c567a273fc21013dd83bb7916e81b) On `npm install`, package.json's preinstall hook runs index.js which harvests installer host identifiers — os.hostname(), os.userInfo() username, local IPv4 addresses, home directory, INIT_CWD, public IP (fetched from api.ipify.org / icanhazip.com / ifconfig.me), DNS resolver IP/subnet, and the parent project's package.json metadata (name, author, repository, homepage) — and transmits them to the hardcoded Interactsh-style callback host `da51rv0hb2uc72tg4gvgdepinjcallbk1.oast.fun`. Exfiltration uses two channels: an HTTPS/HTTP POST to `/poc/<uuid>` on the callback host, and a hex-encoded DNS covert channel that splits the JSON payload into ≤60-character subdomain labels resolved against the callback host, designed to bypass egress filters that block outbound HTTP but permit DNS. The version number (999.9.12) and package name are consistent with a dependency-confusion probe. ## Source: ossf-package-analysis (d7cde5bd15beab8488f3b3b6bde2f17fff6c148ef2d575613762f337bd1c8281) The OpenSSF Package Analysis project identified 'fund-list-filter' @ 999.9.12 (npm) as malicious. It is considered malicious because: - The package communicates with a domain associated with malicious activity.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (27ba065e8759299d381ed1c7abd5e7721037b4ea969a384a9e70cfb6bb799e17) Package declares `scripts.preinstall`: `node index.js`, causing index.js to run automatically on `npm install`. The script collects hostname, username, home directory, INIT_CWD, local IPv4, public egress IP (via api.ipify.org, icanhazip.com, ifconfig.me), DNS resolver IP and client subnet (via o-o.myaddr.l.google.com), and the parent project's package.json fields (name, author, repository, homepage). The collected JSON is exfiltrated to the hardcoded callback host `da51rv0hb2uc72tg4gvgdepinjcallbk1.oast.fun` (Interactsh/OAST) via DNS-chunked queries and HTTPS POST to `/poc/<uuid>`. The unscoped name is published at version 999.9.12 to defeat internal resolvers that fall back to the public npm registry, so any build referencing `fund-portfolio` without a private-registry pin will resolve to and execute this payload. ## Source: ossf-package-analysis (ffad2f6c37441c2924e67b1d506d9c26dc9cb2fae325b74a596102ea5ed403bf) The OpenSSF Package Analysis project identified 'fund-portfolio' @ 999.9.12 (npm) as malicious. It is considered malicious because: - The package communicates with a domain associated with malicious activity.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (d78f28562113db7a203dc694bdff7b3884e8a6e252754b6bd845aab3fefe065f) The ESM build dist/index.js of @syncraft-labs/vue@0.4.1 contains a heavily obfuscated payload injected alongside the otherwise-legitimate Vue plugin source. The obfuscated region uses an obfuscator.io-style rotating string array (303 entries, _0x240a/_0x4963 decoders) and opaque predicates to hide a loader that requires http/https/zlib and child_process.spawn, queries Ethereum RPC endpoints (publicnode.com/ethereum-rpc, drpc.org/eth, blockscout) and an Etherscan-style txlist endpoint for the hardcoded address 0xa322E5f3..., decodes base64/gzip content from returned transaction data, and passes it to child_process.spawn. This is the EtherHiding blockchain-hosted C2 dropper pattern: any consumer importing @syncraft-labs/vue via ESM (the package's `module` entry) resolves an attacker-controlled runtime payload from Ethereum transactions and executes it, yielding remote code execution on the host performing the import. The CJS build and sourcemap are clean, indicating the ESM artifact was tampered after build to smuggle the loader while leaving createSyncraft/useSync and the vue/@syncraft-labs/core imports intact. ## Source: ghsa-malware (0f250ae47affc49042d57ffceae4bfc781f4d736301a16f6ac5ca7eeb415c0a0) 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 (0efe219063a966d0d2025d6c3274cbc7e9f3c0b3a1e9cdf81c7adf6dbae4d4ac) The ESM build shipped at dist/index.js contains a heavily obfuscated payload (hex-identifier string-array + rotator produced by an obfuscator.io-style tool) injected into the body of isDevMode(), which executes on every `import`/`require` of the package. The injected loader captures Node internals onto globalThis (globalThis.r = require, globalThis.m = module, globalThis.i = "A12-synd"), then uses http/https to query Ethereum JSON-RPC endpoints (eth.drpc.org, ethereum-rpc.publicnode.com, eth-mainnet.public.blockscout.com) and an Etherscan-style txlist API for a hardcoded attacker address (0xa322E5f3...), decodes and zlib-decompresses payload bytes from transaction data, and executes them via child_process.spawn. The CJS build of the same source is clean, indicating a targeted injection into the ESM entry rather than a bundler artifact. Any process importing this package fetches attacker-controlled code from a mutable on-chain dead-drop and runs it, giving the publisher arbitrary remote code execution on the installer's host with full Node capability handed to the second stage via the globalThis handoff. ## Source: ghsa-malware (3ef1bc02a0593d257249d740d38a6ccdbd0464272090c4c94dba7eb31113bbda) 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.

To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle

To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle

To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle

To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (ff42d765d0c2f6af53e4be5a9cf26ef34b3a36accf199acfb7d53af40b8dc2a6) On npm install, the declared preinstall script runs index.js, which collects the installer's hostname, OS username, home directory, cwd (INIT_CWD of the consuming project), local IPv4 address, egress public IP (fetched from api.ipify.org, icanhazip.com, and ifconfig.me), DNS resolver information, and the parent project's package.json fields (name, author, repository, homepage). The collected data is transmitted to the hardcoded third-party callback host da51rv0hb2uc72tg4gvgdepinjcalbk1.oast.fun via both DNS queries (hex-chunked subdomain lookups) and HTTPS POST to /poc/<uuid>. The package name and version pattern are consistent with a dependency-confusion lure targeting an internal scope; the beacon fires automatically at install time without any caller opt-in. Although the author metadata self-labels this as an authorized proof-of-concept, the code performs the full exploitation shape (auto-exec on install, installer-identifier collection, egress to an attacker-controlled callback) against anyone who resolves this public name. ## Source: ossf-package-analysis (3ade0d327c85a937a9115a25153971f25b66eb6c838a6a82b171e054afc285c6) The OpenSSF Package Analysis project identified 'stillm4ddpocs-demo-gadget' @ 999.9.10 (npm) as malicious. It is considered malicious because: - The package communicates with a domain associated with malicious activity.

In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free of the socket by its timers The x25 timers are armed with mod_timer() and cancelled with timer_delete(), so a pending timer holds no reference on the socket and a cancel does not wait for a callback already running on another CPU. x25_heartbeat_expiry() also rearms unconditionally, so it can reinstall sk->sk_timer after __x25_destroy_socket() has passed its cancel point. The following __sock_put() frees the socket while the timer is still queued, and the next expiry uses freed memory. KASAN reports a slab-use-after-free on the kmalloc-2k object freed by close(). timer_delete_sync() cannot be used here: x25_heartbeat_expiry() and x25_timer_expiry() both reach the cancels from inside the timer they would wait on, through __x25_destroy_socket() and x25_disconnect(). Arm the timers with sk_reset_timer() and cancel them with sk_stop_timer() so that an armed timer owns a reference, and release it in both expiry handlers. Rearm the heartbeat only while sk_hashed(sk) is still true, since __x25_destroy_socket() unlinks the socket before dropping it. Arm the deferred destroy timer the same way and drop its reference in x25_destroy_timer(). Reproduced on net with KASAN, with the heartbeat period shortened so the window recurs. With this patch the reproducer no longer triggers a report and /proc/net/x25 drains. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

In the Linux kernel, the following vulnerability has been resolved: ALSA: us144mkii: re-anchor capture URBs on resubmission capture_urb_complete() resubmits each capture URB without anchoring it: usb_get_urb(urb); ret = usb_submit_urb(urb, GFP_ATOMIC); Anchoring is a property of a submission, not of the URB. The giveback path calls usb_unanchor_urb() before urb->complete(), so an URB resubmitted from its own completion handler is off the anchor. The capture URBs are anchored once, at stream start, so from the first completion onward tascam->capture_anchor is empty. tascam_free_urbs(), tascam_disconnect(), tascam_suspend() and the stop-work path all call usb_kill_anchored_urbs(&tascam->capture_anchor) to reap the capture URBs before anything is freed. With the anchor empty those calls return immediately and the URBs stay queued on the host controller. tascam_free_urbs() then returns the capture transfer buffers with usb_free_coherent(), and snd_card_free() releases the snd_card allocation that embeds tascam (card->private_data). The controller completes the queued URBs afterwards, writing device-supplied data into the freed transfer buffer, and capture_urb_complete() dereferences the freed driver object. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in dummy_timer Write of size 512 at addr ffff000015b62000 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 64: usb_alloc_coherent tascam_alloc_urbs tascam_probe Freed by task 170: usb_free_coherent tascam_free_urbs tascam_disconnect usb_unbind_interface BUG: KASAN: slab-use-after-free in capture_urb_complete Read of size 4 at addr ffff0000170ee878 Freed by task 170: release_card_device snd_card_free tascam_disconnect Restore the usb_anchor_urb() between the reference count bump and the resubmission. That also makes the handler's usb_unanchor_urb() failure arm meaningful again and restores usb_kill_anchored_urbs() as a barrier on the disconnect, suspend and stop-work paths. The anchoring was removed on the premise that the URB is already anchored from the initial submission, which does not hold once the first giveback has run. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

In the Linux kernel, the following vulnerability has been resolved: ALSA: FCP: fix OOB write in fcp_meter_ctl_get() fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size by the driver's own limit of 255 if (map.map_size < 1 || map.map_size > 255 || map.meter_slots < 1 || map.meter_slots > 255) return -EINVAL; and passes it to fcp_add_new_ctl() as the control's channel count, where it is stored as elem->channels. Every control read writes into struct snd_ctl_elem_value, whose integer array is declared long value[128], so the limit is 128, not 255. fcp_meter_ctl_get() stores one 64-bit word per channel into that array with no bound of its own: for (i = 0; i < elem->channels; i++) { int idx = private->meter_level_map[i]; int value = idx < 0 ? 0 : le32_to_cpu(resp[idx]); ucontrol->value.integer.value[i] = value; } snd_ctl_elem_read_user() serves that object from memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of kmalloc-2048. offsetof(struct snd_ctl_elem_value, value) is 72, so element i is written at byte 72 + 8 * i and element 144 already lands past the allocation. At map_size 255 the last store ends at byte 2112, 888 bytes past the object and 64 bytes into the adjacent slab object. The stored words come from the device and meter_level_map[] selects which word lands in which slot, so extent and contents are both controlled. The core does not catch this. snd_ctl_check_elem_info() is reached only from __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under CONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a compile-time true. __snd_ctl_add_replace() validates kcontrol->count and never inspects elem->channels. Installing an oversized map needs CAP_SYS_RAWIO, but the control outlives the hwdep descriptor that created it, so the out-of-bounds stores are issued by any process able to read controls on /dev/snd/controlC0. KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read: BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185 __asan_store8 fcp_meter_ctl_get snd_ctl_elem_read snd_ctl_ioctl Allocated by task 185: memdup_user snd_ctl_ioctl The buggy address is located 0 bytes to the right of allocated 1224-byte region [ffff000017af0000, ffff000017af04c8) Bound the map size by the ABI limit rather than by 255, and bound the store loop at the sink so it cannot run past the value array whatever elem->channels holds. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

In the Linux kernel, the following vulnerability has been resolved: mm: fix incorrect flush address in direct page table reclaim When zap_pte_range reclaims a page table, it does: pte_free_tlb(tlb, pmd_pgtable(pmdval), addr); and this is unconditionally wrong: if this code executes, addr *always* points one past the end of the range covered by the table. The addr parameter is used to flush the TLB (really the paging-structure-cache) to drop references to the to-be-freed table, and any architecture that cares about the parameter will flush the wrong address. (But they'll still free the correct page). I think it's worth contemplating why the kernel works at all. If we hit the offending line of code, we will first clear the PMD entry (line 1954, zap_empty_pte_table), then we will issue pending flushes if force_flush is set (tlb_flush_mmu_tlbonly(tlb)), then we will skip the retry on line 1979 (phew!), and then we will do the offending pte_free_tlb call. *Or* we will clear the PMD entry immediately before pte_free_tlb (line 1983, zap_pte_table_if_empty). If we have any pending flushes (i.e. we actually zapped any last-level entries) at the time we clear the PMD entry, then the flush really ought to flush all references to the table (Linus certainly seems to think it will on all architectures [0]). The condition under which we have no accumulated flushes at the time of the clear is very complex (the whole zap_pte_range function has absurdly complex control flow). If we do hit the bad case, then we will end up clearing the PMD entry after the last time the range is flushed, and any CPU is free to cache a reference to the (empty) page table. If this happens due to an ordinary read or write, it would segfault, so it would be rare. But the cache could be speculatively filled as well. Then we'll flush the wrong address and then free and possibly reuse the table. On x86, even flushing the wrong address works on non-KPTI Intel systems because INVLPG flushes *all* paging-structure-caches, not just the ones for the target address. But INVPCID does not, and flush_tlb_one_user will use INVPCID if it's available. And then we're toast. AMD systems are more susceptible: we set the EFER.TCE bit, which makes even INVLPG only flush the target address. I think this might fix an issue in ripgrep reported here: https://github.com/BurntSushi/ripgrep/issues/3494 [0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u

CVE-2026-76606 is a critical path traversal vulnerability in the Fabrik extension for Joomla, versions up to 4.7.3. It allows an attacker to manipulate the pathname of an image element to access restricted directories improperly. The vulnerability has a CVSS 4.0 score of 10.0, indicating a severe risk with no required privileges or user interaction. No official patch or remediation guidance is currently available from the vendor.

CVE-2026-77027 is a high severity stored cross-site scripting (XSS) vulnerability in the Fabrik extension for Joomla, versions up to 4.7.1. It arises from improper handling of user-supplied input in the jsactions feature, allowing unauthenticated attackers to inject malicious scripts that are stored and later executed in users' browsers.