Beiträge von b3317133

Das allgemeine Vorgehen bei einem Hack ist z.B. hier beschrieben.

Zitat von Benedikt86

Habt ihr mir vielleicht einen Vorschlag wie ich solche Änderungen unterbinden kann?

Du könntest z.B. das Plugin WP GDRP Compliance, über das der Hacker eingebrochen ist, und das beim ersten o.g. Website nach wie vor in der Version 1.4.2 online ist, auf die Version 1.4.3 mit dem entspr. Fix aktualisieren. o_O

Wenn sich das Formular auf einer extra Seite befindet, kannst Du z.B. von Deiner Berechnung aus einen Redirect auf diese Seite mit dem entspr. Parameter machen und automatisch in ein Feld von CF7 einfügen.

PS. Nutzt Du wirklich WordPress 5.0?

Der Hacker hatte über die im Beispiel genannte und derzeit massiv genutzte Sicherheitslücke Schreibrechte für [FONT=Courier New]update_option()[/FONT] und konnte damit entweder einfach nur die [FONT=Courier New]siteurl[/FONT] überschreiben oder wenn er/sie/es mehr Lust/Expertise/Ein besseres Script gekauft hatte, den Laden ganz übernehmen mit [FONT=Courier New]users_can_register -> 1[/FONT] und [FONT=Courier New]default_role -> administrator[/FONT] und einen neuen Benutzer registrieren, der dann autom. ein Admin wird, meist admin13, t2trollherten, t3trollherten o.ä., und darüber dann auch entspr. Backdoors für später einbaut/hinterlässt.

Daher und aber auch generell bei jedem Hack ist eine umfassende Analyse aller Dateien in allen per PHP zugänglichen Ordnern und Dateien auf dem Server und dem gesamten Inhalt der Datenbank die einzig richtige Herangehensweise.

Das Entfernen eines Symptoms entfernt oft nicht wirklich auch die wahre Ursache bzw. sonstige Hinterlassenschaften.

@mensmaximus Den Filter [FONT=Courier New]automatic_updater_disabled[/FONT] kenne ich, aber wo im Core wird dieser Filter auch benutzt / überstimmt? Ich kenne keine Stelle.

Das berühmte Yoast 1.7.4 Update war ein Plugin Update, das von den wordpress.org Leuten mit dem nur für sie zugänglichen Flag [FONT=Courier New]$item->autoupdate[/FONT] in der "Update offer" ins Repository gestellt wurde, wenn ich das recht in Erinnerung habe, was dann hier das entspr. $update Flag auf true setzt und das Update automatisch installiert. Mit JetPack gab es mal einen ähnlichen Fall.

Auf Websites mit [FONT=Courier New]AUTOMATIC_UPDATER_DISABLED == true[/FONT] oder [FONT=Courier New]add_filter( 'auto_update_plugin', '__return_false' );[/FONT] dürfte bzw. kann auch so ein spezielles Update nicht "forced" installiert werden. Im ersten Fall kommt der Codeflow gar nicht bis zur [FONT=Courier New]$item->autoupdate[/FONT] Abfrage, im zweiten Fall wird das Flag durch den Filter direkt danach wieder auf false gesetzt.

Zu dem Thema gibt es viel unklares und halbwahres im Netz, daher die Nachfrage.

Was für ein Plugin für Benachrichtigungen?

Und sind jetzt alle "Updater" Plugins deaktiviert?

Evtl. steht der Eintrag [FONT=Courier New]define( 'AUTOMATIC_UPDATER_DISABLED', true );[/FONT] bei Dir auch an einer falschen Stelle in der Datei [FONT=Courier New]wp-config.php[/FONT] ? Poste mal alles aus der [FONT=Courier New]wp-config.php[/FONT] ab der Zeile mit [FONT=Courier New]define ('WPLANG', ...[/FONT] , die Zeilen vorher nicht.

Schau mal die [FONT=Courier New]siteurl[/FONT] in den Datenbanken in der jeweiligen Tabelle [FONT=Courier New]wp_options[/FONT] an, ähnlich wie hier.

@mensmaximus Bei welcher genauen Core Version wurde das getan? Wo befindet sich der Code, der ein auf [FONT=Courier New]true[/FONT] gesetztes [FONT=Courier New]AUTOMATIC_UPDATER_DISABLED[/FONT] für den Core überstimmt?

Am Rande für Mitleser, nicht [FONT=Courier New]AUTOMATIC_UPDATER_DISABLED[/FONT] verwechseln mit [FONT=Courier New]WP_AUTO_UPDATE_CORE[/FONT], das z.B. auf autom. Updates von Plugins keinen Einfluss hat.

Die Links z.B. auf die Kontakt oder Datenschutz Seiten sind "hardgecodet" eingegeben, daher hat die "Permalinks" Einstellungen hier keine Auswirkungen.

Leere zwischen allen Versuchen Deinen Browser Cache.

Zitat von gerega

Ich weiß auch nicht, inwiefern ein Plugin, das ich mööööglicherweise in der letzten Zeit in meiner multisite-Installation verantwortlich sein könnte.

Deaktiviere temporär dieses Plugin, speichere dann erneut die Permalinks, funktioniert es dann?

Falls nein, deaktiviere der Reihe nach temporär alle vorhandenen Plugins, speichere jeweils dazwischen die Permalinks. Ändert das etwas?

Du kannst versuchen, ohne weitere Änderungen im Menü "Einstellungen > Permalinks > Speichern" anzuklicken, hilft das?

Weiterhin kann es sein, dass die Beseitigung des o.g. Hacks unvollständig war und dadurch ggf. noch Nebenwirkungen entstehen.

Die besagte Suchabfrage ist bei Dir in der "404 nicht gefunden" Seite integriert, die erscheint, wenn ein Link nicht funktioniert oder ins Leere zeigt.

Wenn [FONT=Courier New]AUTOMATIC_UPDATER_DISABLED[/FONT] auf [FONT=Courier New]true[/FONT] gesetzt ist, sollte keinerlei Updates automatisch installiert werden, weder Core noch Plugins & Themes, mehr dazu hier.

Eigene Einträge bzgl. Updates in [FONT=Courier New]wp-config.php[/FONT] sollte man nicht mit entspr. Plugins kombinieren, hier gilt das "zu viele Köche" Sprichwort...

Die Inhalte der Beiträge usw. befinden sich in der Datenbank und werden von Better Search Replace gefunden.

Direkte Änderungen in den Theme-Dateien, z.B. in single.php, header.php o.ä. werden nicht von Better Search Replace gefunden.

Bzgl. "OFF" für Mitleser: Die REST-API ist bei WordPress standardmässig zugänglich. Um Zugriffe von aussen zu unterbinden, muss man explizit ein extra Plugin o.ä. installieren.

Bzgl. des eigentlichen Problems, inzwischen sind die Pfade offenbar teils mit doppelten Slashes wie [FONT=Courier New]//[/FONT] versehen, oder sie zeigen fälschlicherweise auf interne Dateipfade des Servers wie [FONT=Courier New]/www/htdocs/w00XXX/..[/FONT], das deutet darauf hin, dass irgendwas an der Datenbank herumgebastelt wird, was eine später Hilfe dann immer schwerer macht. Viel Erfolg damit.

Es handelt sich offenbar um ein Kauf-Theme, Hilfe von aussen ist daher nicht so leicht möglich weil man den Quellcode nicht einsehen und das Theme auch nicht testweise schnell mal installieren kann.

Könnte es sein, dass für den Slider und/oder die anderen Elemente der Startseite nur bestimmte Kategorien eingestellt sind? Würde dort mal in den entspr. Widgets oder den Einstellungen suchen.

Evtl. wurde sowas auch bei der Erstinstallation im Code des Themes eingefügt, hast Du die ganze Installation selbst gemacht?

Manche Themes erlauben das Überspringen der ersten X Beiträge auf der Startseite, falls ein entspr. Widget der Startseite diese schon besser aufbereitet anzeigt, evtl. ist es sowas. Wie heisst das Theme? Link zur Seite? Von welcher Kategorie fehlen die ersten Beiträge?

Der Code in Deinem ersten Post zeigt Beiträge eines Custom Post Type.

In der Beschreibung sprichst Du von einer Custom Taxonomy und Terms dieser Custom Taxonomy.

Das sind unterschiedliche Dinge.

Die o.g. Codebeispiele zeigen den entspr. Term, wenn eine Übersichtsseite dieser Taxonomy aufgerufen wird.

Bei WordPress ist z.B. eine "Kategorie" eine Taxonomy, d.h. die o.g. Codebeispiele zeigen auf der Taxonomy Seite [FONT=Courier New]/category/meine-kategorie/[/FONT] den Text "Meine Kategorie".

Evtl. sollte man die Beschreibung des Problems noch etwas verfeinern, am besten mit Links zu echten Seiten, auf denen Du den entspr. Term anzeigen willst, dann kann man besser sehen, was Du eigentlich meinst.

1. Was ist [plain]https://b97zdv3.myraidbox.de/seal.js[/plain] für ein seltsames Ding? Lädt hier nicht..
2. Viele Bilder haben lt. REST-API seltsame Pfade, wie /wp-content[COLOR=#ff0000]/uploads/uploads/[/COLOR]2018/05/featured-image-32996.jpg, wie kommt das zustande?
3. Wie genau wurde der Umzug vorgenommen? Mit einem Plugin?

Probiere es mal damit: https://jsfiddle.net/khuLroy4/1/

Passe einfach mal gar nichts an.

Zitat von b3317133

Wird weiterhin .. das Plugin Relevanssi verwendet? Dafür gibt es eigene Filter, Ansatzpunkte z.B. hier.