Pip — CraftedSignal Threat Feed

LiteLLM Proxy API Key Verification SQL Injection

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

A 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 Authorization 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 POST /chat/completions, which triggers the vulnerable query through the proxy’s error-handling mechanism. Defenders should prioritize patching to version 1.83.7 or later to mitigate this risk, or implement the suggested workaround.

Attack Chain

The attacker sends a crafted HTTP Authorization header to a LiteLLM API endpoint (e.g., /chat/completions).
The LiteLLM proxy receives the request and extracts the API key from the Authorization header.
Due to insufficient sanitization, the API key value is directly concatenated into a SQL query string.
The vulnerable SQL query is executed against the proxy’s database.
The attacker injects SQL code to read sensitive data, such as user credentials or API keys, from the database.
The attacker may further inject SQL code to modify data, potentially granting themselves administrative privileges or compromising other users’ accounts.
The attacker gains unauthorized access to the LiteLLM proxy.
The attacker leverages the compromised proxy to access and control connected LLMs, exfiltrate data, or disrupt services.

Impact

Successful 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’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.

Recommendation

Upgrade LiteLLM to version 1.83.7 or later to patch the SQL injection vulnerability as detailed in the advisory GHSA-r75f-5x8p-qvmc.
If upgrading is not immediately feasible, set disable_error_logs: true in the general_settings configuration to mitigate the risk as described in the advisory GHSA-r75f-5x8p-qvmc.
Monitor web server logs for suspicious Authorization headers containing SQL injection payloads to detect potential exploitation attempts. Deploy the provided Sigma rule targeting HTTP request patterns.

GitPython Vulnerability Allows Arbitrary Code Execution via Git Hooks

hello@craftedsignal.io — Tue, 23 Jan 2024 12:00:00 +0000

GitPython before version 3.1.47 is susceptible to a command execution vulnerability. The issue stems from how the _clone() function validates the multi_options parameter used in the clone_from(), clone(), or Submodule.update() methods. Specifically, the validation occurs on the original list of options before the shlex.split transformation. This allows an attacker to craft a string like "--branch main --config core.hooksPath=/x" which passes the initial validation because it starts with a safe option (--branch). However, after the string is split into tokens, the --config option becomes active, allowing the attacker to inject a malicious core.hooksPath 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.

Attack Chain

An attacker identifies a vulnerable application using GitPython to clone repositories.
The attacker crafts a malicious string containing a Git configuration option, such as --config core.hooksPath=/path/to/malicious/hooks, embedded within a seemingly benign option string like --branch main --config core.hooksPath=/path/to/malicious/hooks.
The attacker injects this malicious string into the multi_options parameter of the clone_from(), clone(), or Submodule.update() methods.
GitPython’s _clone() function validates the multi_options parameter using Git.check_unsafe_options() before it is processed by shlex.split().
Because the malicious string starts with a safe option (--branch), it bypasses the validation check.
The shlex.split() function then transforms the string into a list of individual options, making the --config option active.
The git clone command is executed with the injected --config core.hooksPath=/path/to/malicious/hooks option, causing Git to use the attacker-controlled directory for Git hooks.
Git executes the malicious hooks (e.g., post-checkout), resulting in arbitrary code execution on the victim’s machine.

Impact

Successful 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 multi_options 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.

Recommendation

Upgrade GitPython to version 3.1.47 or later to patch the vulnerability (Affected Packages).
Implement input validation and sanitization for any user-supplied input used to construct the multi_options parameter to prevent injection of malicious Git configurations (Code).
Monitor process creation events for the execution of unexpected processes from directories specified as core.hooksPath (see Sigma rule Detect Suspicious Git Hook Execution).
Deploy the Sigma rules in this brief to your SIEM and tune for your environment.

GitPython Command Injection Vulnerability

hello@craftedsignal.io — Tue, 09 Jan 2024 10:00:00 +0000

GitPython, 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 Repo.clone_from(), Remote.fetch(), Remote.pull(), and Remote.push(). Specifically, when underscore-form kwargs (e.g., upload_pack) are used, they bypass the intended safety checks designed to prevent the execution of arbitrary commands via Git options like --upload-pack. This occurs because the validation logic only checks for hyphenated forms (e.g., upload-pack). Attackers can exploit this by injecting malicious commands through these kwargs, even when allow_unsafe_options is set to its default value of False. This issue was reported on April 25, 2026.

Attack Chain

An attacker identifies a web application or system that uses GitPython to manage Git repositories.
The attacker finds an endpoint or function where they can control kwargs passed to Repo.clone_from(), Remote.fetch(), Remote.pull(), or Remote.push().
The attacker crafts a malicious payload, using underscore-form kwargs such as upload_pack or receive_pack, setting their value to a command they want to execute (e.g., a shell script path or a direct command).
The application or system, using a vulnerable version of GitPython, receives these kwargs and bypasses the intended safety check.
GitPython’s Git.transform_kwarg() method converts the underscore-form kwargs into their corresponding hyphenated Git options (e.g., upload_pack becomes --upload-pack).
The Git command is executed with the attacker-controlled option, leading to arbitrary command execution on the system.
The attacker gains unauthorized access, potentially stealing credentials, modifying repositories, or moving laterally within the network.

Impact

Successful 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.

Recommendation

Upgrade GitPython to version 3.1.47 or later to remediate the vulnerability (affected_products).
Review code that uses Repo.clone_from(), Remote.fetch(), Remote.pull(), or Remote.push() and ensure that kwargs are properly validated to prevent attacker-controlled input (references).
Implement input validation to block underscore-form kwargs such as upload_pack or receive_pack before they are passed to GitPython functions (references).
Deploy the Sigma rule Detect GitPython Kwarg Command Injection to identify potential exploitation attempts in application logs (rules).

pyp2spec Code Injection Vulnerability

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

pyp2spec, 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’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.

Attack Chain

An attacker crafts a malicious PyPI package containing specially formatted metadata, including an RPM macro directive (e.g., within the package summary).
A Fedora packager, intending to package a legitimate Python package, uses pyp2spec to generate an RPM spec file from the malicious PyPI package.
pyp2spec writes the attacker-controlled metadata, including the unescaped RPM macro directive, into the generated spec file.
The packager, or an automated system, uses an RPM tool like rpmbuild -bs, rpmbuild --nobuild, or rpm -q --specfile to inspect or build the package from the spec file.
The RPM tool parses the spec file and, upon encountering the RPM macro directive, executes the embedded command.
The attacker’s command executes on the build machine, potentially granting the attacker access to the packager’s credentials (dist-git SSH keys, Koji build credentials, Bodhi update credentials).
The attacker uses the compromised credentials to commit malicious source code to the distribution’s Git repository (dist-git).
The malicious code is built and distributed to end users through the normal package update pipeline, resulting in a supply chain attack.

Impact

Successful 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.

Recommendation

Upgrade to pyp2spec version 0.14.1 or later to remediate the code injection vulnerability as described in the advisory (https://github.com/advisories/GHSA-r35x-v8p8-xvhw).
Implement 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.
Monitor process executions originating from RPM tools (rpmbuild, rpm), focusing on unusual or unexpected commands that could indicate exploitation, using process_creation logs and the Sigma rule provided.

LiteLLM Authenticated Command Execution via MCP stdio Test Endpoints

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

LiteLLM versions 1.74.2 through 1.83.6 are vulnerable to authenticated command execution. Two endpoints, POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list, 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 command, args, and env 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 PROXY_ADMIN role for these endpoints.

Attack Chain

Attacker authenticates to the LiteLLM proxy with a valid, but low-privilege, API key.
Attacker crafts a malicious JSON payload containing a server configuration intended for the stdio transport. The payload includes the command, args, and env fields, which specify the command to be executed, its arguments, and environment variables, respectively.
Attacker sends a POST request to either the /mcp-rest/test/connection or /mcp-rest/test/tools/list endpoint, with the malicious JSON payload in the request body.
The LiteLLM proxy receives the request and, due to the vulnerability, attempts to connect to the supplied server configuration.
The proxy spawns the supplied command as a subprocess on the proxy host, using the privileges of the proxy process.
The attacker-supplied command executes arbitrary code on the host.
The attacker gains control of the proxy host with the privileges of the LiteLLM proxy.

Impact

Successful 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.

Recommendation

Upgrade LiteLLM to version 1.83.7 or later to remediate the vulnerability (see Patches).
As a temporary workaround, block POST requests to the /mcp-rest/test/connection and /mcp-rest/test/tools/list endpoints at your reverse proxy or API gateway (see Workarounds).
Monitor web server logs for POST requests to /mcp-rest/test/connection and /mcp-rest/test/tools/list endpoints, looking for suspicious command, args, and env parameters in the request body (see rules below).

CKAN Unauthenticated SQL Injection in datastore_search_sql

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

A critical SQL injection vulnerability exists within the datastore_search_sql 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.

Attack Chain

The attacker identifies a CKAN instance running a vulnerable version (prior to 2.10.10 or 2.11.0-2.11.4).
The attacker crafts a malicious HTTP request targeting the datastore_search_sql endpoint.
The malicious request contains a SQL injection payload within the parameters expected by datastore_search_sql.
CKAN’s datastore_search_sql function fails to properly sanitize the input, allowing the injected SQL code to be executed against the PostgreSQL database.
The injected SQL query retrieves sensitive data, such as private resource information, user credentials, or PostgreSQL system details.
The attacker extracts the compromised data from the HTTP response.
The attacker may use the compromised credentials to gain further access to the CKAN instance and its associated systems.

Impact

Successful 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.

Recommendation

Upgrade CKAN instances to version 2.10.10 or 2.11.5 to remediate CVE-2026-42031.
As a temporary workaround, disable the DataStore SQL search by setting ckan.datastore.sqlsearch.enabled = false in the CKAN configuration, as mentioned in the overview.
Monitor web server logs for suspicious requests targeting the datastore_search_sql endpoint, looking for SQL syntax within the query parameters using the Sigma rules provided below.

Pipecat Remote Code Execution via Pickle Deserialization in LivekitFrameSerializer

hello@craftedsignal.io — Tue, 02 Jan 2024 10:00:00 +0000

A critical vulnerability (CVE-2025-62373) exists in Pipecat’s LivekitFrameSerializer, an optional, non-default, and now deprecated frame serializer class intended for LiveKit integration. The deserialize() method in src/pipecat/serializers/livekit.py uses Python’s pickle.loads() 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 LivekitFrameSerializer is not enabled by default and was deprecated in version 0.0.90 in favor of the safer LiveKitTransport 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.

Attack Chain

Attacker identifies a Pipecat server with an exposed WebSocket endpoint (e.g., listening on 0.0.0.0:8765) using the vulnerable LivekitFrameSerializer.
Attacker 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 __reduce__ method that calls os.system().
Attacker establishes a WebSocket connection to the Pipecat server.
Attacker sends the crafted pickle payload as a WebSocket message to the server.
The Pipecat server receives the message and passes the data to the LivekitFrameSerializer.deserialize() method.
The deserialize() method calls pickle.loads() on the attacker-controlled data without proper validation.
pickle.loads() deserializes the malicious pickle object, triggering the execution of the attacker’s code on the server with the privileges of the Pipecat process.
Attacker achieves remote code execution, potentially leading to full compromise of the server, including data exfiltration, malware installation, or pivoting to other systems.

Impact

Successful exploitation of this vulnerability, CVE-2025-62373, allows an attacker to achieve remote code execution on the Pipecat server. If an application uses LivekitFrameSerializer 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.

Recommendation

Immediately stop using the LivekitFrameSerializer due to its use of unsafe pickle deserialization. Migrate to the recommended LiveKitTransport or other secure methods provided by the Pipecat framework (see Overview).
Update Pipecat to a version >= 0.0.94 to receive the deprecation warning.
If you must support LiveKit integration or binary frame serialization, use safer alternatives like JSON, Protocol Buffers, or MessagePack.
Bind the Pipecat service to localhost (127.0.0.1) whenever possible to prevent external network access as mentioned in the Overview.
Implement authentication and authorization on the WebSocket connection to restrict who can send data to the server, as described in the Mitigation section.