Executive Summary

CVE-2026-4830 is a vulnerability in kodbox, an open-source web file management application. It affects the function Add in the file app/controller/explorer/userShare.class.php, specifically in the Public Share Handler component.

The vulnerability allows an attacker to perform an unrestricted upload of files remotely without authentication. This happens because kodbox allows administrators to create public share links that point directly to the real filesystem root (such as the web server root directory) and enable upload and edit permissions on these shares.

An attacker who obtains the share link's hash can upload arbitrary files, including malicious PHP scripts, to the web root via a public upload endpoint. Since there is no server-side validation blocking dangerous file types, these uploaded PHP files can be executed immediately by accessing them through HTTP, leading to remote code execution with the web server's privileges.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability CVE-2026-4830 allows unauthenticated remote code execution and arbitrary file uploads to the web root, which can lead to unauthorized access to sensitive application files and credentials.

Such unauthorized access and potential data breaches could negatively impact compliance with common standards and regulations like GDPR and HIPAA, which require protection of sensitive data and prevention of unauthorized access.

Specifically, the ability for attackers to deploy persistent webshells and backdoors increases the risk of data exposure, manipulation, or loss, which are critical concerns under these regulations.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have severe impacts including:

• Pre-authentication remote code execution on the server with web server user privileges.
• Arbitrary file creation and modification in the web root and other writable directories.
• Deployment of persistent webshells and backdoors, allowing attackers to maintain long-term access.
• Access to sensitive application files and credentials stored on the server.
• Breaking the intended security boundary between administrative share creation and anonymous user access, significantly expanding the attack surface.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by checking for the presence of public editable share links that allow unauthenticated PHP file uploads directly into the web root. Specifically, look for shares created with parameters such as isLink=1 pointing to real filesystem or web root paths, and with upload/edit permissions enabled.

You can attempt to detect if the vulnerable endpoints are accessible and if unauthorized uploads are possible by testing the following endpoints:

• POST /?explorer/userShare/add&accessToken=<token> — to check if public shares can be created pointing to real paths.
• POST /?explorer/share/fileUpload — to test if unauthenticated file uploads are accepted.
• GET /share_shell.php?cmd=id — to verify if an uploaded PHP webshell can be executed.

Suggested commands for detection might include using curl or similar tools to test these endpoints, for example:

• curl -X POST 'http://target/?explorer/share/fileUpload' -F '[email protected]' — to test file upload capability.
• curl 'http://target/share_shell.php?cmd=id' — to check if uploaded PHP files can be executed.

Additionally, review server logs for suspicious POST requests to the fileUpload endpoint or creation of public shares with upload/edit permissions on real paths.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include:

• Disallow creation of public shares on real filesystem or web root paths by rejecting share creation requests where isLink=1 and the path resolves to sensitive directories like /var/www/html.
• Restrict upload and edit permissions on shares that point to real paths by enforcing canUpload=0 and canEditSave=0, making such shares read-only and non-public.
• Harden the file upload endpoint by validating that uploads only target controlled virtual storage areas and not the web root or arbitrary IO paths.
• Implement server-side denylist filtering to block dangerous file extensions such as .php, .phtml, .phar, .php3, .php4, .php5, .user.ini, and .htaccess.
• Warn administrators when creating shares on real paths with upload/edit enabled and log all creation, deletion, and upload attempts on such shares including IP addresses and filenames.
• As a defense in depth measure, separate user-upload directories from PHP-executable web roots and configure the web server to disable PHP execution in upload directories (e.g., using php_admin_value engine off).

Useful 0 Not Useful 0