{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/vendors/pip/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["litellm"],"_cs_severities":["critical"],"_cs_tags":["sqli","litellm","web-application"],"_cs_type":"advisory","_cs_vendors":["pip"],"content_html":"\u003cp\u003eA critical SQL injection vulnerability has been identified in LiteLLM, specifically affecting versions 1.81.16 through 1.83.6. The vulnerability resides within the proxy API key verification process. Due to improper sanitization of the \u003ccode\u003eAuthorization\u003c/code\u003e header, an unauthenticated attacker can inject arbitrary SQL commands. This is achieved by sending a specially crafted header to any LLM API route, such as \u003ccode\u003ePOST /chat/completions\u003c/code\u003e, which triggers the vulnerable query through the proxy\u0026rsquo;s error-handling mechanism. Defenders should prioritize patching to version 1.83.7 or later to mitigate this risk, or implement the suggested workaround.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker sends a crafted HTTP \u003ccode\u003eAuthorization\u003c/code\u003e header to a LiteLLM API endpoint (e.g., \u003ccode\u003e/chat/completions\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe LiteLLM proxy receives the request and extracts the API key from the \u003ccode\u003eAuthorization\u003c/code\u003e header.\u003c/li\u003e\n\u003cli\u003eDue to insufficient sanitization, the API key value is directly concatenated into a SQL query string.\u003c/li\u003e\n\u003cli\u003eThe vulnerable SQL query is executed against the proxy\u0026rsquo;s database.\u003c/li\u003e\n\u003cli\u003eThe attacker injects SQL code to read sensitive data, such as user credentials or API keys, from the database.\u003c/li\u003e\n\u003cli\u003eThe attacker may further inject SQL code to modify data, potentially granting themselves administrative privileges or compromising other users\u0026rsquo; accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to the LiteLLM proxy.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised proxy to access and control connected LLMs, exfiltrate data, or disrupt services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this SQL injection vulnerability can lead to complete compromise of the LiteLLM proxy. Attackers could read or modify sensitive data within the proxy\u0026rsquo;s database, including API keys and credentials. This could lead to unauthorized access to managed LLMs and potentially allow attackers to exfiltrate sensitive data, disrupt services, or gain a foothold for further attacks within the compromised environment. The impact is significant due to the potential for widespread data breaches and service disruptions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade LiteLLM to version 1.83.7 or later to patch the SQL injection vulnerability as detailed in the advisory \u003ca href=\"https://github.com/advisories/GHSA-r75f-5x8p-qvmc\"\u003eGHSA-r75f-5x8p-qvmc\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eIf upgrading is not immediately feasible, set \u003ccode\u003edisable_error_logs: true\u003c/code\u003e in the \u003ccode\u003egeneral_settings\u003c/code\u003e configuration to mitigate the risk as described in the advisory \u003ca href=\"https://github.com/advisories/GHSA-r75f-5x8p-qvmc\"\u003eGHSA-r75f-5x8p-qvmc\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for suspicious \u003ccode\u003eAuthorization\u003c/code\u003e headers containing SQL injection payloads to detect potential exploitation attempts. Deploy the provided Sigma rule targeting HTTP request patterns.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-08T12:00:00Z","date_published":"2024-11-08T12:00:00Z","id":"/briefs/2024-11-litellm-sqli/","summary":"A SQL injection vulnerability exists in LiteLLM versions 1.81.16 to prior to 1.83.7 allowing an unauthenticated attacker to inject SQL queries via a crafted 'Authorization' header, potentially leading to unauthorized data access or modification.","title":"LiteLLM Proxy API Key Verification SQL Injection","url":"https://feed.craftedsignal.io/briefs/2024-11-litellm-sqli/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2023-40267"}],"_cs_exploited":false,"_cs_products":["GitPython"],"_cs_severities":["high"],"_cs_tags":["gitpython","code-execution","git-hooks","command-injection"],"_cs_type":"advisory","_cs_vendors":["pip"],"content_html":"\u003cp\u003eGitPython before version 3.1.47 is susceptible to a command execution vulnerability. The issue stems from how the \u003ccode\u003e_clone()\u003c/code\u003e function validates the \u003ccode\u003emulti_options\u003c/code\u003e parameter used in the \u003ccode\u003eclone_from()\u003c/code\u003e, \u003ccode\u003eclone()\u003c/code\u003e, or \u003ccode\u003eSubmodule.update()\u003c/code\u003e methods. Specifically, the validation occurs on the original list of options before the \u003ccode\u003eshlex.split\u003c/code\u003e transformation. This allows an attacker to craft a string like \u003ccode\u003e\u0026quot;--branch main --config core.hooksPath=/x\u0026quot;\u003c/code\u003e which passes the initial validation because it starts with a safe option (\u003ccode\u003e--branch\u003c/code\u003e). However, after the string is split into tokens, the \u003ccode\u003e--config\u003c/code\u003e option becomes active, allowing the attacker to inject a malicious \u003ccode\u003ecore.hooksPath\u003c/code\u003e configuration. This configuration points Git to a directory containing attacker-controlled Git hooks, which are then executed during the clone operation. This vulnerability is similar in nature to CVE-2023-40267.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies a vulnerable application using GitPython to clone repositories.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious string containing a Git configuration option, such as \u003ccode\u003e--config core.hooksPath=/path/to/malicious/hooks\u003c/code\u003e, embedded within a seemingly benign option string like \u003ccode\u003e--branch main --config core.hooksPath=/path/to/malicious/hooks\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker injects this malicious string into the \u003ccode\u003emulti_options\u003c/code\u003e parameter of the \u003ccode\u003eclone_from()\u003c/code\u003e, \u003ccode\u003eclone()\u003c/code\u003e, or \u003ccode\u003eSubmodule.update()\u003c/code\u003e methods.\u003c/li\u003e\n\u003cli\u003eGitPython\u0026rsquo;s \u003ccode\u003e_clone()\u003c/code\u003e function validates the \u003ccode\u003emulti_options\u003c/code\u003e parameter using \u003ccode\u003eGit.check_unsafe_options()\u003c/code\u003e \u003cem\u003ebefore\u003c/em\u003e it is processed by \u003ccode\u003eshlex.split()\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eBecause the malicious string starts with a safe option (\u003ccode\u003e--branch\u003c/code\u003e), it bypasses the validation check.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eshlex.split()\u003c/code\u003e function then transforms the string into a list of individual options, making the \u003ccode\u003e--config\u003c/code\u003e option active.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003egit clone\u003c/code\u003e command is executed with the injected \u003ccode\u003e--config core.hooksPath=/path/to/malicious/hooks\u003c/code\u003e option, causing Git to use the attacker-controlled directory for Git hooks.\u003c/li\u003e\n\u003cli\u003eGit executes the malicious hooks (e.g., \u003ccode\u003epost-checkout\u003c/code\u003e), resulting in arbitrary code execution on the victim\u0026rsquo;s machine.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows an attacker to execute arbitrary code on the system where the GitPython library is used. Any application that passes user-supplied input to the \u003ccode\u003emulti_options\u003c/code\u003e parameter of the affected functions is vulnerable. This can lead to complete system compromise, data exfiltration, or denial of service. The vulnerability affects GitPython versions prior to 3.1.47.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade GitPython to version 3.1.47 or later to patch the vulnerability (Affected Packages).\u003c/li\u003e\n\u003cli\u003eImplement input validation and sanitization for any user-supplied input used to construct the \u003ccode\u003emulti_options\u003c/code\u003e parameter to prevent injection of malicious Git configurations (Code).\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for the execution of unexpected processes from directories specified as \u003ccode\u003ecore.hooksPath\u003c/code\u003e (see Sigma rule \u003ccode\u003eDetect Suspicious Git Hook Execution\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules in this brief to your SIEM and tune for your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-23-gitpython-hook-execution/","summary":"A vulnerability in GitPython versions prior to 3.1.47 allows for command execution during repository cloning by manipulating the `multi_options` parameter to inject malicious Git configurations, such as `core.hooksPath`, leading to the execution of attacker-controlled hooks.","title":"GitPython Vulnerability Allows Arbitrary Code Execution via Git Hooks","url":"https://feed.craftedsignal.io/briefs/2024-01-23-gitpython-hook-execution/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitPython (3.1.30-3.1.46)"],"_cs_severities":["high"],"_cs_tags":["command-injection","gitpython","vulnerability"],"_cs_type":"advisory","_cs_vendors":["pip"],"content_html":"\u003cp\u003eGitPython, a library providing programmatic interaction with Git repositories, is susceptible to a command injection vulnerability in versions 3.1.30 to 3.1.46. The vulnerability stems from insufficient validation of keyword arguments (kwargs) passed to functions like \u003ccode\u003eRepo.clone_from()\u003c/code\u003e, \u003ccode\u003eRemote.fetch()\u003c/code\u003e, \u003ccode\u003eRemote.pull()\u003c/code\u003e, and \u003ccode\u003eRemote.push()\u003c/code\u003e. Specifically, when underscore-form kwargs (e.g., \u003ccode\u003eupload_pack\u003c/code\u003e) are used, they bypass the intended safety checks designed to prevent the execution of arbitrary commands via Git options like \u003ccode\u003e--upload-pack\u003c/code\u003e. This occurs because the validation logic only checks for hyphenated forms (e.g., \u003ccode\u003eupload-pack\u003c/code\u003e). Attackers can exploit this by injecting malicious commands through these kwargs, even when \u003ccode\u003eallow_unsafe_options\u003c/code\u003e is set to its default value of \u003ccode\u003eFalse\u003c/code\u003e. This issue was reported on April 25, 2026.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies a web application or system that uses GitPython to manage Git repositories.\u003c/li\u003e\n\u003cli\u003eThe attacker finds an endpoint or function where they can control kwargs passed to \u003ccode\u003eRepo.clone_from()\u003c/code\u003e, \u003ccode\u003eRemote.fetch()\u003c/code\u003e, \u003ccode\u003eRemote.pull()\u003c/code\u003e, or \u003ccode\u003eRemote.push()\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious payload, using underscore-form kwargs such as \u003ccode\u003eupload_pack\u003c/code\u003e or \u003ccode\u003ereceive_pack\u003c/code\u003e, setting their value to a command they want to execute (e.g., a shell script path or a direct command).\u003c/li\u003e\n\u003cli\u003eThe application or system, using a vulnerable version of GitPython, receives these kwargs and bypasses the intended safety check.\u003c/li\u003e\n\u003cli\u003eGitPython\u0026rsquo;s \u003ccode\u003eGit.transform_kwarg()\u003c/code\u003e method converts the underscore-form kwargs into their corresponding hyphenated Git options (e.g., \u003ccode\u003eupload_pack\u003c/code\u003e becomes \u003ccode\u003e--upload-pack\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe Git command is executed with the attacker-controlled option, leading to arbitrary command execution on the system.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access, potentially stealing credentials, modifying repositories, or moving laterally within the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability can lead to severe consequences, especially in web applications, CI/CD systems, and automation tools that rely on GitPython for repository management. Attackers could steal SSH keys, API tokens, cloud credentials, or other sensitive information. They could also modify repositories, build outputs, or release artifacts, leading to supply chain attacks. In CI/CD environments, this vulnerability could enable lateral movement from worker nodes or compromise the entire automation infrastructure. The number of affected systems depends on the prevalence of vulnerable GitPython versions in exposed applications.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade GitPython to version 3.1.47 or later to remediate the vulnerability (affected_products).\u003c/li\u003e\n\u003cli\u003eReview code that uses \u003ccode\u003eRepo.clone_from()\u003c/code\u003e, \u003ccode\u003eRemote.fetch()\u003c/code\u003e, \u003ccode\u003eRemote.pull()\u003c/code\u003e, or \u003ccode\u003eRemote.push()\u003c/code\u003e and ensure that kwargs are properly validated to prevent attacker-controlled input (references).\u003c/li\u003e\n\u003cli\u003eImplement input validation to block underscore-form kwargs such as \u003ccode\u003eupload_pack\u003c/code\u003e or \u003ccode\u003ereceive_pack\u003c/code\u003e before they are passed to GitPython functions (references).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect GitPython Kwarg Command Injection\u003c/code\u003e to identify potential exploitation attempts in application logs (rules).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T10:00:00Z","date_published":"2024-01-09T10:00:00Z","id":"/briefs/2024-01-09-gitpython-cmd-injection/","summary":"GitPython versions 3.1.30 through 3.1.46 are vulnerable to command injection by passing attacker-controlled kwargs into `Repo.clone_from()`, `Remote.fetch()`, `Remote.pull()`, or `Remote.push()`, leading to arbitrary command execution due to bypassed safety checks.","title":"GitPython Command Injection Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-09-gitpython-cmd-injection/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["pyp2spec (\u003c 0.14.1)"],"_cs_severities":["high"],"_cs_tags":["code-injection","supply-chain","rpm","linux"],"_cs_type":"advisory","_cs_vendors":["pip","Fedora"],"content_html":"\u003cp\u003epyp2spec, a tool for generating RPM spec files from PyPI packages, contains a code injection vulnerability affecting versions prior to 0.14.1. The vulnerability stems from the tool\u0026rsquo;s failure to properly escape RPM macro directives when writing PyPI package metadata (such as the summary field) into the generated spec file. This allows a malicious PyPI package to inject arbitrary commands into the spec file, which are then executed when an RPM tool processes the file. This poses a significant risk to package maintainers and build systems, particularly within the Fedora ecosystem where compromised credentials can lead to widespread supply chain attacks. The realistic attack vector involves typosquatting or targeting packages known to be under review.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious PyPI package containing specially formatted metadata, including an RPM macro directive (e.g., within the package summary).\u003c/li\u003e\n\u003cli\u003eA Fedora packager, intending to package a legitimate Python package, uses \u003ccode\u003epyp2spec\u003c/code\u003e to generate an RPM spec file from the malicious PyPI package.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003epyp2spec\u003c/code\u003e writes the attacker-controlled metadata, including the unescaped RPM macro directive, into the generated spec file.\u003c/li\u003e\n\u003cli\u003eThe packager, or an automated system, uses an RPM tool like \u003ccode\u003erpmbuild -bs\u003c/code\u003e, \u003ccode\u003erpmbuild --nobuild\u003c/code\u003e, or \u003ccode\u003erpm -q --specfile\u003c/code\u003e to inspect or build the package from the spec file.\u003c/li\u003e\n\u003cli\u003eThe RPM tool parses the spec file and, upon encountering the RPM macro directive, executes the embedded command.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s command executes on the build machine, potentially granting the attacker access to the packager\u0026rsquo;s credentials (dist-git SSH keys, Koji build credentials, Bodhi update credentials).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to commit malicious source code to the distribution\u0026rsquo;s Git repository (dist-git).\u003c/li\u003e\n\u003cli\u003eThe malicious code is built and distributed to end users through the normal package update pipeline, resulting in a supply chain attack.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to execute arbitrary commands on the build machine. This can lead to the compromise of sensitive credentials, such as SSH keys and build system credentials. In the Fedora ecosystem, this could enable an attacker to inject malicious code into packages that are distributed to end users, potentially affecting millions of systems. The vulnerability poses a high risk to package maintainers and build systems.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to \u003ccode\u003epyp2spec\u003c/code\u003e version 0.14.1 or later to remediate the code injection vulnerability as described in the advisory (\u003ca href=\"https://github.com/advisories/GHSA-r35x-v8p8-xvhw)\"\u003ehttps://github.com/advisories/GHSA-r35x-v8p8-xvhw)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement file integrity monitoring on RPM spec files, alerting on unexpected modifications, to detect potentially malicious injected code. Use file_event logs with a rule like the one below.\u003c/li\u003e\n\u003cli\u003eMonitor process executions originating from RPM tools (\u003ccode\u003erpmbuild\u003c/code\u003e, \u003ccode\u003erpm\u003c/code\u003e), focusing on unusual or unexpected commands that could indicate exploitation, using process_creation logs and the Sigma rule provided.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-pyp2spec-code-injection/","summary":"pyp2spec before 0.14.1 is vulnerable to code injection by writing PyPI package metadata into generated spec files without escaping RPM macro directives, allowing malicious packages to execute arbitrary commands on the build machine.","title":"pyp2spec Code Injection Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-pyp2spec-code-injection/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["litellm"],"_cs_severities":["high"],"_cs_tags":["rce","litellm","command-injection"],"_cs_type":"advisory","_cs_vendors":["pip"],"content_html":"\u003cp\u003eLiteLLM versions 1.74.2 through 1.83.6 are vulnerable to authenticated command execution. Two endpoints, \u003ccode\u003ePOST /mcp-rest/test/connection\u003c/code\u003e and \u003ccode\u003ePOST /mcp-rest/test/tools/list\u003c/code\u003e, intended for previewing MCP server configurations, allowed any authenticated user to execute arbitrary commands on the proxy host. This was possible because the endpoints accepted a full server configuration in the request body, including the \u003ccode\u003ecommand\u003c/code\u003e, \u003ccode\u003eargs\u003c/code\u003e, and \u003ccode\u003eenv\u003c/code\u003e fields used by the stdio transport, without proper role checks. An attacker could exploit this vulnerability by using a low-privilege API key to send a crafted request containing malicious commands, leading to command execution with the privileges of the proxy process. The vulnerability was patched in version 1.83.7 by enforcing the \u003ccode\u003ePROXY_ADMIN\u003c/code\u003e role for these endpoints.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker authenticates to the LiteLLM proxy with a valid, but low-privilege, API key.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious JSON payload containing a server configuration intended for the stdio transport. The payload includes the \u003ccode\u003ecommand\u003c/code\u003e, \u003ccode\u003eargs\u003c/code\u003e, and \u003ccode\u003eenv\u003c/code\u003e fields, which specify the command to be executed, its arguments, and environment variables, respectively.\u003c/li\u003e\n\u003cli\u003eAttacker sends a \u003ccode\u003ePOST\u003c/code\u003e request to either the \u003ccode\u003e/mcp-rest/test/connection\u003c/code\u003e or \u003ccode\u003e/mcp-rest/test/tools/list\u003c/code\u003e endpoint, with the malicious JSON payload in the request body.\u003c/li\u003e\n\u003cli\u003eThe LiteLLM proxy receives the request and, due to the vulnerability, attempts to connect to the supplied server configuration.\u003c/li\u003e\n\u003cli\u003eThe proxy spawns the supplied command as a subprocess on the proxy host, using the privileges of the proxy process.\u003c/li\u003e\n\u003cli\u003eThe attacker-supplied command executes arbitrary code on the host.\u003c/li\u003e\n\u003cli\u003eThe attacker gains control of the proxy host with the privileges of the LiteLLM proxy.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows an attacker to execute arbitrary commands on the host running the LiteLLM proxy. Since the vulnerability can be exploited with a low-privilege API key, this significantly broadens the attack surface. Depending on the privileges of the proxy process, this could lead to full system compromise, data exfiltration, or denial of service. The lack of specific victim count or sector targeting information in the advisory suggests a broad potential impact across various deployments of LiteLLM.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade LiteLLM to version 1.83.7 or later to remediate the vulnerability (see Patches).\u003c/li\u003e\n\u003cli\u003eAs a temporary workaround, block \u003ccode\u003ePOST\u003c/code\u003e requests to the \u003ccode\u003e/mcp-rest/test/connection\u003c/code\u003e and \u003ccode\u003e/mcp-rest/test/tools/list\u003c/code\u003e endpoints at your reverse proxy or API gateway (see Workarounds).\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for \u003ccode\u003ePOST\u003c/code\u003e requests to \u003ccode\u003e/mcp-rest/test/connection\u003c/code\u003e and \u003ccode\u003e/mcp-rest/test/tools/list\u003c/code\u003e endpoints, looking for suspicious \u003ccode\u003ecommand\u003c/code\u003e, \u003ccode\u003eargs\u003c/code\u003e, and \u003ccode\u003eenv\u003c/code\u003e parameters in the request body (see rules below).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-litellm-rce/","summary":"Authenticated users with low-privilege API keys could execute arbitrary commands on the host running LiteLLM via the `/mcp-rest/test/connection` and `/mcp-rest/test/tools/list` endpoints, by submitting a server configuration including command execution parameters.","title":"LiteLLM Authenticated Command Execution via MCP stdio Test Endpoints","url":"https://feed.craftedsignal.io/briefs/2024-01-litellm-rce/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["ckan"],"_cs_severities":["high"],"_cs_tags":["ckan","sql-injection","vulnerability"],"_cs_type":"advisory","_cs_vendors":["pip"],"content_html":"\u003cp\u003eA critical SQL injection vulnerability exists within the \u003ccode\u003edatastore_search_sql\u003c/code\u003e function of CKAN, an open-source data management system. This vulnerability allows unauthenticated attackers to inject arbitrary SQL queries, potentially leading to unauthorized access to sensitive data, including private resources and PostgreSQL system information. The vulnerability affects CKAN versions prior to 2.10.10 and versions 2.11.0 up to and including 2.11.4.  Successful exploitation can compromise the confidentiality and integrity of the CKAN instance and its underlying database. The issue was reported by Arvin Shivram of Brutecat Security and patched in CKAN versions 2.10.10 and 2.11.5.  Organizations using vulnerable versions of CKAN are at risk of data breaches and unauthorized access to critical system information.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a CKAN instance running a vulnerable version (prior to 2.10.10 or 2.11.0-2.11.4).\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious HTTP request targeting the \u003ccode\u003edatastore_search_sql\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe malicious request contains a SQL injection payload within the parameters expected by \u003ccode\u003edatastore_search_sql\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eCKAN\u0026rsquo;s \u003ccode\u003edatastore_search_sql\u003c/code\u003e function fails to properly sanitize the input, allowing the injected SQL code to be executed against the PostgreSQL database.\u003c/li\u003e\n\u003cli\u003eThe injected SQL query retrieves sensitive data, such as private resource information, user credentials, or PostgreSQL system details.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts the compromised data from the HTTP response.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the compromised credentials to gain further access to the CKAN instance and its associated systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this SQL injection vulnerability can lead to unauthorized access to sensitive data stored within the CKAN DataStore, including private resources and user credentials. Attackers can also gain access to PostgreSQL system information, potentially leading to further system compromise. The number of affected organizations is unknown, but any organization running a vulnerable version of CKAN is at risk. If successful, the attack can lead to data breaches, financial losses, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade CKAN instances to version 2.10.10 or 2.11.5 to remediate CVE-2026-42031.\u003c/li\u003e\n\u003cli\u003eAs a temporary workaround, disable the DataStore SQL search by setting \u003ccode\u003eckan.datastore.sqlsearch.enabled = false\u003c/code\u003e in the CKAN configuration, as mentioned in the overview.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for suspicious requests targeting the \u003ccode\u003edatastore_search_sql\u003c/code\u003e endpoint, looking for SQL syntax within the query parameters using the Sigma rules provided below.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-ckan-sql-injection/","summary":"An unauthenticated SQL injection vulnerability in CKAN's `datastore_search_sql` function allows attackers to access private resources and PostgreSQL system information, affecting versions prior to 2.10.10 and versions 2.11.0 through 2.11.4.","title":"CKAN Unauthenticated SQL Injection in datastore_search_sql","url":"https://feed.craftedsignal.io/briefs/2024-01-ckan-sql-injection/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2025-62373"}],"_cs_exploited":false,"_cs_products":["pipecat-ai"],"_cs_severities":["critical"],"_cs_tags":["remote code execution","deserialization","pipecat"],"_cs_type":"advisory","_cs_vendors":["pip"],"content_html":"\u003cp\u003eA critical vulnerability (CVE-2025-62373) exists in Pipecat\u0026rsquo;s \u003ccode\u003eLivekitFrameSerializer\u003c/code\u003e, an optional, non-default, and now deprecated frame serializer class intended for LiveKit integration. The \u003ccode\u003edeserialize()\u003c/code\u003e method in \u003ccode\u003esrc/pipecat/serializers/livekit.py\u003c/code\u003e uses Python\u0026rsquo;s \u003ccode\u003epickle.loads()\u003c/code\u003e on data received from WebSocket clients without validation or sanitization. This allows a malicious WebSocket client to send a crafted pickle payload to execute arbitrary code on the Pipecat server. While \u003ccode\u003eLivekitFrameSerializer\u003c/code\u003e is not enabled by default and was deprecated in version 0.0.90 in favor of the safer \u003ccode\u003eLiveKitTransport\u003c/code\u003e method, it remains in the codebase and could be inadvertently used, posing a severe risk if a Pipecat server is configured to use it and is listening on an external interface.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies a Pipecat server with an exposed WebSocket endpoint (e.g., listening on 0.0.0.0:8765) using the vulnerable \u003ccode\u003eLivekitFrameSerializer\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious Python pickle payload. This payload contains instructions to execute arbitrary code on the server, using techniques like defining a class with a \u003ccode\u003e__reduce__\u003c/code\u003e method that calls \u003ccode\u003eos.system()\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAttacker establishes a WebSocket connection to the Pipecat server.\u003c/li\u003e\n\u003cli\u003eAttacker sends the crafted pickle payload as a WebSocket message to the server.\u003c/li\u003e\n\u003cli\u003eThe Pipecat server receives the message and passes the data to the \u003ccode\u003eLivekitFrameSerializer.deserialize()\u003c/code\u003e method.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003edeserialize()\u003c/code\u003e method calls \u003ccode\u003epickle.loads()\u003c/code\u003e on the attacker-controlled data without proper validation.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003epickle.loads()\u003c/code\u003e deserializes the malicious pickle object, triggering the execution of the attacker\u0026rsquo;s code on the server with the privileges of the Pipecat process.\u003c/li\u003e\n\u003cli\u003eAttacker achieves remote code execution, potentially leading to full compromise of the server, including data exfiltration, malware installation, or pivoting to other systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability, CVE-2025-62373, allows an attacker to achieve remote code execution on the Pipecat server. If an application uses \u003ccode\u003eLivekitFrameSerializer\u003c/code\u003e and exposes the Pipecat WebSocket server to untrusted networks, an attacker can completely compromise the server. This could lead to the execution of operating system commands, data modification, malware installation, or pivoting to other systems. The vulnerability is critical because any code execution flaw in a real-time communications server context poses a high risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately stop using the \u003ccode\u003eLivekitFrameSerializer\u003c/code\u003e due to its use of unsafe pickle deserialization. Migrate to the recommended \u003ccode\u003eLiveKitTransport\u003c/code\u003e or other secure methods provided by the Pipecat framework (see Overview).\u003c/li\u003e\n\u003cli\u003eUpdate Pipecat to a version \u0026gt;= 0.0.94 to receive the deprecation warning.\u003c/li\u003e\n\u003cli\u003eIf you must support LiveKit integration or binary frame serialization, use safer alternatives like JSON, Protocol Buffers, or MessagePack.\u003c/li\u003e\n\u003cli\u003eBind the Pipecat service to localhost (127.0.0.1) whenever possible to prevent external network access as mentioned in the Overview.\u003c/li\u003e\n\u003cli\u003eImplement authentication and authorization on the WebSocket connection to restrict who can send data to the server, as described in the Mitigation section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T10:00:00Z","date_published":"2024-01-02T10:00:00Z","id":"/briefs/2024-01-pipecat-rce/","summary":"A critical vulnerability, CVE-2025-62373, exists in Pipecat's LivekitFrameSerializer where the deserialize() method uses Python's pickle.loads() on WebSocket data without validation, allowing a malicious WebSocket client to execute arbitrary code on the Pipecat server if LivekitFrameSerializer is explicitly enabled.","title":"Pipecat Remote Code Execution via Pickle Deserialization in LivekitFrameSerializer","url":"https://feed.craftedsignal.io/briefs/2024-01-pipecat-rce/"}],"language":"en","title":"CraftedSignal Threat Feed — Pip","version":"https://jsonfeed.org/version/1.1"}