Meist handelt es sich um ein Problem bei einem Plugin, dass ist auch häufig unabhängig von der PHP Version.
zB bestimmte Versionen von Revolution Slider, oder von Plugins welche die Timthumb Library verwenden, usw.
Solche Probleme kann der Angreifer meist über eine Suche identifizieren, weil die Plugins eine meist erkennbare Auswirkung auf den Quellcode haben. Mit der Liste wird dann ein Bot gefüttert. Er braucht dann auch kein Passwort, weil er einfach eine Lücke verwendet um auf den Webspace zu schreiben.
Es ist dann fast egal was du absicherst, oder ob du neu anfängst. Irgendwie wirst du auch an den Webseiten schrauben müssen, sonst passiert es immer wieder.
Du könntest alte Webseiten auch lokal hosten und mit httrack einen html Mirror machen den du dann hochlädst. Hat aber auch einige Nachteile hinsichtlich Bearbeitbarkeit, wenn mehrere User dran sind.
--
Die Empfehlung wäre:
0) Alle Webseiten/Domaininhalte leeren.
1) Mit htaccess den Webspace nur für deine IP freigeben
2) Die erste Webseite neu installieren mit einer Version des Projekts vor dem Problem, oder mit einer ganz neuen Wordpressinstallation und Neuinstallation aller Plugins. Dann musst du nur das Theme genau anschauen.
3) Ansonsten die Plugins durchschauen und für diese Versionsnummern mal schauen, ob es exploits gibt. Um dem auf den Grund zu gehen: https://wpvulndb.com/
4) Alle Plugins updaten, das ist für die Webseite meist kein Fehler und unbenötigte Plugins löschen
5) Webspace hinsichtlich Berechtigungen und PHP Einstellungen absichern. PHP Version ist auch wichtig, aber das ist nicht das Hauptding für dein Problem (Es gibt nur einen Supportstop, aber noch keinen fatalen Bug).
6) Passwörter der Wordpressinstallationen ändern, Passwörter von FTP und Admin soll man auch ändern, aber hier ist der Angreifer zu 99,9% nie dran gewesen.
7) Webseite wieder freigeben, und die nächste Webseite wieder ab 1) durcharbeiten
--
Hinsichtlich Punkt 5 bin ich jetzt aber selbst ins Zweifeln gekommen, ob wir dies mit unserem Produkt überhaupt korrekt machen können. 
Was ich beim Produkt Webhosting 8000 als Problem sehe:
-) exec scheint standardmässig aktiviert zu sein und die disabled_functions in der php.ini können nicht individuell bearbeitet werden (1)
-) die open_basedir standardmässig und nicht umfangreich veränderbar (2) im Admin auf folgendes zeigt: /var/www/vhosts/hosting111110.a11111.netcup.net/:/tmp/:/var/lib/php5/sessions:/var/lib/php/sessions
So sieht dies in meinem Admin aus:
Einstellungen.PNG
--
Ich habe es getestet man kann mit einem PHP Script in der Installation auf einer Domain auf alle Dateien anderer Domains zugreifen, sowie auch exec ausführen.
Dies geht zum Beispiel mittels require() bei beiden open_basedir Einstellungen.
Ich habe auch 2 Funktionen recherchiert, die PHP Versions unabhängig sein sollten, um dies zu testen:
print "Absolute Path:".$_SERVER['DOCUMENT_ROOT'];
//https://stackoverflow.com/questions/3938120/check-if-exec-is-disabled
function exec_enabled() {
$disabled = explode(',', ini_get('disable_functions'));
return !in_array('exec', $disabled);
}
//https://stackoverflow.com/questions/21427211/check-if-open-basedir-restriction-is-in-effect
function isRestricted($path)
{
// Default error handler is required
set_error_handler(null);
// Clean last error info. You can do it using error_clean_last in PHP 7.
@trigger_error('__clean_error_info');
// Testing...
@file_exists($path);
// Restore previous error handler
restore_error_handler();
// Return `true` if error has occured
return ($error = error_get_last()) && $error['message'] !== '__clean_error_info';
}
Alles anzeigen
Ein direkter Zugriff auf die php.ini ist aber nach meiner Recherche nicht erlaubt. Die Ordnerrechte zu reduzieren führt dazu, dass die Webseiten nicht mehr ausführbar wären.
Bei bisherigen Hostern sind einzelne Accounts immer unter einem eigenen User gelaufen und bei eigenen Installationen habe ich dies selbst ändern können.
Hoffentlich übersehe ich eine ganz banale Lösung, da ich ja selbst erst begonnen habe mit dem Webhosting 8000 zu arbeiten.
