Description

Polyaxon through 2.16.4 renders operation specification fields with an unsandboxed Jinja2 environment during server-side run preparation, allowing authenticated users to execute arbitrary code. Attackers can submit runs with Jinja2 payloads in queue, namespace, conditions, presets, or dependencies fields to execute operating system commands in the scheduler process context, exposing database credentials and service tokens.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-15T11:17:13.220Z",
  "pubdate": "2026-09-15T11:17:13.220Z",
  "executiveSummary": "Polyaxon versions up to 2.16.4 are susceptible to a critical Remote Code Execution (RCE) vulnerability stemming from improper input validation within the server-side operation preparation logic.\nThe vulnerability arises from the utilization of an unsandboxed Jinja2 templating engine when processing specific operation specification fields. By injecting malicious Jinja2 syntax into these fields, an authenticated user can trigger arbitrary code execution within the context of the scheduler process.\nSuccessful exploitation allows attackers to execute operating system commands with the privileges of the scheduler process. This grants the attacker significant control over the environment, enabling the exfiltration of sensitive information, such as database credentials, service account tokens, and potentially broader system compromise.\nGiven that this attack vector requires authenticated access, the risk is particularly high in multi-tenant environments where internal users or compromised accounts may leverage this functionality to escalate privileges or move laterally within the infrastructure.\nImmediate remediation is necessary, ideally involving an upgrade to a version where the Jinja2 rendering process is properly sandboxed or where input sanitization is strictly enforced before template evaluation.",
  "technicalDetails": "The root cause of this vulnerability is the insecure use of the Jinja2 templating engine during the server-side processing of operation specifications. When a user submits a run, Polyaxon parses the provided operation specification to prepare the environment. If the input contains Jinja2 expressions, the application incorrectly evaluates these expressions within an unsandboxed context, essentially treating user-supplied data as executable code.\nSpecifically, the affected fields include queue, namespace, conditions, presets, and dependencies. These fields are processed by the scheduler, which expects them to be static configurations. By injecting Jinja2 syntax (e.g., {{ ... }}), an attacker can break out of the intended data structure and invoke Python functions or system commands via the Jinja2 environment's capabilities.\nThe attack flow proceeds as follows: First, the attacker must be authenticated to the Polyaxon platform. Second, the attacker crafts a malicious operation request, substituting standard values in one of the vulnerable fields (e.g., 'presets') with a Jinja2 payload designed to execute system commands, such as utilizing the subprocess module or accessing the underlying file system. Third, upon submission, the Polyaxon backend receives the request and triggers the run preparation phase.\nDuring this phase, the application's internal engine parses the operation specification and attempts to render the templated fields. Because the engine is not configured with a restrictive sandbox, the Jinja2 payload is executed with the context and permissions of the scheduler process. This allows for arbitrary OS command injection.\nThe impact of successful exploitation is severe. The attacker operates with the same privilege level as the scheduler service. This typically includes access to sensitive environment variables, database connection strings, API tokens for integrated services, and potential access to the Kubernetes API if the scheduler is configured with a service account possessing wide cluster permissions. Consequently, an attacker can exfiltrate configuration data, manipulate other runs, or further compromise the underlying orchestration environment."
}