CVE-2026-38930

RapidCMS v1.3.1 Authentication Bypass Vulnerability

Overview

• CVE ID: CVE-2026-38930
• Vendor: OpenRapid
• Product: RapidCMS
• Version: v1.3.1
• Vulnerability Type: Incorrect Access Control
• Affected Component: /template/default/menu.php

Description

RapidCMS v1.3.1 is vulnerable to Authentication Bypass via Cookie Injection in /template/default/menu.php.

An unauthenticated attacker can exploit this vulnerability by sending a specially crafted HTTP Cookie request. Specifically, a SQL injection payload is placed in the name cookie parameter to manipulate the database query result used for authentication. By calculating a matching user cookie value based on the application's internal encode() logic and the injected data, the attacker can successfully bypass the authentication process and gain unauthorized access.

PoC

1. Register an arbitrary user and log in to the website. Then open Developer Tools by pressing F12, navigate to the Application (or Storage) tab, and observe that there are two cookies: user and name .

2. Modify the value of the user cookie to:

   dtGeVsztdCIgYW5kIDAgdW5pb24gc2VsZWN0ICJ0ZXN0IiMO0O0O

   Modify the value of the name cookie to:

   test" and 0 union select "test"#

   After making the changes, refresh the website. The authentication bypass vulnerability will be triggered.

Details

First, I set up the relevant website locally for testing.

Then, I registered a user test with the password test .

Next, we log in with this user. Then, in the browser's F12 Developer Tools (Network tab), we can see the related cookies as shown in the figure below. There are two cookies named name and user. I suspect they are related to authentication.

Therefore, I found the relevant logic in the website source code at /template/default/menu.php .

Through code review and manual testing, we discovered several key pieces of information: First, the value of $_COOKIE["name"] is determined by the username. Second, there is a cookie injection vulnerability at this location, allowing users to control the SQL query by modifying the cookie value, thereby performing SQL injection. This enables control over the SQL query result and, consequently, the parameter pa . Third, the logic of the encode() function can be observed in the code above, and its return value can be directly calculated by running PHP locally.

By piecing together the exploitation logic, an attacker can modify the cookie parameter name to inject SQL payload, control the SQL query to return a specific known string and assign it to parameter pa . Then, using the name cookie value, the pa value, and the known encode() function logic, the attacker calculates the expected value of the user cookie locally. Finally, by setting the user cookie to the calculated value, the attacker bypasses authentication and gains access to the system as a logged-in user.

To verify this, I first set the name cookie value to test" and 0 union select "test"# . By modifying the source code to directly output the value of variable pa on the page, I confirmed that the value of variable pa was successfully changed to test . And we also know that $_COOKIE["name"] = 'test" and 0 union select "test"#' , combining this with the logic of the encode() function, I wrote a short PHP script to locally calculate the value of $_COOKIE["user"] .

<?php
function encode($string = '', $skey = 'cxphp')
        {
            $strArr = str_split(base64_encode($string));
            $strCount = count($strArr);
            foreach (str_split($skey) as $key => $value)
                $key < $strCount && $strArr[$key] .= $value;
            return str_replace(array('=', '+', '/'), array('O0O0O', 'o000o', 'oo00o'), join('', $strArr));
        }
echo(encode('test" and 0 union select "test"#', 'test'));
?>
# dtGeVsztdCIgYW5kIDAgdW5pb24gc2VsZWN0ICJ0ZXN0IiMO0O0O

Then, I set the user cookie to the calculated value. After refreshing the page, the authentication was successfully bypassed, and I logged into the system as the user test" and 0 union select "test"# .