Application-Vulnerability - CraftedSignal Threat Feed

Stack Buffer Overflow in Oj Ruby Gem (CVE-2026-54502)

hello@craftedsignal.io — Fri, 19 Jun 2026 19:47:47 +0000

An attacker can exploit a critical stack-based buffer overflow vulnerability, identified as CVE-2026-54502, within the Oj.dump function of the Oj Ruby gem. This vulnerability affects all versions of the Oj gem prior to 3.17.2. The flaw stems from insufficient input validation of the :indent parameter; when an application passes an extremely large integer value (such as INT_MAX, 2,147,483,647) to this parameter, the internal fill_indent function in ext/oj/dump.h calls memset without proper size checks. This leads to an attempt to write gigabytes of data into a small, stack-allocated buffer, corrupting the process's stack and resulting in an immediate denial of service through a crash. If exploited precisely, this could also enable remote code execution, posing a significant risk to the availability and integrity of Ruby applications using the vulnerable gem.

Attack Chain

Initial Access: An attacker identifies a Ruby application utilizing a vulnerable Oj gem version (prior to 3.17.2) and exposing a parameter or input field that directly or indirectly controls the indent argument for the Oj.dump function. This could be a web API endpoint, a file processing service, or another untrusted input vector.
Input Provision: The attacker crafts a request (e.g., an HTTP GET/POST parameter, an API call payload, or a crafted data file) containing an excessively large integer value (such as 2,147,483,647 representing INT_MAX) for the indent parameter.
Application Processing: The vulnerable Ruby application receives and processes this malicious input, passing the large integer value to the Oj.dump function's indent option without adequate validation.
Vulnerable Function Call: Internally, Oj.dump invokes its C extension fill_indent function (located in ext/oj/dump.h), which receives the large indent value.
Buffer Overflow: Within fill_indent, the memset function is called with the attacker-controlled large size, causing it to attempt to write gigabytes of data ((size_t)opts->indent * depth) into a much smaller, fixed-size stack-allocated out buffer (approximately 4KB).
Stack Corruption and Crash: This massive write operation overflows the out buffer, severely corrupting the stack memory of the Ruby process.
Denial of Service: The stack corruption immediately triggers an abnormal termination of the Ruby application process, leading to a denial of service for the affected service or application.
Potential Code Execution: In specific, carefully crafted scenarios, this stack corruption could potentially be leveraged to overwrite critical program control flow data (e.g., return addresses), allowing the attacker to achieve arbitrary code execution within the context of the vulnerable Ruby process.

Impact

Successful exploitation of CVE-2026-54502 primarily leads to a denial of service (DoS) for Ruby applications relying on the vulnerable Oj gem, causing immediate process crashes and service unavailability. Depending on the application's design, this can severely impact business operations and user access. In more sophisticated attack scenarios, the stack-based buffer overflow might be exploited to achieve arbitrary remote code execution (RCE). If RCE is successful, attackers could compromise the underlying server, execute commands with the privileges of the Ruby process, exfiltrate sensitive data, or establish further persistence within the environment, leading to significant data breaches, system compromise, and financial losses.

Recommendation

Patch CVE-2026-54502 immediately by upgrading the oj gem to version 3.17.2 or later in all affected Ruby applications.
Deploy the webserver Sigma rule "Detect CVE-2026-54502 Exploitation Attempt - Large Oj.dump Indent" in this brief to your SIEM to identify attempts at exploiting this vulnerability.
Implement robust input validation for all user-supplied data, particularly for parameters that influence data formatting or transformation, to prevent excessively large integer values from reaching sensitive functions.
Deploy the process creation Sigma rules "Detect Ruby Process Spawning Suspicious Child Process (Windows)" and "Detect Ruby Process Spawning Suspicious Child Process (Linux)" to monitor for potential remote code execution payloads from Ruby processes.

PraisonAI GitHub template cache path traversal allows outside-cache file write and directory deletion

hello@craftedsignal.io — Thu, 18 Jun 2026 15:28:36 +0000

PraisonAI's template loader, particularly versions 2.6.0 through 4.6.57, contains a path traversal vulnerability (GHSA-f44v-7qgw-9gh9) that allows an attacker to manipulate file system operations. The issue stems from insufficient validation of user-controlled ref and template path segments within GitHub template URIs (e.g., github:owner/repo/template@v1.0.0). When a crafted URI with directory traversal sequences (..) is processed, PraisonAI's cache layer constructs file paths that escape its intended cache directory. This enables an attacker to either write arbitrary .cache_meta.json files to unintended locations or, under specific conditions, delete arbitrary directories on the host system. This vulnerability, distinct from Zip Slip attacks, does not require malicious archives and affects PraisonAI installations across various operating systems, posing a significant risk of data corruption or denial of service.

Attack Chain

An attacker crafts a malicious PraisonAI GitHub template URI containing directory traversal sequences (e.g., github:attacker/repo/template@../../../../outside-target) within the ref portion.
A user or automated service loads this crafted URI using PraisonAI's TemplateLoader.load() method.
PraisonAI's template resolver (praisonai/templates/resolver.py) captures the owner, repo, template path, and the malicious ref verbatim without segment validation.
The _get_cache_path() function in praisonai/templates/cache.py concatenates these unvalidated segments to construct a local cache path, resulting in a path that escapes the intended ~/.praison/cache/templates/ directory.
Scenario A (Arbitrary File Write): During the first load, the cache.put() method attempts to write the .cache_meta.json file to the attacker-controlled escaped path.
Scenario B (Arbitrary Directory Deletion): If a legitimate cache entry for the same owner/repo/template prefix already exists, a subsequent load with the malicious URI causes cache.put() to first call shutil.rmtree() on the attacker-controlled escaped path, deleting an arbitrary directory.
The attacker successfully performs either the creation of .cache_meta.json at an arbitrary location (e.g., corrupting application configuration) or the deletion of an arbitrary directory on the system where PraisonAI is running.
This leads to corruption of user configuration, project state, or application data, potentially resulting in denial of service or further compromise.

Impact

Successful exploitation of this path traversal vulnerability can lead to severe consequences for organizations utilizing PraisonAI. An attacker can create arbitrary files, specifically .cache_meta.json, in locations outside the application's intended cache, potentially overwriting critical configuration files or injecting malicious data. More critically, under a specific two-stage scenario, an attacker can trigger the deletion of arbitrary directories via shutil.rmtree(), leading to data destruction, corruption of user or project data, or even a complete denial of service by removing essential system directories. All PraisonAI versions from 2.6.0 up to 4.6.57 are affected.

Recommendation

Patch PraisonAI immediately when a fix is released for versions >= 2.6.0 and <= 4.6.57 as per GHSA-f44v-7qgw-9gh9.
Deploy the provided Sigma rules to detect suspicious file write and deletion activities initiated by PraisonAI processes.
Enable detailed file creation and deletion logging (e.g., Sysmon Event ID 11 for file creation, Event ID 23 for file deletion on Windows; auditd on Linux) for Python processes to activate the detection rules.
If PraisonAI is used in a critical environment, implement strict path validation within any custom TemplateCache or TemplateLoader implementations to reject absolute paths, . or .. segments, or paths escaping the intended cache root, as suggested in GHSA-f44v-7qgw-9gh9.

PraisonAI Recipe Policy Bypass via YAML Workflow Approval

hello@craftedsignal.io — Thu, 18 Jun 2026 15:01:53 +0000

A critical policy bypass vulnerability affects PraisonAI, a recipe execution platform, specifically versions v4.5.87 through v4.6.57. The platform's security model intends to block "dangerous tools" (e.g., execute_command) unless an operator explicitly allows them via allow_dangerous_tools=True. However, an untrusted recipe can circumvent this control. By crafting a workflow.yaml that declares a default-denied tool within an agent's tools section and simultaneously using a top-level approve: directive, the recipe can effectively self-approve the dangerous tool. This bypasses the initial security policy that only checks TEMPLATE.yaml requires.tools, enabling the recipe to execute arbitrary commands without operator consent. The vulnerability affects both local CLI usage and HTTP recipe-runner deployments, with potentially higher severity if exposed to authenticated users.

Attack Chain

Attacker crafts malicious PraisonAI recipe: The attacker prepares a recipe consisting of a workflow.yaml that declares a default-denied critical tool (e.g., execute_command) under an agent's tools section and includes approve: [execute_command] at the top level, while ensuring the TEMPLATE.yaml requires.tools section does not list any dangerous tools.
Operator runs untrusted recipe: An operator or user runs the attacker-controlled recipe through the PraisonAI local CLI or an exposed HTTP recipe runner, critically without specifying allow_dangerous_tools=True.
Initial policy check bypassed: PraisonAI's _check_tool_policy() function inspects only the TEMPLATE.yaml requires.tools list. Since the malicious workflow.yaml avoids listing dangerous tools there, the recipe passes this initial security gate.
YAMLWorkflowParser processes workflow.yaml: During the _execute_steps_workflow() phase, YAMLWorkflowParser parses the workflow.yaml, resolving agent-level tools: declarations and extracting the top-level approve: directives.
Workflow self-approves dangerous tools: The Workflow.start() method invokes set_yaml_approved_tools(), which registers the tools specified in the approve: directive (including the dangerous execute_command) within the application's approval context, effectively self-approving them.
Agent executes dangerous command: When the PraisonAI agent within the workflow attempts to utilize the execute_command tool, it is treated as pre-approved due to the bypass, allowing the agent to proceed with its execution.
Arbitrary command execution: The execute_command tool then executes arbitrary operating system commands specified by the attacker within the workflow.yaml, inheriting the privileges of the underlying PraisonAI process.
Impact: This unapproved command execution can lead to remote code execution, data exfiltration, system compromise, or facilitate further lateral movement within the compromised environment.

Impact

This policy bypass allows an untrusted recipe to execute arbitrary commands with the privileges of the PraisonAI process. If an operator runs such a recipe, or if a PraisonAI HTTP recipe runner is exposed to users who can choose recipe names or URIs, successful exploitation can lead to full system compromise. The exact trigger for command execution depends on the specific workflow and model/tool-call path, but the core policy boundary is breached before execution. This impacts both local CLI usage of PraisonAI and deployments utilizing the HTTP recipe runner, potentially escalating to an authenticated remote execution issue if the API is accessible.

Recommendation

Patch PraisonAI: Upgrade PraisonAI to version 4.6.61 or later immediately to address the vulnerability described in the GHSA advisory.
Monitor process_creation logs: Deploy the Sigma rules provided in this brief to detect suspicious command execution originating from PraisonAI processes.
Enable Sysmon logging: Ensure Sysmon process creation and command line logging (Event ID 1) is enabled on all Windows systems running PraisonAI to facilitate detection of spawned shell processes.