Threats Tagged 'javascript'

By Yarden Porat, Check Point Research Key Points Check Point Research analyzed Cloudflare Code Mode, a technique that changes how AI agents use MCP by turning tools into a TypeScript API the model can write code against. The research uncovered five vulnerabilities in workerd, the open-source runtime behind Code Mode and Cloudflare Workers. Two were rated Critical by Cloudflare. The blast radius is broad: by Cloudflare’s own numbers, Workers is built by millions of developers ,[1] serves millions of requests per second ,[2] and carries more than 10% of all traffic on Cloudflare’s network .[3] Because workerd underpins both Code Mode sandboxes and Workers tenant isolation, the findings create sandbox-escape and cross-tenant exposure risk. Cloudflare’s managed Workers environment has been fixed in production. Self-hosted workerd / Code Mode deployments should update to v1.20260619.1. Check Point Research released proof-of-concept code as part of its Black Hat USA 2026 presentation. The short version We set out to break Cloudflare Code Mode , and ended up breaking Cloudflare Workers too. We did both by targeting workerd , the runtime beneath both: an in-process sandbox that relies entirely on V8 to isolate untrusted code. We found five memory-corruption bugs in workerd’s native C++ (the “glue” between JavaScript and the runtime), and turned them into two end-to-end attacks: Cross-tenant heap swipe. An out-of-bounds read in URLPattern lets one Worker reach across the shared process heap and swipe another tenant’s secrets . Code Mode sandbox escape. Starting from a prompt injection, a use-after-free in node:zlib breaks out of the sandbox and runs native code on the host . Part I – Understanding the target 1. Where this started: Code Mode Code Mode is Cloudflare’s take on LLM tool use. Instead of a model emitting structured tool calls one at a time, Code Mode exposes the available tools as a typed TypeScript API and lets the model write code that calls them: loops, conditionals, data shuffling and all. In the traditional MCP / tool-calling loop, the model emits one {tool, args} call, the agent runs it, feeds the result back. The model then emits the next call. Every step is a fresh model invocation, and usually a network round-trip. Code Mode collapses that: the model writes one program that orchestrates many tool calls itself (looping, branching, and combining intermediate results locally) and only the final output returns to the model. Cloudflare’s argument is that LLMs, trained on enormous amounts of real-world code, are simply better at writing a program against a typed API than at emitting long chains of synthetic tool calls. [4] Figure 1 – Tool calling vs. Code Mode That code has to run somewhere, and that “somewhere” is workerd , the runtime behind Cloudflare Workers. 2. The workerd origin story To understand workerd, start with the product it was built for: Cloudflare Workers . Workers is Cloudflare’s serverless platform: you upload a piece of code and Cloudflare runs it at the edge , in data centers close to the user, on demand for every request. There’s no server to manage and, ideally, no cold machine to wait for. That model creates a hard isolation problem. Cloudflare runs code from a huge number of different customers, and to keep latency and cost down it packs many of them onto the same machines, and, as we’ll see, into the same process. The classic answer (a container or VM per tenant) is far too heavy for this: each one adds tens to hundreds of milliseconds of cold start and a real memory footprint, which is exactly what an edge platform serving oceans of short requests cannot afford. Cloudflare’s answer is to isolate at the language-runtime level rather than the OS level, using V8 isolates, the same primitive Chrome uses to separate browser tabs. An isolate is a lightweight, independent JavaScript context. Many can live inside a single process, each starts in single-digit milliseconds, and the isolate is the security…

Analysis of ChainDrop, an npm supply chain worm extracting GitHub Actions runner secrets and using Ethereum smart contracts for C2 routing. The post ChainDrop: Inside a Self-Propagating npm Worm appeared first on Unit 42 .

In this article Attack chain overview Mitigation and protection guidance Indicators of compromise (IOC) Microsoft Defender XDR detections Advanced hunting queries Learn more Microsoft Threat Intelligence identified a large-scale npm supply chain attack affecting more than 400 packages across multiple unrelated publishers, including packages associated with major enterprise software ecosystems such as keyv, flat-cache, cache-manager, and others. The malicious releases contain a Mini Shai-Hulud variant, a self-propagating credential-stealing worm delivered through a large, heavily obfuscated Bun-based JavaScript payload. The malware typically executes automatically through an npm preinstall lifecycle hook before package installation completes. Once executed, the malware searches developer workstations and continuous integration and continuous delivery (CI/CD) environments for npm, GitHub, cloud, and infrastructure credentials. It uses recovered identities to authenticate to npm, GitHub, Amazon Web Services (AWS), Kubernetes, and HashiCorp Vault, enabling it to enumerate packages, repositories, workflow secrets, cloud parameters, and secret-store values. Collected data is encrypted and transmitted through an attacker-controlled HTTPS endpoint, with GitHub repositories serving as a fallback exfiltration channel. The payload’s most significant capability is automated propagation. After obtaining an npm publishing token, it enumerates packages available to the compromised identity, downloads their latest tarballs, inserts the malware and setup loader, adds a preinstall hook, increments the patch version, and republishes the modified packages. The malware can also use stolen GitHub credentials to inject Claude and Visual Studio Code configuration files into repositories, establishing persistence and creating an additional developer-to-developer infection path. In this blog, we’re sharing our analysis of this supply chain attack, along with protection, detection, amd hunting guidance. Organizations that installed an affected package with lifecycle scripts enabled should treat the associated developer workstation or build runner as potentially compromised. Investigations should prioritize credentials accessible to the affected identity, unauthorized npm releases, unexpected repository or workflow modifications, suspicious cloud and secret-store access, and artifacts produced by affected build systems. Organizations should revoke and rotate exposed credentials from a known-clean environment and rebuild affected systems and downstream artifacts from trusted sources. Attack chain overview The campaign appeared as a rapid sequence of unauthorized patch releases across more than 400 npm packages maintained by otherwise unrelated publishers. Many malicious versions had no corresponding source-code commit, pull request, tag, or legitimate release, indicating that the attackers modified and published package tarballs directly rather than compromising each public source repository. Affected releases typically added a preinstall lifecycle script that launched a malicious file, setup.mjs, contained within the package, which launched the large, obfuscated Bun JavaScript bundle included in the package. Because npm runs preinstall scripts before installation completes, the payload could execute on developer workstations and build runners before application tests or conventional security checks began. After execution, the malware performs the following actions: Determines whether it is running on a developer workstation or in a CI/CD environment. On workstations, it detaches itself to continue after installation; on CI/CD systems, it remains in the active job to access workflow secrets, runner credentials, and OpenID Connect (OIDC) publishing permissions. Both paths could support further package or repository propagation when suitable credentials are found. Collects credentials from local files, environment variables, command-line tools, and GitHub A…

When you learn that a compromised package executed on one of your build hosts, muscle memory takes over: revoke the npm token, rotate the GitHub PAT, cycle the cloud keys. That reflex has been correct in almost every supply-chain incident I have worked. In the keyv/cacheable compromise that has been unfolding since yesterday, it is the one thing you should not do first — because revoking the stolen token is exactly what arms the payload.

The malware was designed to steal and exfiltrate secrets, and to propagate itself via stolen NPM and GitHub credentials. The post Over 400 NPM Packages Infected in ChainDrop Supply Chain Attack appeared first on SecurityWeek .

Self-propagating malware named 'ChainDrop' has compromised more than 1,300 packages with a combined 2 billion monthly downloads on the Node Package Manager (npm) registry. [...]

A China-based advanced persistent threat (APT) group TA423, also known as Red Ladon, conducted watering hole attacks using the ScanBox JavaScript-based reconnaissance tool. The attacks targeted domestic Australian organizations and offshore energy firms in the South China Sea region by compromising websites that appeared as legitimate news sources. ScanBox operates as a keylogger embedded in JavaScript, enabling covert data collection without installing malware on victim systems. The campaign ran from April to mid-June 2022 and leveraged phishing emails to lure victims to compromised sites. ScanBox collects detailed browser and system information, including browser extensions and network details, facilitating further targeted espionage activities. The threat actor is linked to the Chinese Ministry of State Security and focuses on intelligence gathering related to geopolitical interests in the South China Sea and beyond.

Overview Firmware versions 2.7.7 and earlier of the Arris BGW210-700 residential gateway contain an authentication bypass vulnerability, tracked as CVE-2026-16771, that allows any unauthenticated LAN-side user to read sensitive configuration data and modify device settings through web management endpoints. Although this vulnerability was recently discovered, the majority of in-service gateways are not expected to be running the affected version. Only devices that have not received automated ISP-managed firmware updates since version 2.7.7 in 2020 are vulnerable. Description The Arris BGW210-700 is a residential gateway used widely in AT&T deployments to provide routing, wireless networking, and wide-area network (WAN) connectivity for home users. The device exposes a browser-based management interface on the local-area network (LAN) side that allows users to configure WiFi settings, check diagnostics, and run system operations. Several CGI (Common Gateway Interface) handlers within the BGW210-700's web interface do not enforce any server-side authentication checks. Although the interface presents an "Access Code" prompt to users, this restriction is entirely implemented through client-side HTML and JavaScript and is not validated by the server before processing requests. As a result, any HTTP client that ignores client-side code can directly access and interact with the underlying CGI endpoints. The lack of server-side authentication affects multiple configuration and diagnostic pages. The wconfig_unified.ha endpoint returns the plaintext WiFi pre-shared key for all configured SSIDs to any unauthenticated requester. The broadbandconfig.ha endpoint accepts unauthenticated POST requests that directly modify WAN configuration parameters, including settings that persist across device reboots. Additional diagnostic endpoints, such as diag.ha , allow unauthenticated triggering of backend diagnostic jobs. Impact This vulnerability allows any unauthenticated user on the LAN, including devices connected to the gateway through the main WiFi network, Guest WiFi network, or LAN ethernet, to read sensitive configuration information and make persistent changes to gateway settings. A local attacker can retrieve the network's plaintext WiFi password with a single HTTP request and achieve unauthorized access to manipulate, intrude on, and interfere with protected networks. Solution This gateway is ISP-managed, so all standard internet-connected devices are expected to have been automatically updated to newer unaffected versions. Users can determine their active version by checking their router's diagnostic settings via web browser, and optionally contact their ISP to confirm that automatic updates are functioning correctly. Because the vulnerability is limited to the LAN-side management interface, standard network hygiene practices such as isolating untrusted devices, keeping IoT systems updated, and monitoring for the presence of unknown clients can further reduce risk in environments where older firmware may still be present. Acknowledgements Thanks to David Weekly for researching and reporting this vulnerability. This document was written by Molly Jaconski. Vendor Information One or more vendors are listed for this advisory. Please reference the full report for more information. Other Information CVE IDs: CVE-2026-16771 Date Public: 2026-07-28 Date First Published: 2026-07-28 Date Last Updated: 2026-07-28 18:43 UTC Document Revision: 3 About vulnerability notes Contact us about this vulnerability Provide a vendor statement

A large malvertising campaign uses fake Solana, Luno, and TradingView websites with malicious JavaScript that assembles malware directly in browser memory. The attack uses service workers and shared workers to build a unique malware executable locally, avoiding transmission of a complete file over the network. This technique helps evade static detection and complicates analysis. The campaign targets retail traders and crypto investors primarily in Asia Pacific and Latin America. The malware reportedly can intercept network traffic, steal credentials and cryptocurrency wallet data, record keystrokes, take screenshots, and maintain persistence. Users are advised to download financial software only from official sources and verify digital signatures.

Unit 42 details a Russian cyberespionage campaign targeting Zimbra webmail servers using JavaScript injection to steal credentials. The post Russian Global Webmail Espionage appeared first on Unit 42 .

MediumCampaignUkraine#web#java#javascript