September 2026 | SECaaS Platform AIONCLOUD

[2026.09] Threat Intelligence Report

Status of High-Risk Vulnerabilities No. Vulnerability No. (CVE) Content CVSS Risk Level 1 CVE-2026-72898 Metabase Unauthenticated SQL Injection 10 CRITICAL 2 CVE-2026-58231 SAP Commerce Cloud Unauthenticated Code Injection 10 CRITICAL 3 CVE-2026-48362 Adobe ColdFusion OS Command Injection 10 CRITICAL 4 CVE-2026-18051 W3 Total Cache Unauthenticated Arbitrary File Write 10 CRITICAL 5 CVE-2026-74253 Joomla Sourcerer Unauthenticated Read more about [2026.09] Threat Intelligence Report[…]

[2026.09 Vulnerability Report] Adobe Commerce RCE (CVE-2026-75650)

CVE-2026-75650, dubbed “StyleSmuggler,” is a maximum-severity (CVSS 10.0) unauthenticated Remote Code Execution vulnerability in Adobe Commerce, Adobe Commerce B2B, and Magento Open Source. An attacker injects malicious PHP code through the template engine’s `styles` property—which bypasses all built-in security validation—causing it to be written to disk and later executed when Magento’s dependency-injection scanner processes a “Payment Transaction Failed” email template. No authentication, no user interaction, and no email delivery are required for code execution. Active exploitation was confirmed in the wild on September 4, 2026, three days before Adobe released the emergency hotfix (APSB26-146), making this a true zero-day. Observed post-exploitation activities include the deployment of a Rust-based Linux backdoor disguised as a system process and PHP web shells. The vulnerability has been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog, and the MONITORAPP TA team has confirmed that AIWAAP can detect the malicious template injection payload in HTTP traffic. Tags: CVE-2026-75650, StyleSmuggler, Adobe Commerce, Magento, Template Injection, CWE-1336, RCE, Zero-Day, CVSS 10.0, CISA KEV, Rust Backdoor, Web Shell, T1190, September 2026, Actively Exploited — 1. Overview Read more about [2026.09 Vulnerability Report] Adobe Commerce RCE (CVE-2026-75650)[…]

[2026.09 Vulnerability Report] FuelCMS Remote Code Execution (CVE-2026-30457)

This is a Remote Code Execution (RCE) vulnerability found in FuelCMS. An attacker can execute arbitrary code by sending malicious PHP code via the `data` parameter of the `/fuel//preview?module=blocks&field=view` endpoint. Although the vulnerability was reported to the vendor, no patch has been released yet. AIWAAP plans to address this issue with the “2342 / Daylight Studio FuelCMS Remote Code Execution” pattern, which will be included in the September 2026 pattern update. Tags: CVE-2026-30457, FuelCMS, Daylight Studio, Dwoo, PHP Code Execution, Remote Code Execution, Code Injection — 1. Overview FuelCMS (Daylight Studio) is an open-source content management system (CMS) based on PHP CodeIgniter that provides functionality for managing content such as pages, blocks, and navigation. This report summarizes the analysis of the CVE-2026-30457 vulnerability discovered in FuelCMS. — 2. Attack Vector This vulnerability allows an attacker to execute arbitrary PHP code by exploiting a validation flaw in the Dwoo template parser—which is designed to prevent the injection of malicious PHP code into FuelCMS—specifically a failure to validate backslash characters, thereby bypassing the Dwoo string constraints. An attacker /fuel//preview?module=blocks&field=view send malicious PHP code containing backslashes via the endpoint’s `data` parameter, thereby bypassing the Dwoo template parser to execute the code. For example, if the string `{assign(aaa\ ‘bbb’)}` is sent in the `data` parameter, the backslash escapes the single quote (`’`) in the string, causing the safe value “’aaa\’“ to be expanded to “’aaa\’, ‘“, and the subsequent string “bbb” is interpreted as a T_STRING object, recognized as PHP code, and executed. Attack Request: POST /fuel//preview?module=blocks&field=view HTTP/1.1 Content-Length: 167 Content-Type: multipart/form-data; boundary=PieBoundary123456789012345678901234567 Host: www.test.com User-Agent: HTTPie –PieBoundary123456789012345678901234567 Content-Disposition: form-data; name=”data” {assign(aaa\’. die(`id`));//’)} –PieBoundary123456789012345678901234567– — 3. Mitigation Measures FuelCMS has not been updated for approximately four years. Although Pentest-Tools, the research team that discovered this vulnerability, reported it, no related patch had been released as of September 23, 2026. At AIWAAP, we plan to address this issue with the “2342 / Daylight Studio FuelCMS Remote Code Execution” pattern, which Read more about [2026.09 Vulnerability Report] FuelCMS Remote Code Execution (CVE-2026-30457)[…]

[2026.09 Vulnerability Report] Analysis of GitLab Unauthenticated Arbitrary File Read Vulnerability (CVE-2026-85706)

CVE-2026-85706 is a critical path traversal vulnerability (CWE-22) found in the widely used DevOps platforms GitLab Community Edition (CE) and Enterprise Edition (EE). Remote attackers can read arbitrary local files accessible to the GitLab server process by sending specially crafted HTTP(S) API requests without requiring authentication. This vulnerability stems from insufficient file path validation and missing authentication checks within the GitLab Repository Commits API. A successful attack could expose sensitive server-side information—such as system settings, GitLab configuration files, secrets, database credentials, and SSH keys—potentially leading to further system compromise through the use of leaked credentials or encryption keys. In particular, the exposure of core internal secrets, such as secret\_key\_base, could enable session forgery and privilege escalation, thereby expanding the scope of the impact across the entire GitLab environment. This vulnerability has been assigned the maximum CVSS v3.1 score of 10.0 (Critical); CISA confirmed active exploitation in September 2026 and added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog. Tags: gitlab, cve-2026-85706 — 1. Overview CVE-2026-85706 is a severe path traversal (CWE-22) vulnerability discovered in GitLab Community Edition (CE) and Enterprise Edition (EE), widely used DevOps platforms. A remote attacker can send a maliciously crafted HTTP(S) API request without any authentication to read arbitrary local files accessible to the GitLab server process. This vulnerability arises from insufficient file path validation and missing authentication checks in the GitLab Repository Commits API. A successful attack could expose critical internal server information, such as system configuration files, GitLab configuration files, secrets, database credentials, and SSH keys, and could lead to further system compromises using leaked credentials or encryption keys. In particular, if core GitLab secrets—such as `secret_key_base`—are exposed, session forgery and privilege escalation become possible, potentially expanding the scope of damage across the entire GitLab environment. This vulnerability was rated 10.0 (Critical)—the highest score under CVSS v3.1—and CISA confirmed its exploitation in September 2026, adding it to the Known Exploited Vulnerabilities (KEV) catalog. — 2. Cause This vulnerability arises from a combination of two flaws: the GitLab Repository Commits API references user-supplied paths without validation, and the file-handling logic executes before authentication checks. The interaction of these two flaws allows an unauthenticated remote attacker to read arbitrary files on the server. 2-1. Insufficient File Path Validation The GitLab Repository Commits API references the `file.path` value provided by the client when processing files to be included in a commit. In the normal processing flow, GitLab Workhorse stores the uploaded file as a temporary file and sets the path to that value. However, the API does not verify whether the path passed via `file.path` is located within an allowed repository or the temporary file area. Consequently, if an attacker directly specifies an absolute path on the server in the request, GitLab will open and process the file specified by the attacker—located on the server—instead of the intended upload file. 2-2. Issue with Authentication Check Order In the vulnerable API processing flow, user authentication checks are performed after file processing. In other words, the system first opens and reads the file at the path specified in the request before verifying whether the requester is an authenticated user. Due to this sequence, even requests without a valid user session or access token pass through the file-reading stage before being blocked by the authentication check. Consequently, an attacker can reach the vulnerable file-processing logic without a separate account or prior permissions. 2-3. Combination of the Two Flaws Although the two flaws described above do not constitute complete vulnerabilities on their own, when they coexist, they lead to unauthenticated file reading through the following processing flow. An attacker sends a request containing a manipulated path GitLab opens and reads the file without validating the path Although authentication checks are performed after the file is read, the file has already been read Under certain conditions, part or all of the read file’s contents are returned via the API response If path validation had been in place, the request would have been blocked in Step 2; if authentication checks had been performed first, it would have been blocked in an earlier step. However, because these two flaws overlap, the request is not filtered out at any point and leads to file exposure. — 3. Key Attack Process The attack flow exploiting CVE-2026-85706 proceeds as follows. While this vulnerability itself is limited to read-only access, it can escalate to subsequent attacks through exposed credentials. Scanning for Target Instances and Accessing Vulnerable APIs: The attacker scans for GitLab Self-Managed instances exposed to the internet to identify vulnerable versions. They then target public projects that can be read anonymously—without requiring a separate user login or access token—and access the Repository Commits API and Files API (POST /api/v4/projects/{id}/repository/commits, POST/PUT …/repository/files/{file_path}). Sending Malicious API Requests via File Path Manipulation: The attacker specifies an arbitrary local file path on the server—rather than a legitimate upload path—in the request’s `file.path` parameter. In the normal processing flow, GitLab Workhorse overwrites this value with a safe temporary file path; however, the attacker bypasses Workhorse’s preprocessing by percent-encoding static segments of the URL path (e.g., representing the “c” in “commits” as %63) and passes the forged `file.path` value directly to the Rails handler. Targeted files may include system configuration files, GitLab configuration files, and secret information. Loading Internal Server Files and Information Disclosure: A vulnerable GitLab server reads the local file with GitLab process privileges before performing authentication checks, without verifying whether the provided file path exists within an allowed directory. Subsequently, if a parsing error occurs while the file contents are being processed as request parameters, part or all of the file’s contents may be included in the error response and exposed to the attacker. Follow-up Attacks and System Compromise Based on Stolen Information: An attacker can analyze the exposed GitLab configuration information, database credentials, secret keys, or other authentication information to carry out further attacks. In particular, if critical secret information—such as `secret_key_base`—is exposed, this could escalate to session or credential forgery, account takeover, or the acquisition of administrative privileges. Furthermore, there is a possibility that the stolen credentials could be used to exploit features such as CI/CD pipelines or Runners, leading to remote code execution (RCE) and server takeover. — 4. Impact CVE-2026-85706 is a critical vulnerability rated 10.0 (Critical) under CVSS v3.1, the highest possible score. Since it allows access to files within the GitLab server without additional authentication, the impact can extend beyond simple information exposure to account compromise, privilege escalation, and compromise of the CI/CD environment. Leakage of Core Server Confidential Information and Secrets: Attackers can steal sensitive information—such as system configuration files, GitLab secrets, database credentials, SSH keys, deployment tokens, and CI/CD variables—that are accessible with GitLab server process privileges. In particular, if the /etc/gitlab/gitlab-secrets.json file—which is specifically targeted by the publicly available exploit code—is exposed, the encryption keys contained in this file could be used to decrypt other secrets stored by GitLab, potentially leading to a cascading increase in damage. Potential for Follow-up Attacks and System Compromise: Leaked secret keys, authentication information, or database credentials serve as the foundation for additional attacks, such as account takeover, session spoofing, and access to internal services. As a result, the scope of the breach may extend beyond the exposure of a single file to encompass the entire GitLab server and its associated internal infrastructure. It is important to note that while the patch blocks future file reads, it does not invalidate secrets that have already been leaked; therefore, the risk persists until potentially exposed credentials are revoked and reissued. Compromise of CI/CD Supply Chain Integrity: Since GitLab is used as a core platform for source code management and build and deployment automation, if an attacker gains control of a repository or CI/CD pipeline, the attack can escalate into a software supply chain attack, including source code tampering, modification of deployment scripts, credential theft, and tampering with build artifacts. Confirmed Exploitation (CISA KEV Listing): On September 11, 2026, CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities (KEV) catalog and required federal agencies to complete remedial actions by September 14. Security firm watchTower reported observing scans across the internet beginning at 06:00 (UTC) on September 11 and subsequently confirmed that activity had progressed beyond simple detection to actual exploitation and the exfiltration of sensitive files. According to data compiled by the ShadowServer Foundation, as of the time of this report, thousands of exposed servers remain vulnerable, and vulnerable versions of GitLab Self-Managed environments exposed to the internet face a widespread risk of exploitation. — 5. Mitigation Measures Since CVE-2026-85706 is a Critical-rated vulnerability currently being exploited in real-world attacks, organizations operating GitLab Self-Managed environments must prioritize applying the official security patch. 5-1. Security Patches and Version Updates Upgrade immediately to the official security update version provided by GitLab. The fix versions for each affected version are as follows. GitLab 19.3.x users: Update to 19.3.2 or later GitLab 19.2.x users: Update to version 19.2.6 or later GitLab 18.7–19.1.x users: Update to version 19.1.8 or later Read more about [2026.09 Vulnerability Report] Analysis of GitLab Unauthenticated Arbitrary File Read Vulnerability (CVE-2026-85706)[…]

[2026.08] Threat Intelligence Report

Status of High-Risk Vulnerabilities No. Vulnerability No. (CVE) Content CVSS Risk Level 1CVE-2026-48276Adobe ColdFusion Arbitrary File Upload RCE10CRITICAL 2CVE-2026-48286Adobe Campaign Classic Authorization Bypass RCE10CRITICAL 3CVE-2026-10134IBM Langflow OSS Code Injection10CRITICAL 4CVE-2026-50160Hoppscotch Mass Assignment Authentication Bypass10CRITICAL 5CVE-2026-48316Adobe ColdFusion Improper Input Validation RCE10CRITICAL 6CVE-2026-57572Crawl4AI Docker API Argument Injection RCE10CRITICAL 7CVE-2026-15409SonicWall SMA1000 Server-Side Request Forgery10CRITICAL 8CVE-2026-16812Arista VeloCloud Orchestrator On-Prem Read more about [2026.08] Threat Intelligence Report[…]