Description

In DocsGPT 0.15.0 and below, the application provides a custom prompt feature that allows users to define prompt content used during chatbot interactions. This functionality renders user-supplied prompt data using Jinja templates without input sanitization or sandboxing. An unauthenticated attacker can inject malicious template expressions, leading to a server-side template injection (SSTI) vulnerability that can be exploited to achieve full remote code execution (RCE).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-04T17:16:56.910Z",
  "pubdate": "2026-09-04T17:16:56.910Z",
  "executiveSummary": "DocsGPT 0.15.0 and earlier versions are susceptible to a critical Server-Side Template Injection (SSTI) vulnerability. The flaw originates from the insecure processing of user-defined custom prompts, which are rendered using the Jinja2 template engine without appropriate sanitization or sandboxing.\nAn unauthenticated attacker can exploit this vulnerability by injecting arbitrary template expressions into the custom prompt fields. Due to the way the application processes these templates, the injected code is executed server-side with the privileges of the application process.\nThe successful exploitation of this vulnerability results in full Remote Code Execution (RCE). This allows an attacker to interact with the underlying operating system, potentially leading to complete system compromise, unauthorized data exfiltration, and lateral movement within the hosting infrastructure. The risk is considered critical, as no authentication or specific user privileges are required to initiate the attack, significantly lowering the barrier for exploitation.",
  "technicalDetails": "The vulnerability resides in the application's handling of user-supplied data within the custom prompt feature. In DocsGPT 0.15.0 and lower, the backend utilizes the Jinja2 template engine to dynamically construct chatbot prompts based on inputs provided by the user.\nThe root cause of the vulnerability is the lack of input validation and the absence of a restrictive sandbox environment during the rendering process. Jinja2 templates are evaluated server-side, and by default, they permit the execution of Python expressions if they are not explicitly restricted via a secure context or sandbox configuration.\nAn attacker can exploit this by crafting a malicious payload formatted as a Jinja2 template expression, such as '{{ self.__init__.__globals__.__builtins__.__import__('os').popen('id').read() }}'. When the application processes the prompt, it evaluates the expression instead of treating it as literal text.\nThe attack flow begins when an attacker submits a crafted custom prompt via the application interface. Upon receipt, the application passes this unvalidated string to the Jinja2 rendering engine. Because the engine is initialized without proper namespace restrictions, the attacker gains access to internal Python objects and methods. This facilitates the instantiation of 'os' or 'subprocess' modules to execute arbitrary system commands.\nSince the application processes these requests without requiring authentication, the attack is fully remotely exploitable over the network. The payload behavior involves escaping the template context to execute commands at the OS level, granting the attacker the same permissions as the application's runtime user. Post-exploitation impact is severe, as the attacker can manipulate files, install persistent backdoors, or compromise internal network segments depending on the server's environment configuration."
}