Ruby — 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.

bsv-sdk and bsv-wallet Credential Forgery Vulnerability

hello@craftedsignal.io — Thu, 09 Apr 2026 20:28:10 +0000

The bsv-sdk and bsv-wallet Ruby gems are vulnerable to credential forgery due to a signature verification bypass in the acquire_certificate function. This function, present in both gems, persists certificate records to storage without properly verifying the certifier’s signature. An attacker can exploit this vulnerability through two acquisition paths: by directly supplying certificate fields (direct path) or by controlling a certifier endpoint (issuance path). This allows the attacker to forge identity certificates that are then treated as authentic by other functions like list_certificates and prove_certificate. The vulnerability affects bsv-sdk versions >= 0.3.1 and < 0.8.2, and bsv-wallet versions >= 0.1.2 and < 0.3.4. This vulnerability was identified during a cross-SDK compliance review conducted on 2026-04-08.

Attack Chain

Attacker gains access to a system that uses either the bsv-sdk or bsv-wallet Ruby gem.
The attacker invokes the acquire_certificate function with acquisition_protocol: 'direct'.
The attacker supplies arbitrary certificate fields, including a forged signature, a certifier, serial_number, and revocation_outpoint.
Alternatively, the attacker invokes the acquire_certificate function with acquisition_protocol: 'issuance' and specifies a malicious certifier URL they control.
The vulnerable acquire_certificate function persists the attacker-supplied certificate data to storage without verifying the certifier’s signature.
The attacker or a downstream process invokes list_certificates or prove_certificate to retrieve the forged certificate.
The application trusts the forged certificate as authentic, leading to credential forgery and potential unauthorized access or privilege escalation.

Impact

Successful exploitation of this vulnerability allows an attacker to forge identity certificates attributed to arbitrary certifier identities. This can lead to credential forgery, where the attacker can assert false attributes about a subject. Applications relying on the wallet’s certificate store for identity attributes, such as KYC assertions or role claims, become vulnerable to credential forgery. This is a credential-forgery primitive, not merely a spec divergence from BRC-52.

Recommendation

Upgrade to bsv-sdk >= 0.8.2 or bsv-wallet >= 0.3.4 to patch the vulnerability. These versions implement signature verification using BSV::Wallet::CertificateSignature and raise BSV::Wallet::CertificateSignature::InvalidError for invalid certificates.
If upgrading is not immediately possible, do not expose acquire_certificate (either acquisition protocol) to untrusted callers, as described in the Workarounds section of this brief.
If upgrading is not immediately possible, treat any record returned by list_certificates / prove_certificate as unverified and perform an out-of-band BRC-52 verification against the certifier’s public key before acting on it.

BSV Ruby SDK Improper ARC Response Handling

hello@craftedsignal.io — Thu, 09 Apr 2026 18:17:03 +0000

The BSV Ruby SDK, a tool for interacting with the BSV blockchain, contains a vulnerability in versions prior to 0.8.2. Specifically, the BSV::Network::ARC component’s failure detection mechanism is flawed. It only recognizes REJECTED and DOUBLE_SPEND_ATTEMPTED ARC responses as failures. Responses with txStatus values like INVALID, MALFORMED, MINED_IN_STALE_BLOCK, or any ORPHAN-containing string in extraInfo or txStatus are incorrectly treated as successful broadcasts. This can lead applications that rely on successful broadcast confirmations to trust transactions that were never actually accepted by the BSV network. The vulnerability is identified as CVE-2026-40069 and is patched in version 0.8.2 of the SDK. This affects any application using the vulnerable SDK to interact with the BSV blockchain where transaction confirmation is critical for subsequent actions.

Attack Chain

An attacker crafts a transaction designed to fail under specific conditions on the BSV network (e.g., invalid format, conflicts with existing transactions).
The attacker uses an application built with a vulnerable BSV Ruby SDK (versions < 0.8.2) to broadcast the malicious transaction.
The BSV network responds with an ARC response indicating a failure status, such as INVALID, MALFORMED, MINED_IN_STALE_BLOCK, or a status containing ORPHAN.
The vulnerable BSV::Network::ARC component in the SDK incorrectly interprets the failure response as a successful broadcast due to inadequate error handling.
The application, relying on the SDK’s flawed confirmation, proceeds with actions dependent on the transaction’s supposed success.
These actions could include updating local state, triggering further transactions, or providing access to resources based on the false confirmation.
The attacker benefits from the application’s misinterpretation, potentially gaining unauthorized access or manipulating the application’s state.

Impact

Successful exploitation of CVE-2026-40069 allows attackers to deceive applications using vulnerable BSV Ruby SDK versions into believing that a transaction has been successfully broadcast to the BSV blockchain when it has not. This can lead to incorrect application state, unauthorized actions, or other security breaches depending on the application’s logic. While the exact number of affected applications isn’t specified, any application relying on transaction confirmation from the BSV Ruby SDK prior to version 0.8.2 is potentially vulnerable. This could impact financial applications, supply chain management systems, or any other application using the BSV blockchain for critical operations.

Recommendation

Upgrade all instances of the BSV Ruby SDK to version 0.8.2 or later to remediate CVE-2026-40069.
Implement additional transaction verification mechanisms independent of the BSV Ruby SDK in applications where transaction confirmation is critical.
Deploy the Sigma rule “Detect BSV Ruby SDK ARC Response Errors” to identify potentially vulnerable applications based on network traffic patterns.

Rack::Static Information Disclosure Vulnerability (CVE-2026-34785)

hello@craftedsignal.io — Thu, 02 Apr 2026 17:16:24 +0000

Rack, a modular Ruby web server interface, is susceptible to an information disclosure vulnerability in versions prior to 2.2.23, 3.1.21, and 3.2.6. The flaw resides in the Rack::Static middleware component, which uses a simple string prefix check to determine if a request should be served as a static file. When configured with URL prefixes, such as “/css”, Rack::Static incorrectly matches any request path starting with “/css”, potentially serving unintended files like “/css-config.env” or “/css-backup.sql”. This allows unauthorized access to sensitive files located under the static root directory. This vulnerability, identified as CVE-2026-34785, can lead to the disclosure of configuration files, database backups, and other sensitive information. The vulnerability has been patched in Rack versions 2.2.23, 3.1.21, and 3.2.6.

Attack Chain

An attacker identifies a Rack-based web application using a vulnerable version of Rack (prior to 2.2.23, 3.1.21, or 3.2.6).
The attacker identifies a static file directory configured in the Rack application, for example using a path prefix like “/css”.
The attacker crafts a malicious request targeting a sensitive file within the static directory, such as “/css-config.env” or “/css-backup.sql”, that shares the configured prefix but is not intended to be served publicly.
The Rack::Static middleware incorrectly matches the malicious request due to the simple string prefix check.
The web server serves the unintended file to the attacker.
The attacker gains access to sensitive information contained in the served file.
The attacker leverages the disclosed information to further compromise the application or infrastructure.

Impact

Successful exploitation of this vulnerability (CVE-2026-34785) can lead to the disclosure of sensitive information, including configuration files, database backups, and other critical data. The impact severity is dependent on the nature of the exposed files. For example, exposure of database credentials could result in a full compromise of the application’s data. Organizations using vulnerable Rack versions are susceptible to information breaches if they rely on Rack::Static to serve files.

Recommendation

Upgrade Rack to version 2.2.23, 3.1.21, or 3.2.6 or later to patch CVE-2026-34785.
Review Rack::Static configurations to ensure appropriate restrictions are in place for serving static files.
Deploy the Sigma rule “Detect Suspicious Rack Static File Access” to identify attempts to access files with similar prefixes.
Monitor web server logs (category: webserver) for unusual requests with file extensions such as .env, .sql, .bak that fall under static directories (e.g., /css, /js, /img).

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.