YesWiki CalcField eval() Injection with ReDoS Pre-condition – Dual RCE & DoS Vector

Vulnerability Description

The vulnerability resides in tools/bazar/fields/CalcField.php within the formatValuesBeforeSave() method. The application attempts to create a sandbox for mathematical formula evaluation by validating input against a complex recursive PCRE regex pattern before passing the formula to PHP's eval(). This is a well-known anti-pattern: regex validation followed by dynamic code execution is fundamentally insecure because: (1) regex engines have computational limits that can be exploited (ReDoS), and (2) regex cannot comprehensively express the security constraints of a Turing-complete language like PHP. The regex uses nested quantifiers with recursive subpatterns (?1)+ which stress the PCRE engine's stack allocation, and any bypass of the regex validation directly grants arbitrary PHP code execution.

PoC Significance

The disclosed PoC is significant for defenders because it proves two distinct attack vectors: ReDoS/Stack Exhaustion – attacker sends a crafted formula with deeply nested parentheses or repetitive patterns to trigger catastrophic backtracking, consuming server memory and CPU, resulting in application crash or unresponsiveness (DoS). Regex Bypass to RCE – attacker crafts a mathematically-looking formula that passes the regex but contains PHP syntax (e.g., through function chaining, variable expansion, or escaped sequences) that executes arbitrary code when eval() processes it. The PoC proves the validation is not hermetic. Preconditions are minimal: any user with ability to submit a Bazar form with a calculated field can trigger both vectors; no authentication bypass needed if Bazar is public-facing.

Detection Guidance

Log Indicators:

• PHP fatal errors or stack overflow exceptions in CalcField.php
• Abnormally long formula strings submitted via POST/GET to Bazar form endpoints (>500–1000 chars with nested parentheses)
• Unusual characters in formula fields: $, {, }, backticks, system(), exec(), passthru() function names
• CPU/memory spikes coinciding with form submissions
• PHP error logs showing preg_match() timeout or stack depth exceeded

YARA-style pattern (for WAF/IDS):

• Regex: detect repeated (( or ))+ sequences; flag submissions with >10 consecutive nesting levels
• Payload: match PHP superglobals or function calls in formula parameters

File Integrity: monitor CalcField.php modification timestamps and checksum changes.

Mitigation Steps

1. Immediate (Workaround): Disable the Bazar calculated field feature or restrict form access via access control lists until patching is complete.
2. Short-term (Patch): Apply YesWiki security update (version TBD by vendor) that replaces eval() with a safe mathematical expression evaluator (e.g., EvalMath, Fhaculty/Graph-Math, or a sandboxed expression parser).
3. Long-term (Hardening):
   • Remove eval() entirely; use AST-based expression parsing with a whitelist of allowed functions/operators
   • Implement input length limits (e.g., max 200 characters)
   • Use a dedicated formula evaluation library with no dynamic code generation
   • Add WAF rules to reject formulas containing PHP syntax keywords
   • Implement rate-limiting on formula submission endpoints

Risk Assessment

Likelihood: High. ReDoS exploitation is trivial (just nest parentheses); RCE exploitation requires deeper PHP/regex knowledge but is reproducible. The vulnerability affects any YesWiki deployment with Bazar enabled and public form submission. Threat Actor Interest: Very High. PHP RCE vulnerabilities in content management systems are actively exploited by opportunistic scanners and targeted actors. Ransomware and web shell campaigns routinely target eval() sinks. CVSS Context: The CVE 2026 numbering suggests future disclosure; treat as pre-release intel. Prioritize patching within 48–72 hours of update availability. Monitor GitHub and YesWiki security channels for official remediation.