Rubygems — CraftedSignal Threat Feed

ERB Deserialization Bypass via def_module/def_method/def_class

hello@craftedsignal.io — Sat, 25 Apr 2026 12:00:00 +0000

Ruby versions before ERB 2.2.0 implemented an @_init instance variable guard in ERB#result and ERB#run to prevent code execution upon deserialization via Marshal.load. This guard is intended to block execution when an ERB object is reconstructed from untrusted data. However, the methods ERB#def_method, ERB#def_module, and ERB#def_class were not given the same protection, creating a bypass. An attacker capable of triggering Marshal.load on untrusted data in a Ruby application with the erb gem loaded can exploit ERB#def_module (using its zero-argument, default-parameter form) as a code execution sink. This bypass impacts Ruby on Rails applications that import untrusted serialized data, Ruby tools employing Marshal.load for caching or IPC, and legacy Rails applications (pre-7.0) utilizing Marshal for cookie session serialization. This bypass renders the @_init mitigation ineffective across all ERB versions from 2.2.0 through 6.0.3. Combined with the DeprecatedInstanceVariableProxy gadget (present in all ActiveSupport versions through 7.2.3), this enables a universal RCE gadget chain for Ruby 3.2+ applications using Rails. The vulnerability is identified as CVE-2026-41316.

Attack Chain

The attacker crafts a malicious Ruby object containing an ERB instance and/or an ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy instance.
The ERB instance has its @src instance variable set to a string containing malicious code with the “end\nsystem(‘id’)\ndef x” payload.
The vulnerable application calls Marshal.load on the crafted object, triggering deserialization.
During deserialization, the DeprecatedInstanceVariableProxy is instantiated (if used), which then invokes the ERB#def_module method via method_missing.
The ERB#def_module method calls ERB#def_method without checking the @_init guard.
Inside ERB#def_method, the malicious code in @src is wrapped in a method definition and evaluated via module_eval.
The “end\nsystem(‘id’)\ndef x” payload causes the system('id') command to execute during the module_eval call, bypassing the intended deserialization protection.
The attacker achieves arbitrary code execution on the target system, gaining the ability to perform malicious actions.

Impact

Successful exploitation allows an attacker to execute arbitrary code on the target system. This affects Ruby applications, including Ruby on Rails, which use Marshal.load on untrusted data. Specific impact includes potential compromise of web servers and the ability to read sensitive files, modify data, or install malware. Vulnerable applications include those using Marshal.load for caching, data import, or IPC, and legacy Rails applications (pre-7.0) using Marshal for cookie session serialization. This bypass renders the @_init mitigation ineffective across all ERB versions from 2.2.0 through 6.0.3.

Recommendation

Upgrade your erb gem to version 4.0.3.1, 4.0.4.1, 6.0.1.1, or 6.0.4 to patch the vulnerability as described in the “Patches” section.
Avoid using Marshal.load on untrusted data, as it is inherently unsafe. Consider using alternative serialization formats like JSON or YAML.
Deploy the “Detect ERB def_module Code Execution via Deserialization” Sigma rule to detect exploitation attempts.

OpenC3 COSMOS SQL Injection Vulnerability in QuestDB Time-Series Database

hello@craftedsignal.io — Thu, 23 Apr 2026 14:12:02 +0000

A SQL injection vulnerability has been identified in the OpenC3 COSMOS Time-Series Database (TSDB) component, which utilizes QuestDB. The vulnerability resides within the tsdb_lookup function in the cvt_model.rb file, where user-supplied input is directly incorporated into SQL queries without proper sanitization. An authenticated attacker with “tlm” permissions, which includes Admin, Operator, Viewer, or Runner roles, can exploit this flaw to inject arbitrary SQL commands. This can lead to unauthorized data access, modification, or deletion within the TSDB. The affected versions are OpenC3 rubygems package versions >= 6.7.0 and < 7.0.0-rc3. Successful exploitation allows attackers to compromise the confidentiality, integrity, and availability of telemetry data stored within the COSMOS system.

Attack Chain

An attacker authenticates to the COSMOS system with a role that possesses “tlm” permissions (Admin, Operator, Viewer, or Runner).
The attacker crafts a malicious JSON-RPC request targeting the get_tlm_values endpoint.
Within the request body, the attacker injects a SQL payload into the start_time parameter, such as ' OR 1=1 --.
The tsdb_lookup function incorporates the unsanitized input into a SQL query.
The injected SQL payload manipulates the query logic, allowing the attacker to bypass intended restrictions.
The attacker can then exfiltrate all telemetry data within the database by manipulating the SQL query.
The attacker modifies the SQL payload to execute arbitrary commands, such as DROP TABLE statements.
The attacker successfully deletes historical data from the database, impacting data availability and system integrity.

Impact

Successful exploitation of this SQL injection vulnerability allows an attacker to perform unauthorized actions on the OpenC3 COSMOS Time-Series Database (TSDB). An attacker with “tlm” permissions can disclose sensitive telemetry data, modify existing data, or delete data altogether. The vulnerability impacts systems running OpenC3 rubygems package versions >= 6.7.0 and < 7.0.0-rc3. Depending on the role of the compromised account and the specific SQL commands executed, an attacker could potentially cause significant disruption to operations relying on the integrity and availability of telemetry data.

Recommendation

Upgrade the rubygems/openc3 package to version 7.0.0-rc3 or later to remediate the SQL injection vulnerability.
Implement input sanitization on user-supplied data within the tsdb_lookup function in cvt_model.rb to prevent SQL injection attacks.
Deploy the Sigma rule “Detect Suspicious OpenC3 Telemetry Requests” to identify potential exploitation attempts targeting the get_tlm_values endpoint.
Review and restrict “tlm” permissions to the get_tlm_values RPC endpoint according to the principle of least privilege, limiting access to only those users who require it.

OpenC3 COSMOS Script Runner Permissions Bypass

hello@craftedsignal.io — Fri, 08 Nov 2024 12:00:00 +0000

The openc3-COSMOS-script-runner-api container includes a Script Runner widget that enables users to execute Python and Ruby scripts. A vulnerability exists where users with script execution privileges can bypass API permission checks due to shared networking among Docker containers. This bypass allows unauthorized administrative actions such as reading and modifying data within the Redis database, which can lead to the exposure of sensitive credentials and alteration of COSMOS settings. Attackers can also read and write to the buckets service, affecting configuration, logs, and plugins. The vulnerability affects versions prior to 7.0.0-rc3 of the rubygems/openc3 package, posing a significant risk to data integrity and system security. Any authenticated user with script execution capabilities can exploit this flaw to connect to any service within the Docker network, escalating their privileges and gaining control over critical system components.

Attack Chain

An attacker logs into the OpenC3 COSMOS platform with a valid, non-administrative user account that has access to the Script Runner widget.
The attacker crafts a Ruby script to extract Redis credentials (username, password, hostname, port) by querying the environment variables within the openc3-COSMOS-script-runner-api container using a command like puts \env | grep redis``.
The attacker executes the Ruby script within the Script Runner widget, successfully retrieving the Redis credentials, which are then displayed in the script’s output.
The attacker crafts a Python script using the obtained Redis credentials to connect to the Redis database. The script is designed to create a new entry or modify an existing one. For example, r.hset('openc3__settings_hacked','store_url',json.dumps(setting_data))
The attacker executes the Python script within the Script Runner widget, successfully adding or modifying data in the Redis database, bypassing normal permission controls.
The attacker leverages the ability to write to the buckets service to modify critical system configuration files, such as the plugin store URL, by uploading a malicious file via a Python or Ruby script.
The attacker verifies the changes by using redis-cli to confirm the new data was added to the Redis database, or by observing the altered behavior of the system due to the modified configuration files.
The attacker gains complete control over the OpenC3 COSMOS environment by exploiting modified settings, potentially leading to data exfiltration, service disruption, or further lateral movement within the network.

Impact

Successful exploitation of this vulnerability allows unauthorized data disclosure and manipulation within the OpenC3 COSMOS environment. An attacker can access sensitive information such as Redis credentials, modify system settings, and alter configuration files, leading to privilege escalation. The number of affected installations is currently unknown, but the vulnerability poses a significant risk to organizations using OpenC3 COSMOS, potentially resulting in complete system compromise and loss of data integrity. The vulnerability allows unauthorized access to data and functionality typically restricted to administrators, bypassing intended security controls.

Recommendation

Upgrade the rubygems/openc3 package to version 7.0.0-rc3 or later to remediate the vulnerability (reference: rubygems/openc3 v7.0.0-rc3).
Implement network segmentation to isolate the openc3-COSMOS-script-runner-api container from other critical services like Redis, limiting the blast radius of potential attacks.
Deploy the Sigma rule to detect the execution of suspicious scripts within the Script Runner widget that attempt to access Redis or modify configuration files.
Monitor process creation events within the openc3-COSMOS-script-runner-api container for commands such as env | grep redis or any calls to redis-cli which is abnormal behavior, and create alerts (reference: process_creation log source).

Avo Framework Broken Access Control Vulnerability

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

A critical broken access control vulnerability exists within the Avo framework, specifically affecting version 3.x. This vulnerability resides in the ActionsController and stems from an insecure action lookup mechanism. An authenticated user, regardless of their privilege level, can execute any Action class (descendants of Avo::BaseAction) on any resource within the application. This occurs because the system fails to validate whether the requested action is legitimately registered or permitted for the resource context specified in the request. The absence of this verification allows for the circumvention of intended resource-action mappings. Successful exploitation leads to privilege escalation, unauthorized data manipulation, and potential compromise of the application’s integrity. It is recommended to upgrade to version 3.31.2 or later, which addresses this vulnerability.

Attack Chain

An attacker authenticates to the Avo admin panel with low-level privileges.
The attacker identifies a sensitive action class, such as Avo::Actions::ToggleAdmin.
The attacker identifies a target record ID, such as a user ID they wish to manipulate.
The attacker crafts a POST request to a resource endpoint where the target action is NOT registered (e.g., /admin/resources/posts/actions).
The POST request includes a payload containing the action_id parameter set to the sensitive action class (Avo::Actions::ToggleAdmin).
The POST request also includes a fields[avo_resource_ids] parameter set to the target record ID.
Due to the insecure action lookup in Avo::ActionsController, the server executes the ToggleAdmin action on the specified user ID.
The attacker’s privileges are escalated, or unauthorized data manipulation occurs due to the successful execution of the unintended action.

Impact

The exploitation of this broken access control vulnerability can have severe consequences. A successful attack can lead to privilege escalation, allowing attackers to gain administrative control over the application. Unauthorized operations can be performed, leading to data breaches or data manipulation. Sensitive actions designed for restricted resources can be triggered against any record ID, potentially compromising the integrity and confidentiality of data. The impact includes unauthorized deletion, archival, or updates to records, causing reputational damage and potential financial losses.

Recommendation

Upgrade to Avo version 3.31.2 or later, which contains the necessary fix to restrict action lookup to registered actions for the current resource context.
Deploy the Sigma rule Detect Avo Unauthorized Action Execution to monitor for attempts to execute actions on resources where they are not registered.
Review and audit existing Avo action registrations to ensure that actions are appropriately mapped to resources within the application.