Author Archives: CERT

Overview

UEFI firmware applications DTBios and BiosFlashShell from DTResearch contain a vulnerability that allows Secure Boot to be bypassed using a specially crafted NVRAM variable. The vulnerability stems from improper handling of a runtime NVRAM variable that enables an arbitrary write primitive, capable of modifying critical firmware structures, including the global Security2 Architectural Protocol used for Secure Boot verification.. Because the affected applications are signed by the Microsoft UEFI Certificate Authority, this vulnerability can be exploited on any UEFI-compliant system, allowing unsigned code to run during the boot process.

Description

Unified Extensible Firmware Interface (UEFI) defines a modern firmware architecture that facilitates interaction between a computer’s hardware and its operating system during early boot. When a UEFI-compliant system starts, UEFI applications and drivers are executed to initialize the system and hand off control to the operating system (OS) loader. These UEFI applications must be signed and verified for execution under Secure Boot. These signatures can originate from the OEM or from entries in the system’s signature database (DB), which commonly includes the Microsoft UEFI Certificate Authority (CA).

UEFI defines extensible NVRAM variables that store configuration, device customization, and runtime context shared across UEFI applications and the operating system. A vulnerability was identified in a Microsoft-signed UEFI application that uses the NVRAM variable IhisiParamBuffer as a pointer for memory operations, including overwriting the critical global security parameter gSecurity2 . This allows bypassing Security2 Architectural Protocol-based verification , enabling the execution of any unsigned UEFI binaries irresepective of UEFI Secure Boot settings.

In some implementations, IhisiParamBuffer is locked early during boot, preventing modification at runtime. However, as Binarly observed, the vulnerability can be exploited in environments where the IhisiParamBuffer NVRAM variable is not locked and remains writable at runtime. In such cases, attackers can bring and execute the vulnerable UEFI application even on systems with Secure Boot enabled—using a Bring Your Own Vulnerable Driver (BYOVD) approach. Initially the vulnerability was reported on DTResearch’s Dtbios application version 71.22 for 64-bit architecture, however Microsoft has further identified that this vulnerability is present in both DtBios and BiosFlashShell on multiple versions. A total of 14 hashes have been added to the Forbidden Signature Database (DBX or Revocation List) to address these various binaries.

To mitigate this vulnerability, affected UEFI modules must be updated via vendor-provided software. Additionally, all UEFI-compliant system owners should update their Secure Boot Forbidden Signature Database (DBX or Revocation List), which is available via OEM updates, Microsoft, or the Linux Vendor Firmware Service (LVFS).

Impact

An attacker with the ability to modify the IhisiParamBuffer NVRAM variable can use it to perform arbitrary memory writes, enabling a Secure Boot bypass during early boot. This allows unsigned or malicious code to run before the OS loads, potentially installing persistent malware or kernel rootkits that survive reboots and OS reinstallations. Because this attack occurs before OS-level security tools initialize, it can evade detection by endpoint detection and response (EDR) systems. In some cases, it can even entirely disable EDR systems by modifying low-level interfaces before they load.

Solution

Apply a Patch

Multiple vendors have released software updates to address this vulnerability and prevent potential exploitation. Please refer to the Vendor Information section for applicable updates. Microsoft has also indicated they will release an updated DBX (Revocation List) file to prevent vulnerable components from being executed under Secure Boot. Windows Users can further use Check-UEFISecureBootVariables PowerShell scripts to verify whether the latest DBX updates can be applied. For Linux users, LVFS has released a blog article to detail revocation list updates through the Linux tools provided by the fwupd project.

Recommendations for Enterprises and Developers

Changes to the DBX (Forbidden Signature Database) may cause system boot failures if not carefully managed. Vendors should thoroughly test updates to ensure system stability. In some cases, it may be necessary to update the DB (Signature Database) before updating the DBX, as described in Microsoft’s KB5025885. Enterprises and cloud providers managing broad deployments of systems should prioritize these updates and confirm DBX revocation is enforced, particularly in virtualized environments, to block unauthorized UEFI binaries during early boot phases.

Acknowledgements

Thanks to Binarly REsearch team for the responsible disclosure of this vulnerability to CERT/CC. Thanks also to Microsoft and various vendors for their collaboration and timely response. This document was written by Vijay Sarvepalli.

Continue reading VU#806555: A Vulnerability in UEFI Applications allows for secure boot bypass via misused NVRAM variable→

Overview

An out-of-bounds (OOB) read vulnerability has been identified in the Trusted Platform Module (TPM) 2.0 reference library specification, currently at Level 00, Revision 01.83 (March 2024). An attacker with access to a TPM command interface can exploit this vulnerability by sending specially crafted commands, potentially leading to unauthorized access to sensitive data or denial of service of the TPM.

Description

Trusted Platform Module (TPM) technology is a hardware-based solution that provides secure cryptographic functions to operating systems on modern computing platforms. Designed to resist tampering, TPM can be implemented as a discrete chip, integrated component, or firmware-based module. Software-based implementations are also available to support the cryptographic needs of cloud and virtualized environments. The Trusted Computing Group (TCG) maintains the TPM specifications and provides a reference implementation to assist vendor adoption.

A Security researcher have discovered an OOB read vulnerability in the CryptHmacSign function of the reference implementation. The issue arises because the reference code did not implement appropriate consistency checks in CryptHmacSign function resulting in potential out-of-bound read. An attacker with access to the TPM interface can exploit this mismatch by submitting a maliciously crafted packet, resulting in an out-of-bounds read from TPM memory, which may expose sensitive data.

Impact

An authenticated local attacker can send malicious commands to a vulnerable TPM interface, resulting in information disclosure or denial of service of the TPM. The impact assessment depends on the vendor specific implementation.

Solution

The TCG has released an errata update to the TPM 2.0 Library Specification and updated the reference implementations to address this vulnerability. Users are strongly encouraged to apply TPM-related firmware updates provided by their hardware or system vendors. Please refer to the Vendor Information section for any specific guidance from affected vendors. TPM2.0 vendors are urged to use the latest specifications and the reference implementation to ensure these vulnerabilities are resolved in their implementations. TCG has published VRT009 advisory and uses VRT0009 to track this advisory.

libtpms open source

See also related CVE-2025-49133 and the patch commit 04b2d8e for the opensource libtpms 0.10.1 released.

Acknowledgements

Thanks to the reporter, who wishes to remain anonymous. This document was written by Vijay Sarvepalli.

Continue reading VU#282450: Out-of-Bounds read vulnerability in TCG TPM2.0 reference implementation→

Overview

A vulnerability in an Insyde H2O UEFI firmware application allows digital certificate injection through an unprotected NVRAM variable. This issue arises from the unsafe use of an NVRAM variable, which is used as trusted storage for a digital certificate in the trust validation chain. An attacker can store their own certificate in this variable and subsequently run arbitrary firmware (signed by the injected certificate) during the early boot process within the UEFI environment.

Description

Unified Extensible Firmware Interface (UEFI) defines a modern firmware architecture that facilitates interaction between a computer’s hardware and its operating system during early boot. When a UEFI-compliant system starts, UEFI applications and drivers are executed to initialize the system and hand off control to the operating system (OS) loader. These UEFI applications must be signed and verified for execution under Secure Boot. These signatures can originate from the OEM or from entries in the system’s signature database (DB), which commonly includes the Microsoft UEFI Certificate Authority (CA).

UEFI defines extensible NVRAM variables that store configuration, device customization, and runtime context shared across UEFI applications and the operating system. A vulnerability was identified in a firmware application due to the use of an untrusted NVRAM variable, SecureFlashCertData, to store and exchange public keys. Because this NVRAM variable is not protected (i.e., not locked), it can be updated at runtime—allowing an attacker to inject their own keys.

As described by the security researcher Nikolaj Schlej

The origin of this vulnerability is the fact that Insyde H2O authors decided to use volatile NVRAM as trusted storage for data exchange between the points of loading the signing certificates from the FW (which can happen in many places in multiple DXE drivers) and verifying the signature of platform tools and update capsules (which happens in a library implementing LoadImage/StartImage pair). Due to use of common library functions (akin LibGetVariable), there’s no way for LoadImage to ensure that the NVRAM variables it consults are indeed volatile and had been previously set by the firmware itself, so hijacking them becomes a trivial “set the very same variables as non-volatile from OS environment”, which the PoC tool performs if ran from Windows Administrator terminal. Any other means to write the same variables to non-volatile NVRAM (i.e. Linux efivars subsystem) will also work the same way.

To mitigate this vulnerability, affected UEFI modules must be updated via vendor-provided firmware updates. Firmware security analysis tools can also inspect affected variables in firmware images to assess exposure to this vulnerability. Note that UEFI variable locking, while supported in some implementations, is currently poorly documented or as it stands unavailable with reference implementations for vendors to adopt.

Impact

An attacker with the ability to modify the SecureFlashCertData NVRAM variable at runtime can use it to inject their digital certificate and bypass Secure Boot. This allows unsigned or malicious code to run before the OS loads, potentially installing persistent malware or kernel rootkits that survive reboots and OS reinstallations. Because this attack occurs before OS-level security tools initialize, it can evade detection by endpoint detection and response (EDR) systems. In some cases, it may even disable EDR systems entirely by modifying low-level interfaces before they load.

Solution

Due to the supply-chain redistribution of this firmware application across multiple Original Device Manufacturers (ODMs) and Original Equipment Manufacturers (OEMs), the vulnerability may be present in multiple PC models. Please check the Vendor Information section for details.

Acknowledgements

Thanks to researcher Nikolaj Schlej for the responsible disclosure of this vulnerability to CERT/CC. Thanks also to Insyde and other vendors for addressing the vulnerability with appropriate actions. This document was written by Vijay Sarvepalli.

Continue reading VU#211341: A vulnerability in Insyde H2O UEFI application allows for digital certificate injection via NVRAM variable→

Overview

A stack overflow vulnerability has been discovered within the libexpat open source library. When parsing XML documents with deeply nested entity references, libexpat can recurse indefinitely. This can result in exhaustion of stack space and a crash. An attacker can weaponize this to either perform denial of service (DoS) attacks or memory corruption attacks, based on the libexpat environment and library usage.

Description

libexpat is an Open Source XML parsing library. It is a stream oriented XML parsing library written in the C programming language. It can be used in particular with large files difficult for processing in RAM. A vulnerability has been discovered, tracked as CVE-2024-8176. The vulnerability description can be observed below.

CVE-2024-8176

A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage.

Impact

An attacker with access to software that uses libexpat could provide a XML document to the program and cause a DoS attack or memory corruption attack. libexpat is used in a variety of different software, and by various companies.

Solution

A patch for the vulnerability has been provided in version 2.7.0 of libexpat. Groups that use libexpat can verify their patch using the POCs provided here: https://github.com/libexpat/libexpat/issues/893#payload_generators

Acknowledgements

This vulnerability was reported to us by the maintainer of the project, Sebastian Pipping, to increase awareness. The vulnerability was originally discovered by Jann Horn of Googles Project Zero. Vendors who wish to join the discussion within VINCE can do so here: https://www.kb.cert.org/vince/. This document was written by Christopher Cullen.

Continue reading VU#760160: libexpat library is vulnerable to DoS attacks through stack overflow→

Overview

The Radware Cloud Web Application Firewall is vulnerable to filter bypass by multiple means. The first is via specially crafted HTTP request and the second being insufficient validation of user-supplied input when processing a special character. An attacker with knowledge of these vulnerabilities can perform additional attacks without interference from the firewall.

Description

The Radware Cloud Web Application Firewall can be bypassed by means of a crafted HTTP request. If random data is included in the HTTP request body with a HTTP GET method, WAF protections may be bypassed. It should be noted that this evasion is only possible for those requests that use the HTTP GET method.

Another way the Radware Cloud WAF can be bypassed is if an attacker adds a special character to the request. The firewall fails to filter these requests and allows for various payloads to reach the underlying web application.

Impact

An attacker with knowledge of these vulnerabilities can bypass filtering. This allows malicious inputs to reach the underlying web application.

Solution

The vulnerabilities appear to be fixed (see reference URL below). Initially Radware did not acknowledge the reporter’s findings when they were first disclosed. As of June 4, 2025, Radware has reached out to the SEI and has stated that Radware acknowledges the vulnerability and appreciates the responsible disclosure. Additionally, Radware has fixed the issue and published a technical knowledge base article covering the CVE and attributing the discovery to Oriol Gegundez.

Acknowledgements

Thanks to Oriol Gegundez for reporting this issue. This document was written by Kevin Stephens and Ben Koo.

Continue reading VU#722229: Radware Cloud Web Application Firewall Vulnerable to Filter Bypass→

Overview

Digigrams PYKO-OUT audio-over-IP (AoIP) product is used for audio decoding and intended for various uses such as paging, background music, live announcements and others. It has hardware compatibility with two analog mono outputs and a USB port for storing local playlists. The product does not require a password by default, and when opened to the Internet, can allow attackers access to the device, where they can then pivot to attacking adjacent connected devices or compromise the device’s functionality.

Description

Digigram is an audio-based hardware and software vendor, providing various products including sound cards, AoIP gateways, and speaker-related support software. Digigram sells a PYKO-OUT audio-over-IP product that is used for audio decoding and intended for various uses such as paging, background music, and live announcements.

A vulnerability has been discovered within the web-server component of the PYKO-OUT AoIP, where the default configuration does not require any login information or password. This web server spawns on 192.168.0.100 by default. The lack of log-in credentials allows any attacker who discovers the vulnerable IP address of the device to connect and manipulate it, without any authentication or authorization.

An attacker who gains access to the device can access its configuration, control audio outputs and inputs, and potentially pivot to other connected devices, whether this be through network connections, or by placing malicious files in a connected USB device.

Impact

An attacker with access to a vulnerable device can access the devices configuration, control audio-over-IP data streams managed by the device, and pivot to other network and physical connected devices, such as through a connected USB thumb drive.

Solution

Digigram has marked this product as EOL and will not be providing a patch to change the default configuration. Users can alter the password settings within the web server UI and force attempted connections to provide a password. Additionally, the product is no longer being sold by Digigram.

Acknowledgements

Thanks to the reporter, Souvik Kandar. Additional thanks to CERT-FR. This document was written by Christopher Cullen.

Continue reading VU#360686: Digigram PYKO-OUT audio-over-IP (AoIP) does not require a password by default→

Overview

Two systemic jailbreaks, affecting a number of generative AI services, were discovered. These jailbreaks can result in the bypass of safety protocols and allow an attacker to instruct the corresponding LLM to provide illicit or dangerous content. The first jailbreak, called “Inception,” is facilitated through prompting the AI to imagine a fictitious scenario. The scenario can then be adapted to another one, wherein the AI will act as though it does not have safety guardrails. The second jailbreak is facilitated through requesting the AI for information on how not to reply to a specific request.
Both jailbreaks, when provided to multiple AI models, will result in a safety guardrail bypass with almost the exact same syntax. This indicates a systemic weakness within many popular AI systems.

Description

Two systemic jailbreaks, affecting several generative AI services, have been discovered. These jailbreaks, when performed against AI services with the exact same syntax, result in a bypass of safety guardrails on affected systems.

The first jailbreak, facilitated through prompting the AI to imagine a fictitious scenario, can then be adapted to a second scenario within the first one. Continued prompting to the AI within the second scenarios context can result in bypass of safety guardrails and allow the generation of malicious content. This jailbreak, named “Inception” by the reporter, affects the following vendors:

• ChatGPT (OpenAI)
• Claude (Anthropic)
• • Copilot (Microsoft)
• DeepSeek
• Gemini (Google)
• Grok (Twitter/X)
• MetaAI (FaceBook)
• MistralAI

The second jailbreak is facilitated through prompting the AI to answer a question with how it should not reply within a certain context. The AI can then be further prompted with requests to respond as normal, and the attacker can then pivot back and forth between illicit questions that bypass safety guardrails and normal prompts. This jailbreak affects the following vendors:

• ChatGPT
• Claude
• • Copilot
• DeepSeek
• Gemini
• Grok
• MistralAI

Impact

These jailbreaks, while of low severity on their own, bypass the security and safety guidelines of all affected AI services, allowing an attacker to abuse them for instructions to create content on various illicit topics, such as controlled substances, weapons, phishing emails, and malware code generation.
A motivated threat actor could exploit this jailbreak to achieve a variety of malicious actions. The systemic nature of these jailbreaks heightens the risk of such an attack. Additionally, the usage of legitimate services such as those affected by this jailbreak can function as a proxy, hiding a threat actors malicious activity.

Solution

Various affected vendors have provided statements on the issue and have altered services to prevent the jailbreak.

Acknowledgements

Thanks to the reporters, David Kuzsmar, who reported the first jailbreak, and Jacob Liddle, who reported the second jailbreak. This document was written by Christopher Cullen.

Continue reading VU#667211: Various GPT services are vulnerable to two systemic jailbreaks, allows for bypass of safety guardrails→

Overview

PyTorch Lightning versions 2.4.0 and earlier do not use any verification mechanisms to ensure that model files are safe to load before loading them. Users of PyTorch Lightning should use caution when loading models from unknown or unmanaged sources.

Description

PyTorch Lightning, a high-level framework built on top of PyTorch, is designed to streamline deep learning model training, scaling, and deployment. PyTorch Lightning is widely used in AI research and production environments, often integrating with various cloud and distributed computing platforms to manage large-scale machine learning workloads.

PyTorch Lightning contains multiple vulnerabilities related to the deserialization of untrusted data (CWE-502). These vulnerabilities arise from the unsafe use of torch.load(), which is used to deserialize model checkpoints, configurations, and sometimes metadata. While torch.load() provides an optional weights_only=True parameter to mitigate the risks of loading arbitrary code, PyTorch Lightning does not require or enforce this safeguard as a principal security requirement for the product.

Kasimir Schulz of HiddenLayer identified and reported the following five vulnerabilities:

1. The DeepSpeed integration in PyTorch Lightning loads optimizer states and model checkpoints without enforcing safe deserialization practices. It does not validate the integrity or origin of serialized data before passing it to torch.load(), allowing deserialization of arbitrary objects.
2. The PickleSerializer class directly utilizes Python’s pickle module to handle data serialization and deserialization. Since pickle inherently allows execution of embedded code during deserialization, any untrusted or manipulated input processed by this class can introduce security risks.
3. The _load_distributed_checkpoint component is responsible for handling distributed training checkpoints. It processes model state data across multiple nodes, but it does not include safeguards to verify or restrict the content being deserialized.
4. The _lazy_load function is designed to defer loading of model components for efficiency. However, it does not enforce security controls on the serialized input, allowing for the potential deserialization of unverified objects.
5. The Cloud_IO module facilitates storage and retrieval of model files from local and remote sources. It provides multiple deserialization pathways, such as handling files from disk, from remote servers, and from in-memory byte streams, without applying constraints on how the serialized data is interpreted.

Impact

A user could unknowingly load a malicious file from local or remote locations containing embedded code that executes within the system’s context, potentially leading to full system compromise.

Solution

To reduce the risk of deserialization-based vulnerabilities in PyTorch Lightning, users and organizations can implement the following mitigations at the system and operational levels:

1. Verify that files to be loaded are from trusted sources and with valid signatures;
2. Use Sandbox environments to prevent abuse of arbitrary commands when untrusted models or files are being used or tested;
3. Perform static and dynamic analysis of files to be loaded to verify that the ensuing operations will remain restricted to the data processing needs of the environment;
4. Disable unnecessary deserialization features by ensuring that torch.load() is always used with weights_only = True when the files to be loaded are model weights.

We have not received a statement from Lightning AI at this time. Please check the Vendor Information section for updates as they become available.

Acknowledgements

Thanks to the reporter, Kasimir Schulz [kschulz@hiddenlayer.com] from HiddenLayer. Thanks to Matt Churilla for verifying the vulnerabilities. This document was written by Renae Metcalf, Vijay Sarvepalli, and Eric Hatleback.

Continue reading VU#252619: Multiple deserialization vulnerabilities in PyTorch Lightning 2.4.0 and earlier versions→

Overview

The Paragon Software Hard Disk Manager (HDM) product line contains a vulnerable driver titled BioNTdrv.sys. The driver, versions 10.1.X.Y and older, 1.0.0.0, 1.1.0.0, 1.3.0.0, 1.4.0.0, and 1.5.1.0, contain five vulnerabilities. These include arbitrary kernel memory mapping and write vulnerabilities, a null pointer dereference, insecure kernel resource access, and an arbitrary memory move vulnerability. An attacker with local access to a device can exploit these vulnerabilities to escalate privileges or cause a denial-of-service (DoS) scenario on the victim’s machine. Additionally, as the attack involves a Microsoft-signed Driver, an attacker can leverage a Bring Your Own Vulnerable Driver (BYOVD) technique to exploit systems even if Paragon Software products are not installed. Microsoft has observed threat actors (TAs) exploiting this weakness in BYOVD ransomware attacks, specifically using CVE-2025-0289 to achieve privilege escalation to SYSTEM level, then execute further malicious code. These vulnerabilities have been patched by both Paragon Software, and vulnerable BioNTdrv.sys versions blocked by Microsoft’s Vulnerable Driver Blocklist.

Description

The Paragon Software HDM is a series of tools from Paragon Software, available in both Community and Commercial versions, that allows users to manage partitions (individual sections) on a hard drive, create backups, copy drive contents, and wipe disks. These products include a kernel-level driver distributed as BioNTdrv.sys. The driver allows for a low-level access to the hard drive with elevated privileges to access and manage data as the kernel device.

Microsoft researchers have identified five vulnerabilities in Paragon Partition Manager version 17.9.1. These vulnerabilities, particularly in BioNTdrv.sys versions 1.3.0 and 1.5.1, allow attackers to achieve SYSTEM-level privilege escalation, which surpasses typical administrator permissions. The vulnerabilities also enable attackers to manipulate the driver via device-specific Input/Output Control (IOCTL) calls, potentially resulting in privilege escalation or system crashes (e.g., a Blue Screen of Death, or BSOD). Even if Paragon Partition Manager is not installed, attackers can install and misuse the vulnerable driver through the BYOVD method to compromise the target machine. The vulnerabilities are additionally present within versions 10.1.X.Y and older, 1.0.0.0, 1.1.0.0, and 1.4.0.0 of BioNTdrv.sys.

Identified Vulnerabilities:

CVE-2025-0288
Various Paragon Software products contain an arbitrary kernel memory vulnerability within biontdrv.sys, facilitated by the memmove function, which does not validate or sanitize user controlled input, allowing an attacker the ability to write arbitrary kernel memory and perform privilege escalation.

CVE-2025-0287
Various Paragon Software products contain a null pointer dereference vulnerability within biontdrv.sys that is caused by a lack of a valid MasterLrp structure in the input buffer, allowing an attacker to execute arbitrary code in the kernel, facilitating privilege escalation.

CVE-2025-0286
Various Paragon Software products contain an arbitrary kernel memory write vulnerability within biontdrv.sys that is caused by a failure to properly validate the length of user supplied data, which can allow an attacker to execute arbitrary code on the victim machine.

CVE-2025-0289
Various Paragon Software products contain an insecure kernel resource access vulnerability facilitated by the driver not validating the MappedSystemVa pointer before passing it to HalReturnToFirmware, which can allows an attacker the ability to compromise the service.

CVE-2025-0285
Various Paragon Software products contain an arbitrary kernel memory mapping vulnerability within biontdrv.sys that is caused by a failure to properly validate the length of user supplied data, which can allow an attacker to perform privilege escalation exploits.

Impact

An attacker with local access to a target device can exploit specific BioNTdrv.sys versions to escalate privileges to SYSTEM level or cause a DoS scenario. Microsoft has observed this driver being used in ransomware attacks, leveraging the BYOVD technique for privilege escalation prior to further malicious code execution.

Solution

Paragon Software has updated the affected products and released a new driver, BioNTdrv.sys version 2.0.0, which addresses these vulnerabilities. To update your Paragon product, follow the guidance listed here: https://paragon-software.zendesk.com/hc/en-us/articles/32993902732817-IMPORTANT-Paragon-Driver-Security-Patch-for-All-Products-of-Hard-Disk-Manager-Product-Line-Biontdrv-sys. Users can verify if their Vulnerable Driver Block list is enabled under Windows Security settings. On Windows 11 devices, this block list is enabled by default. Users can learn more about the Vulnerable Driver Block list here: Microsoft Vulnerable Driver Blocklist Information. Enterprise organizations should ensure the block list is applied for their user base to prevent potential loading of affected vulnerable BioNTdrv.sys versions by TAs. This will not prevent exploitation by TAs who already have administrator access.

Acknowledgements

Thanks to Microsoft for reporting the vulnerability.This document was written by Christopher Cullen.

Continue reading VU#726882: Paragon Software Hard Disk Manager product line contains five memory vulnerabilities within its BioNTdrv.sys driver that allow for privilege escalation and denial-of-service (DoS) attacks→

Overview

PandasAI, an open source project by SinaptikAI, has been found vulnerable to Prompt Injection attacks. An attacker with access to the chat prompt can craft malicious input that is interpreted as code, potentially achieving arbitrary code execution. In response, SinaptikAI has implemented specific security configurations to address this vulnerability.

Description

PandasAI is a Python library that allows users to interact with their data using natural language queries. The library parses these queries into Python or SQL code, leveraging a large language model (LLM) (such as OpenAI’s GPT or similar) to generate explanations, insights, or code. As part of its setup, users import the AI Agent class, instantiate it with their data, and facilitate a connection to the database. Once connected the AI agent can maintain the context throughout the discussion, allowing for ongoing exchanges with the user’s queries as prompts.

A vulnerability was discovered that enables arbitrary Python code execution through prompt injection. Researchers at NVIDIA demonstrated the ability to bypass PandasAI’s restrictions, such as preventing certain module imports, jailbreak protections, and the use of allowed lists. By embedding malicious Python code in various ways via a prompt, attackers can exploit the vulnerability to execute arbitrary code within the context of the process running PandasAI.

This vulnerability arises from the fundamental challenge of maintaining a clear separation between code and data in AI chatbots and agents. In the case of PandasAI, any code generated and executed by the agent is implicitly trusted, allowing attackers with access to the prompt interface to inject malicious Python or SQL code. The security controls of PandasAI (2.4.3 and earlier) fail to distinguish between legitimate and malicious inputs, allowing the attackers to manipulate the system into executing untrusted code, leading to untrusted code execution (RCE), system compromise, or pivoting attacks on connected services. The vulnerability is tracked as CVE-2024-12366. Sinaptik AI has introduced new configuration parameters to address this issue and allow the user to choose appropriate security configuration for their installation and setup.

Impact

An attacker with access to the PandasAI interface can perform prompt injection attacks, instructing the connected LLM to translate malicious natural language inputs into executable Python or SQL code. This could result in arbitrary code execution, enabling attackers to compromise the system running PandasAI or maintain persistence within the environment.

Solution

SinaptikAI has introduced a Security parameter to the configuration file of the PandasAI project. Users can now select one of three security configurations:

1. Standard: Default security settings suitable for most use cases.
2. Advanced: Higher security settings for environments with stricter requirements.
3. None: Disables security features (not recommended).

By choosing the appropriate configuration, users can tailor PandasAI’s security to their specific needs. SinaptikAI has also released a sandbox. More information regarding the sandbox can be found at the appropriate documentation page.

Acknowledgements

Thank you to the reporter, the NVIDIA AI Red Team (Joe Lucas, Becca Lynch, Rich Harang, John Irwin, and Kai Greshake). This document was written by Christopher Cullen.

Continue reading VU#148244: PandasAI interactive prompt function can be exploited to run arbitrary Python code through prompt injection, which can lead to remote code execution (RCE)→