CVE-2026-38526 in Krayin CRM Enables RCE

CVE-2026-38526 is a critical authenticated remote code execution (RCE) vulnerability affecting Webkul Krayin CRM / Krayin Laravel CRM v2.2.x. The issue is in the admin-side TinyMCE media upload feature and allows a logged-in user to upload a server-executable file, such as PHP, and then execute it via a normal web request. A public proof of concept is available, and patch details were not clearly published at the time of reporting.

This post explains what is vulnerable, how exploitation works at a high level, what is known about active exploitation, and what defenders should do immediately.

What Is CVE-2026-38526?

CVE-2026-38526 is an authenticated arbitrary file upload vulnerability that can lead directly to remote code execution. It is commonly mapped to CWE-434 (Unrestricted Upload of File with Dangerous Type).

Details of CVE-2026-38526 (SOCRadar Vulnerability Intelligence)

The reported CVSS score is 9.9 (Critical) with a vector indicating network reachability, low complexity, and only low privileges required: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. In practical terms, a low-privilege authenticated user who can reach the vulnerable upload endpoint may be able to move from basic access to code execution on the CRM server.

Which Krayin CRM Versions Are Affected?

The vulnerable product line is Webkul Krayin CRM (krayin/laravel-crm) v2.2.x.

The vulnerable functionality is tied to the admin interface’s TinyMCE integration. Advisory material points to the TinyMCE upload handler implemented in:

• packages/Webkul/Admin/src/Http/Controllers/TinyMCEController.php

If you run Krayin CRM 2.2.x and the admin panel is reachable by users beyond a tightly controlled admin group, treat this as a high-priority risk.

Where Is the Vulnerable Endpoint?

The exposed attack surface is the TinyMCE media upload handler:

• POST /admin/tinymce/upload

This endpoint accepts media uploads for rich text editing in the admin UI. The core problem is that the server-side logic reportedly does not enforce a strict allowlist for safe file types and stores uploads in a location that is reachable over HTTP.

That matters because uploads become dangerous when the server can interpret the uploaded content. Here, an attacker can upload a PHP file and then request it directly, causing the server to execute the code.

Is There a Public PoC or Confirmed Exploitation?

A Proof of Concept (PoC) exploit for CVE-2026-38526 is available on GitHub, demonstrating the vulnerable request structure and an example PHP snippet to confirm execution. It is presented as educational, but it still lowers the barrier for adaptation into more operational tooling.

What is not confirmed from the available sources:

• No confirmed exploitation in the wild was identified.
• There is no confirmed threat actor attribution tied to CVE-2026-38526.
• There is no indication that the vulnerability appears in a government known-exploited catalog.

Even so, a working PoC plus a high-impact outcome (RCE) is often enough to drive attacker interest, especially when the affected service is internet-exposed.

In fact, threat actors have started circulating the exploit in Dark Web forums, where a post has been observed sharing a proof-of-concept exploit link alongside a Shodan dork (http.html:”krayin crm” port:80,443) designed to help attackers enumerate publicly exposed Krayin CRM instances, effectively lowering the barrier for widespread exploitation.

A threat actor has shared the public PoC for CVE-2026-38526

How Does Exploitation Work in Practice?

Exploitation follows a standard file upload to code-execution pattern, with one key constraint: the attacker needs to be authenticated.

High-level exploit flow:

1. Authenticate to Krayin CRM with a valid account session.
2. Upload a PHP payload via multipart/form-data to POST /admin/tinymce/upload. The public PoC shows an attacker can spoof the upload part’s Content-Type (for example, claiming an image MIME type) to make it look more like a normal upload.
3. The server responds with a JSON object containing a file location/URL for the uploaded content, shown in examples under a path like /storage/media/uploads/….
4. The attacker sends an HTTP GET request to that location, and the server executes the uploaded PHP code.

The PoC demonstrates code execution in the context of the web server user (for example, www-data), which is typically enough to read application configuration, access secrets, and pivot further depending on how the server is deployed.

What Should Defenders Do Now to Reduce Risk?

Patch guidance was unclear in the available reporting, so focus on reducing exploitability and tightening access while you confirm a fixed version from the vendor or upstream project.

Contain the upload-to-RCE path

• Disable PHP execution in upload directories, especially paths used for TinyMCE uploads (for example, directories under /storage/media/uploads/). Enforce this at the web server layer (nginx location rules or Apache configuration) so even an uploaded .php cannot execute.
• Store uploads outside the web root and serve them through an application handler that enforces safe content types.

Reduce who can hit the endpoint

• Audit access control for /admin/tinymce/upload. If low-privilege authenticated users can access it, restrict it to trusted admin roles only.
• If feasible, limit admin panel exposure to internal networks, VPN, or an allowlisted management subnet.

Improve detection and response readiness

• Monitor for POST requests to /admin/tinymce/upload, especially from unusual accounts or IPs.
• Alert on newly created .php files (and other executable extensions) in upload directories.
• Review web logs for GET requests to unexpected scripts living under upload paths.

Validate the remediation path

• Confirm whether a fixed release exists beyond v2.2.x or as a 2.2.x point update, then plan an upgrade and verification cycle.
• After mitigation changes, test that uploading a file cannot result in server-side execution, even if the file is reachable.

How Can SOCRadar Help?

To help your organization respond more effectively, SOCRadar Cyber Threat Intelligence can support vulnerability tracking by monitoring exploit availability, attacker activity, and broader developments that may raise the urgency of a flaw. If internet exposure is part of the risk, SOCRadar Attack Surface Management can also help your team identify exposed assets and reduce unnecessary external access before attackers take advantage of it.

SOCRadar’s Vulnerability Intelligence: Track the latest CVEs, updates & exploits

What Open Questions Should Security Teams Track?

A few items remain unresolved based on public details:

• Fixed version or patch commit information was not clearly published.
• Real-world exploitation status is unconfirmed, and defenders should watch for future updates that change prioritization.
• Role gating varies by deployment, so teams should validate which user roles can access the TinyMCE upload feature in their environment.

For organizations running Krayin CRM v2.2.x, the immediate priority is to treat file upload paths as potentially executable until proven otherwise, restrict access to the upload endpoint, and implement web server controls that prevent uploaded scripts from running.