{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/application-vulnerability/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["oj gem (\u003c 3.17.2)"],"_cs_severities":["high"],"_cs_tags":["overflow","ruby","gem","denial-of-service","remote-code-execution","application-vulnerability"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAn attacker can exploit a critical stack-based buffer overflow vulnerability, identified as CVE-2026-54502, within the \u003ccode\u003eOj.dump\u003c/code\u003e function of the \u003ccode\u003eOj\u003c/code\u003e Ruby gem. This vulnerability affects all versions of the \u003ccode\u003eOj\u003c/code\u003e gem prior to \u003ccode\u003e3.17.2\u003c/code\u003e. The flaw stems from insufficient input validation of the \u003ccode\u003e:indent\u003c/code\u003e parameter; when an application passes an extremely large integer value (such as \u003ccode\u003eINT_MAX\u003c/code\u003e, 2,147,483,647) to this parameter, the internal \u003ccode\u003efill_indent\u003c/code\u003e function in \u003ccode\u003eext/oj/dump.h\u003c/code\u003e calls \u003ccode\u003ememset\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access\u003c/strong\u003e: An attacker identifies a Ruby application utilizing a vulnerable \u003ccode\u003eOj\u003c/code\u003e gem version (prior to 3.17.2) and exposing a parameter or input field that directly or indirectly controls the \u003ccode\u003eindent\u003c/code\u003e argument for the \u003ccode\u003eOj.dump\u003c/code\u003e function. This could be a web API endpoint, a file processing service, or another untrusted input vector.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInput Provision\u003c/strong\u003e: 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 \u003ccode\u003e2,147,483,647\u003c/code\u003e representing \u003ccode\u003eINT_MAX\u003c/code\u003e) for the \u003ccode\u003eindent\u003c/code\u003e parameter.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eApplication Processing\u003c/strong\u003e: The vulnerable Ruby application receives and processes this malicious input, passing the large integer value to the \u003ccode\u003eOj.dump\u003c/code\u003e function's \u003ccode\u003eindent\u003c/code\u003e option without adequate validation.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVulnerable Function Call\u003c/strong\u003e: Internally, \u003ccode\u003eOj.dump\u003c/code\u003e invokes its C extension \u003ccode\u003efill_indent\u003c/code\u003e function (located in \u003ccode\u003eext/oj/dump.h\u003c/code\u003e), which receives the large \u003ccode\u003eindent\u003c/code\u003e value.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBuffer Overflow\u003c/strong\u003e: Within \u003ccode\u003efill_indent\u003c/code\u003e, the \u003ccode\u003ememset\u003c/code\u003e function is called with the attacker-controlled large size, causing it to attempt to write gigabytes of data (\u003ccode\u003e(size_t)opts-\u0026gt;indent * depth\u003c/code\u003e) into a much smaller, fixed-size stack-allocated \u003ccode\u003eout\u003c/code\u003e buffer (approximately 4KB).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStack Corruption and Crash\u003c/strong\u003e: This massive write operation overflows the \u003ccode\u003eout\u003c/code\u003e buffer, severely corrupting the stack memory of the Ruby process.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDenial of Service\u003c/strong\u003e: 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePotential Code Execution\u003c/strong\u003e: 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-54502 primarily leads to a denial of service (DoS) for Ruby applications relying on the vulnerable \u003ccode\u003eOj\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePatch CVE-2026-54502 immediately by upgrading the \u003ccode\u003eoj\u003c/code\u003e gem to version 3.17.2 or later in all affected Ruby applications.\u003c/li\u003e\n\u003cli\u003eDeploy the webserver Sigma rule \u0026quot;Detect CVE-2026-54502 Exploitation Attempt - Large Oj.dump Indent\u0026quot; in this brief to your SIEM to identify attempts at exploiting this vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement 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.\u003c/li\u003e\n\u003cli\u003eDeploy the process creation Sigma rules \u0026quot;Detect Ruby Process Spawning Suspicious Child Process (Windows)\u0026quot; and \u0026quot;Detect Ruby Process Spawning Suspicious Child Process (Linux)\u0026quot; to monitor for potential remote code execution payloads from Ruby processes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-06-19T19:47:47Z","date_published":"2026-06-19T19:47:47Z","id":"https://feed.craftedsignal.io/briefs/2026-06-stack-buffer-overflow-oj-gem/","summary":"The `Oj.dump` function in the `Oj` Ruby gem is vulnerable to a stack-based buffer overflow (CVE-2026-54502) due to improper validation of the `:indent` parameter, allowing an attacker to trigger a process crash or potentially remote code execution by providing an excessively large integer value, affecting all `Oj` gem versions prior to `3.17.2`.","title":"Stack Buffer Overflow in Oj Ruby Gem (CVE-2026-54502)","url":"https://feed.craftedsignal.io/briefs/2026-06-stack-buffer-overflow-oj-gem/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["praisonai (\u003e= 2.6.0, \u003c= 4.6.57)"],"_cs_severities":["high"],"_cs_tags":["path-traversal","application-vulnerability","python","file-write","file-deletion"],"_cs_type":"advisory","_cs_vendors":["PraisonAI"],"content_html":"\u003cp\u003ePraisonAI'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 \u003ccode\u003eref\u003c/code\u003e and \u003ccode\u003etemplate path\u003c/code\u003e segments within GitHub template URIs (e.g., \u003ccode\u003egithub:owner/repo/template@v1.0.0\u003c/code\u003e). When a crafted URI with directory traversal sequences (\u003ccode\u003e..\u003c/code\u003e) is processed, PraisonAI's cache layer constructs file paths that escape its intended cache directory. This enables an attacker to either write arbitrary \u003ccode\u003e.cache_meta.json\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious PraisonAI GitHub template URI containing directory traversal sequences (e.g., \u003ccode\u003egithub:attacker/repo/template@../../../../outside-target\u003c/code\u003e) within the \u003ccode\u003eref\u003c/code\u003e portion.\u003c/li\u003e\n\u003cli\u003eA user or automated service loads this crafted URI using PraisonAI's \u003ccode\u003eTemplateLoader.load()\u003c/code\u003e method.\u003c/li\u003e\n\u003cli\u003ePraisonAI's template resolver (\u003ccode\u003epraisonai/templates/resolver.py\u003c/code\u003e) captures the owner, repo, template path, and the malicious \u003ccode\u003eref\u003c/code\u003e verbatim without segment validation.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003e_get_cache_path()\u003c/code\u003e function in \u003ccode\u003epraisonai/templates/cache.py\u003c/code\u003e concatenates these unvalidated segments to construct a local cache path, resulting in a path that escapes the intended \u003ccode\u003e~/.praison/cache/templates/\u003c/code\u003e directory.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eScenario A (Arbitrary File Write):\u003c/strong\u003e During the first load, the \u003ccode\u003ecache.put()\u003c/code\u003e method attempts to write the \u003ccode\u003e.cache_meta.json\u003c/code\u003e file to the attacker-controlled escaped path.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eScenario B (Arbitrary Directory Deletion):\u003c/strong\u003e If a legitimate cache entry for the \u003cem\u003esame owner/repo/template prefix\u003c/em\u003e already exists, a subsequent load with the malicious URI causes \u003ccode\u003ecache.put()\u003c/code\u003e to first call \u003ccode\u003eshutil.rmtree()\u003c/code\u003e on the attacker-controlled escaped path, deleting an arbitrary directory.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully performs either the creation of \u003ccode\u003e.cache_meta.json\u003c/code\u003e at an arbitrary location (e.g., corrupting application configuration) or the deletion of an arbitrary directory on the system where PraisonAI is running.\u003c/li\u003e\n\u003cli\u003eThis leads to corruption of user configuration, project state, or application data, potentially resulting in denial of service or further compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this path traversal vulnerability can lead to severe consequences for organizations utilizing PraisonAI. An attacker can create arbitrary files, specifically \u003ccode\u003e.cache_meta.json\u003c/code\u003e, 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 \u003ccode\u003eshutil.rmtree()\u003c/code\u003e, 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePatch PraisonAI immediately when a fix is released for versions \u0026gt;= 2.6.0 and \u0026lt;= 4.6.57 as per GHSA-f44v-7qgw-9gh9.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rules to detect suspicious file write and deletion activities initiated by PraisonAI processes.\u003c/li\u003e\n\u003cli\u003eEnable 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.\u003c/li\u003e\n\u003cli\u003eIf PraisonAI is used in a critical environment, implement strict path validation within any custom \u003ccode\u003eTemplateCache\u003c/code\u003e or \u003ccode\u003eTemplateLoader\u003c/code\u003e implementations to reject absolute paths, \u003ccode\u003e.\u003c/code\u003e or \u003ccode\u003e..\u003c/code\u003e segments, or paths escaping the intended cache root, as suggested in GHSA-f44v-7qgw-9gh9.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-06-18T15:28:36Z","date_published":"2026-06-18T15:28:36Z","id":"https://feed.craftedsignal.io/briefs/2026-06-praisonai-path-traversal/","summary":"PraisonAI's template loader is vulnerable to a path traversal flaw (GHSA-f44v-7qgw-9gh9) when processing GitHub template URIs, allowing an unauthenticated attacker to write arbitrary files or delete arbitrary directories on the system running PraisonAI, leading to corruption of user configuration, project state, or application data.","title":"PraisonAI GitHub template cache path traversal allows outside-cache file write and directory deletion","url":"https://feed.craftedsignal.io/briefs/2026-06-praisonai-path-traversal/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["PraisonAI (\u003e= 4.5.87, \u003c 4.6.61)"],"_cs_severities":["high"],"_cs_tags":["application-vulnerability","policy-bypass","remote-code-execution","praisonai","python"],"_cs_type":"advisory","_cs_vendors":["MervinPraison"],"content_html":"\u003cp\u003eA critical policy bypass vulnerability affects PraisonAI, a recipe execution platform, specifically versions \u003ccode\u003ev4.5.87\u003c/code\u003e through \u003ccode\u003ev4.6.57\u003c/code\u003e. The platform's security model intends to block \u0026quot;dangerous tools\u0026quot; (e.g., \u003ccode\u003eexecute_command\u003c/code\u003e) unless an operator explicitly allows them via \u003ccode\u003eallow_dangerous_tools=True\u003c/code\u003e. However, an untrusted recipe can circumvent this control. By crafting a \u003ccode\u003eworkflow.yaml\u003c/code\u003e that declares a default-denied tool within an agent's \u003ccode\u003etools\u003c/code\u003e section and simultaneously using a top-level \u003ccode\u003eapprove:\u003c/code\u003e directive, the recipe can effectively self-approve the dangerous tool. This bypasses the initial security policy that only checks \u003ccode\u003eTEMPLATE.yaml requires.tools\u003c/code\u003e, 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eAttacker crafts malicious PraisonAI recipe\u003c/strong\u003e: The attacker prepares a recipe consisting of a \u003ccode\u003eworkflow.yaml\u003c/code\u003e that declares a default-denied critical tool (e.g., \u003ccode\u003eexecute_command\u003c/code\u003e) under an agent's \u003ccode\u003etools\u003c/code\u003e section and includes \u003ccode\u003eapprove: [execute_command]\u003c/code\u003e at the top level, while ensuring the \u003ccode\u003eTEMPLATE.yaml requires.tools\u003c/code\u003e section does not list any dangerous tools.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOperator runs untrusted recipe\u003c/strong\u003e: An operator or user runs the attacker-controlled recipe through the PraisonAI local CLI or an exposed HTTP recipe runner, critically without specifying \u003ccode\u003eallow_dangerous_tools=True\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInitial policy check bypassed\u003c/strong\u003e: \u003ccode\u003ePraisonAI\u003c/code\u003e's \u003ccode\u003e_check_tool_policy()\u003c/code\u003e function inspects only the \u003ccode\u003eTEMPLATE.yaml requires.tools\u003c/code\u003e list. Since the malicious \u003ccode\u003eworkflow.yaml\u003c/code\u003e avoids listing dangerous tools there, the recipe passes this initial security gate.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e\u003ccode\u003eYAMLWorkflowParser\u003c/code\u003e processes \u003ccode\u003eworkflow.yaml\u003c/code\u003e\u003c/strong\u003e: During the \u003ccode\u003e_execute_steps_workflow()\u003c/code\u003e phase, \u003ccode\u003eYAMLWorkflowParser\u003c/code\u003e parses the \u003ccode\u003eworkflow.yaml\u003c/code\u003e, resolving agent-level \u003ccode\u003etools:\u003c/code\u003e declarations and extracting the top-level \u003ccode\u003eapprove:\u003c/code\u003e directives.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWorkflow self-approves dangerous tools\u003c/strong\u003e: The \u003ccode\u003eWorkflow.start()\u003c/code\u003e method invokes \u003ccode\u003eset_yaml_approved_tools()\u003c/code\u003e, which registers the tools specified in the \u003ccode\u003eapprove:\u003c/code\u003e directive (including the dangerous \u003ccode\u003eexecute_command\u003c/code\u003e) within the application's approval context, effectively self-approving them.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAgent executes dangerous command\u003c/strong\u003e: When the PraisonAI agent within the workflow attempts to utilize the \u003ccode\u003eexecute_command\u003c/code\u003e tool, it is treated as pre-approved due to the bypass, allowing the agent to proceed with its execution.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eArbitrary command execution\u003c/strong\u003e: The \u003ccode\u003eexecute_command\u003c/code\u003e tool then executes arbitrary operating system commands specified by the attacker within the \u003ccode\u003eworkflow.yaml\u003c/code\u003e, inheriting the privileges of the underlying PraisonAI process.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact\u003c/strong\u003e: This unapproved command execution can lead to remote code execution, data exfiltration, system compromise, or facilitate further lateral movement within the compromised environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003ePatch \u003ccode\u003ePraisonAI\u003c/code\u003e\u003c/strong\u003e: Upgrade \u003ccode\u003ePraisonAI\u003c/code\u003e to version \u003ccode\u003e4.6.61\u003c/code\u003e or later immediately to address the vulnerability described in the GHSA advisory.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMonitor \u003ccode\u003eprocess_creation\u003c/code\u003e logs\u003c/strong\u003e: Deploy the Sigma rules provided in this brief to detect suspicious command execution originating from \u003ccode\u003ePraisonAI\u003c/code\u003e processes.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEnable Sysmon logging\u003c/strong\u003e: 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-06-18T15:01:53Z","date_published":"2026-06-18T15:01:53Z","id":"https://feed.craftedsignal.io/briefs/2026-06-praisonai-policy-bypass/","summary":"A policy bypass vulnerability in PraisonAI (CVE-NONE) allows untrusted recipes to self-approve and execute default-denied critical shell tools, such as `execute_command`, by declaring them in `workflow.yaml` instead of `TEMPLATE.yaml requires.tools`, leading to arbitrary command execution with the privileges of the PraisonAI process.","title":"PraisonAI Recipe Policy Bypass via YAML Workflow Approval","url":"https://feed.craftedsignal.io/briefs/2026-06-praisonai-policy-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed - Application-Vulnerability","version":"https://jsonfeed.org/version/1.1"}