CVE-2026-57853 in DataGerry
Summary
by MITRE • 11/04/2026
DataGerry before 3.3.0 contains a server-side template injection vulnerability that allows authenticated attackers with base.docapi.template.add permission to store arbitrary Jinja2 payloads in the template_data field via POST /rest/docapi/template, which is later rendered in a non-sandboxed Jinja2 environment when a user calls GET /rest/docapi/template/<id>/render/<object_id>. Attackers can exploit the standard cycler.__init__.__globals__.os gadget chain to execute arbitrary operating system commands as the DataGerry web process user, confirmed as root in default Docker deployments, achieving remote code execution.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
DataGerry versions prior to 3.3.0 are susceptible to a critical server-side template injection vulnerability that facilitates unauthorized remote code execution. This flaw resides within the document API module, specifically affecting how user-supplied data is processed during template rendering operations. The vulnerability allows authenticated attackers who possess the base.docapi.template.add permission to inject malicious Jinja2 payloads into the system by submitting crafted requests to the POST /rest/docapi/template endpoint. These injected payloads are stored in the template_data field without adequate sanitization or validation, creating a persistent threat vector within the application's database and configuration stores.
The exploitation mechanism relies on the subsequent rendering of these templates via the GET /rest/docapi/template//render/ endpoint. When an authorized user triggers this render operation, the system processes the stored data using Jinja2 in a non-sandboxed environment. This lack of sandboxing is pivotal to the severity of the issue, as it removes the protective barriers that typically restrict template engines from accessing sensitive host resources or executing external commands. Consequently, any code embedded within the injected payload is executed with the same privileges as the DataGerry web process itself.
Attackers can leverage specific Python object gadgets to achieve arbitrary command execution. By utilizing the standard cycler._init_._globals_.os gadget chain, which is a well-known technique in Jinja2 exploitation scenarios, adversaries can bypass input restrictions and invoke operating system commands directly. This method allows for precise control over the executed code, enabling actions such as data exfiltration, lateral movement within the network, or complete compromise of the underlying infrastructure. The impact is particularly severe because default Docker deployments often run the application with root privileges, meaning successful exploitation results in full host-level access rather than just process-level compromise.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) and specifically falls under the category of Server-Side Template Injection as defined by common weakness enumerations for web applications. In terms of adversary behavior, it maps to ATT&CK technique T1059 Command and Scripting Interpreter, where attackers use system utilities or scripting languages to execute commands on a compromised host. The attack path also involves initial access through authenticated credentials followed by privilege escalation if the service account is not properly restricted in production environments.
Mitigation strategies must prioritize immediate patching of DataGerry to version 3.3.0 or later, where this vulnerability has been addressed. In addition to upgrading, organizations should enforce strict principle of least privilege for database and application service accounts, ensuring that even if exploitation occurs, the blast radius is limited by running processes under non-root users with minimal permissions. Input validation and output encoding should be implemented rigorously across all API endpoints handling user-generated content. Furthermore, deploying a Web Application Firewall can provide an additional layer of detection and prevention for known template injection patterns, although patching remains the definitive remediation step to eliminate this risk vector entirely.