Gecka

Feature Request 2 — Disable or warn about mod_php on Prefork in shared hosting

Summary

When using Apache Prefork MPM (without ITK), mod_php (PHP Apache module) runs all PHP code as www-data regardless of the site owner. ISPManager should either disable mod_php by default on Prefork or display a prominent security warning.

The vulnerability

On Prefork without ITK, mod_php runs PHP inside the Apache process as www-data (uid 33). While open_basedir restricts PHP functions like file_get_contents(), it does NOT restrict shell commands. A malicious user can:

// This reads another user's database credentials
echo shell_exec("cat /var/www/other_user/data/www/site.com/wp-config.php");

The shell_exec() call spawns a process as www-data, which has read access to all users' files. open_basedir only applies to PHP's own file functions, not to external commands.

Proof of concept

We tested this on a fresh ISPManager Host installation (Ubuntu 24.04, Apache Prefork):

  1. User test creates a PHP file on module.test.com (mod_php mode):

    <?php echo shell_exec("cat /var/www/test2/data/www/hack.test.com/secret.txt");
    
  2. Result: the file content of user **test2** is displayed. The secret is exposed.

  3. The same attack on FastCGI (Apache) mode fails with Permission denied because PHP-FPM runs under the user's own uid, not www-data.

Recommendation

ISPManager should:

  1. Display a security warning in the panel when mod_php is enabled on Prefork: "Warning: PHP Apache module on Prefork runs all PHP code as www-data. Users can read each other's files via shell commands. Use FastCGI (Apache) or Nginx+PHP-FPM for user isolation."
  2. Or better: disable mod_php as a user-selectable option when ITK is not active. Only allow FastCGI (Apache), CGI, and Nginx+PHP-FPM on Prefork.
  3. Or best: implement Event MPM which makes mod_php unavailable by design.

Additional security issue: Apache FollowSymLinks

Related but separate: ISPManager installs Apache with Options FollowSymLinks in /etc/apache2/apache2.conf. This allows a user to create a symlink to another user's files and Apache will serve them. The fix is Options SymLinksIfOwnerMatch. Nginx already has disable_symlinks if_not_owner by default — Apache should have equivalent protection.

19.03.2026 02:34

0
Added to backlog
Mary K

Thanks for the feedback and the detailed explanation. We really appreciate you taking the time to share this. We’ll carefully review your comments and take them into account moving forward.

20.03.2026 06:16