Summary
MaxSite CMS contains a remote code execution vulnerability in its installation endpoint. An unauthenticated attacker may submit crafted POST data that injects PHP statements into the application configuration, causing persistent code execution when the web server processes later requests.
Affected context
The vulnerability occurs when the MaxSite CMS installation endpoint remains reachable after the application has already been installed and accepts configuration values without safely encoding or validating them. A crafted database prefix value can break out of a generated PHP string in application/config/database.php, allowing attacker-controlled statements to become part of the deployed configuration.
Exploit preconditions
- Attack surface: The publicly reachable MaxSite CMS installation endpoint
- Required access: No authentication, provided the endpoint accepts the request
- Trigger point: Processing a crafted POST request containing a malicious database-prefix value
- Why exploitation is possible: User-controlled input is incorporated into a PHP configuration file without preventing PHP syntax or code injection
- Persistence condition: The modified configuration file remains available to the web application and is loaded on subsequent requests
Why this happens
The underlying flaw is direct generation of executable PHP configuration from insufficiently constrained user input. A value intended to be treated as database metadata can terminate a PHP string literal and introduce additional statements, mapping to CWE-94: Improper Control of Generation of Code. The issue is compounded when an installation workflow remains usable after setup and does not enforce a one-time installation state or protect configuration-file generation.
Potential impact
- An attacker may execute arbitrary PHP code as the web-server process user.
- The application may be fully compromised through persistent code execution.
- Sensitive configuration data, credentials, or application records could be accessed.
- Attackers could modify site content, create persistence, or use the host for further attacks.
- The server may be used to affect connected services or other applications.
General mitigation guidance
Mitigation generally focuses on preventing post-installation access to setup functionality and ensuring that configuration values cannot become executable PHP code.
Common defensive patterns include:
- Disable, remove, or strongly gate installation endpoints after successful setup.
- Generate configuration files using safe serialization or structured formats rather than concatenating executable PHP source.
- Apply strict allowlisting and context-appropriate encoding to configuration values.
- Treat all setup requests as untrusted, even when they write local files.
- Restrict write permissions for application configuration files and run the web process with least privilege.
- Add an explicit installation-complete state that prevents repeated configuration generation.
How teams detect issues like this
Organizations can look for:
- Static-analysis findings involving user input concatenated into PHP source or configuration files.
- Code-review signals such as setup handlers that remain enabled after installation or write directly to executable application files.
- Web-application logs showing unauthenticated POST requests to installation paths after deployment.
- File-integrity monitoring alerts for unexpected changes to
application/config/database.php. - Policy checks requiring installation endpoints to be disabled or access-controlled in production.
Automated security review tools can help identify dynamic code-generation patterns, unsafe file writes, and missing installation-state enforcement.
