CVE-2026-70553

This vulnerability is not a single injection flaw — it's a cascading failure where three independently defensible design decisions compound into trivial unauthenticated RCE. The attack surface is threefold: an install endpoint that remains accessible after setup, configuration files writable by the web server process, and direct string interpolation of user input into executable PHP. Chaining these together, an attacker sends a single POST with a quote character to the post-install endpoint and achieves remote code execution as the web server user. The critical insight is that each of these failures has a known mitigation in isolation, but their combination creates exploitability that bypasses the need for any technical sophistication. The web-server-writable config file is the enabling condition — if database.php were owned by a deployment user and read-only to the web server, the string interpolation bug in config generation would be moot regardless of input validation failures. For defenders, the priority actions are: first, verify whether the /install endpoint is still present and accessible on any MaxSite CMS deployment — if it exists in production, treat it as an immediate risk. Second, audit config file ownership — configuration files should be owned by a deployment or system user, not writable by the web server process. This is a deployment hygiene check, not a code review exercise. Third, if the CMS allows runtime config regeneration through any endpoint, that capability should be removed in production; config files should be deployment-time artifacts, not mutable runtime state. The CVSS 9.8 score obscures more than it reveals. It implies technical sophistication is required, but the exploit is sending a quote character via POST. What the score actually reflects is catastrophic impact — persistent RCE inside the web server daemon means every subsequent HTTP request executes as the web server process. In shared hosting environments, this one compromise exposes database credentials for every site on that server and provides pivot capability to adjacent tenants. The broader lesson: this exact vulnerability pattern has appeared in WordPress (2008), Drupal (2010), and phpBB variants across a decade. The genealogy is predictable — whenever a PHP CMS ships with web-server-writable config files and an install endpoint that survives into production, you're not one vulnerability away from RCE, you're already there waiting for any string formatting error anywhere in the codebase. Architectural intervention (treating config as immutable, removing install endpoints post-setup) prevents this class entirely, regardless of input validation failures.

Reviewed through automated stages and approved by a human before publication.