CVE-2026-52778: Unauthenticated Remote Code Execution and ReDoS in YesWiki Bazar Formula Calculator

The vulnerability designated as CVE-2026-52778 represents a critical code execution flaw and a denial-of-service vector within YesWiki, a collaborative wiki platform written in PHP. The vulnerability is located within the Bazar module's mathematical calculation component, specifically implemented in CalcField.php. This component evaluates user-supplied algebraic formulas to dynamically calculate and store values within form entries.

By default, the mathematical execution engine relies on PHP's dynamic interpretation capabilities to process these calculations. Because of this architectural choice, the application attempts to restrict the input characters and functions to prevent arbitrary code execution. The security boundaries of this system depend entirely on a validation mechanism that filters formulas before they are executed.

The validation component utilizes a highly complex, recursive regular expression to verify that inputs contain only permitted numbers, operators, and mathematical functions. However, this implementation is flawed, exposing two primary attack surfaces. First, the regex is susceptible to catastrophic backtracking and stack exhaustion, which causes immediate worker process termination. Second, any parser discrepancy or logical bypass in the validation allows arbitrary PHP strings to reach an active evaluation sink, resulting in complete server compromise.

The primary root cause of the vulnerability is the reliance on a dynamic code evaluation sink, eval(), combined with a complex regular expression for input validation. In tools/bazar/fields/CalcField.php, the function formatValuesBeforeSave($entry) accepts a user-defined formula and evaluates it dynamically. This pattern violates basic secure coding practices by treating untrusted user input as executable instructions rather than purely structured data.

To enforce safety, the application defines a regular expression pattern: /^((' . $number . '|' . $functions . '\s*\((?1)+\)|\((?1)+\))(?:' . $operators . '(?1))?)+$/. The recursive subpattern token (?1)+ instructs the PCRE (Perl Compatible Regular Expressions) engine to evaluate matching groups recursively to validate nested parentheses. In PHP, the PCRE engine allocates memory on the system call stack or the thread stack to handle these recursive operations. If an input contains deeply nested groupings, the engine exhausts the available stack memory, triggering a segmentation fault (SIGSEGV) and crashing the web server worker process.

Furthermore, using a regular expression to sanitize code destined for an evaluation sink is an anti-pattern. There are inherent parser differentials between the PCRE engine and the PHP Zend compiler. Discrepancies in handling multi-byte characters, whitespaces, scientific notations, or unexpected string representations allow malicious commands to bypass the validation pattern. Once the regex match succeeds or fails with a non-boolean error due to backtrack limits, the malicious string is executed directly by the PHP interpreter.

The vulnerability resides within the Bazar form field calculator component located in tools/bazar/fields/CalcField.php. Prior to version 4.6.6, the application validated the mathematical formulas using the recursive regular expression and then passed them to the dynamic execution engine.

The vulnerable code segment evaluates formulas as follows:

$regexpToCheckIfMathFormula = '/^((' . $number . '|' . $functions . '\s*\((?1)+\)|\((?1)+\))(?:' . $operators . '(?1))?)+$/';
if (preg_match($regexpToCheckIfMathFormula, $formula)) {
    $formula = preg_replace('!pi|π!', 'pi()', $formula);
    try {
        eval("\$value = $formula;"); // Dangerous evaluation sink
        $value = $value ?? 0;
    } catch (Throwable $th) {
        $value = 0;
    }
}

This implementation executes the formula immediately if the regex matches. Because $formula is modified via preg_replace after the validation has occurred, the validated structure is modified before execution, introducing a classic validation-before-modification flaw.

In the patched version, the developer removed both the regular expression check and the eval() call. The system now uses a custom parser to tokenize and evaluate mathematical formulas.

private const ALLOWED_FUNCTIONS = [
    'sin' => 'sin', 'sinh' => 'sinh',
    'cos' => 'cos', 'cosh' => 'cosh',
    // ... list of whitelisted functions
];
// Formula execution is restricted to the safe evaluateFormula method
try {
    $value = $this->evaluateFormula($formula);
} catch (Throwable $th) {
    $value = 0;
}

This safe implementation utilizes a lexer (tokenizeFormula) that parses the formula character by character into strictly validated tokens. The tokens are then processed using a deterministic recursive descent parser, ensuring that no raw string is ever interpreted by the PHP engine.

Exploitation of CVE-2026-52778 can be executed through two distinct methodologies depending on the attacker's objective. To execute a Denial of Service (DoS) attack, an unauthenticated remote attacker targets the Bazar module forms that contain mathematical calculator fields. The attacker crafts a request containing a nested formula payload designed to exhaust the PCRE recursion stack.

The payload consists of deeply nested parentheses, for example, several thousand levels of (((...1...))). When the application attempts to process this payload, the PCRE engine encounters the (?1)+ recursive token in the regular expression. The recursive stack exhaustion occurs immediately, forcing the operating system to terminate the PHP-FPM or Apache worker process with a segmentation fault. Continuous submission of this payload effectively disables the application by exhausting available worker threads.

To achieve Remote Code Execution (RCE), an attacker must bypass the regular expression validation to inject PHP instructions. This involves exploiting parser differentials or input manipulation. For example, if the system's pcre.backtrack_limit is exceeded, preg_match can fail and return false or null. If the code checks truthiness loosely instead of strictly comparing the return value to 1, the validation check can be bypassed. Once the payload reaches the eval() sink, arbitrary functions such as system() or passthru() can be executed to gain server control.

The impact of successful exploitation is severe, leading to compromise of both the application and the underlying hosting infrastructure. Remote Code Execution (RCE) allows an unauthenticated adversary to run system commands with the privileges of the web server daemon (e.g., www-data). This enables unauthorized access to local files, database connection strings, and application source code.

Once initial access is established, the adversary can perform database manipulation, write persistent web shells to public directories, or attempt local privilege escalation to compromise the entire server. Because YesWiki handles wiki data and collaborative inputs, an attacker could also modify site content, deface pages, or exfiltrate sensitive data stored within the Bazar database tables.

The alternate attack vector, Regular Expression Denial of Service (ReDoS), has a significant impact on system availability. Because a single malformed request can crash an active PHP worker, an attacker can launch an automated script to continuously submit nested payloads. This exhausts the web server pool, leading to a permanent denial of service for legitimate users. This requires minimal computational power from the attacker but consumes significant CPU and memory resources on the targeted host.

The primary remediation for CVE-2026-52778 is to upgrade YesWiki to version 4.6.6 or later. This release replaces the insecure regular expression and evaluation sink with a safe, custom mathematical expression parser. The new implementation parses the input string into concrete tokens and evaluates them using strict mathematical logic, preventing code execution.

If an immediate upgrade is not feasible, administrators should apply a manual patch to tools/bazar/fields/CalcField.php. The dynamic execution block must be replaced with a static validation parser, as shown in the official patch diff. Additionally, the system's PHP configuration should be hardened by lowering the pcre.recursion_limit and pcre.backtrack_limit values in php.ini to mitigate the risk of process crashes due to regex stack exhaustion.

While the official patch is highly complete and eliminates the RCE vector by removing eval(), there remains a minimal residual risk of localized denial of service. The new recursive descent parser relies on recursive function calls in PHP. If an attacker submits a formula with extremely deep nested structures, it may trigger a PHP execution stack depth error or memory exhaustion. To prevent this, developers should implement an explicit limit on the nesting level inside the custom parser to reject expressions with a nesting depth greater than 50.