The vulnerability stems from Giskard's ConformityCheck class rendering a user-supplied rule string via Jinja2's default Template() constructor without sandboxing. When check definitions are loaded from an untrusted source, a crafted rule string can be interpreted as Jinja2 template code and executed with the process' privileges, allowing an attacker to run arbitrary code. The flaw is a classic unsandboxed template injection, classified as CWE‑1336. The potential impact is that any code injected through the rule parameter will run during test execution, compromising confidentiality, integrity, and availability of the host system.

The affected product is Giskard‑AI's open‑source framework Giskard‑oss. All releases earlier than 1.0.2b1 are vulnerable, because the ConformityCheck class contains the unchecked Jinja2 rendering. Attackers must be able to create or modify check definitions, which are then imported by the test suite as part of normal operation.

The CVSS score of 5.4 indicates a moderate level of severity. No EPSS data is available, and the issue is not listed in CISA's KEV catalog, but the presence of arbitrary code execution makes it a high‑risk vector if an attacker can supply a malicious check. Exploitation requires write access to the location where check definitions are stored and subsequent execution of the test suite. Once those prerequisites are met, the attacker can execute arbitrary code with the same privileges as the test runner. The attack vector is inferred to be local to the machine running Giskard, unless the framework accepts externally provided check definitions through a network channel.