CVE-2026-52778: YesWiki has Unsafe eval() in Formula Calculator - Remote Code Execution (RCE) & Denial of Service (DoS)
Summary
An unsafe execution vulnerability exists in the Bazar form field calculator (CalcField.php) of YesWiki. The application attempts to sanitize user-defined mathematical formulas using a complex recursive regular expression before passing them to the PHP eval() function. This implementation is inherently flawed: it is vulnerable to Regular Expression Denial of Service (ReDoS / Stack Overflow) which can crash the server, and it creates a high-risk architecture where any logic bypass directly results in arbitrary PHP code execution.
Details
Affected Component - File: tools/bazar/fields/CalcField.php - Method: formatValuesBeforeSave($entry) - Vulnerable Mechanism: Combination of a complex recursive regex validation followed by eval().
The code attempts to implement a sandbox for mathematical operations by verifying the formula structure before executing it:
$regexpToCheckIfMathFormula = '/^((' . $number . '|' . $functions . '\s\((?1)+\)|\((?1)+\))(?:' . $operators . '(?1))?)+$/';
if (pregmatch($regexpToCheckIfMathFormula, $formula)) { $formula = pregreplace('!pi|π!', 'pi()', $formula); try { eval("\$value = $formula;"); // VULNERABLE LINE // ... Architectural Flaws
PCRE Stack Overflow & ReDoS (The Immediate Exploit):
The regex definition heavily relies on a recursive pattern (?1)+. In PHP's PCRE engine, deeply nested recursive patterns are processed on the system stack. If an attacker inputs a formula with thousands of nested parentheses or repeating groups, the engine will either trigger a pcre.recursionlimit exhaust (returning false or null) or cause a Segmentation Fault, instantly crashing the PHP process (Denial of Service).
The "Validation-Before-Substitution" Trap:
The regex checks the $formula variable after it has tokenized and reassembled the input string. If any underlying function called during tokenization (like testEntryValue or future updates to getEntryValue) returns or leaks an unexpected string format, the string structure changes.
Complete Trust in eval():
Using eval() as a math parser means the application's security perimeter relies entirely on a single regular expression. History shows that complex regex sanitizers for script evaluation are consistently bypassed via edge-case syntaxes, character encoding tricks, or PCRE engine bugs.
PoC
Scenario A: Remote Denial of Service (Server Crash)
An attacker with rights to create or edit a Bazar form adds a Calc field and injects a deeply nested recursive mathematical structure.
Payload:
((((((((((((((((((((((((((((((((((((((((((1+1))))))))))))))))))))))))))))))))))))))))))))
(Multiplied by 2000 to 5000 iterations depending on the server's pcre.recursionlimit and stack configuration).
The PCRE engine runs out of stack memory, leading to an immediate crash of the PHP-FPM worker or Apache process handling the request, rendering the service unavailable.
Scenario B: Logical Bypass to RCE
Because eval() executes raw PHP code, if an attacker successfully fuzzes the recursive pattern or exploits an unpatched vulnerability in the specific PCRE library version installed on the host OS, they can slip a PHP payload through the validation block. Payload:
abs(1) + system('id')
If a validation bypass occurs, the string evaluates as native PHP, granting the attacker the privileges of the www-data (web server) user, leading to a full host compromise.
Impact
- Confidentiality: HIGH. Attackers can read sensitive system files (e.g., /etc/passwd, .env configuration files).
- Integrity: HIGH. Attackers can modify application files, inject backdoors, or alter the database content.
- Availability: HIGH. Attackers can easily bring down the web service via the ReDoS/Segmentation Fault vector.
Remediation & Mitigation
- Do not use regular expressions to safe-guard eval(). Instead, replace the execution block with a dedicated, safe Abstract Syntax Tree (AST) math parser or an expression language component that cannot execute system context.
Other sources
YesWiki is a wiki system written in PHP. Prior to version 4.6.6, an unsafe execution vulnerability exists in the Bazar form field calculator (CalcField.php) of YesWiki. The application attempts to sanitize user-defined mathematical formulas using a complex recursive regular expression before passing them to the PHP eval() function. This implementation is inherently flawed: it is vulnerable to Regular Expression Denial of Service (ReDoS / Stack Overflow) which can crash the server, and it creates a high-risk architecture where any logic bypass directly results in arbitrary PHP code execution. Version 4.6.6 patches the issue.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/yeswiki/yeswikito a version that resolves this vulnerability.Fixed in 4.6.6 - Upgrade
Upgrade
YesWiki Bazar CalcField.php (Formula Calculator)to a version that resolves this vulnerability.Fixed in 4.6.6 - Configuration
Remove the eval()-based execution of the Calc field formula. Replace the execution block with a dedicated, safe Abstract Syntax Tree (AST) math parser or expression language component that cannot execute system context, instead of relying on regex validation before eval().
YesWiki Bazar form field calculator (CalcField.php) Use of eval() for user-supplied formulas = Replace eval() execution with a dedicated safe AST math parser / expression language (non-PHP-code execution) - Compensating control
Since the issue can lead to server crash (ReDoS/PCRE stack overflow and possible segmentation fault) and potential host compromise via eval(), restrict Bazar form authoring/editing permissions so untrusted users cannot create or edit forms with Calc fields.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-52778?
CVE-2026-52778 has a critical severity rating of 9.8.
How do I fix CVE-2026-52778?
To fix CVE-2026-52778, upgrade YesWiki to version 4.6.6 or later.
What type of vulnerability is CVE-2026-52778?
CVE-2026-52778 is a code injection vulnerability that allows for remote code execution and denial of service.
What impact does CVE-2026-52778 have on YesWiki users?
CVE-2026-52778 can lead to unauthorized code execution and potential service downtime affecting YesWiki users.
In which component of YesWiki is CVE-2026-52778 found?
CVE-2026-52778 is found in the Bazar form field calculator (CalcField.php) of YesWiki.