Npm — CraftedSignal Threat Feed

Increased npm Supply Chain Attacks Targeting SAP Developers

hello@craftedsignal.io — Sat, 02 May 2026 00:10:33 +0000

The npm ecosystem is experiencing a surge in sophisticated supply chain attacks following the Shai-Hulud worm in September 2025. Attackers, including TeamPCP, are actively compromising npm packages to gain access to sensitive information and establish persistence within CI/CD pipelines. The attacks have evolved to include wormable propagation, infrastructure-level persistence, and multi-stage payloads designed to evade detection. In April 2026, two campaigns were observed: one included the string “Shai-Hulud: The Third Coming,” and the other, dubbed “Mini Shai-Hulud,” targeted the SAP developer ecosystem. The compromised packages are often part of SAP’s Cloud Application Programming (CAP) Model and multitarget application (MTA) build toolchain, increasing the likelihood of impacting enterprise developers and CI/CD pipelines with access to cloud credentials and GitHub tokens.

Attack Chain

Initial Compromise: Attackers compromise legitimate npm packages, such as @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service, and mbt, by injecting malicious code.
Malicious Code Injection: Compromised packages receive two new files: setup.mjs and execution.js, along with a modified package.json containing a “preinstall” hook.
Execution of setup.mjs: During the npm install process, the preinstall hook executes setup.mjs, which detects the host OS and architecture.
Bun Runtime Download and Execution: setup.mjs downloads the Bun JavaScript runtime (v1.3.13) from GitHub releases and extracts it to a temporary directory.
Execution of execution.js: The Bun runtime executes execution.js, a large (11.7 MB) obfuscated credential stealer and propagation framework.
Credential Harvesting: execution.js harvests GitHub tokens, npm tokens, environment variables, GitHub Actions secrets, AWS STS identity, Azure Key Vault secrets, GCP Secret Manager values, and Kubernetes service account tokens. It also targets Claude and MCP configuration files and Electrum wallets.
Data Exfiltration: The collected data is compressed, encrypted, and exfiltrated to freshly created public GitHub repositories with randomized names and descriptions.
Propagation: The malware searches for commits containing the keyword “OhNoWhatsGoingOnWithGitHub,” decodes matching commit messages as a token dead-drop, recovers stolen GitHub tokens, and uses them to spread the malware to other packages.

Impact

Compromised npm packages can lead to the theft of sensitive credentials, including cloud provider credentials, GitHub tokens, and CI/CD secrets. Successful attacks can result in unauthorized access to cloud infrastructure, code repositories, and deployment pipelines. The Mini Shai-Hulud campaign targeted packages with approximately 570,000 weekly downloads, potentially impacting a large number of SAP developers and enterprise environments. The attackers use stolen credentials to further propagate the malware, increasing the scale and scope of the compromise.

Recommendation

Rotate npm tokens and GitHub Personal Access Tokens (PATs) immediately if any affected packages were installed (refer to the list of affected packages in the IOC table).
Monitor npm install processes for unexpected execution of node setup.mjs (see Attack Chain).
Implement the Sigma rule “Detect Suspicious Bun Process Execution” to identify potential execution of the Bun runtime from temporary directories.
Monitor network connections for unusual processes connecting to api.github[.]com/search/commits?q=OhNoWhatsGoingOnWithGitHub (see IOCs) to detect potential C2 activity.
Deploy the Sigma rule “Detect Github Commit By Claude Email” to identify commits authored with the email claude@users.noreply.github.com to detect malicious commits.

n8n XML Node Prototype Pollution Leading to RCE

hello@craftedsignal.io — Wed, 29 Apr 2026 21:25:53 +0000

A critical vulnerability, CVE-2026-42232, exists within the n8n workflow automation tool. This flaw allows an authenticated user, who possesses permissions to create or modify workflows, to achieve remote code execution (RCE). The attack vector involves exploiting global prototype pollution through the XML Node. Versions affected include those prior to 1.123.32, versions 2.17.0 up to but not including 2.17.4, and versions 2.18.0 up to but not including 2.18.1. Defenders should prioritize patching n8n instances due to the high potential for complete system compromise if exploited.

Attack Chain

An attacker authenticates to an n8n instance with workflow creation/modification privileges.
The attacker crafts a malicious workflow that leverages the XML Node to inject a payload designed to trigger prototype pollution.
The crafted XML node manipulates global object prototypes within the n8n application.
The attacker introduces a property into a global object prototype that can be exploited by another node.
The attacker adds a secondary node (e.g., Function node) that leverages the polluted prototype property.
The secondary node’s execution triggers the polluted prototype, leading to arbitrary code execution.
The attacker executes arbitrary commands on the n8n server.
The attacker gains complete control of the n8n server, potentially leading to data exfiltration, lateral movement, or other malicious activities.

Impact

Successful exploitation of this vulnerability allows an attacker to execute arbitrary code on the n8n server. This can lead to full system compromise, including data exfiltration, credential theft, and lateral movement within the network. Given the nature of n8n as an automation platform, successful attacks can severely impact connected systems and services. This vulnerability affects n8n users who have not upgraded to patched versions.

Recommendation

Upgrade n8n to version 1.123.32, 2.17.4, 2.18.1, or later to remediate CVE-2026-42232.
As a temporary mitigation, limit workflow creation and editing permissions to only fully trusted users as suggested in the advisory.
As a temporary mitigation, disable the XML node by adding n8n-nodes-base.xml to the NODES_EXCLUDE environment variable as suggested in the advisory.

n8n MCP OAuth Client XSS Vulnerability

hello@craftedsignal.io — Wed, 29 Apr 2026 21:25:44 +0000

n8n, a workflow automation platform, is susceptible to a cross-site scripting (XSS) vulnerability (CVE-2026-42235) related to the registration of malicious MCP OAuth clients. An unauthenticated attacker can register an OAuth client with a crafted client_name containing malicious JavaScript. This vulnerability exists in versions prior to 2.14.2 and also affects versions 2.17.0 to 2.17.3 and 2.18.0. A successful exploit allows the attacker to execute arbitrary JavaScript within a victim’s authenticated n8n session, potentially leading to credential theft, session token theft, workflow manipulation, or privilege escalation. Defenders should prioritize patching to version 2.14.2 or later to mitigate the risk.

Attack Chain

An unauthenticated attacker registers a malicious MCP OAuth client with a crafted client_name containing XSS payload.
A victim user navigates to the n8n instance and is presented with the malicious OAuth consent dialog.
The victim user authorizes the malicious OAuth client, unknowingly injecting the attacker’s script into their session.
A second user, possibly an administrator, revokes the OAuth access granted to the malicious client.
This revocation triggers a toast notification to the original victim user.
The toast notification renders the attacker’s injected script from the crafted client_name.
The victim user clicks on the link within the toast notification.
The injected JavaScript executes within the victim’s authenticated n8n browser session, enabling the attacker to perform malicious actions such as stealing credentials, manipulating workflows, or escalating privileges.

Impact

Successful exploitation of this XSS vulnerability can lead to significant compromise of an n8n instance. Attackers can steal user credentials and session tokens, allowing them to impersonate legitimate users. Malicious actors could also modify or create workflows, leading to data breaches, system disruption, or unauthorized access. Privilege escalation is also possible, potentially granting attackers administrative control over the n8n platform. The number of potential victims depends on the exposure and user base of the vulnerable n8n instances.

Recommendation

Upgrade n8n to version 2.14.2 or later to patch CVE-2026-42235, as recommended in the advisory.
Deploy the Sigma rule Detect Suspicious n8n MCP OAuth Client Registration to identify attempts to register OAuth clients with suspicious names.
If immediate patching is not feasible, restrict access to the n8n instance and the MCP OAuth registration endpoint to trusted users only, as suggested in the advisory’s workaround.

n8n Prototype Pollution in XML Webhook Body Parser Leads to RCE

hello@craftedsignal.io — Wed, 29 Apr 2026 21:25:02 +0000

A critical vulnerability exists within the n8n workflow automation platform, specifically affecting the parsing of XML request bodies in webhook handlers. This flaw stems from the use of the xml2js library, which is susceptible to prototype pollution attacks. An authenticated user possessing the capability to create or modify workflows can leverage this vulnerability by sending a specially crafted XML payload. Successful exploitation results in the pollution of the JavaScript object prototype. Attackers can chain this pollution with the Git node’s SSH operations to achieve arbitrary remote code execution (RCE) on the underlying n8n host. The vulnerability affects n8n versions prior to 1.123.32, versions 2.17.0 to 2.17.3, and versions 2.18.0 to 2.18.0.

Attack Chain

An attacker authenticates to the n8n instance.
The attacker crafts a malicious XML payload designed to exploit the prototype pollution vulnerability in the xml2js library.
The attacker creates or modifies a workflow containing a webhook node configured to receive XML data.
The attacker sends the crafted XML payload to the webhook endpoint.
The xml2js library parses the malicious XML, inadvertently polluting the JavaScript object prototype with attacker-controlled properties.
The attacker includes a Git node in the workflow.
The polluted prototype modifies the behavior of the Git node’s SSH operations.
When the workflow executes, the Git node’s SSH operation is hijacked due to the prototype pollution, leading to arbitrary code execution on the n8n host.

Impact

Successful exploitation allows a malicious actor to execute arbitrary code on the n8n server. This grants them complete control over the n8n instance and potentially the underlying infrastructure. The vulnerability impacts any n8n instance accessible to authenticated users who can create or modify workflows. The number of affected installations is unknown, but the potential impact is high due to the sensitive nature of workflows often managed by n8n, which can include access to other systems and data.

Recommendation

Upgrade n8n to version 1.123.32, 2.17.4, 2.18.1, or later to patch the vulnerability as described in the overview.
Deploy the Sigma rule “Detect n8n Prototype Pollution via Crafted XML Payload” to detect malicious XML payloads targeting the vulnerability. Enable webserver logs to activate this rule.
Limit workflow creation and editing permissions to trusted users to mitigate the risk of exploitation, as described in the workaround.

i18next-http-middleware Prototype Pollution and Path Traversal Vulnerability

hello@craftedsignal.io — Fri, 26 Jan 2024 12:00:00 +0000

i18next-http-middleware versions prior to 3.9.3 are susceptible to prototype pollution, path traversal, and SSRF attacks. The vulnerability stems from the insufficient validation of the lng (language) and ns (namespace) parameters passed via HTTP requests to the getResourcesHandler and the missingKeyHandler. These handlers, intended to serve localization resources, expose attack surface because they process user-controlled input without proper sanitization. This allows attackers to manipulate object properties, access unintended files or internal services, and cause denial-of-service conditions. The vulnerability was discovered via an internal security audit. Defenders should upgrade to version 3.9.3 to remediate the risks.

Attack Chain

The attacker crafts an HTTP GET request to the /locales/resources.json endpoint, targeting the getResourcesHandler.
The request includes malicious lng and ns query parameters, such as lng=__proto__&ns=isAdmin, or ns=../../etc/passwd.
The getResourcesHandler extracts the lng and ns parameters without sufficient validation.
The lng and ns values are passed to utils.setPath(resources, [lng, ns], ...) which allows writing to the Object prototype if lng is __proto__.
The lng and ns values are passed to i18next.services.backendConnector.load(languages, namespaces, ...) to load resource bundles. With filesystem or HTTP backends, this can enable path traversal or SSRF if ns or lng contain malicious path segments.
Alternatively, the attacker sends a POST request with a body containing a malicious __proto__ key to missingKeyHandler, for example {"__proto__": {"isAdmin": true}}.
The missingKeyHandler iterates over the request body using for...in, including inherited prototype properties, and forwards the malicious data into saveMissing.
Successful exploitation leads to prototype pollution, arbitrary file access, SSRF, or denial of service.

Impact

Successful exploitation can have significant consequences. Prototype pollution allows attackers to manipulate object properties globally, leading to broken authorization checks (e.g., bypassing if (user.isAdmin)), type confusion errors, or potentially remote code execution. Path traversal enables access to sensitive files on the server, like configuration files or password databases, while SSRF allows attackers to interact with internal services. Finally, the unbounded growth of the i18next.options.ns list and repeated backend load calls can lead to denial of service due to memory and CPU exhaustion. This can impact availability of the service and potentially other services on the same host.

Recommendation

Upgrade to i18next-http-middleware version 3.9.3 or later to address the vulnerabilities.
Deploy the Sigma rules provided below to detect exploitation attempts targeting the getResourcesHandler and missingKeyHandler endpoints.
If upgrading is not immediately feasible, implement a WAF rule as a partial mitigation to block requests containing __proto__, constructor, prototype, .., or control characters in lng/ns query parameters or body keys as suggested in the advisory.

i18next-fs-backend Path Traversal Vulnerability

hello@craftedsignal.io — Thu, 25 Jan 2024 12:00:00 +0000

The i18next-fs-backend library, a file system backend for the i18next internationalization framework, is vulnerable to a path traversal attack in versions prior to 2.6.4. This vulnerability arises from the unsanitized use of the lng (language) and ns (namespace) parameters when constructing file paths for loading and writing locale files. If an application exposes the language code to user input, an attacker can craft a malicious lng or ns value containing directory traversal sequences (e.g., ../) to escape the intended locale directory. Successful exploitation can lead to arbitrary file read, arbitrary file overwrite, and, if .js or .ts files are used for localization, arbitrary code execution. This vulnerability highlights the importance of input validation, especially when constructing file paths from user-controlled data. The vulnerability was patched in version 2.6.4.

Attack Chain

An attacker identifies an application using a vulnerable version of i18next-fs-backend (versions prior to 2.6.4) and exposes the language code to user input via query parameters (e.g., ?lng=), cookies, or request headers.
The attacker crafts a malicious lng value containing directory traversal sequences, such as ../../../../etc, to target sensitive files outside the intended locale directory.
The attacker sends a request to the application with the crafted lng parameter.
The application passes the unsanitized lng value to the i18next.t() function.
The i18next-fs-backend library interpolates the malicious lng value into the loadPath configuration option, without proper validation. For example, loadPath: '/locales/{{lng}}/{{ns}}.json' becomes /locales/../../../../etc/{{ns}}.json.
The backend attempts to read the file specified by the crafted path (e.g., /etc/passwd).
If successful, the contents of the targeted file are returned as a translation resource, potentially exposing sensitive information. If the attacker crafted the lng or ns value to point to a .js or .ts file containing malicious code, the backend will execute the file using eval(), leading to arbitrary code execution on the server.
Alternatively, if the application attempts to write a missing translation key using the crafted path (via addPath), the attacker could overwrite arbitrary files on the system, potentially leading to application compromise.

Impact

Successful exploitation of this vulnerability can have severe consequences. Arbitrary file read allows attackers to access sensitive data, such as configuration files, database credentials, or application source code. Arbitrary file overwrite can lead to application malfunction or complete compromise. If the application uses .js or .ts files for localization and the attacker is able to inject malicious code into those files through path traversal, arbitrary code execution can result, potentially allowing the attacker to gain full control of the server. The number of victims depends on the popularity and configuration of applications using the vulnerable i18next-fs-backend library.

Recommendation

Upgrade to i18next-fs-backend version 2.6.4 or later to patch the path traversal vulnerability as this version introduces the isSafePathSegment and interpolatePath functions to sanitize the path.
If upgrading is not immediately feasible, sanitize the lng and ns values at the application boundary before passing them to i18next. Reject values containing .., /, \, control characters, and limit the length to prevent path traversal as mentioned in the advisory.
If using .js or .ts locale files, carefully review them for any suspicious or unexpected code. The advisory highlights that these files must be treated as trusted code.
Monitor web server logs for suspicious requests containing directory traversal sequences in the lng or ns parameters. Deploy the first Sigma rule for this purpose.

OpenClaw MCP Loopback Token Spoofing Vulnerability

hello@craftedsignal.io — Tue, 09 Jan 2024 12:00:00 +0000

OpenClaw, a package available on npm, contains a vulnerability in versions 2026.4.21 and earlier that allows for token spoofing within the MCP loopback path. This flaw stems from the acceptance of spoofable owner-context metadata from request headers. A malicious actor could exploit this by crafting requests that falsely present them as the owner, thereby bypassing authorization checks and potentially gaining unauthorized access to operations intended only for the owner. The vulnerability was reported by @VladimirEliTokarev and patched in version 2026.4.22. This issue matters for defenders because it can lead to privilege escalation and unauthorized modification of system configurations or data.

Attack Chain

Attacker identifies a vulnerable OpenClaw instance (version <= 2026.4.21) utilizing the MCP loopback.
Attacker crafts a malicious HTTP request targeting the MCP loopback endpoint.
Attacker injects a forged “sender-owner” header into the HTTP request, claiming owner privileges.
The vulnerable OpenClaw instance incorrectly trusts the spoofed “sender-owner” header.
The application bypasses owner authorization checks due to the forged header.
Attacker gains access to owner-gated operations within the MCP loopback.
Attacker performs unauthorized actions, such as modifying configurations or accessing sensitive data.
Attacker maintains unauthorized access, potentially escalating privileges further within the system.

Impact

Successful exploitation of this vulnerability could allow unauthorized access to critical system functions intended only for the owner. This could lead to configuration changes, data breaches, or other malicious activities depending on the specific owner-gated operations exposed within the OpenClaw MCP loopback. The severity depends on the permissions granted to the “owner” context within the application but could be critical.

Recommendation

Upgrade OpenClaw to version 2026.4.22 or later to remediate the vulnerability as described in the fix commit 3cb1a56bfc9579a0f2336f9cfa12a8a744332a19.
Implement network monitoring to detect suspicious HTTP requests containing potentially forged “sender-owner” headers targeting MCP loopback endpoints using the Sigma rule Detect OpenClaw MCP Loopback Owner Spoofing.
Review and audit existing OpenClaw deployments to identify and patch vulnerable instances quickly.

xmldom XML Injection Vulnerability

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The @xmldom/xmldom and xmldom packages are vulnerable to XML injection due to the lack of validation when serializing DocumentType node fields. Specifically, the internalSubset, publicId, and systemId fields are serialized verbatim without any escaping or validation. This vulnerability affects @xmldom/xmldom versions prior to 0.8.13 and versions 0.9.0 to 0.9.9, as well as xmldom versions up to 0.6.0. The vulnerability is triggered when these fields are programmatically set to attacker-controlled strings, leading to potential arbitrary markup injection outside the DOCTYPE declaration during serialization using XMLSerializer.serializeToString. This can lead to downstream XML parsers being susceptible to XXE attacks. Defenders should audit serializeToString() call sites and add { requireWellFormed: true } to mitigate this vulnerability.

Attack Chain

The attacker identifies an application using a vulnerable version of @xmldom/xmldom or xmldom.
The attacker finds a code path where they can control the publicId, systemId, or internalSubset properties of a DocumentType node.
The attacker crafts a malicious string containing XML injection payloads (e.g., closing DOCTYPE tags or injecting SYSTEM entities).
The attacker uses programmatic calls to createDocumentType or direct property writes to set the malicious string as the value of the publicId, systemId, or internalSubset field.
The application calls XMLSerializer.serializeToString on the document, without the { requireWellFormed: true } option.
The vulnerable serializer emits a DOCTYPE declaration where the injected malicious string is included verbatim, causing the DOCTYPE declaration to be terminated early or to include injected entities.
The serialized XML is passed to a downstream XML parser that performs entity expansion.
The downstream XML parser expands the injected entities, leading to potential XXE attacks, information disclosure, or other malicious actions.

Impact

Successful exploitation of this vulnerability can lead to the injection of arbitrary XML markup, potentially enabling XXE attacks against downstream XML parsers. The impact includes potential information disclosure, arbitrary code execution, or denial-of-service if the downstream parser expands external entities. This vulnerability impacts applications using vulnerable versions of @xmldom/xmldom and xmldom that construct DocumentType nodes from user-controlled data and serialize the document without proper validation.

Recommendation

Upgrade to @xmldom/xmldom version 0.8.13 or later, or version 0.9.10 or later, to receive the fix.
Upgrade to a version of xmldom greater than 0.6.0.
Audit all calls to XMLSerializer.serializeToString() and add the option { requireWellFormed: true } to enforce validation of DocumentType node fields, as described in the advisory.
Applications that pass untrusted data to createDocumentType() or write untrusted values directly to a DocumentType node’s publicId, systemId, or internalSubset properties should audit all serializeToString() call sites and add the option.

VM2 Sandbox Escape via lookupGetter Vulnerability

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The vm2 library, a popular Node.js sandbox environment, is susceptible to a critical sandbox breakout vulnerability. This flaw allows malicious code executed within the vm2 sandbox to escape its confines and execute arbitrary commands on the host operating system. The vulnerability leverages the __lookupGetter__ method to bypass context isolation and gain access to host-level functions and objects. Previous attempts to mitigate similar issues were circumvented using Object.getOwnPropertyDescriptor to access the constructor property. The vulnerability affects vm2 versions 3.10.4 and earlier. Exploitation allows an attacker to achieve remote code execution with the privileges of the Node.js process running the vm2 sandbox, which could lead to significant system compromise.

Attack Chain

Attacker injects malicious JavaScript code into the vm2 sandbox.
The injected code retrieves the __lookupGetter__ method, which is used to access the getter of an object.
The malicious code obtains the apply method from the Buffer object within the sandbox.
The apply method is used to invoke the host version of __lookupGetter__ with Buffer and __proto__ as arguments, gaining access to the host’s prototype lookup method.
The host’s Function.prototype object is retrieved using the prototype lookup method.
The constructor property of the Function.prototype object is accessed using Object.getOwnPropertyDescriptor to bypass previous mitigation attempts.
The host Function constructor is used to create a new function that returns the process object, granting access to Node.js runtime functions on the host.
The code then uses child_process.execSync to execute arbitrary commands on the host system (e.g., touch pwned).

Impact

Successful exploitation of this vulnerability allows attackers to execute arbitrary code on the host system. Given the critical nature of many applications that employ sandboxing, this can lead to complete system compromise, data exfiltration, and denial of service. The vulnerability affects vm2 versions up to and including 3.10.4. The impact includes remote code execution, potentially leading to sensitive data exposure, system takeover, or further lateral movement within a network.

Recommendation

Upgrade to a patched version of vm2 greater than 3.10.4 to remediate CVE-2026-24118.
Implement strict input validation and sanitization to minimize the risk of malicious code injection into the vm2 sandbox.
Monitor process creation events on the host system for suspicious activity originating from Node.js processes, which may indicate a sandbox escape (see the process_creation Sigma rule below).
Monitor for the execution of commands such as child_process.execSync called from within vm2 sandboxes to detect potential exploitation attempts (see the nodejs_child_process_exec Sigma rule).

i18next-http-middleware HTTP Response Splitting and DoS Vulnerability

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The i18next-http-middleware library, in versions prior to 3.9.3, exhibits a vulnerability stemming from insufficient sanitization of user-controlled language values. These values are written into the Content-Language HTTP response header. The utils.escape() function, employed for sanitization, performs HTML-entity encoding but fails to strip critical characters like carriage return and line feed. When the application uses an older i18next (< 19.5.0) or produces raw detected values, CRLF sequences within the lng parameter reach res.setHeader('Content-Language', ...) without proper escaping. This flaw can result in HTTP response splitting (Node.js < 14.6.0) or a denial-of-service condition (Node.js >= 14.6.0), impacting all concurrent users of the affected process. The same vulnerability is triggered multiple times per request. This issue is resolved in version 3.9.3.

Attack Chain

The attacker crafts a malicious HTTP request targeting an application using a vulnerable version of i18next-http-middleware. The request includes a lng parameter with a payload containing CRLF sequences (e.g., %0d%0a).
The i18next-http-middleware receives the request and extracts the language value from the lng parameter.
The extracted language value is passed through utils.escape(), which performs HTML-entity encoding but does not remove CRLF sequences.
The middleware attempts to set the Content-Language header using res.setHeader(), incorporating the unsanitized language value.
If the Node.js version is less than 14.6.0, the res.setHeader() function processes the CRLF sequences, resulting in HTTP response splitting. This allows the attacker to inject arbitrary headers and control parts of the response body.
If the Node.js version is 14.6.0 or greater, res.setHeader() throws an ERR_INVALID_CHAR error because the value contains CRLF sequences.
The middleware fails to catch this error, and the exception propagates, leading to an unhandled exception.
The unhandled exception causes the Node.js process to terminate or become unresponsive, resulting in a denial-of-service condition for all concurrent users sharing that process.

Impact

Successful exploitation allows attackers to inject arbitrary HTTP headers, leading to session fixation, cache poisoning, or reflected XSS attacks. In Node.js versions 14.6.0 and later, exploitation leads to a denial-of-service condition, potentially impacting all users of an application instance. This can result in significant disruption of service availability and potential data compromise. The number of affected applications is unknown, but any application using a vulnerable version of i18next-http-middleware is at risk.

Recommendation

Upgrade i18next-http-middleware to version 3.9.3 or later to address the vulnerability by patching the utils.sanitizeHeaderValue() function, as described in the advisory.
Deploy the Sigma rule Detect i18next-http-middleware CRLF Injection Attempt to monitor for exploitation attempts by detecting suspicious URL-encoded characters in HTTP requests.
Implement a Web Application Firewall (WAF) rule to reject requests containing \r or \n characters in query parameters, cookies, and path segments as a partial mitigation, as suggested in the advisory.
Enable web server logging to ensure events related to potential exploits are captured for analysis.

Denial of Service Vulnerability in marked via Infinite Recursion

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

A critical Denial of Service (DoS) vulnerability has been identified in marked@18.0.0. This vulnerability arises from the processing of a specific 3-byte input sequence: a tab character, a vertical tab character, and a newline character (\x09\x0b\n). An unauthenticated attacker can exploit this by sending this sequence to a Node.js application utilizing the vulnerable version of the marked library. This input triggers an infinite recursion loop within the marked tokenizer during parsing, leading to unbounded memory allocation and ultimately causing the host Node.js application to crash due to Memory Exhaustion (OOM). This vulnerability allows for a total loss of availability for any application using the vulnerable library to process potentially untrusted input.

Attack Chain

The attacker sends a crafted input string containing the sequence \x09\x0b\n to a Node.js application using marked@18.0.0.
The space() tokenizer in marked consumes the initial tab character (\x09) using the regex /^(?:[ \t]*(?:\n|$))+/.
The newline block rule fails to match the remaining \x0b\n sequence because the vertical tab is not accounted for in the rule [ \t].
The parser falls through to the text tokenizer (/^[^\n]+/), which matches the \x0b\n sequence.
Inside the blockTokens() function, the text tokenizer creates a text token.
The blockTokens() function then calls inlineTokens() on the same input (\x0b\n).
The inlineTokens() function’s text rule matches \x0b\n and recursively calls inlineTokens() again, leading to an infinite loop.
Each recursive call allocates new token objects and concatenates strings, causing memory usage to grow until the Node.js heap limit is reached, resulting in a crash.

Impact

This vulnerability results in a High-Severity Denial of Service (DoS) via Memory Exhaustion. Any application, API, chatbot, or documentation system using marked@18.0.0 to parse untrusted user input is vulnerable. The attack requires minimal resources from the attacker, only the ability to send a 3-byte payload, to cause a total loss of availability. The vulnerability affects npm/marked versions greater than or equal to 18.0.0 and less than or equal to 18.0.1.

Recommendation

Upgrade to a patched version of the marked library that addresses the infinite recursion vulnerability.
Monitor Node.js application logs for error messages indicating memory exhaustion or crashes, which might indicate exploitation attempts.
Implement input validation to sanitize or reject input containing the malicious \x09\x0b\n sequence.
Deploy the Sigma rule for marked process crashes due to memory exhaustion to identify exploitation attempts.

OpenClaw Symlink Race Condition Allows Sandbox Escape

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

OpenClaw, a tool available via npm, contains a vulnerability in versions 2026.4.21 and earlier that could allow for a sandbox escape. This vulnerability stems from a time-of-check/time-of-use (TOCTOU) race condition during filesystem writes within the OpenShell sandbox environment. An attacker could potentially exploit this vulnerability by manipulating symlinks to redirect write operations outside of the intended local mount root. This can occur because OpenClaw does not properly validate the target of write operations against the mount root, leaving it susceptible to symlink-based redirection attacks. Successful exploitation could allow an attacker to modify sensitive files outside the sandbox. The vulnerability is fixed in version 2026.4.22.

Attack Chain

An attacker crafts a malicious OpenClaw package or leverages an existing package.
The package contains a symlink within the intended sandbox directory.
The OpenClaw application attempts to write to a file via the symlink.
Between the time OpenClaw checks the symlink and the time it performs the write operation, the attacker replaces the symlink with a new symlink pointing outside the intended sandbox root.
OpenClaw, due to the TOCTOU race condition, writes to the file location pointed to by the new symlink, which resides outside the sandbox.
This allows the attacker to overwrite or modify arbitrary files on the system.
The attacker leverages this capability to gain elevated privileges or compromise sensitive data.

Impact

Successful exploitation of this vulnerability could allow an attacker to bypass the intended security restrictions of the OpenClaw sandbox. An attacker could potentially overwrite system files, inject malicious code into existing applications, or steal sensitive data. While the exact number of affected installations is unknown, any system running a vulnerable version of OpenClaw is susceptible to this attack.

Recommendation

Upgrade to OpenClaw version 2026.4.22 or later to patch the vulnerability (reference: Affected Packages / Versions).
Monitor file system events for unexpected modifications outside of the expected OpenClaw sandbox directory. Deploy the Sigma rule Detect OpenClaw Sandbox Escape via Symlink to detect potential exploitation attempts.
Implement stricter file system access controls to limit the potential impact of successful exploitation (reference: Impact).

n8n Unauthenticated Denial of Service via MCP Client Registration

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

n8n, a workflow automation platform, is susceptible to a denial-of-service (DoS) vulnerability due to insufficient resource controls on the MCP OAuth client registration endpoint. This vulnerability, identified as CVE-2026-42236, allows an unauthenticated remote attacker to send large registration payloads to the server, potentially exhausting server memory resources. Even if the MCP is disabled via the enable/disable toggle, client registrations are still possible. The attack results in the n8n instance becoming unavailable, disrupting normal operations. The vulnerability affects n8n versions before 1.123.32, versions 2.0.0 to 2.17.4, and versions 2.18.0 to 2.18.1. Patches are available in n8n versions 1.123.32, 2.17.4, and 2.18.1 to address this issue by implementing an upper bound on registered clients and disabling client creation when MCP is disabled.

Attack Chain

The attacker identifies an n8n instance running a vulnerable version (e.g., < 1.123.32, 2.0.0 < x < 2.17.4, or 2.18.0 < x < 2.18.1).
The attacker sends an unauthenticated HTTP POST request to the MCP OAuth client registration endpoint. The exact URI path for this endpoint is not specified in the advisory, but it is related to MCP OAuth client registration.
The POST request contains a large payload designed to consume significant server memory during processing.
The n8n instance processes the registration request without proper resource limitations or input validation on the payload size.
The server allocates memory to handle the large payload, potentially leading to memory exhaustion.
The attacker sends multiple such requests in rapid succession, exacerbating the memory exhaustion issue.
The n8n instance becomes unresponsive due to memory starvation, resulting in a denial of service.
Legitimate users are unable to access or use the n8n platform.

Impact

Successful exploitation of this vulnerability leads to a denial-of-service condition, rendering the n8n instance unavailable to legitimate users. The advisory does not specify the number of victims or sectors targeted. However, any organization using a vulnerable version of n8n is at risk. If the attack succeeds, critical workflow automation processes managed by n8n will be interrupted, potentially leading to business disruptions and data loss.

Recommendation

Upgrade n8n to version 1.123.32, 2.17.4, or 2.18.1, or later to remediate the vulnerability as mentioned in the Patches section.
If upgrading is not immediately possible, restrict network access to the n8n instance to prevent requests from untrusted sources, as outlined in the Workarounds section.
If upgrading is not immediately possible, reduce the maximum accepted payload size by lowering the N8N_PAYLOAD_SIZE_MAX environment variable as described in the Workarounds section.
Monitor web server logs for unusual POST requests to the MCP OAuth client registration endpoint (path not specified in advisory) that may indicate exploitation attempts. Create detection rules for this activity on webserver logs.

Npm — CraftedSignal Threat Feed

Increased npm Supply Chain Attacks Targeting SAP Developers

Attack Chain

Impact

Recommendation

n8n XML Node Prototype Pollution Leading to RCE

Attack Chain

Impact

Recommendation

n8n MCP OAuth Client XSS Vulnerability

Attack Chain

Impact

Recommendation

n8n Prototype Pollution in XML Webhook Body Parser Leads to RCE

Attack Chain

Impact

Recommendation

i18next-http-middleware Prototype Pollution and Path Traversal Vulnerability

Attack Chain

Impact

Recommendation

i18next-fs-backend Path Traversal Vulnerability

Attack Chain

Impact

Recommendation

OpenClaw MCP Loopback Token Spoofing Vulnerability

Attack Chain

Impact

Recommendation

xmldom XML Injection Vulnerability

Attack Chain

Impact

Recommendation

VM2 Sandbox Escape via __lookupGetter__ Vulnerability

Attack Chain

Impact

Recommendation

i18next-http-middleware HTTP Response Splitting and DoS Vulnerability

Attack Chain

Impact

Recommendation

Denial of Service Vulnerability in marked via Infinite Recursion

Attack Chain

Impact

Recommendation

OpenClaw Symlink Race Condition Allows Sandbox Escape

Attack Chain

Impact

Recommendation

n8n Unauthenticated Denial of Service via MCP Client Registration

Attack Chain

Impact

Recommendation

VM2 Sandbox Escape via lookupGetter Vulnerability