CVE-2026-31843: Laravel pay-uz Package RCE Vulnerability

CVE-2026-31843 Overview

The goodoneuz/pay-uz Laravel package (versions <= 2.2.24) contains a critical remote code execution vulnerability in the /payment/api/editable/update endpoint. This vulnerability allows unauthenticated attackers to overwrite existing PHP payment hook files, which are subsequently executed during normal payment processing workflows. The endpoint is exposed via Route::any() without any authentication middleware, enabling remote access without credentials. User-controlled input is directly written into executable PHP files using file_put_contents(), and these files are later executed via require(), resulting in complete remote code execution under default application behavior.

Critical Impact

Unauthenticated remote code execution allows attackers to gain complete control over affected Laravel applications, potentially compromising payment data, user credentials, and entire server infrastructure.

Affected Products

• goodoneuz/pay-uz Laravel package version 2.2.24 and earlier
• Laravel applications integrating the pay-uz payment processing package

Discovery Timeline

• April 16, 2026 - CVE CVE-2026-31843 published to NVD
• April 16, 2026 - Last updated in NVD database

Technical Details for CVE-2026-31843

Vulnerability Analysis

This vulnerability represents a severe case of improper access control (CWE-284) combined with arbitrary file write capabilities leading to remote code execution. The vulnerability exists in the /payment/api/editable/update endpoint within the ApiController.php file. The endpoint accepts unauthenticated requests and processes user-supplied input that is written directly to PHP files on the filesystem.

The attack chain consists of three critical security failures: First, the routing configuration in web.php uses Route::any() to expose the vulnerable endpoint without any authentication middleware. Second, the controller accepts user input without proper validation or sanitization. Third, this input is written to executable PHP files using file_put_contents() with no restrictions on the content.

During normal payment processing workflows, the application executes these hook files using PHP's require() function. This means any malicious PHP code injected by an attacker will be executed with the same privileges as the web application, typically enabling full server compromise.

The vendor's documentation references a payment secret token as a security mechanism, but this token is unrelated to the vulnerable endpoint and provides no protection against exploitation.

Root Cause

The root cause of this vulnerability is the complete absence of authentication and authorization controls on a sensitive administrative endpoint. The Route::any() configuration in the package's routing file exposes the update endpoint to all HTTP methods without requiring any form of authentication. Combined with the direct use of file_put_contents() to write user-controlled input to PHP files, this creates a trivially exploitable code injection vulnerability.

Attack Vector

An attacker can exploit this vulnerability by sending a crafted HTTP request to the /payment/api/editable/update endpoint. The attack requires no authentication and can be performed remotely over the network. The attacker supplies malicious PHP code in the request body, which is written to a payment hook file. When the payment processing workflow is triggered—either by the attacker or through normal application use—the malicious code is executed via require().

The vulnerability is particularly dangerous because:

1. The endpoint is accessible without any credentials
2. No input validation is performed on the submitted content
3. The written files are automatically executed during payment processing
4. Successful exploitation grants the attacker full control over the application server

For technical implementation details, refer to the GitHub ApiController Source Code and GitHub Web Routes Source Code.

Detection Methods for CVE-2026-31843

Indicators of Compromise

• Unexpected HTTP requests to /payment/api/editable/update endpoint in web server access logs
• Modified PHP files in the payment hooks directory with unexpected content or recent timestamps
• Unusual PHP processes or shell commands spawned by the web server user
• New or unfamiliar files appearing in the application directory structure
• Web shell activity or reverse shell connections originating from the application server

Detection Strategies

• Monitor web server logs for requests to /payment/api/editable/update from external or unexpected IP addresses
• Implement file integrity monitoring on all PHP files within the payment package directory
• Deploy web application firewall (WAF) rules to detect and block requests containing PHP code patterns in POST bodies
• Use runtime application self-protection (RASP) to detect unauthorized file writes to PHP files

Monitoring Recommendations

• Enable detailed logging for the Laravel application to capture all requests to payment-related endpoints
• Configure alerting for any modifications to files within the vendor/goodoneuz/pay-uz directory
• Implement network-level monitoring for outbound connections from the web server to detect reverse shells
• Review server access logs regularly for requests to the vulnerable endpoint pattern

How to Mitigate CVE-2026-31843

Immediate Actions Required

• Remove or disable the goodoneuz/pay-uz package from production environments until a patched version is available
• Block access to the /payment/api/editable/update endpoint at the web server or WAF level
• Audit existing payment hook files for unauthorized modifications or malicious code
• Review system logs for evidence of prior exploitation attempts

Patch Information

At the time of publication, no official patch has been released by the vendor. Organizations should monitor the Packagist Package Information and GitHub Repository Overview for updates. Consider migrating to an alternative payment integration package if a patch is not released promptly.

Workarounds

• Add authentication middleware to the vulnerable route by overriding the package's route definitions in your application
• Implement IP-based access restrictions to limit access to the endpoint from trusted sources only
• Use .htaccess or nginx configuration to deny all external access to the /payment/api/editable path
• Deploy application-level firewall rules to reject requests containing PHP code patterns

# Nginx configuration to block access to vulnerable endpoint
location ~* ^/payment/api/editable {
    deny all;
    return 403;
}