Search: com.ar

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.

### 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.

--- _-= 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.

Have you ever tried to open an “encrypted” email or an urgent document, only to realize with horror that your usual DOCX attachment is actually a file with the extension .docx.exe? Or maybe you received an email supposedly with an invoice, contract, or internal memo attached — only for the file to prove something entirely different from what it claimed to be? If so, you were likely targeted in a malware infection attempt. Cybercriminals routinely disguise malicious files as harmless documents and archives, banking on recipients blindly clicking without checking the extension. Kaspersky experts analyzed the file formats most frequently deployed in malicious email blasts to reveal what really lurks behind these extensions — and how attackers weaponize them in their campaigns. Important note: the extensions we’ll be discussing here are routinely used for completely legitimate files. For example, Windows executables normally end in .exe. However, we’re focusing specifically on scenarios where attackers disguise or spoof a file’s extension to pass it off as a totally different type of file. What extensions are most commonly found in malware? Our experts analyzed malicious email blasts from the beginning of 2026 to pinpoint the 15 most common dangerous file extensions. .exe .js .html .dll .bat .vbs .xls .pdf .jse .au3 .docx .htm .wsf .scr .lnk The top 15 file extensions used in malicious email blasts Let’s take a look at what files with these extensions actually do under the hood. Executable files An executable file is a compiled computer program that’s ready to run. Once launched, a malicious executable can download additional payloads, alter system settings, steal user data, connect your device to external attacker-controlled servers, and much more. These are the most common executable extensions found in malicious email campaigns: .exe .dll .com .scr .exe The classic Windows executable extension. It powers every program you use daily, from web browsers and games to office suites and software installers. By the way, attackers often wrap EXE malware in double extensions: invoice.docx.exe, report.pdf.exe, or even photo.jpg.exe. They take advantage of a default Windows setting: hiding extensions for known file types. Because this setting is turned on by default, users only see the first part of the file name — invoice.docx, report.pdf, or photo.jpg — and assume it’s just a normal document or image. But the second you open this trap file, the malware fires up. .dll Another common extension abused in malicious campaigns is .dll (dynamic-link library). These libraries hold functions that Windows programs frequently require while running, such as printing a document. This modular architecture prevents redundant code by letting multiple applications call on the exact same library for specific tasks. However, if an attacker replaces a legitimate library with an infected one, running any normal program that calls on it can trigger malicious code. .com While files with the .com extension have absolutely nothing to do with the web domain of the same name, cybercriminals likely count on victims mistaking these files for links in an unusual format. In reality, it’s a legacy Windows executable format. While modern versions of Windows no longer rely on this file type, the operating system can still run and execute it, which makes opening one a very bad idea. .scr SCR files are screensavers — those idle Windows screen animations featuring abstract patterns, the iconic bouncing logo, or whatever else. Despite their harmless reputation, screensavers are essentially executables just like EXE files: once opened, they can install extra components or alter system settings all the same. In malicious campaigns, these files routinely masquerade as images, screenshots, or documents. Scripts Scripts are text files containing a sequence of commands that a computer runs automatically in order. They can download files, install and launch programs, modify securi…

The Webbox of TeamDavid by Tobit Laboratories AG constructs redirect URLs using user-supplied input, which is appended to the redirect target in a 302 HTTP response. By using URL-encoded characters such as “%2e” (representing a dot), an attacker can manipulate the portion of the URL following the top-level domain (TLD). If a similar, registerable TLD exists (for example, if “.com” is the application’s domain, and “.company” is available for registration), an attacker can craft a URL to redirect users to a malicious “.company” domain. By using URL-encoded line feeds, it becomes possible to insert arbitrary response headers in the server's HTTP response. This issue affects TeamDavid before Rollout 528. Starting with Rollout 528 (June 30, 2026), the affected functionality is disabled by default and the vulnerabilities are therefore no longer exposed through this functionality.

A flaw was found in Epiphany. An issue in how the browser reads web addresses allows attackers to fake the domain name shown in the address bar. If a user clicks a specially crafted link containing a colon (for example, [https://trusted.com:80@attacker.com/](https://trusted.com:80@attacker.com/)), the address bar and security menus will display the safe website (trusted.com) but it will actually load the attacker website (attacker.com) on the screen. This allows attackers to create convincing phishing pages to trick users into trusting a malicious site.

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 (65aa3700b74bc0d50e4a4ee4fb3b903af0ac2ebea5867a3d1ffd0876647ec2a1) Package advertises itself as a 2048-style grid game statistics utility, but its declared postinstall hook (`node install-cb.js`) executes on `npm install` and performs behavior unrelated to that purpose. The postinstall shells out via execSync to run `uname -a` and `id`, reads `/proc/1/cgroup` and `/proc/mounts`, inspects Linux capabilities, checks for `/var/run/docker.sock`, and reads the Kubernetes service-account token and namespace at `/var/run/secrets/kubernetes.io/serviceaccount/`. It also enumerates `/`, `/root`, `/root/projects`, performs a host write-test, inspects network configuration, and greps the process environment for variables matching `token|secret|key|password|db_|redis|s3` and related patterns. The collected data (including the k8s SA token length and env keys) is written to `NCODE_ESCAPE.txt` in the current working directory and two parent directories. Author metadata is placeholder-shaped (`merge-tools <merge-tools@example.com>`) and the README/behavior mismatch indicates a cover-story shape. The install-time read of an installer-owned Kubernetes service-account token plus environment secret enumeration constitutes installer-side credential access and container-escape reconnaissance staging.

### Summary Four inline processors in pymdown-extensions contain regular expressions with exponential backtracking. A single untrusted Markdown line under 50 bytes drives `markdown.markdown()` into unbounded CPU on the rendering thread (seconds at ~45 bytes, growing exponentially with each added character). All four fire in the extension's **default configuration** and are reachable through the documented public API. The `caret`/`tilde`/ `betterem` blow-up was introduced by the emphasis-pattern rewrite in PR #2547 (first released in **10.13**, Dec 2024) — earlier releases used a linear `(.+?)` / `([^\s]+?)` content group — and is present through **11.0** (latest); `magiclink`'s host pattern is long-standing and affects effectively all releases. Likely **CWE-1333 (Inefficient Regular Expression Complexity)**. This is a distinct issue from CVE-2025-68142 (ReDoS in `pymdownx.blocks.caption`, `RE_FIG_NUM`, fixed in 10.16.1): different extensions, different regexes, and a different root cause (delimiter-run partition ambiguity rather than a `.`/`\.` typo). ### Details Four regexes share, or closely mirror, a vulnerable shape — an inner group that can partition a run of the delimiter character into `{2,}`-sized pieces in exponentially many ways, wrapped in a lazy `+?` that must fail before the engine can give up: | Extension | Regex | Location (`11.0`) | |---|---|---| | `pymdownx.caret` (superscript `^…^`) | `SUP2` | `pymdownx/caret.py:56` | | `pymdownx.tilde` (subscript `~…~`) | `SUB2` | `pymdownx/tilde.py:55` | | `pymdownx.betterem` (underscore `_…_`) | `SMART_UNDER_EM2` (default) | `pymdownx/betterem.py:93` | | `pymdownx.magiclink` (bare-URL autolink) | `RE_LINK` | `pymdownx/magiclink.py:56` (host at `:59`) | `pymdownx/caret.py:56` (`pymdown-extensions 11.0`): ```python SUP2 = r'(?<!\^)(\^)(?![\^\s])((?:[^\^\s]|\^{2,})+?)(?<![\^\s])(\^)(?!\^)' ``` The content group `(?:[^\^\s]|\^{2,})+?` matches a run of carets only via the `\^{2,}` branch. A run of *k* carets can be split into ≥2-length pieces in exponentially many combinations; when no caret can serve as a valid closing delimiter (the trailing `(?<![\^\s])(\^)` cannot be satisfied), the engine explores every partition before failing. `SUB2` (tilde) and `SMART_UNDER_EM2` (betterem) are the same construct for `~` and `_`. In `betterem` the default `smart_enable='underscore'` routes underscores to `SmartUnderscoreProcessor` → `SMART_UNDER_EM2` (`betterem.py:93`), which is the default-reachable, API-exploitable pattern; the non-smart `UNDER_EM2` (`:69`, used only when `smart_enable` is `asterisk`/`disable`) shares the shape but did not reproduce through the public `markdown.markdown()` pipeline on the tested payload, so a fix and regression test should target `SMART_UNDER_EM2`. `pymdownx/magiclink.py:59` has the analogous ambiguity in the host portion, where overlapping character classes let a run of dots be grouped exponentially: ```python (?:ht|f)tps?://[^_\W][-\w]*(?:\.[-\w.]+)* # host: '\.' and '[-\w.]' inside (?:...)* both match '.' ``` `SUP2`/`SUB2`/`SMART_UNDER_EM2` are applied at each delimiter occurrence via the default `PatternSequenceProcessor` subclasses (`pymdownx/util.py`); `RE_LINK` is applied by `MagiclinkPattern` (registered unconditionally at priority 85). In all four cases, rendering `markdown.markdown(src, extensions=[ext])` on untrusted `src` in default configuration is sufficient to reach the regex. ### PoC Single self-contained script; runs against the pinned release in an ephemeral env. Non-destructive — the input is ordinary Markdown text; the impact is CPU/time (a per-render alarm caps each attempt so the script terminates). ```python import signal import time from importlib.metadata import version import markdown print(f"# pymdown-extensions {version('pymdown-extensions')} / markdown {version('markdown')}") CAP = 5.0 # a single render exceeding this is treated as a hang class Timeout(Exception): pass def render(ext, text): signal.signal(signal.SIGALRM, lambda *_: (_ for _ in ()).throw(Timeout())) signal.setitimer(signal.ITIMER_REAL, CAP) t = time.perf_counter() try: markdown.markdown(text, extensions=[ext]) return time.perf_counter() - t except Timeout: return None finally: signal.setitimer(signal.ITIMER_REAL, 0) # ext -> (malicious builder, benign builder [valid & closed], ramp, hang count) CASES = { "pymdownx.caret": (lambda n: "^a" + "^" * n + "b", lambda n: "^" + "a" * n + "^", [24, 30, 36], 44), "pymdownx.tilde": (lambda n: "~a" + "~" * n + "b", lambda n: "~" + "a" * n + "~", [24, 30, 36], 44), "pymdownx.betterem": (lambda n: "_a" + "_" * n + "b", lambda n: "_" + "a" * n + "_", [24, 30, 36], 44), "pymdownx.magiclink": (lambda n: "http://a" + "." * n + " ", lambda n: "http://" + "a" * n + ".com ", [28, 32, 36], 40), } repro = [] for ext, (evil, benign, ramp, hang) in CASES.

OpenZeppelin Contracts Wizard is a web application to interactively build a contract out of components from OpenZeppelin Contracts. Versions prior to 0.10.9 generate a Hardhat test file (`test/test.ts`) by interpolating user-supplied `opts.name` (ERC20/ERC721) and `opts.uri` (ERC1155) directly into TypeScript string literals at `zip-hardhat.ts:48` and `:50` without any JavaScript string escaping. No authentication is required: an attacker crafts a URL such as `https[:]//wizard[.]openzeppelin[.]com/#/erc20?name=");require("child_process").execSync("...");("` and shares it with a developer. When the victim downloads the resulting zip archive and runs `npx hardhat test`, the injected Node.js code executes with the developer's local OS privileges. Version 0.10.9 fixes the issue.