CVE-2026-40320
Arbitrary Code Execution via Jinja2 Template Injection in Giskard
Publication date: 2026-04-17
Last updated on: 2026-04-24
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| giskard | giskard | to 1.0.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-1336 | The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the Giskard open-source testing framework for AI models, specifically in versions prior to 1.0.2b1. The issue is in the ConformityCheck class, which uses Jinja2's default Template() constructor to render the rule parameter. This causes template expressions to be interpreted silently at runtime. If an attacker has write access to a check definition and can insert a crafted rule string from an untrusted source, they could execute arbitrary code when the test suite runs.
The vulnerability has been fixed in giskard-checks version 1.0.2b1.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, upgrade giskard-checks to version 1.0.2b1 or later, where the issue has been fixed.
Additionally, restrict write access to check definitions to trusted users only, as exploitation requires write access and execution of the test suite.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the Giskard testing framework versions prior to 1.0.2b1 where the ConformityCheck class uses Jinja2's default Template() constructor to render the rule parameter, allowing arbitrary code execution if untrusted check definitions are loaded.
Detection requires verifying if your system is running a vulnerable version of giskard-checks (prior to 1.0.2b1) and if any check definitions have been modified or loaded from untrusted sources.
Since no specific detection commands or network indicators are provided in the available information, general steps include:
- Check the installed version of giskard-checks to confirm if it is older than 1.0.2b1.
- Audit check definition files for unexpected modifications or untrusted sources.
- Review logs or execution traces for suspicious activity during test suite runs.
No specific commands for detection are provided in the available context or resources.
How can this vulnerability impact me? :
If exploited, this vulnerability allows an attacker with write access to a check definition to execute arbitrary code on the system running the Giskard test suite. This could lead to unauthorized actions such as data manipulation, system compromise, or disruption of AI model testing processes.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in Giskard's ConformityCheck class allows for arbitrary code execution if an attacker has write access to a check definition and can execute the test suite. This could potentially lead to unauthorized access or manipulation of data processed by the AI models tested with this framework.
Such unauthorized code execution and potential data compromise may impact compliance with standards and regulations like GDPR and HIPAA, which require protection of sensitive data and prevention of unauthorized access.
However, the specific effects on compliance depend on the context in which Giskard is used, the nature of the data involved, and the security controls in place.