Dieser Beitrag handelt von eigener Software. Das gehört an den Anfang und nicht ins Kleingedruckte: Wir entwickeln ein Redaktionssystem namens FreezrCMS, und dieser Text erklärt, warum. Wer keine Lust auf eigene Sachen hat, hört hier auf — die ersten zwei Abschnitte stehen trotzdem für sich, denn die Zahl darin gilt unabhängig davon, was wir verkaufen.
Wir haben nachgezählt, wovon wir eigentlich schreiben.
20 von 98
Seit dem 1. April 2026 sind auf dieser Website 98 Beiträge erschienen. Davon hatten 20 eine Lücke im Redaktionssystem, in einem Plugin oder in einem Theme zum Gegenstand. Jede fünfte Meldung.
Sechs drehten sich um den WordPress-Kern: 7.0.3 mit zwölf Lücken, 7.0.4, 7.1, dazu die Angriffswellen wp2shell und XSS2Shell und die Lücke vom 22. September, die bis Version 4.7 zurückreicht.
Drei um Joomla und seine Erweiterungen: zehn Lücken auf einmal im August, neun von einem einzigen Anbieter im September, und die Astroid- und JCE-Lücken, die seit März geschlossen waren und auf vielen Seiten trotzdem offen standen.
Acht um Plugins: Elementor Pro, TranslatePress, GiveWP, WPMU DEV SSO, Events Calendar, ein Migrations-Plugin, das nach dem Umzug liegen blieb, eine Hintertür, die über ein CDN kam, obwohl alles aktuell war — und eine zweite Elementor-Lücke, bei der wir eine Entwarnung zurücknehmen mussten.
Zwei um Themes, darunter eines, das nie aktiviert war und trotzdem Code ausführte.
Dazu die Trackbacks, eine Funktion aus den Anfängen des Bloggens, über die Anfang September drei Millionen Websites angegriffen wurden.
Was diese 20 gemeinsam haben
Sie setzen voraus, dass auf dem Webserver Software läuft.
Ein Plugin kann nur eine Lücke haben, wenn es dort ausgeführt wird. Ein Theme kann nur Code ausführen, wenn ein PHP-Prozess es lädt. Eine Rechteausweitung im Redaktionssystem braucht ein Redaktionssystem, das Anfragen aus dem Netz annimmt.
Bei einer Website, die als fertige HTML-Dateien ausgeliefert wird, ist keines dieser Bauteile vorhanden. Nicht besser geschützt — nicht da.
Das ist kein Kunststück und keine Erfindung von uns. So wurden Websites zwanzig Jahre lang gebaut, bevor jede Seite ein System dahinter hatte. Der Grund, warum kaum jemand dazu zurückgeht, ist ein anderer: Ohne System kann niemand mehr Inhalte pflegen, ohne HTML zu schreiben.
Woran wir deshalb sitzen
FreezrCMS dreht die Reihenfolge um. Gepflegt wird in einem gewöhnlichen Redaktionssystem im Browser — Seiten, Abschnitte, Text, Tabellen, Diagramme, alles an Ort und Stelle bearbeitet. Auf Knopfdruck entsteht daraus ein Satz fertiger HTML-Dateien, der per FTP oder SFTP auf den Zielserver wandert. Übertragen wird nur, was sich geändert hat.
Auf dem Zielserver liegen danach Dateien und sonst nichts. Kein PHP, keine Datenbank, keine Erweiterung, kein Update. Die Volltextsuche funktioniert weiter, weil der Export einen Suchindex als Skriptdatei beilegt, den der Browser durchsucht. Diagramme und Aufklappbereiche ebenso.
Gebaut haben wir es für Schweizer Gemeinden, die ihre Zahlen im Netz zeigen müssen: Budget, Budgetplanung, Rechnung, Geschäftsbericht. Das ist ein Anwendungsfall mit einer Eigenart — die Website wird einmal im Jahr ernsthaft angefasst und steht danach elf Monate still. Genau in diesen elf Monaten sammelt ein gewöhnliches System die Lücken an, von denen wir hier berichten. Und die Person, die das Budget einstellt, tut das neben ihrer eigentlichen Arbeit.
Weil Gemeinden barrierefrei sein müssen, erfüllen die ausgelieferten Seiten WCAG 2.1 Stufe AA. Gemessen, nicht behauptet: 90 Seitenaufrufe in hellem und dunklem Farbschema und auf drei Breiten, 0 Beanstandungen. Die Erklärung zur Barrierefreiheit nach eCH-0059 legt das System selbst an. Vor jeder Auslieferung laufen 1850 Prüfungen durch.
Was das ausdrücklich nicht löst
Hier wird es unbequem, und deshalb steht es hier und nicht am Ende.
Das Bearbeitungssystem bleibt. Irgendwo läuft eine Installation mit PHP und Datenbank, in der die Inhalte entstehen, und die muss gepflegt werden wie jede andere. Der Unterschied ist, wo sie steht: nicht auf dem öffentlichen Server, sondern dort, wo nur die Redaktion hinkommt. Das verkleinert die Angriffsfläche, es beseitigt sie nicht.
Der Server bleibt ein Server. Er braucht Updates, ein Zertifikat, eine Konfiguration, die stimmt. Von unseren 98 Beiträgen hätte eine eingefrorene Gemeinde die meisten trotzdem lesen sollen — die über Webmail etwa, oder die über Mailbetrug, NAS-Lücken und Anrufe von falschen Technikern. Jede fünfte Meldung ist gegenstandslos. Vier von fünf sind es nicht.
Es geht nicht alles. Ein eingefrorenes System kann keinen Shop, keinen Kundenbereich, keine Online-Buchung und keinen Kommentarbereich. Wer das braucht, braucht ein laufendes System — und dann ist Wartung die Antwort, nicht Einfrieren. Für einen Restaurantbetrieb mit Tischreservation ist FreezrCMS falsch. Für eine Gemeinde, die Zahlen veröffentlicht, ist es richtig.
Wir sagen das so deutlich, weil die bequeme Version dieses Beitrags anders geklungen hätte.
Warum wir das selbst bauen
Auf unserer Produkteseite stehen sechs eigene Entwicklungen, und der Grund ist immer derselbe: Wer ein System nicht nur verkauft, sondern täglich damit arbeitet, merkt früher, wo es hakt — und wer den Quelltext kennt, behebt eine Störung, statt ein Ticket beim Hersteller zu eröffnen.
Bei FreezrCMS kam noch etwas dazu. Wir schreiben seit Monaten jede Woche über dieselbe Art von Problem, und irgendwann stellt sich die Frage, ob man es immer nur berichten will.
Anschauen lässt sich das System unter freezrcms.ch, es gibt dort eine Demo. Und wenn Sie eine bestehende Website haben und wissen wollen, welche der 20 Meldungen Sie betroffen hätte: Das können wir nachsehen, das ist eine halbe Stunde Arbeit.