Loading story…
Researchers disclosed an out-of-bounds heap-write flaw in the Go-based JavaScript engine Goja affecting TypedArray.prototype.with and TypedArray.prototype.toReversed. The implementations incorrectly apply a source TypedArray offset when writing to a newly allocated destination array; Goja’s use of unsafe pointer operations converts the logic error into memory corruption. Researchers built arbitrary read/write primitives and hijacked a Go function pointer associated with Date.now to achieve arbitrary code execution.
The flaw was demonstrated as post-authentication remote code execution in Zendesk Action Flows and as arbitrary code execution in ProjectDiscovery Nuclei. In Nuclei, a malicious JavaScript payload placed in a template’s init section could execute before template signature validation. Zendesk and ProjectDiscovery have issued patches; organizations running untrusted JavaScript through Goja should update to the latest patched Goja release and review JavaScript-enabled workflows and Nuclei template sources.
See affected versions and whether adversaries are exploiting it.
5 events from the most recent confirmed update back to the earliest known activity.
Zendesk and ProjectDiscovery Nuclei applied patches for the Goja vulnerability. Organizations using Goja to run untrusted JavaScript were advised to update to the latest Goja release.
Researchers showed that malicious JavaScript in a Nuclei template's init section executed before template signature validation, enabling arbitrary code execution even though Nuclei subsequently rejected the unsigned template. The proof of concept executed commands as root in the test environment, including on macOS through a ROP-based path.
Researchers demonstrated that an authenticated user able to provide malicious JavaScript to a Zendesk Action Flows custom-code step could achieve remote code execution through Goja.
The researchers reported the vulnerability to Zendesk and the Goja project in mid-June. Zendesk merged a remediation pull request within days, according to the researchers.
Researchers identified an out-of-bounds heap-write in Goja's TypedArray.prototype.with and TypedArray.prototype.toReversed methods. The flaw could be developed into arbitrary read/write primitives and Go function-pointer hijacking for arbitrary code execution.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
4 references tracked. Mallory keeps watching after this page renders.
reddit.com
Open sourceslcyber.io
Open sourceslcyber.io
Open sourcepkg.go.dev
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A vulnerability in the npm package **`protobufjs`** allows arbitrary JavaScript execution when an application processes attacker-controlled protobuf definition files. The flaw, tracked as **`GHSA-xq3m-2v4x-88gg`**, stems from unsafe handling of protobuf **`type`** fields, which can be compiled into executable JavaScript and triggered during object decoding, creating a path to remote code execution in affected deployments. The issue affects **`protobufjs`** versions up to **`8.0.0`** and **`7.5.4`**, and has been fixed in **`8.0.1`** and **`7.5.5`**. A published proof of concept shows a malicious JSON descriptor invoking Node.js **`child_process`** during decode, underscoring the risk for applications that ingest untrusted schema or descriptor data. Organizations using `protobufjs` should upgrade to the patched releases and review whether external parties can supply protobuf definitions.
Jun 29, 2026
A critical vulnerability in the Node.js sandboxing library **`isolated-vm`** allows guest JavaScript to escape its sandbox, corrupt host memory, and potentially achieve remote code execution. Tracked as **`GHSA-864f-rcv7-6rh4`** and awaiting a CVE, the flaw was disclosed by Endor Labs as a type confusion bug in **`ExternalCopy`** handling of the **`transferList`** option. Researchers said the issue stems from a time-of-check/time-of-use gap across two iterations of a JavaScript array, where attacker-controlled getters can return an `ArrayBuffer` during validation and a different value during unchecked use, leading to unsafe behavior in the host process. The bug affects **all versions through `7.0.0`**, with fixes released in **`6.2.0`** and **`7.0.1`**. Endor Labs demonstrated exploitation beginning with only a single **`ivm.Reference`** exposed to the sandbox, first triggering a controlled host crash and then hijacking host control flow to call a chosen libc function. The maintainer patched the issue by blocking JavaScript execution during the copy operation using **`v8::Isolate::DisallowJavascriptExecutionScope`**. The disclosure is especially significant because `isolated-vm` is widely used to run untrusted code despite longstanding project warnings that misuse of objects such as `Reference` and `ExternalCopy`, as well as unsafe handling of snapshots or `cachedData`, can undermine isolation and expose the main Node.js process.
Aug 24, 2026
A **critical remote code execution** issue in the *n8n* open-source workflow automation platform, tracked as **CVE-2026-25049** (also published as **GHSA-6cqr-8cfr-67f8**), allows an **authenticated** user with permission to create or modify workflows to escape n8n’s expression sandbox and execute arbitrary system commands on the underlying host. The flaw stems from **insufficient input sanitization/weak sandboxing** in n8n’s expression evaluation (server-side JavaScript) and was identified during follow-up analysis after an earlier critical n8n vulnerability (**CVE-2025-68613**) was patched; researchers report the new issue effectively **bypasses prior mitigations**. Reporting indicates exploitation can lead to **full compromise** of the n8n instance, including access to the filesystem and the ability to **steal stored credentials and secrets** (e.g., API keys, OAuth tokens) and sensitive configuration, with potential for **pivoting** into connected internal services and cloud accounts in multi-tenant deployments. Public reporting also notes **public exploits** are available. n8n maintainers state the issue is patched, and affected organizations should upgrade to fixed releases (**1.123.17** and **2.5.2**), as versions **prior to 1.123.17 and 2.5.2** are impacted.
Jun 29, 2026