Vulnerability Report for July 2026

The vulnerability is a Server-Side Template Injection (SSTI) within the Jupyter Enterprise Gateway. The root cause lies in the _determine_kernel_pod_name function of the KubernetesProcessProxy class, located in enterprise_gateway/services/processproxies/k8s.py. This function processes the KERNEL_POD_NAME environment variable, which can be controlled by a user making an API request to start a new kernel. The vulnerable version of the code directly used the Jinja2 template engine to render this variable without any sanitization. An attacker could provide a malicious payload like {{ cycler.__init__.__globals__.os.popen("hostname").read() }} as the value for KERNEL_POD_NAME. The render method would execute this payload, allowing for remote code execution in the context of the Enterprise Gateway pod. The security patch (commit 1e6b2f35497682e6581c48cc6d273644d32ab89e) addresses this by removing the direct use of the Jinja2 rendering engine and replacing it with a custom, safer function (_safe_template_substitute) that uses a regular expression to perform simple variable substitution, explicitly preventing the evaluation of complex expressions, function calls, or attribute access, thus mitigating the SSTI vulnerability.

The vulnerability is a classic remote code execution caused by improper input validation. User-controlled input, specifically the functionName and variableName parameters in JSON scripts, is directly concatenated into a string that is later executed as JavaScript code by a Node.js child process. The analysis of the patches between the vulnerable version (7.1.8) and the fixed version (7.1.9) confirms this. The core of the fix is the introduction of validation functions, assertValidJsIdentifier and assertValidShellApiFunctionName, which are applied to the user-controlled parameters before they are used in code generation. The vulnerable functions identified are the entry points that receive the malicious data (runners.start, runners.loadReader) and the functions that are directly involved in the insecure code generation (ScriptWriter.assignCore, compileShellApiFunctionName, ScriptWriterEval.assign). An attacker exploiting this vulnerability would cause these functions to appear in a runtime profile.

The analysis of the provided security advisory and the associated patch commit 3356b86a8bfab3f960aa420310ebff765df9dede clearly indicates that the vulnerability is located in the generateCronTriggerCronJobSpec function within the pkg/platform/kube/functionres/lazy.go file. The vulnerability stems from the improper construction of a shell command that is used to create a Kubernetes CronJob. The function takes unsanitized user input from the event.headers and event.body of a cron trigger and includes it in a curl command string. This string is then executed by /bin/sh -c. The patch rectifies this by removing the shell (/bin/sh -c) entirely and instead building an argument list for curl to be executed directly. This prevents any user-supplied data from being interpreted as shell commands. Therefore, the generateCronTriggerCronJobSpec function is the exact location of the vulnerability.

The vulnerability is a PHP Object Injection in the ps_facetedsearch module of PrestaShop. The analysis of the security advisory and the associated patch commit 9ca839fac68a60641d8187a3ff9730ab09af33cb confirms that the vulnerability is located in the getFromCache method of the PrestaShop\Module\FacetedSearch\Filters\Block class. The method insecurely deserializes cached data using unserialize(). An attacker can craft a malicious payload in the search filter parameters of a URL, which then gets stored in the cache. When the getFromCache function is executed, it deserializes this payload, leading to the execution of arbitrary code. The patch mitigates this by replacing the call to unserialize() with Tools::unSerialize(), which is a safer alternative that validates the serialized data.

The vulnerability exists in two locations within the langroid library where the eval() function is used to execute code derived from user input. The advisory points out that TableChatAgent.pandas_eval and a function in VectorStore (which the patch reveals to be VectorStore.compute_from_docs) are affected. The core of the vulnerability is that eval() was called with an empty locals dictionary ({}), which was intended to act as a sandbox. However, the globals dictionary passed to eval() was not sanitized. When Python's eval() does not find a __builtins__ key in the globals dictionary, it automatically injects the full builtins module, which includes dangerous functions like __import__, open, and exec. An attacker could craft input that causes the Large Language Model (LLM) to generate Python code containing a payload like __import__('os').system('command'). This payload would then be executed by eval(), resulting in Remote Code Execution (RCE) on the host system. The patch addresses this by introducing a new function, safe_eval_globals, which creates a globals dictionary with a heavily restricted __builtins__ set, removing access to these dangerous functions.

The vulnerability is an authentication bypass in Pheditor's forced password-change mechanism. The root cause lies in the main script, pheditor.php, where the application checks if the instance is still using the default password ('admin'). The original code, if (PASSWORD == hash('sha512', 'admin')), only verified the stored password hash, but critically, it did not validate the password provided by the user in the $_POST['pheditor_password'] field. This flaw allows an attacker to send any non-empty password to the login form. If the server still has the default password, the check passes, and the attacker is presented with the password change form, allowing them to set a new password and gain administrative access without ever knowing the original one. The fixing commit 0978bcda644832b67357340e2f271e32d86fdf86 addresses this by adding a check to ensure the submitted password's hash matches the stored password hash: if (PASSWORD == hash('sha512', 'admin') && $submitted_hash === PASSWORD). Since the vulnerable logic is in the global scope of pheditor.php and not within a defined function, the file itself is the runtime indicator.

The vulnerability exists in the NunjucksRenderer.render function within @prompty/core. The function directly rendered Nunjucks templates without sanitizing the input data or restricting the execution environment. This allowed for Server-Side Template Injection (SSTI), enabling an attacker to execute arbitrary JavaScript code by accessing and manipulating object prototypes through crafted template syntax. The provided patch addresses this by introducing several security controls:

1. Input Sanitization: A new sanitizeInputs function recursively cleans the data passed to the template, removing any properties that are not own-properties and preventing prototype traversal.
2. Safe Member Lookup: A safeMemberLookup function is injected into the Nunjucks runtime to explicitly block access to sensitive properties like __proto__, constructor, and prototype.
3. Disabled Template Function Calls: A safeCallWrap function is used to completely disable the ability to call functions from within the template.

The render method was modified to use a new renderSafely function, which orchestrates these security measures before rendering the template. The vulnerable function is NunjucksRenderer.render as it was the entry point for the untrusted data into the template engine.

The vulnerability in Rancher Fleet (GHSA-xr65-5cpm-g36x) allowed for cross-namespace secret and configmap disclosure. This was due to the Helm deployer using the Fleet controller's own privileged Kubernetes client when processing valuesFrom references in GitRepo or HelmOp resources. An attacker could craft a resource that referenced a secret in any namespace, and the controller would fetch and expose its contents.

The root cause was traced to the internal/helmdeployer package. Specifically, the getValues function used the controller's client instead of a client scoped to the permissions of the service account specified for the deployment. The fix, identified in commit 190f2815a2f6bb208d7ffd3b7da1c9f942716cc0, involved a chain of modifications:

1. The createCfg function was updated to accept a RESTClientGetter, allowing it to create Helm configurations with specific, non-privileged credentials.
2. The install function was changed to generate a correctly-scoped Kubernetes client based on the deployment's serviceAccount.
3. The getValues function was modified to use this passed-in, scoped client for all Kubernetes API calls, thereby enforcing RBAC policies correctly.

A new Policy custom resource was introduced as a defense-in-depth measure, allowing administrators to define explicit restrictions on what resources can be accessed. However, the core vulnerability fix was the correct scoping of the client used for valuesFrom lookups.

The vulnerability is a SQL injection in the FacturaScripts REST API. The root cause is in the FacturaScripts\Core\Where::sqlColumn function, which improperly handles field names containing parentheses, bypassing SQL escaping. This flaw is exploitable through the API because several getWhereValues functions in API controllers (APIModel, ApiAttachedFiles, ApiProductoImagen) did not validate the filter parameter from user requests. An attacker could craft a malicious filter key with parentheses to inject arbitrary SQL, as demonstrated by the provided PoC. The identified patch, commit 03e282e88b8a0ae1a639c878469d040729f344e2, mitigates the vulnerability by adding strict validation to the getWhereValues functions, ensuring that only valid column names are processed. This prevents malicious input from reaching the vulnerable sqlColumn function through the API.