Vulnerability Report for September 2026

LiteSpeed User-End cPanel Plugin before 2.4.5 allows privilege escalation (possibly to root), as exploited in the wild in May 2026. Detection is best done via a command line of grep -rE "cpanel_jsonapi_func=redisAble" /var/cpanel/logs /usr/local/cpanel/logs/ 2>/dev/null in Bash. If you get no output, you have not been hit with exploitation of the vulnerability. If there is output, we recommend you examine the IP addresses in the list, determine if they are valid IP addresses, and if not, block them. To determine damage done, examine the system logs for use by the detected IP addresses. The issue is related to mishandling of Redis enable/disable features. The recommended minimum version is 2.4.7.

The vulnerability, CVE-2026-49869, describes an unauthenticated remote code execution flaw in Kestra due to an authentication bypass in the AuthenticationFilter. The core issue was that the AuthenticationFilter used request.getPath().endsWith("/configs") to whitelist a public configuration endpoint. This suffix match was too broad, allowing any API path ending in /configs to bypass authentication. An attacker could exploit this to create and execute arbitrary workflows, leading to RCE.

By analyzing the GitHub advisory (GHSA-5vc5-wxxq-3fjx) and the commit 2475839f6859bd4ae7952bff2c252668320cfda5 (which explicitly states 'fix(auth): potential authentication bypass in the authentication filter'), the changes in webserver/src/main/java/io/kestra/webserver/filter/AuthenticationFilter.java were identified. Specifically, the doFilter method was modified. The vulnerable endsWith("/configs") check was replaced with a precise "/api/v1/configs".equals(normalizedPath) check, along with the introduction of a normalizePath helper function to handle path variations. This change directly addresses the authentication bypass by ensuring only the intended exact path is whitelisted.

The secondary impact of SSRF via HttpFunction.java is a consequence of the authentication bypass, as the HttpFunction itself lacks URI filtering. However, the primary vulnerability enabling unauthenticated exploitation is the flaw in AuthenticationFilter.doFilter.

The vulnerability, CVE-2026-75650 (StyleSmuggler), is described as an 'Improper Neutralization of Special Elements Used in a Template Engine' in Adobe Commerce, leading to arbitrary code execution. Analysis of the Sansec report indicates that attackers inject malicious PHP code into Magento's template system, specifically leveraging 'styles' properties to bypass existing safeguards. This injected code is then executed when Magento renders a template, with 'failed payment emails' being a confirmed trigger.

Without direct access to the patch file (VULN-39341-composer-patches.zip), the identification of vulnerable functions relies on inferring from the detailed description of the attack vector and Magento's architecture. The two functions identified, Magento\Email\Model\Template::getProcessedTemplate and Magento\Framework\View\TemplateEngine\Php::render, are central to email template processing and the underlying PHP template rendering, respectively.

getProcessedTemplate is implicated because it's responsible for combining template content with dynamic data, including potentially malicious 'styles' properties, before rendering. If sanitization is insufficient at this stage, the malicious input proceeds. render is the ultimate execution point for PHP code within templates. Therefore, during an exploitation, the malicious payload would flow through getProcessedTemplate (or a similar email template processing function) and eventually be executed by render within the template engine. The confidence is low due to the absence of the actual patch to confirm the exact lines of code modified, but these functions represent the most probable points of failure based on the vulnerability description.

The analysis for CVE-2026-85706 focused on identifying vulnerable functions based on the vulnerability description and available exploit code. The CVE describes an 'Improper Limitation of a Pathname to a Restricted Directory (Path Traversal)' and 'missing authentication enforcement in the repository commits API' in GitLab.

Initial attempts to find direct commit information from GitLab work items and HackerOne reports were unsuccessful due to lack of specific links or rate-limiting. A Google search for the CVE led to several security advisories and, crucially, public exploit code on GitHub.

Examination of the Python exploit code (from guneykabel and solivaquaant) revealed the exact API endpoints and parameters used to trigger the vulnerability. The exploits target POST requests to /api/v4/projects/{id}/repository/commits and POST/PUT requests to /api/v4/projects/{id}/repository/files/{fp}. In both cases, a file.path parameter is used to specify the target file for path traversal.

Given that GitLab is a Ruby on Rails application, these API endpoints are handled by controller actions. The naming convention suggests controllers like API::V4::Projects::Repository::CommitsController and API::V4::Projects::Repository::FilesController. The POST requests would typically map to a create action, and PUT requests to an update action.

The core of the vulnerability lies in two aspects: 1. Missing Authentication: The identified controller actions were accessible to unauthenticated users, allowing them to initiate the file reading process. 2. Improper Path Confinement: Within these actions, the file.path parameter, supplied by the attacker, was used to construct file paths without proper sanitization or validation, enabling path traversal to arbitrary files on the server.

Therefore, the functions identified are the specific controller actions that serve as the entry points for these vulnerable API calls, as they are where both the lack of authentication and the processing of the malicious path input occur.

The vulnerability CVE-2026-84869 affects the ScreenConnect client, allowing unauthorized file transfer and execution. The provided reference URLs, including the GitHub advisory and ConnectWise security bulletins, describe the nature of the vulnerability and state that it is resolved in ScreenConnect version 26.6.5 and later. The description indicates that 'file-transfer actions could be processed through an active remote session without proper authorization or Host confirmation.' This points to a lack of authorization checks within the client's file transfer handling mechanism. However, ScreenConnect is a commercial product, and its source code is not publicly available. Without access to the specific code changes or commit diffs that constitute the patch for version 26.6.5, it is impossible to identify the exact function names, their file paths, or provide specific patch evidence as required. The available information is high-level and does not detail the implementation specifics of the vulnerability or its fix.

The analysis of the provided security advisory and the associated commits (470d34b1de87d901bd9135564d5ee18c0d339e82 and d7bc52beeadff4be5f5690de4d5de42abd10affe) points directly to the ApplyDiffPatch function in services/repository/files/patch.go as the source of the vulnerability. The vulnerability description explicitly mentions that the diffpatch endpoint is abused by applying patches in a 'shared bare temporary clone'. The patch diff confirms this was the case. The original code called t.Clone(ctx, opts.OldBranch, true), where the true argument indicates a bare clone. The fix changes this to false and adds a comment explaining why a bare repository is dangerous in this context. This allowed an attacker to write a malicious git hook into the .git/hooks directory, which would then be executed by the git process, resulting in remote code execution. The vulnerable function is therefore services/repository/files.ApplyDiffPatch as it was responsible for this insecure sequence of operations.

The vulnerability is a classic authentication bypass in the web application's request handling logic. PaperCut uses the Apache Tapestry framework, and the exploit leverages a weakness in how 'complex-direct' requests are handled. The application correctly checks for authentication on the page being rendered to the user but fails to check authentication for the backend component being invoked. This allows an unauthenticated attacker to call administrative functions by routing their request through a public page. The exploit specifically targets the 'ConfigEditor' to modify the 'external user lookup' settings to point to a malicious JDBC URL. Then, by triggering a user search via the 'UserList' page, the application attempts to connect to the malicious database, leading to remote code execution. The vulnerable functions are therefore the administrative components that can be accessed without authentication and the database connection function that is subsequently abused.

JFrog Artifactory contains an authentication weakness that, under default configuration, may allow an unauthenticated attacker with network access to obtain

Improper input validation vulnerability in Citrix NetScaler ADC and Citrix NetScaler Gateway.

This issue affects ADC: before 14.1-73.37, before 13.1-64.23, before 14.1-73.37 FIPS, and before 13.1.37.279 FIPS and NDcPP; Gateway: before 14.1-73.37 and before 13.1-64.23 leading to an unauthenticated attacker to execute arbitrary commands.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Drupal Drupal core allows SQL Injection.

This issue affects Drupal core: from 8.9.0 before 10.4.10, from 10.5.0 before 10.5.10, from 10.6.0 before 10.6.9, from 11.0.0 before 11.1.10, from 11.2.0 before 11.2.12, from 11.3.0 before 11.3.10.