Authenticated Arbitrary File Upload leading to Remote Code Execution Technical analysis and controlled reproduction of CVE-2026-38526 in Webkul Krayin CRM 2.2.x.
Authenticated Arbitrary File Upload leading to Remote Code Execution Technical analysis and controlled reproduction of CVE-2026-38526 in Webkul Krayin CRM 2.2.x.
CVE-2026-38526 is an authenticated arbitrary file upload vulnerability affecting Webkul Krayin CRM 2.2.x.
The vulnerable functionality is exposed through the application's TinyMCE upload endpoint:
POST /admin/tinymce/upload
The application does not sufficiently restrict the type of file that can be uploaded. An authenticated user can submit a file with a server-side executable extension, such as .php. The application stores the uploaded file and returns its accessible URL.
When the deployment allows PHP execution from the upload location the uploaded file can subsequently be requested through the web server, resulting in remote code execution in the context of the web application process.
The published CVE record rates the vulnerability CVSS 3.1: 9.9 (Critical).
This repository contains my own technical analysis and controlled reproduction of the vulnerability.
The vulnerability was already publicly disclosed under CVE-2026-38526. This work does not claim discovery of the vulnerability. The purpose of this research was to understand the vulnerable implementation, reproduce the exploitation path in a controlled environment, and examine the conditions that turn the file-upload issue into remote code execution.
The vulnerability was also used in the Hack The Box GCSB 2026 Nexus machine, which provided a practical environment for studying the issue.
Product: Webkul Krayin CRM Affected versions: 2.2.x Vulnerability: Arbitrary File Upload Resulting impact: Remote Code Execution Authentication: Required Attack vector: Network CWE: CWE-434 — Unrestricted Upload of File with Dangerous Type CVSS: 9.9 Critical CVE: CVE-2026-38526
The vulnerable functionality is handled by:
/admin/tinymce/upload
The endpoint accepts an uploaded file through the file parameter. The relevant application logic derives the stored filename from the original filename and preserves its original extension.
This behavior is important because the application is not simply accepting an uploaded object; it is retaining an attacker controlled executable extension and making the resulting object accessible through the application storage mechanism.
The primary issue is insufficient server-side validation of uploaded files.
The application uses the original client-supplied extension when constructing the stored filename. There is no sufficiently restrictive allowlist preventing executable file types from reaching the storage layer.
The relevant flow is
The use of a generated filename does not address the underlying problem.
For example, changing shell.php into a generated filename such as .php does not make the uploaded file safe if the server continues to interpret .php files as executable PHP code.
An unrestricted upload does not automatically mean remote code execution.
The execution path depends on the servers handling of the uploaded file.
In the vulnerable deployment scenario, the chain becomes
