Python
CVE-2026-40320
MEDIUM
GHSA-7xjm-g8f4-rp26
Severity by source
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
Lifecycle Timeline
5DescriptionGitHub Advisory
Summary
The ConformityCheck class in giskard-checks rendered the rule parameter through Jinja2's default Template() constructor. Because the rule string is silently interpreted as a Jinja2 template, a developer may not realize that template expressions embedded in rule definitions are evaluated at runtime. In a scenario where check definitions are loaded from an untrusted source (e.g. a shared project file or externally contributed configuration), this could lead to arbitrary code execution.
giskard-checks is a local developer testing library with no network-facing service. Check definitions, including the rule parameter, are provided in application code or project configuration files and executed locally. Exploitation requires write access to a check definition and subsequent execution of the test suite by a developer.
However, the implicit template evaluation of the rule parameter is not obvious from the API surface. This hidden behavior increases the likelihood of a developer inadvertently passing untrusted input to it when integrating the library into a larger system.
Affected Component
conformity.py, line 59:
from jinja2 import Template
...
formatted_rule = Template(self.rule).render(trace=trace)Affected Versions
giskard-checks < 1.0.2b1
Patched Version
giskard-checks >= 1.0.2b1 (template parsing removed from rule evaluation entirely)
Remediation
Upgrade to giskard-checks >= 1.0.2b1. The template rendering has been removed from rule evaluation.
Credit
Giskard-AI thanks @dhabaleshwar for identifying the unsandboxed template usage.
AnalysisAI
Remote code execution in giskard-checks through server-side template injection (SSTI) in the ConformityCheck class allows arbitrary Python code execution when the rule parameter is processed via unsandboxed Jinja2 template rendering. Affected versions prior to 1.0.2b1 silently interpret rule strings as Jinja2 templates, enabling attackers with write access to check definitions or configuration files to inject malicious template expressions that execute during test suite execution. Exploitation requires local file write access and subsequent developer execution of the test suite, but the implicit template evaluation increases risk when untrusted check definitions are integrated from shared projects or external sources.
Technical ContextAI
giskard-checks is a Python library for model validation that uses Jinja2 templating for rule evaluation. The vulnerability exists in the ConformityCheck class (conformity.py, line 59) where the rule parameter is passed directly to Jinja2's Template() constructor without explicit opt-in or documentation. Jinja2 templates support full expression evaluation including access to Python built-ins and imported modules, allowing template injection payloads like {{ __import__('os').system('command') }} to execute arbitrary code. The root cause is CWE-1336 (Improper Neutralization of Special Elements used in a Template Engine), a variant of CWE-94 (Improper Control of Generation of Code). The library interprets developer-provided configuration as code without clear boundaries or sandboxing, and the implicit nature of this behavior means developers integrating the library may not realize untrusted input could be exploited.
RemediationAI
Upgrade giskard-checks to version 1.0.2b1 or later immediately. The patch removes Jinja2 template processing from the rule evaluation entirely, eliminating the injection vector. For users unable to upgrade immediately, do not load check definitions from untrusted sources (e.g., user-contributed configuration files, pull requests from unknown contributors, or externally hosted project files); restrict write access to check definition files and review any recent changes before running tests. The vendor advisory at https://github.com/advisories/GHSA-7xjm-g8f4-rp26 provides additional context and confirms the fix.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Share
External POC / Exploit Code
Leaving vuln.today