Injection — CraftedSignal Threat Feed

HKUDS OpenHarness Remote Code Execution via /bridge Slash Command (CVE-2026-7551)

hello@craftedsignal.io — Thu, 30 Apr 2026 22:17:40 +0000

HKUDS OpenHarness is vulnerable to a remote code execution flaw (CVE-2026-7551) affecting the /bridge slash command. This vulnerability permits remote attackers, who are authorized by the OpenHarness configuration, to execute arbitrary operating system commands on the host system. The attack leverages the /bridge spawn command, which, when supplied with attacker-controlled command text, is processed by the bridge session manager and executed through a shared shell subprocess. This execution context grants attackers the ability to spawn shell sessions with the privileges of the OpenHarness process user, potentially exposing local files, credentials, workspace state, and repository contents. Successful exploitation results in a complete compromise of the OpenHarness instance.

Attack Chain

Attacker identifies an accessible OpenHarness instance with the vulnerable /bridge slash command enabled.
The attacker authenticates or gains access to a communication channel (e.g., chat application) accepted by OpenHarness.
The attacker crafts a malicious /bridge spawn command containing OS commands to be executed.
The attacker sends the crafted /bridge spawn command to the OpenHarness instance via the configured communication channel.
OpenHarness processes the /bridge command and forwards the attacker-controlled command text to the bridge session manager.
The bridge session manager executes the injected OS commands through a shared shell subprocess.
The attacker gains a shell session with the privileges of the OpenHarness process user.
The attacker accesses local files, credentials, workspace state, and repository contents, potentially exfiltrating sensitive data or establishing persistence.

Impact

Successful exploitation of CVE-2026-7551 allows attackers to execute arbitrary operating system commands on the OpenHarness server. This grants them the ability to spawn shell sessions as the OpenHarness process user, which can lead to the exposure of sensitive information such as local files, credentials, workspace state, and repository contents. The impact of this vulnerability is significant, potentially allowing for complete system compromise and data exfiltration, but the exact number of victims is currently unknown.

Recommendation

Apply available patches or updates provided by HKUDS to address CVE-2026-7551 on all OpenHarness instances.
Implement input validation and sanitization on the /bridge slash command to prevent the injection of malicious OS commands.
Monitor process creation events for suspicious shell executions originating from the OpenHarness process using the provided Sigma rule.
Restrict network access to the OpenHarness server to only authorized users and systems.
Review OpenHarness configurations to ensure that only trusted communication channels are accepted.

Dagster SQL Injection Vulnerability in Dynamic Partition Keys

hello@craftedsignal.io — Sat, 18 Apr 2026 01:07:59 +0000

A SQL injection vulnerability has been identified in Dagster’s I/O managers for DuckDB, Snowflake, BigQuery, and DeltaLake. The vulnerability stems from the construction of SQL WHERE clauses where dynamic partition key values are interpolated into queries without proper escaping. This allows an attacker with the Add Dynamic Partitions permission to inject arbitrary SQL code. The injected SQL would then execute against the target database backend using the I/O manager’s credentials. This issue affects Dagster OSS versions up to 1.13.0, and dagster-* package versions up to 0.29.0. This vulnerability is most relevant when the Add Dynamic Partitions permission is granted independently of broader database access, such as in multi-tenant or custom RBAC configurations.

Attack Chain

An attacker gains access to the Dagster API with the Add Dynamic Partitions permission. This could be through compromised credentials or a misconfigured RBAC setup.
The attacker crafts a malicious dynamic partition key containing SQL injection payloads.
The attacker uses the Dagster API to create a new dynamic partition or modify an existing one, injecting the malicious key.
A Dagster pipeline or asset execution is triggered that utilizes the dynamic partitions functionality and the vulnerable I/O manager.
When the I/O manager constructs the SQL query, the malicious partition key is interpolated without proper escaping.
The injected SQL code is executed against the target database (DuckDB, Snowflake, BigQuery, or DeltaLake) using the I/O manager’s credentials.
The attacker can read sensitive data, modify existing data, or potentially escalate privileges within the database.
The attacker achieves their final objective, such as exfiltrating data or compromising the database’s integrity.

Impact

Successful exploitation of this SQL injection vulnerability can lead to unauthorized access and modification of data within the affected databases. The impact is particularly high in deployments where the Add Dynamic Partitions permission is granted to users without broader database access. This vulnerability could allow attackers to bypass intended access controls and potentially gain full control of the database, leading to data breaches, data corruption, or denial of service. The number of affected deployments is currently unknown, but organizations using Dagster with dynamic partitions should assess their exposure.

Recommendation

Upgrade all dagster-* packages (dagster-duckdb, dagster-snowflake, dagster-gcp, dagster-deltalake, dagster-snowflake-polars) to versions greater than 0.29.0 and dagster package to versions greater than 1.13.0 as outlined in the advisory to remediate the vulnerability.
Review user roles and permissions within Dagster, specifically focusing on who has the Add Dynamic Partitions permission, and restrict access to only trusted users to reduce the attack surface.
Monitor Dagster logs for suspicious API requests related to the creation or modification of dynamic partitions to detect potential exploitation attempts.
Implement database auditing to track SQL queries executed by the I/O manager and identify potential SQL injection attempts.

Simple IT Discussion Forum SQL Injection Vulnerability (CVE-2026-5827)

hello@craftedsignal.io — Thu, 09 Apr 2026 01:16:50 +0000

A SQL injection vulnerability, identified as CVE-2026-5827, affects code-projects Simple IT Discussion Forum version 1.0. The vulnerability resides in the /question-function.php file and is triggered by manipulating the content argument. Successful exploitation allows a remote attacker to inject arbitrary SQL commands, potentially leading to data exfiltration, modification, or complete system compromise. This vulnerability is considered high risk due to its ease of exploitation and the sensitive nature of data often stored in forum databases. The exploit is publicly available, increasing the likelihood of widespread exploitation. Defenders should prioritize patching and implementing mitigations to prevent potential attacks against vulnerable Simple IT Discussion Forum instances.

Attack Chain

Attacker identifies a vulnerable Simple IT Discussion Forum 1.0 instance.
The attacker crafts a malicious HTTP request targeting /question-function.php.
The crafted request includes a SQL injection payload within the content argument.
The application fails to properly sanitize the input, passing the malicious SQL query to the database.
The database executes the injected SQL code.
The attacker can extract sensitive data, such as user credentials or forum content.
The attacker may modify data within the database, altering forum posts or user profiles.
In a worst-case scenario, the attacker gains complete control of the database server.

Impact

Successful exploitation of this SQL injection vulnerability can have severe consequences. An attacker can gain unauthorized access to sensitive data, including user credentials, private messages, and other confidential information stored within the Simple IT Discussion Forum database. This can lead to identity theft, financial fraud, and reputational damage. Furthermore, attackers can modify or delete data, disrupt forum operations, or even gain complete control of the underlying server. Given the public availability of the exploit, unpatched instances are at significant risk of compromise.

Recommendation

Apply any available patches or updates for code-projects Simple IT Discussion Forum 1.0 to address CVE-2026-5827.
Implement input validation and sanitization on the /question-function.php file to prevent SQL injection attacks, specifically targeting the content argument.
Deploy a web application firewall (WAF) with rules to detect and block SQL injection attempts against /question-function.php.
Monitor web server logs for suspicious activity, such as unusual characters or SQL keywords in the content parameter of requests to /question-function.php. Enable webserver logging to activate the rules below.
Deploy the Sigma rule to detect SQL injection attempts in web server logs.

Vim Code Execution Vulnerability via Crafted Files (CVE-2026-34714)

hello@craftedsignal.io — Mon, 30 Mar 2026 19:16:26 +0000

Vim, a widely used text editor, is susceptible to a critical vulnerability (CVE-2026-34714) affecting versions prior to 9.2.0272. This flaw allows for arbitrary code execution simply by opening a malicious file. The vulnerability stems from a %{expr} injection vulnerability within the tabpanel component, specifically when it lacks the P_MLE protection. The default configuration of Vim is susceptible, amplifying the risk. An attacker can craft a Vim file that, when opened, will trigger the…

AWS SDK for PHP CloudFront Policy Document Injection via Special Characters

hello@craftedsignal.io — Fri, 27 Mar 2026 19:54:58 +0000

A vulnerability exists in the CloudFront signing utilities within the AWS SDK for PHP, specifically impacting versions 3.11.7 through 3.371.3. These utilities are responsible for generating Amazon CloudFront signed URLs and signed cookies, which control access to content. The vulnerability arises from the improper handling of special characters, such as double quotes and backslashes, within input values used to construct policy documents. If an application passes unsanitized input containing these characters to the signing utilities, the resulting policy document may deviate from the application’s intended access restrictions. An enhancement was made to the AWS SDK for PHP version 3.371.4 to address this issue. This vulnerability impacts applications that do not properly sanitize inputs passed to the CloudFront signing utilities.

Attack Chain

An attacker identifies an application using a vulnerable version of the AWS SDK for PHP (3.11.7 - 3.371.3) that utilizes CloudFront signed URLs or cookies.
The attacker locates an input field within the application that is used to generate CloudFront policy documents.
The attacker crafts a malicious input string containing special characters (e.g., double quotes, backslashes) designed to manipulate the resulting policy document.
The application passes the attacker-controlled input to the CloudFront signing utilities without proper sanitization or validation.
The CloudFront signing utilities generate a signed URL or cookie with a flawed policy document due to the injected special characters.
The attacker uses the crafted signed URL or cookie to bypass intended access restrictions and potentially gain unauthorized access to protected content.
The attacker accesses restricted resources on CloudFront that should have been protected by the intended policy.

Impact

Successful exploitation of this vulnerability could lead to unauthorized access to content protected by Amazon CloudFront. If an attacker can manipulate the policy document, they might bypass intended access restrictions, potentially exposing sensitive data or allowing unauthorized actions. The number of affected applications is unknown, but any application using the vulnerable versions of the AWS SDK for PHP and failing to sanitize input is at risk.

Recommendation

Upgrade to AWS SDK for PHP version 3.371.4 or later to incorporate the fix that addresses special character handling (reference: Patches section).
Implement robust input validation in application code to sanitize or escape special characters before passing values to CloudFront signing utilities (reference: Workarounds section).
Monitor web server logs for unusual patterns of URL requests containing special characters that might indicate exploitation attempts (reference: webserver log source).

BadAML Injection Allows Arbitrary Code Execution in Confidential VMs

hello@craftedsignal.io — Fri, 27 Mar 2026 12:00:00 +0000

The BadAML injection attack, initially published in 2024, exploits the ACPI interface in confidential virtual machines, allowing for arbitrary code execution. This vulnerability arises from the ability of an attacker with control over the host to inject malicious AML (ACPI Machine Language) code. This code, embedded within ACPI tables, is passed from the host (QEMU) to the guest firmware (OVMF) and subsequently to the Linux kernel. The kernel’s AML interpreter then executes this code, granting the attacker control within the guest environment. The Contrast platform versions prior to 1.18.0 are vulnerable on Metal-QEMU-SNP and Metal-QEMU-SNP-GPU platforms. Successful exploitation allows attackers to bypass security measures designed to protect confidential VMs.

Attack Chain

Attacker gains control over the host machine running the QEMU hypervisor.
Attacker crafts a malicious ACPI table containing arbitrary AML code.
The malicious ACPI table is injected into the guest VM via QEMU.
The OVMF firmware in the guest VM parses the ACPI table and passes the AML code to the Linux kernel.
The Linux kernel’s AML interpreter executes the injected AML code.
The AML code leverages its access to guest memory to escalate privileges.
The attacker gains arbitrary code execution within the guest VM.
The attacker can then perform malicious actions, such as data exfiltration or further compromise of the system.

Impact

Successful exploitation of the BadAML vulnerability allows attackers to execute arbitrary code within confidential VMs, potentially leading to data theft, service disruption, or complete system compromise. While the number of victims is unknown, the affected sectors include any environment utilizing the vulnerable Contrast platforms (Metal-QEMU-SNP and Metal-QEMU-SNP-GPU) for confidential computing. The impact is significant, as it undermines the security guarantees provided by confidential computing technologies.

Recommendation

Upgrade Contrast installations on Metal-QEMU-SNP and Metal-QEMU-SNP-GPU platforms to version 1.18.0 or later to incorporate the kernel patch.
Monitor host systems for suspicious ACPI table modifications using custom scripts or host-based intrusion detection systems (no specific rule provided, but ACPI table modification events should be logged where possible).

Spring AI Redis Store TAG Injection Vulnerability (CVE-2026-22744)

hello@craftedsignal.io — Fri, 27 Mar 2026 06:16:38 +0000

CVE-2026-22744 is a critical vulnerability found within the RedisFilterExpressionConverter of the Spring AI Redis Store. The vulnerability arises because the stringValue() function directly inserts user-supplied strings into the @field:{VALUE} RediSearch TAG block without proper sanitization or escaping. This allows an attacker to inject arbitrary commands or data into the Redis database if they can control the input used as a filter value for a TAG field. This vulnerability affects…

n8n Merge Node AlaSQL Injection Vulnerability

hello@craftedsignal.io — Thu, 26 Mar 2026 12:00:00 +0000

A critical remote code execution vulnerability has been identified in n8n, a popular workflow automation tool. Specifically, the vulnerability resides within the Merge node’s “Combine by SQL” mode. Versions of n8n prior to 2.14.1, 2.13.3, and 1.123.27 are affected. An authenticated user with the ability to create or modify workflows can leverage the AlaSQL sandbox’s insufficient input sanitization to inject malicious SQL code. This allows the attacker to potentially read arbitrary local files from the n8n host or execute arbitrary commands, leading to full system compromise. This vulnerability poses a significant risk to organizations using n8n, as it allows attackers to gain unauthorized access and control over their systems and data.

Attack Chain

An attacker authenticates to the n8n instance with user account having workflow creation/modification permissions.
The attacker creates or modifies an existing workflow.
The attacker adds a Merge node to the workflow and sets its mode to “Combine by SQL”.
The attacker crafts a malicious SQL query within the Merge node’s SQL configuration, taking advantage of insufficient input validation in the AlaSQL sandbox. The SQL query may attempt to read sensitive files from the file system, for example, /etc/passwd or application configuration files.
The malicious SQL query executes when the workflow is triggered, potentially reading files from the n8n server.
Alternatively, the malicious SQL query could execute commands via the SYSTEM function or other methods available through AlaSQL, leading to remote code execution on the n8n host.
If successful, the attacker gains control of the n8n process.
The attacker uses the compromised n8n instance to pivot to other systems on the network, steal sensitive data, or disrupt services.

Impact

Successful exploitation of this vulnerability allows an attacker to execute arbitrary code on the n8n server. This can lead to complete system compromise, including the ability to steal sensitive data, install malware, or disrupt services. The number of affected n8n instances is currently unknown, but given the popularity of the platform in various sectors, the potential impact is widespread. Organizations using vulnerable versions of n8n are at high risk of data breaches, financial losses, and reputational damage.

Recommendation

Upgrade n8n to version 2.14.1, 2.13.3, 1.123.27 or later to patch CVE-2026-33660.
If upgrading is not immediately feasible, limit workflow creation and editing permissions to only fully trusted users as a short-term mitigation (reference Overview).
As an alternative temporary workaround, disable the Merge node by adding n8n-nodes-base.merge to the NODES_EXCLUDE environment variable (reference Overview).
Monitor n8n application logs for suspicious SQL queries or other anomalous activity originating from the Merge node (create custom detection logic based on observed AlaSQL activity).

Dgraph Pre-Auth DQL Injection Vulnerability

hello@craftedsignal.io — Sat, 26 Oct 2024 12:00:00 +0000

A critical vulnerability exists in Dgraph, a graph database, allowing unauthenticated attackers to perform full database exfiltration. This flaw resides within the /mutate endpoint, specifically when Access Control Lists (ACL) are disabled, which is the default configuration. By injecting malicious DQL queries via a crafted cond field in an upsert mutation, attackers can bypass authorization checks and extract sensitive data, including user credentials and secrets. The vulnerability stems from the lack of proper sanitization of the cond field, leading to direct concatenation into the DQL query string. This vulnerability was found in v25.3.0, but may exist in other versions as well.

Attack Chain

The attacker sends an HTTP POST request to the /mutate?commitNow=true endpoint without any authentication headers (e.g., X-Dgraph-AccessToken, X-Dgraph-AuthToken).
The mutationHandler in http.go extracts the request body and processes the mutations array, including the cond field, using strconv.Unquote.
The request proceeds to edgraph.Server.QueryNoGrpc, where the Cond value is copied verbatim to dql.Mutation.Cond in server.go.
The buildUpsertQuery function in server.go performs a simple string replacement (@if to @filter) but otherwise concatenates the unsanitized Cond value into the DQL query.
The dql.ParseWithNeedVars parser processes the constructed DQL string, accepting the injected query blocks as valid DQL.
The authorizeQuery function in access.go returns nil immediately because ACL is disabled (AclSecretKey == nil), bypassing authorization checks.
The injected query block executes, traversing and extracting data from the database.
The response, containing the exfiltrated data, is returned to the attacker via http.go, effectively granting unauthorized access to sensitive information.

Impact

Successful exploitation of this vulnerability results in complete database exfiltration. Attackers can retrieve all nodes, predicates, and values within the Dgraph database, including sensitive data such as user credentials, API keys, and Personally Identifiable Information (PII). Given the default configuration of Dgraph lacking ACL enabled, this poses a significant risk to organizations relying on Dgraph for data storage. The injection can also manipulate upsert conditions, bypassing uniqueness constraints and conditional mutation logic.

Recommendation

Enable ACL on all Dgraph instances and configure appropriate access controls to mitigate unauthorized data access.
Implement the Sigma rule Detect Dgraph DQL Injection in Mutation Endpoint to identify potentially malicious requests to the /mutate endpoint.
Sanitize and validate user-supplied input, especially the cond field in mutation requests, to prevent DQL injection attacks.
Monitor network traffic to detect suspicious POST requests to the /mutate endpoint with unusual or unexpected cond values.
Review and restrict network access to the Dgraph instance, limiting access only to authorized clients and networks.

xmldom XML Node Injection via Comment Serialization

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

The xmldom library is susceptible to XML node injection due to a lack of validation when serializing comment nodes. Versions prior to 0.8.13 and versions between 0.9.0 and 0.9.10 are vulnerable. An attacker can inject arbitrary XML nodes into the serialized output by including comment-breaking sequences (e.g., -->) in the comment data. This allows them to alter the structure of the XML document. Exploitation involves crafting malicious input that leverages the library’s DOM construction and serialization flow. It matters because applications using xmldom to process potentially untrusted XML data could be coerced into generating malicious XML structures. The fix requires an opt-in requireWellFormed flag to be enabled when calling serializeToString().

Attack Chain

An application receives untrusted data intended for use in XML comment content.
The application calls createComment(data) in xmldom, passing the untrusted data. The library stores the data without proper validation.
The application constructs an XML document, including the comment node created in the previous step.
The application calls serializeToString() on the XML document to serialize it.
If the untrusted data contains comment-breaking sequences, such as -->, the serializer prematurely terminates the comment.
The serializer injects any subsequent content in the untrusted data as live XML markup.
The application stores, forwards, signs, or hands the serialized XML to another parser.
The downstream consumer trusts the altered XML structure, leading to unintended consequences, such as misconfiguration or security bypass.

Impact

Successful exploitation allows attackers to inject arbitrary XML nodes, potentially altering the structure and meaning of generated XML documents. This could lead to misconfiguration, policy bypass, or other security vulnerabilities in applications that rely on the integrity of the XML structure. The vulnerability affects applications that use xmldom to build XML from untrusted input. The number of victims depends on the usage of the vulnerable library and the exposure of applications to untrusted XML data.

Recommendation

Upgrade to @xmldom/xmldom version 0.8.13 or 0.9.10 or later to gain access to the fix.
Audit all calls to serializeToString() and add the { requireWellFormed: true } option when serializing comments containing potentially untrusted data.
Implement server-side input validation to sanitize comment data by removing comment-breaking sequences like --> before passing it to createComment().
Deploy the Sigma rule to detect comment injections.

NocoBase SQL Injection via Recursive Eager Loading

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

A SQL injection vulnerability exists in NocoBase version 2.0.32 and earlier due to string concatenation in the queryParentSQL() function within the @nocobase/database core package. The vulnerability stems from how the queryParentSQL() function constructs a recursive CTE query by concatenating nodeIds instead of using parameterized queries. An attacker with record creation permissions on a tree collection with string-type primary keys can inject arbitrary SQL via a malicious string primary key value in a created record. This injection is triggered when a subsequent request initiates recursive eager loading on that collection. This can lead to confidentiality breaches (extraction of database values including credentials), integrity issues (data manipulation via stacked queries), and availability problems (resource exhaustion). On PostgreSQL with superuser privileges, OS command execution is possible. The vulnerability affects all collections using a tree/adjacency-list structure with string primary keys. The same concatenation pattern also exists in plugin-field-sort/src/server/sort-field.ts:124. The vulnerability is tracked as CVE-2026-41640.

Attack Chain

An attacker gains access to the NocoBase application with privileges to create records in a collection.
The attacker identifies a “tree” collection that utilizes a string-type primary key.
The attacker crafts a malicious primary key string containing SQL injection payload, such as root') UNION ALL SELECT CAST((SELECT email FROM users LIMIT 1) AS integer)::text, NULL::text WHERE ('1'='1.
The attacker creates a new record in the target collection using the crafted malicious primary key.
A subsequent request is made that triggers recursive eager loading on the target collection, specifically when a BelongsTo association has recursively: true and instances exist, calling the vulnerable queryParentSQL function.
The queryParentSQL function concatenates the malicious primary key into the SQL query without proper sanitization or parameterization.
The injected SQL code is executed against the database, allowing the attacker to extract sensitive data via error messages or potentially perform other malicious actions.
The attacker retrieves the extracted data from the error messages or through other means, such as direct database access if integrity is compromised.

Impact

This SQL injection vulnerability can lead to severe consequences. Successful exploitation can result in the unauthorized disclosure of sensitive information, including database credentials and other user data. Attackers can potentially modify data or execute arbitrary commands on the database server, leading to data corruption or system compromise. In the case of PostgreSQL databases with superuser privileges, attackers might gain operating system-level access. The vulnerability affects all collections using tree/adjacency-list structure with string-type primary keys, increasing the attack surface. Confirmed extractions include version information, database names, emails, and password hashes.

Recommendation

Deploy the Sigma rule Detect NocoBase SQL Injection Attempt in Primary Key to your SIEM to detect attempts to exploit this vulnerability via malicious primary key values.
Apply the suggested fix from the advisory by using parameterized queries in packages/core/database/src/eager-loading/eager-loading-tree.ts as referenced in the overview.
Apply the same fix to plugin-field-sort/src/server/sort-field.ts:124 to address the identical concatenation pattern as described in the overview.
Validate primary key values at record creation time to reject or escape values containing SQL metacharacters (', ", ;, --) in string-type primary key fields, as suggested in the advisory.