Dateirechte 755: warum die meisten Ratgeber falsch liegen

Von CMS ADMINS Redaktion · Aktualisiert am 14. September 2026

Veröffentlicht: 06.09.2026 · Letzte Aktualisierung: 06.09.2026

„Setzen Sie Verzeichnisse auf 755 und Dateien auf 644.“ Dieser Satz steht in fast jedem WordPress-Sicherheitsratgeber, und er ist als Empfehlung auch nicht falsch. Falsch wird es, wenn daraus eine Prüfung wird: Werkzeuge und Checklisten, die jede Abweichung von exakt 755 als Sicherheitsproblem melden. Dabei ist 750 strenger als 755, und das auf vielen Hostern übliche 2755 ist schlicht Alltag. Wir wissen das so genau, weil unser eigenes Plugin denselben Fehler hatte. Dazu weiter unten mehr.

Was 755 wirklich bedeutet

Unix-Dateirechte bestehen aus drei Ziffern, eine pro Personengruppe: der Eigentümer der Datei (user), dessen Gruppe (group) und alle anderen Accounts auf dem Server (other). Jede Ziffer ist die Summe aus Lesen (4), Schreiben (2) und Ausführen beziehungsweise Verzeichnis betreten (1).

7 5 5
| | |
| | +-- other: 4+1 = lesen + betreten
| +---- group: 4+1 = lesen + betreten
+------ user:  4+2+1 = lesen + schreiben + betreten

In der Ausgabe von ls -l sieht das so aus:

$ ls -ld wp-content
drwxr-xr-x 6 web108 client25 4096 Sep  6 10:12 wp-content
 |--||--||--|
 user group other

rwx für den Eigentümer, r-x für die Gruppe, r-x für alle anderen: das ist 755. Der Eigentümer darf alles, alle übrigen dürfen lesen und das Verzeichnis betreten, aber nichts verändern.

Warum „exakt 755″ der falsche Maßstab ist

Wer auf Gleichheit mit 755 prüft, meldet zwei Konfigurationen als Problem, die keines sind.

750 ist strenger, nicht unsicherer. Bei 750 verlieren alle fremden Accounts auch das Leserecht. Auf einem Shared-Hosting-Server, auf dem 200 Kunden nebeneinander liegen, ist das eine Verbesserung. Ein Werkzeug, das 750 rot markiert, fordert den Betreiber faktisch auf, Rechte zu lockern. Das ist das Gegenteil von Härtung.

2755 ist auf vielen Hostern der Normalzustand. Die führende 2 ist das setgid-Bit. Auf einem Verzeichnis bewirkt es, dass neue Dateien automatisch die Gruppe des Verzeichnisses erben statt der Gruppe des erzeugenden Prozesses. Hoster mit sauberer Rechtetrennung (etwa ISPConfig- oder Plesk-Umgebungen) setzen es absichtlich, damit Dateien, die mal per SFTP und mal per PHP entstehen, in derselben Gruppe landen. Die eigentlichen Rechte dahinter sind identisch mit 755. Wer 2755 als „unsicher“ meldet, erklärt eine korrekt konfigurierte Serverlandschaft zum Befund und produziert einen Fehlalarm auf tausenden völlig normaler Installationen.

Fehlalarme sind dabei nicht nur lästig. Wer dreimal erlebt hat, dass die rote Meldung nichts bedeutet, liest auch die vierte nicht mehr. Und die vierte ist dann vielleicht echt.

Das eine Bit, das zählt: o+w

Sicherheitsrelevant an Dateirechten ist im Kern eine einzige Frage: Darf jeder Account auf dem Server schreiben? Das ist die 2 an der letzten Stelle, das World-Writable-Bit, in Symbolschreibweise o+w. Betroffen sind Werte wie 777, 776, 757 oder 666 bei Dateien.

Das Angriffsszenario dazu ist unspektakulär und genau deshalb realistisch: Auf einem Shared-Hosting-Server wird ein anderer Kunde kompromittiert, etwa über ein veraltetes Plugin. Der Angreifer hat jetzt einen Account auf derselben Maschine. An Ihre Dateien kommt er trotzdem nicht heran, denn er ist weder Eigentümer noch Gruppenmitglied. Er ist „other“. Steht Ihre wp-config.php auf 644, kann er sie nicht verändern. Steht sie auf 666, schreibt er 3 Zeilen hinein und Ihre Site gehört ihm, samt Datenbank-Zugangsdaten und Authentifizierungsschlüsseln. Der Unterschied zwischen 644 und 666 ist genau dieses eine Bit.

Ob daneben 755, 750 oder 2755 steht, ändert an diesem Szenario nichts. Deshalb ist die richtige Prüfung keine Gleichheitsprüfung, sondern ein Bit-Test: $perms & 0002. Eine Zeile, und sie beantwortet die Frage, auf die es ankommt.

Unser eigenes Plugin hatte denselben Fehler

Unser kostenloses Audit-Plugin Security Check Report prüft unter anderem die Rechte von wp-config.php und den zentralen WordPress-Verzeichnissen. Bis Version 2.2.2 tat es das mit einem Vergleich auf exakt 0755. Die Folge war genau das oben beschriebene Verhalten: 0750 wurde als unsicher gemeldet, 2755 auch. Ein Nutzer auf einem sauber konfigurierten Shared Hosting bekam einen Befund für eine Einstellung, die sein Hoster mit Absicht so gesetzt hatte.

Mit dem Rebuild in Version 2.3.0 haben wir die Prüfung ersetzt. Sie testet seitdem das World-Writable-Bit und unterscheidet zwei Stufen: Schreibrecht für alle ist ein Befund mit hoher Dringlichkeit, ein für alle lesbares wp-config.php auf Shared Hosting eine Warnung mit Empfehlung auf 640 oder 440. Der Eintrag steht so auch im Changelog, und weil das Plugin quelloffen ist, können Sie die neue Prüfung auf GitHub nachlesen.

Wir schreiben das hier so ausführlich, weil es den Punkt des Beitrags belegt: Der 755-Gleichheitsvergleich ist kein Fehler, den nur schlampige Ratgeber machen. Er ist naheliegend, er sieht korrekt aus, und er stand in unserem eigenen Code. Der Unterschied liegt darin, ob man ihn findet und korrigiert.

So prüfen Sie richtig

Mit SSH-Zugang finden diese beiden Befehle jede world-writable Datei und jedes world-writable Verzeichnis unterhalb Ihrer WordPress-Installation:

# world-writable Dateien
find . -type f -perm -o+w

# world-writable Verzeichnisse
find . -type d -perm -o+w

Beide Listen sollten leer sein. Ist etwas dabei, korrigieren Sie gezielt:

chmod o-w pfad/zur/datei        # nur das eine Bit entfernen
chmod 640 wp-config.php         # wp-config.php zusätzlich härten

Zwei Hinweise dazu. Erstens: Widerstehen Sie dem Reflex, rekursiv alles auf 755/644 zu setzen. chmod -R über die ganze Installation überschreibt auch Rechte, die Ihr Hoster bewusst anders gesetzt hat, und repariert nichts, was nicht kaputt war. Entfernen Sie das o+w-Bit dort, wo es auftaucht, und lassen Sie den Rest in Ruhe. Zweitens: Ohne SSH-Zugang übernimmt unser Plugin diese Prüfung als einen von 60 Punkten, direkt aus dem WordPress-Dashboard. Es ist ein rein lesendes Konfigurations-Audit, keine Firewall und kein Malware-Scanner: Es meldet Befunde mit Anleitung, verändert aber nichts an Ihrem Server.

Häufige Fragen

Muss ich meine Verzeichnisse von 2755 auf 755 ändern?

Nein. Das setgid-Bit ist eine bewusste Entscheidung Ihres Hosters für konsistente Gruppenzuordnung neuer Dateien. Es erweitert keine Zugriffsrechte für Dritte. Wenn Sie es entfernen, riskieren Sie Rechteprobleme bei Uploads und Updates, gewinnen aber nichts.

Sind 750 oder 640 nicht zu streng? Funktioniert WordPress damit?

Auf den meisten modernen Hosting-Umgebungen läuft PHP unter Ihrem eigenen Account (etwa via PHP-FPM). Dann greift WordPress als Eigentümer auf die Dateien zu und 750/640 funktionieren problemlos. Läuft PHP unter einem separaten Benutzer wie www-data, der nur über die Gruppe zugreift, brauchen Verzeichnisse 770 oder eine passende Gruppenkonfiguration. Im Zweifel testen Sie nach der Änderung einen Medien-Upload und ein Plugin-Update.

Mein Security-Plugin meldet meine Dateirechte als unsicher. Was jetzt?

Prüfen Sie zuerst, was tatsächlich gemeldet wird. Steht dort 750 oder 2755, prüft das Werkzeug vermutlich auf exakt 755 und der Befund ist ein Fehlalarm. Steht dort 777, 776 oder 666, ist das World-Writable-Bit gesetzt und der Befund ist echt: Entfernen Sie das Schreibrecht für „other“ mit chmod o-w.

Reicht es, wenn die Dateirechte stimmen?

Nein. Dateirechte begrenzen, was ein bereits vorhandener fremder Account auf dem Server anrichten kann. Gegen veraltete Plugins, schwache Passwörter oder offene Registrierungen helfen sie nicht. Einen Überblick über die weiteren Baustellen gibt unsere Seite zur WordPress-Sicherheit.

Weiterführende Links

• Security Check Report: die Produktseite mit allen 60 Prüfungen im Überblick
• Das Plugin im WordPress-Verzeichnis (kostenlos, GPLv2, keine Pro-Version)
• Der Quelltext auf GitHub, inklusive der hier beschriebenen Rechte-Prüfung
• WordPress-Sicherheit bei CMS ADMINS: wenn Sie die Befunde nicht selbst abarbeiten wollen