critical · 9.8CVE-2026-52778Jul 9, 2026

CVE-2026-52778: YesWiki CalcField Unsafe eval() Remote Code Execution and ReDoS

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

YesWiki's Bazar form calculator passes user-supplied math formulas through a broken regex check and then directly into PHP eval(), letting an attacker crash the server or run arbitrary system commands

Packageyeswiki/yeswiki
Ecosystemcomposer
Affected< 4.6.6
Fixed in4.6.6

The problem

The `formatValuesBeforeSave()` method in `tools/bazar/fields/CalcField.php` attempts to validate user-defined formulas with a recursive PCRE pattern (`(?1)+`) before handing the raw string to `eval("$value = $formula;")`. This is a fundamentally unsafe architecture: the regex is the only barrier between user input and arbitrary PHP execution.

The recursive pattern itself is the first weapon. Feeding thousands of nested parentheses exhausts the PCRE stack, crashing the PHP-FPM or Apache worker immediately (ReDoS / segfault). Any bypass of the regex, whether through PCRE engine edge-cases or future logic changes, drops the attacker directly into `eval()` with web-server privileges.

Proof of concept

A working proof-of-concept for CVE-2026-52778 in yeswiki/yeswiki, with the exact payload below.

bash
# --- Scenario A: ReDoS / Server Crash (confirmed in advisory) ---
# Submit as a Bazar Calc field formula value.
# Repeat the nesting 2000-5000 times to exceed pcre.recursion_limit.
((((((((((((((((((((((((((((((((((((((((((1+1))))))))))))))))))))))))))))))))))))))))))))

# --- Scenario B: RCE if regex bypass is achieved ---
# If validation is bypassed, eval() executes this as raw PHP:
abs(1) + system('id')

For the DoS path, the recursive PCRE pattern `(?1)+` is processed on the system stack. PHP's `pcre.recursion_limit` is finite; deeply nested input exhausts it and either returns a null match (allowing the eval path to be skipped safely) or triggers a segmentation fault that kills the worker process entirely.

For RCE, the flaw is architectural. `eval()` executes any valid PHP expression, so the formula string `abs(1) + system('id')` is syntactically legal PHP. The regex is the only guard, and complex recursive sanitizers have a consistent history of bypass via edge-case inputs or PCRE engine quirks.

The patch (commit `dd2bd8f`, +200/-10 lines) removes the `eval()` call entirely and replaces it with a dedicated AST-based math expression parser that never passes user input to the PHP interpreter. CWEs: CWE-94 (Code Injection), CWE-1333 (Inefficient Regular Expression Complexity).

The fix

Upgrade to YesWiki 4.6.6 or later. The release (June 2, 2026) removes `eval()` from `CalcField.php` and replaces the recursive-regex-plus-eval pattern with a safe AST math evaluator. If immediate patching is not possible, disable the Bazar Calc field type at the application level and restrict Bazar form access to authenticated, trusted users only.

Reported by mrflos.

References: [1][2][3][4][5]

Related research