Search: h-w-g.com

### Problem The referrer enforcement introduced with [TYPO3-CORE-SA-2020-006](https://news.typo3.com/security/advisory/typo3-core-sa-2020-006) ([CVE-2020-11069](https://www.cve.org/CVERecord?id=CVE-2020-11069)) became ineffective in TYPO3 v13.0, where TYPO3 CMS started serving the backend and Admin Tool applications from the site's main entry script instead of the dedicated typo3/ directory. Whether a request originated from the backend or Install Tool itself was determined by comparing the referrer against the directory of the entry script, which since then is the site root. As a consequence, requests originating from any script running on one of the TYPO3 instance's own domains, such as a frontend page, were accepted by backend routes and Install Tool endpoints. Attackers able to execute JavaScript on one of those domains, for instance by exploiting a cross-site scripting vulnerability, could invoke these endpoints via Fetch/XHR with the privileges of an authenticated victim's user session. ### Solution Update to TYPO3 versions 13.4.34 LTS, 14.3.6 LTS that fix the problem described. ### Credits Thanks to Hổ Cao Từ for reporting this issue, and to TYPO3 core & security team member Benjamin Franzke for fixing it.

A flaw was found in insights-core where the password redaction layer fails to recognize credentials not keyed under the literal string 'password'. This allows SSSD LDAP bind passwords (ldap_default_authtok) and Pacemaker fence device credentials to be included in cleartext in archives uploaded to console.redhat.com.

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

npm/@dreamguyxeon/baileyx is a Baileys WhatsApp Web API fork with the same undisclosed remote-controlled consentless newsletter auto-follow as related DGXeon packages. In lib/Socket/newsletter.js, after session setup it waits 120 seconds, fetches https://raw.githubusercontent.com/DGXeon13/strings/refs/heads/main/strings.json, and silently FOLLOWs listed newsletter JIDs. Trigger is runtime (makeNewsletterSocket), not install. It also fetches Baileys version metadata from DGXeon13/dgxeon-soket and aliases libsignal to npm:@dgxeon13/libsignal-node@1.0.0 (a separate package that patches @whiskeysockets/baileys). Independently corroborated by LPM Firewall's public malicious report for 2.0.0. Related OSV entries: dgxeon-baileys (MAL-2026-2252), baileys-dgxeon (MAL-2025-806). Tarball sha256 for 5.0.0: 0dffc5f0c8fd53b520c26de8788e6eafb1d939070a698e39f9f9853f42e6f7db. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (c1b873d1c35283cbabd9bc82c8bffa55d3151abec85a75522ed8565c93d0546a) This package is a fork of the Baileys WhatsApp library that contains an undocumented runtime hijack of the consumer's authenticated WhatsApp account. In lib/Socket/newsletter.js (lines 102-122), when the consumer creates a WhatsApp socket — the package's main advertised function — a 120-second setTimeout fires, fetches https://raw.githubusercontent.com/DGXeon13/strings/refs/heads/main/strings.json, and for each newsletter ID in that list issues a QueryIds.FOLLOW request under the user's authenticated session. The list is hosted on a mutable `main` branch under the package author's GitHub account, so the author can rotate the targeted channels at any time post-publication without republishing the package. The behavior is not mentioned in the README and is not gated by any user prompt or configuration. The main entrypoint lib/index.js is additionally wrapped in a custom base91 string-table decoder with anti-debugger `debugger` statements and `eval("this")`, concealing the bootstrap edges from casual review. The package also aliases the security-critical `libsignal` dependency to the same author's scope (`npm:@dreamguyxeon/libsignal-node@1.0.0`), placing crypto primitives under the same trust boundary as the silent-relay code. Installer harm: any consumer who connects this fork to their WhatsApp account has their identity used to silently follow channels of the author's choosing, with the target list mutable indefinitely.

npm/my-auto-follow is a Baileys WhatsApp Web API fork that embeds undisclosed, remote-controlled consentless newsletter auto-follow behavior. In lib/Socket/newsletter.js, after a session is established the code waits 120 seconds, fetches a JSON list of WhatsApp newsletter JIDs from https://raw.githubusercontent.com/DGXeon13/strings/refs/heads/main/strings.json (attacker-controlled; observed contents include newsletter JIDs), and silently issues newsletterWMexQuery(..., QueryIds.FOLLOW) for each entry with errors swallowed. There is no caller opt-in. Trigger is runtime (makeNewsletterSocket / normal socket path), not install: preinstall only checks Node >= 20. The package also depends on libsignal via the npm alias npm:@dreamguyxeon/libsignal-node@1.0.1 (separate malicious patcher reported alongside this entry). Related DGXeon campaign packages already in OSV include dgxeon-baileys (MAL-2026-2252) and baileys-dgxeon (MAL-2025-806). Tarball sha256 for 1.0.3: 1332d396a2251692c2654fca52620a433a880551500a567ade040e8f01440e68. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (481bdecc52b4f32afcfd2e6755ef8c74191cc0010714a0403aa93d1bd958369b) my-auto-follow is a Baileys WhatsApp library fork whose `makeWASocket` newsletter socket schedules an undocumented setTimeout (120s after socket creation) that fetches a remote JSON list from https://raw.githubusercontent.com/DGXeon13/strings/refs/heads/main/strings.json and unconditionally force-follows every channel ID in that list via `newsletterWMexQuery(id, QueryIds.FOLLOW)` (lib/Socket/newsletter.js lines 100-122). The fetched list is hosted on a mutable branch under the package author's GitHub account and can be changed at any time without republishing the package. There is no opt-in, no documentation, and no user prompt. Any developer who uses this library to power a WhatsApp bot will have their authenticated WhatsApp account silently issue FOLLOW commands to whatever channel IDs the author chooses to publish — abusing the installer's WhatsApp identity for the author's social-graph manipulation. The behavior matches the package name `my-auto-follow` but is never disclosed to the consumer.

A threat hunting investigation identified suspicious PowerShell content served from an IP address (203.188.171.166) and domain (dorenzaa.com), both retrieving ZIP archives from Vercel-hosted infrastructure. The PowerShell loaders extract and execute payloads locally, including Grape.exe, UltraToolliteSetup.exe, and draw.io.exe. Analysis revealed heavily obfuscated PowerShell stages utilizing Base64 encoding, XOR-based obfuscation with the key 'Write', dynamically constructed IEX commands, and hidden PowerShell execution. A decoy 'Verification complete!' message disguised as Google.com was presented to victims during execution. Multiple Vercel instances hosted additional artifacts including loader scripts and executables. The initial infection vector remains unidentified, suggesting these PowerShell-hosting URLs represent second-stage delivery points in a multi-stage attack chain.

In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(&params->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---

A member of "The Com," a loose-knit online cybercrime collective that targets children and teenagers, has been sentenced to two years in prison for blackmail and sextortion offenses against nearly 120 victims worldwide. [...]

Joomla Extension - fabrikar.com - Remote code execution in Fabrik < 4.7.2 - An unauthenticated attacker could execute arbitrary code by using the ajax_calc feature of the calc plugin.

This security update provides a functional equivalent of RHSA-2026:52399. The original Red Hat(R) advisory is available from the Red Hat web site at https://access.redhat.com/errata/RHSA-2026:52399.

The @depup/memfs npm package is a malicious republish of the legitimate memfs package. It replaces the original source code with requires to attacker-controlled packages under the @jsonjoy.com namespace, causing installation or import to execute malicious code from these dependencies. This repackaging effectively creates a dependency-chain dropper that runs attacker-published code without lifecycle hooks. The affected version is exactly 4.67.0-depup.0.

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

### Impact A path traversal issue in `go-git` could allow malicious reference names to access files outside the repository's intended reference storage. Loose references are stored under `.git/<reference-name>`. The reference name was previously used as a path without verifying that the resolved path remained within the reference storage. A name such as `refs/heads/../../config` could therefore resolve to unrelated repository metadata such as `.git/config` or `.git/HEAD`. A malicious Git server could advertise such a reference name. The name may also survive refspec mapping; for example, it could be mapped to `refs/remotes/origin/../../config` during a clone or fetch operation. This vulnerability affects filesystem-backed repositories using the `storage/filesystem` package and its `dotgit` reference storage. Users relying exclusively on the in-memory storage implementation, `storage/memory`, are not affected, because reference names are not resolved as filesystem paths. Exploitation requires an application using `go-git` with filesystem-backed storage to interact with a malicious Git server or otherwise process attacker-controlled reference names. ### Patches The issue has been addressed by validating reference names at the `dotgit` storage entry points and rejecting names whose resolved paths could escape the reference storage. Users of filesystem-backed storage should upgrade to a patched version. ### Workarounds Applications that exclusively use `storage/memory` are not affected and do not require a workaround for this vulnerability. For applications using filesystem-backed storage, avoid cloning from or fetching from untrusted Git servers until an upgrade is possible. Applications that directly construct or process reference names may also validate them before passing them to filesystem-backed `go-git` storage. Application-level validation should only be considered a temporary mitigation and does not replace upgrading to a patched version. ### References - Fixes: - https://github.com/go-git/go-git/pull/2247 - https://github.com/go-git/go-git/pull/2254 ### Credits Thanks to @Saku0512 for reporting this issue and @Sahana2524 for proposing the initial fix. 🙇

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (6512bd1cea27977e679186d569d524555fdf0ed5ea9e4b965aa640b1ae8326cb) src/index.js opens a persistent WebSocket to a hardcoded default relay at wss://relay.mangomindbd.com and dispatches on message types received from that remote endpoint. On messages of type 'diagnosis' with autoFix set, the handler passes msg.fixCommand — a string chosen by whoever controls the relay — directly to child_process.execSync on the local machine (timeout 120000ms), yielding full-host command execution under the user running the agent. On messages of type 'opencode_request', the handler forwards attacker-chosen HTTP method, path, and body to a locally-spawned opencode AI coding agent bound on 127.0.0.1 and returns its response, giving the same remote party a proxied channel to drive that agent's file and shell tool access against the installer's workspace. The relay hostname mangomindbd.com is also referenced from https://api.mangomindbd.com in the same file, and the module makes cross-platform curl/http.get/os.hostname calls consistent with host-context reporting to the relay. The remote-execution paths are gated only by an initial token handshake with the relay operator, so any party in control of relay.mangomindbd.com holds arbitrary RCE and AI-agent-driven filesystem access on every host running this package.

Joomla Extension - seblod.com - Unauthenticated path traversal in SEBLOD < 3.30.0, < 4.7.0, < 6.0.1 - An unauthenticated attacker could download files from both inside and outside the webroot.

Joomla Extension - joomshaper.com - Unauthenticated stored XSS in Shapes API endpoint SP Page Builder < 6.7.0 - An unauthenticated attacker can store malicious JavaScript in a Joomla site's database via a single HTTP request. When an administrator opens the SP Page Builder editor, the JavaScript executes in their browser automatically..

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (42dcf2c659fc0c8b63b90671ae2a865a7811d5eeaaf321aab8355358117be47d) dojo-rn-interview@1.0.1 declares a preinstall script that runs index.js on `npm install`. The script collects host identifiers via os.hostname(), os.userInfo(), os.homedir(), __dirname, and DNS server list, and reads the installer's /etc/passwd and /etc/hosts files, then POSTs the collected data over HTTPS to the hardcoded Burp Collaborator subdomain kqepxa9s4krgw7e7b6f7kufiy943stgi.oastify.com. The package name and behavior are consistent with a dependency-confusion reconnaissance beacon targeting internal build systems. ## Source: ghsa-malware (469a616c12ee5e0418ab67bca357fcbb29c5ecc46eff755b5f1fa6f330ef6475) 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 (ce64fb8d6264bfc9affaf6b3544637cb8559b232075b70a48144e5f1c1743020) blekit is published as a React Native BLE SDK, but its main entry re-exports a logger module (`consoleApp`/`initializeLogger`/`getCurrentStatus` from `dist/src/handlelogs.mjs`) that POSTs any string passed to it to `https://api.telegram.org/bot<token>/sendMessage` with a hardcoded `chat_id` of `-1003846719897`. Three live Telegram bot tokens are embedded in the compiled bundle and rotated round-robin; the destination chat is not caller-configurable and is not disclosed in the README. Alongside the relay, the same file exposes `getEnhancedDeviceInfo` (re-exported as `getDeviceInfo`), which gathers precise GPS latitude/longitude with a `https://www.google.com/maps?q=<lat>,<lng>` link, unique device id, IP address, VPN state, brand/model/OS, battery, storage, timezone, locale, and security posture (rooted, emulator, screenLock, mockLocation), and can be stringified via `stringifyData` and passed straight into `consoleApp` to be shipped to the same Telegram chat. Any application that integrates blekit and calls the exported logger silently transmits its data — and, when the device-info helper is used, end-user GPS coordinates and persistent device identifiers — to an author-controlled Telegram channel that the app developer and end user never opted into. ## Source: ghsa-malware (f4213a76b2c5c574d5bfa41897a698d068ba56f146c88855eb2aeb2aac8ec9eb) 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 (4b1f6143f5a7c6106ab4ba0a21a6adaf9020e332835b1e528de6f36b64537734) index.js is advertised as a Foundry gas-report diff utility but on module load / CLI run schedules a setTimeout of 259,200,000 ms (3 days) that calls https.get against https://gist.githubusercontent.com/opensource-crypto/3946ef88aa057c9d10f1a7d80391d164/raw/default.json. The gist is hosted on a GitHub account (opensource-crypto) unrelated to the declared package publisher (danird9). If the fetched JSON contains a `c2` field, the value is persisted to ~/.forge-gas-diff.remote for later use. A separate getInstallId() routine writes a per-host UUID to ~/.forge-gas-diff, providing a stable install fingerprint. None of this behavior — outbound network fetch, install-ID generation, remote-config persistence, or a field literally named `c2` — has any relationship to the advertised gas-diff functionality and is not documented in the package. The gist is author-mutable, so the content delivered to installers can be changed at any time without republishing the package; the 3-day delay places the fetch well outside typical install-time sandboxing windows. The mechanism is the staging half of a remote-config-driven dropper: a hidden update channel keyed to attacker-editable content on a third-party host, with persistence to a well-known filesystem path on the installer's machine.