CVE-2026-52778: YesWiki has Unsafe eval() in Formula Calculator - Remote Code Execution (RCE) & Denial of Service (DoS)

Published Jun 8, 2026
·
Updated

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

2 affected componentsFixes available
YesWiki YesWiki<4.6.6
composer/yeswiki/yeswiki<4.6.6
4.6.6

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade composer/yeswiki/yeswiki to a version that resolves this vulnerability.

    Fixed in 4.6.6
  2. Upgrade

    Upgrade YesWiki Bazar CalcField.php (Formula Calculator) to a version that resolves this vulnerability.

    Fixed in 4.6.6
  3. 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)
  4. 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

Jun 8, 2026
CVE Published
via MITRE·06:24 PM
Data Sourced
via MITRE·06:24 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·07:16 PM
DescriptionSeverityWeakness
Jul 9, 2026
Advisory Published
via GitHub·09:03 PM
Data Sourced
via GitHub·09:03 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-52778?

CVE-2026-52778 has a critical severity rating of 9.8.

2

How do I fix CVE-2026-52778?

To fix CVE-2026-52778, upgrade YesWiki to version 4.6.6 or later.

3

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.

4

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.

5

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203