Die schlimmsten habe ich gefixt, ich sehe weiterhin ein geringes Risiko, das kann meiner meinung nach auch bis nach dem Urlaub warten
Du hattest einen SSH-Breach, die komplette Maschine ist quasi als kompromittiert anzusehen Nur da der TO das nicht einsehen will, muss halt von andere Seite aus gehandelt werden. Niemand bei Verstand sollte irgendwelche Daten an ein solches System liefern.
Jemand Fremdes hatte komplettem Zugriff auf deine System, alles kann passiert sein, er könnte Backdoors installiert haben, Daten ausleiten, was auch immer... und du lässt es einfach weiter laufen. Monitoren hilft nichts, oder hast du die Integrität jedes Binaries über ein externes System überprüft? Das geringe Risiko siehst du Mangels Erfahrung, auf erfahrene Hasen willst du aber nicht hören.
Die schlimmsten habe ich gefixt
Dein Code war absolut unstrukturiert und hatte haarsträubende Fehler, du hast teilweise GET-Parameter direkt in den SQL-String eingebaut, ohne alles. Einen Schutz für XSS oder ähnliches seh ich nicht. SQL-Injections gehen auf mindestens einer Seite noch Du kannst mir (und vermutlich den anderen) nicht glaubhaft machen, dass du innerhalb von 5 Minuten dein Wissen von "ich kann gerade so php coden" zu "ich schreibe sicheren Code" erweitert hast. Allgemein hattest du im alten Code noch nicht mal str_replace richtig benutzt... und jetzt soll der Code sicher sein? Dann poste ihn doch mal auf Github, machen wir ein Security Audit