Ein Update-Wächter für selbst betriebene Software

Microsoft schreibt in seinem Lagebericht vom 1. Oktober, dass von der Entdeckung einer Sicherheitslücke bis zu ihrer Ausnutzung im Median deutlich weniger als 24 Stunden vergehen, und dass Unternehmen 30 bis 60 Tage brauchen, um sie zu schließen. Unser Leitfaden zum Selbsthosten von n8n trägt die Fassung bewusst von Hand ein. Das ist richtig, aber es setzt voraus, dass jemand erfährt, wann es Zeit dafür ist. Wir bauen den Teil, der es erfährt: ein Skript, das jeden Morgen nachsieht und sich nur meldet, wenn es etwas zu sagen hat.

Was du danach in der Hand hast:

• ein Skript, das für eine Liste eurer Software prüft, ob es eine neuere Fassung gibt und ob eine veröffentlichte Sicherheitsmeldung eure eingetragene Fassung betrifft
• einen Vorschlag, auf welche Fassung ihr gehen müsst, damit alle gefundenen Lücken geschlossen sind
• höchstens eine Meldung am Tag, als Datei und auf Wunsch als Mail, statt einer Benachrichtigung je Veröffentlichung
• die Zeile für den Zeitplan

Voraussetzungen: ein Server oder Rechner, der jeden Tag läuft, mit Python 3 (gebaut und geprüft mit 3.12.2) und Zugang zu api.github.com. Für die Mail ein SMTP-Konto. Kein GitHub-Konto, kein Schlüssel, keine Kosten.

Der Aufbau

Was wir weglassen: das Aktualisieren selbst. Der Wächter liest, vergleicht und meldet. Er zieht kein Abbild, startet nichts neu und ändert keine .env. Den Sprung macht weiter ein Mensch, mit dem Skript aus dem Leitfaden und nach einem Blick in die Anmerkungen zur neuen Fassung. Ebenfalls weggelassen: allgemeine Schwachstellendatenbanken wie die NVD. Die Projekte selbst wissen am genauesten, welche ihrer Fassungen betroffen sind, und ihre Meldungen liegen auf GitHub.

Das Inventar

Ein Eintrag je Programm. Die Fassungen in unserem Beispiel stammen für n8n und Postgres aus dem Leitfaden zum Selbsthosten, Stand 19. September 2026; Nextcloud und Paperless-ngx haben wir ausgedacht, weil wir sie für diesen Beitrag nicht betreiben.

{
  "name": "n8n",
  "repo": "n8n-io/n8n",
  "fassung_aus": {"datei": "beispiel-n8n.env", "schluessel": "N8N_VERSION"},
  "tag_praefix": "n8n@",
  "reihe_stellen": 2,
  "meldungen_repo": "n8n-io/n8n",
  "meldungen_paket": "n8n",
  "erreichbar_von_aussen": true
}

reihe_stellen sagt, was bei diesem Projekt eine Reihe ist. n8n pflegt Korrekturen je Nebenfassung, also 2.41 und 2.42 getrennt; Nextcloud je Hauptfassung, also 34 und 35. Das braucht der Wächter, um zu entscheiden, ob eine Korrektur eure Reihe betrifft. Steht in der .env „latest“, bricht der Eintrag mit einer Meldung ab: dann weiß niemand, was läuft, auch der Wächter nicht.

Drei Quellen, drei Eigenheiten

Die erste Abfrage gegen die echte API am 4. Oktober 2026 hat drei Dinge gezeigt, die in keiner Anleitung stehen.

n8n führt neben den nummerierten Fassungen zwei Veröffentlichungen namens „stable“ und „beta“. Das sind wandernde Namen, die auf die jeweils aktuelle Fassung zeigen. „stable“ war an diesem Tag der oberste Eintrag der Liste und nicht als Vorabfassung markiert. Wer einfach den obersten Eintrag nimmt, bekommt einen Namen statt einer Nummer.

Postgres veröffentlicht auf GitHub keine Releases, die Liste ist leer. Es gibt nur einen Spiegel des Quellcodes mit Tags, und die Tag-Liste kommt alphabetisch sortiert: Für die Reihe 17 standen am Prüftag REL_17_0, REL_17_1, REL_17_10, REL_17_11, REL_17_2 und so weiter. Als Text ist REL_17_9 die größte Nummer. Der Wächter fragt deshalb nur die Tags der eigenen Reihe ab, in einer einzigen Anfrage, und vergleicht Zahlen:

def fassung(text, praefix=""):
    """'n8n@2.41.6' -> (2, 41, 6). Vorabfassungen (rc, beta) und Namen wie 'stable' -> None."""
    if text is None:
        return None
    t = text.strip()
    if praefix and t.startswith(praefix):
        t = t[len(praefix):]
    t = t.removeprefix("v").removeprefix("REL_").replace("_", ".")
    if not re.fullmatch(r"\d+(\.\d+)+", t):
        return None
    return tuple(int(x) for x in t.split("."))

Ein Tupel aus Zahlen vergleicht Python Stelle für Stelle, und (17, 11) ist größer als (17, 9). Alles, was nicht nur aus Ziffern und Punkten besteht, ist keine Fassung: „stable“, „beta“, „v35.0.1rc1“, „REL_17_BETA1“.

Nextcloud schreibt in seine Releases nur einen Verweis auf ein anderes Repository und keine Anmerkungen. Die Sicherheitsmeldungen liegen in einem eigenen Repository, nextcloud/security-advisories, zusammen mit denen für alle Nextcloud-Apps. Der Eintrag im Inventar filtert deshalb auf das Paket „Server“ und lässt die Enterprise-Fassungen weg, deren Nummern vierstellig sind.

Welche Meldung euch betrifft

Jede Sicherheitsmeldung auf GitHub nennt betroffene Bereiche und korrigierte Fassungen. Wörtlich nehmen kann man die Bereiche nicht. Drei echte Beispiele aus den Antworten vom 4. Oktober:

n8n             GHSA-x5cw-hm7v-q7mj  betroffen: < 1.123.83 | < 2.42.1 | < 2.41.4
Nextcloud       GHSA-7hwf-8pcj-33h4  betroffen: >= 32.0.0, >= 33.0.0, >= 34.0.0
                                     korrigiert: 32.0.13, 33.0.7, 34.0.2
Paperless-ngx   GHSA-59xh-5vwx-4c4q  betroffen: v2.14.5 >= paperless-ngx <= v2.20.10

Bei n8n liegt 2.41.5 formal unter 2.42.1 und wäre damit betroffen, obwohl die Reihe 2.41 ab 2.41.4 korrigiert ist. Bei Nextcloud ergibt die Bedingung wörtlich gelesen „ab 34.0.0“, gemeint sind drei Reihen. Bei Paperless-ngx ist die Angabe keine Bedingung, sondern ein Satz. Der Wächter liest deshalb nur die korrigierten Fassungen und entscheidet über die eigene Reihe:

def bewerte_meldung(eingetragen, korrigiert, reihe_stellen):
    if not korrigiert:
        return "unklar", None
    reihe = eingetragen[:reihe_stellen]
    eigene = [k for k in korrigiert if k[:reihe_stellen] == reihe]
    if eigene:
        ziel = min(eigene)
        return ("betroffen", ziel) if eingetragen < ziel else (None, None)
    if eingetragen >= max(korrigiert):
        return None, None
    hoeher = [k for k in korrigiert if k > eingetragen]
    return "reihe_nicht_genannt", min(hoeher)

Gibt es eine Korrektur in eurer Reihe, zählt nur sie. Liegt eure Fassung über allen Korrekturen, betrifft euch die Meldung nicht. Bleibt der dritte Fall: Eure Reihe ist gar nicht genannt, und es gibt Korrekturen über eurer Fassung. Dann ist die Reihe entweder betroffen und ohne Korrektur, oder sie wird nicht mehr gepflegt. Für euch heißt beides dasselbe, und der Wächter sagt das ausdrücklich, statt zu raten.

Was dabei herauskommt

Der erste vollständige Lauf, am 4. Oktober 2026 um 17:38 gegen die echte GitHub-API:

[Update-Wächter] 2 Sicherheit, 1 neu (04.10.2026)
Update-Wächter, Prüfung vom 04.10.2026 17:38
Quelle: GitHub-API ohne Schlüssel, 7 Anfragen, danach 24 von 60 frei

SICHERHEIT (steht jeden Tag wieder hier, bis die Fassung eingetragen ist)
- n8n 2.39.8 (von außen erreichbar): 12 Sicherheitsmeldung(en), höchste Stufe high
    GHSA-x5cw-hm7v-q7mj  high    2026-09-30  n8n Chat Trigger Stored XSS via customCss Parameter on Hoste
    GHSA-x8wx-g24x-3549  high    2026-09-30  Code Execution in the Git Node Log Operation via Unneutraliz
    GHSA-5jr4-xmvf-frmj  high    2026-09-30  Shared Prototype Mutation Through the MCP Workflow-Validatio
    GHSA-728h-pmr2-7cgh  high    2026-09-30  Send-and-Wait HMAC Bypass Allows Unauthenticated Approval of
    GHSA-x25p-9mr6-cwgp  high    2026-09-30  Shared-Workflow Credential Check Misses Agent Node Parameter
    ... und 7 weitere
    Eure Reihe 2.39 ist in den Meldungen nicht genannt: nicht mehr gepflegt oder ohne Korrektur.
    Vorschlag: auf 2.41.6 gehen (behebt alle 12), vorher sichern, Anmerkungen zur Fassung lesen.
- Nextcloud 34.0.1 (von außen erreichbar): 1 Sicherheitsmeldung(en), höchste Stufe high
    GHSA-7hwf-8pcj-33h4  high    2026-09-17  ImageMagick vulnerability abusable via previews of malicious
    Vorschlag: auf 34.0.4 gehen (behebt sie), neueste insgesamt 35.0.1, vorher sichern, Anmerkungen zur Fassung lesen.

NEUE FASSUNGEN (einmalig)
- Paperless-ngx 3.2.0 -> 3.2.1

OHNE HANDLUNGSBEDARF HEUTE
- PostgreSQL 17.11: aktuell

Die Zahl, die zählt, steht in der ersten Zeile unter SICHERHEIT. n8n 2.39.8 ist die Fassung, mit der wir den Leitfaden am 19. September nachgeprüft haben, damals die neueste stabile. Zwei Wochen später betreffen sie zwölf veröffentlichte Meldungen, acht davon mit der Stufe high, alle vom 30. September. Die korrigierte Fassung 2.41.4 ist laut GitHub am selben Morgen um 6:04 Uhr UTC erschienen, die Meldungen zwischen 8:35 und 8:38 Uhr. Die Reihe 2.39 hatte ihre letzte Fassung am 21. September und taucht in keiner der Meldungen auf.

Dass der Wächter nicht einfach alles meldet, zeigt derselbe Tag: n8n hat am 30. September 14 Meldungen veröffentlicht, nicht zwölf. Zwei davon nennen nur die alte 1er-Reihe als betroffen, behoben ab 1.123.83; die hat er zu Recht weggelassen. Und die beiden Meldungen vom 16. September mit der Stufe high sind in der Reihe 2.39 ab 2.39.6 behoben, 2.39.8 ist davon nicht betroffen. Beides haben wir nach dem Lauf in den Rohdaten nachgesehen.

Wer am 30. September Bescheid wissen wollte, hätte am 1. Oktober eine Meldung gebraucht. Wer nachsieht, „wenn wir dazu kommen“, liegt mitten in den 30 bis 60 Tagen aus Microsofts Bericht.

Der Kern der Korrektur sind vier Zeilen:

mindestens = max(fassung(m["ab"]) for m in e["meldungen"])
n = e["reihe_stellen"]
passend = [f for f in e["alle"] if f[:n] == mindestens[:n] and f >= mindestens]
ziel = max(passend) if passend else mindestens

Bei n8n heißt das ein Sprung von 2.39 auf 2.41, also über zwei Nebenfassungen. Der Wächter sagt deshalb dazu, dass vor dem Sprung die Anmerkungen zur Fassung zu lesen sind. Die Entscheidung, ob ein laufender Ablauf das verträgt, nimmt er euch nicht ab.

Eine Meldung am Tag, nicht eine je Veröffentlichung

Vom 21. September bis zum 2. Oktober hat n8n auf GitHub 20 Releases veröffentlicht: 18 nummerierte Fassungen, sieben davon als Vorabfassung markiert, dazu die wandernden Einträge „stable“ und „beta“. Wer jede davon als Mail bekommt, liest nach der dritten keine mehr. Der Wächter merkt sich in zustand.json, wann er zuletzt gemeldet hat und welche gewöhnlichen Fassungen schon gemeldet sind. Ein zweiter Aufruf am selben Tag fragt GitHub gar nicht erst:

Heute (2026-10-04) wurde schon gemeldet. Nichts abgefragt. Mit --erzwingen trotzdem.

Am nächsten Tag stehen die Sicherheitsbefunde wieder drin, die gewöhnliche neue Fassung nicht mehr. So sah das aus, als wir am selben Nachmittag mit --heute 2026-10-05 einen zweiten Tag vorgegeben haben; die GitHub-Daten sind also die vom 4. Oktober:

[Update-Wächter] 2 Sicherheit, 0 neu (05.10.2026)
...
OHNE HANDLUNGSBEDARF HEUTE
- Paperless-ngx 3.2.0 -> 3.2.1  [gemeldet am 2026-10-04]
- PostgreSQL 17.11: aktuell

Gibt es weder einen Sicherheitsbefund noch etwas Neues, schreibt der Wächter keine Meldung. Und wenn er nicht prüfen kann, weil GitHub nicht antwortet oder das Kontingent aufgebraucht ist, geht das denselben Weg wie eine Meldung, als Datei und als Mail. Ein Wächter, der still ausfällt, ist schlechter als keiner, weil sich alle auf ihn verlassen.

Ratenlimit

Ohne Anmeldung erlaubt GitHub 60 Anfragen pro Stunde, gezählt je IP-Adresse, nicht je Programm. Ein Lauf braucht zwei Anfragen je Programm, bei unserem Inventar sieben, weil Postgres keine Sicherheitsmeldungen auf GitHub hat. Vor dem Lauf fragt der Wächter /rate_limit ab, was selbst nicht mitzählt, und bricht ab, wenn weniger frei ist als gebraucht.

In der Ausgabe oben steht „danach 24 von 60 frei“. Das ist nicht der Verbrauch eines Laufs, sondern der unserer Stunde: Vorher hatten wir die API von Hand befragt, um die Antworten kennenzulernen, und den Wächter zweimal laufen lassen, einmal davon mit dem falschen Vorschlag aus der Practice-Note. Auf einem Server teilen sich alle Werkzeuge dasselbe Kontingent, auch aktualisieren.sh aus dem Leitfaden, das bei jedem Aufruf eine Anfrage stellt. Für einen Lauf am Tag ist das kein Engpass. Wer zwanzig Programme überwacht oder stündlich prüfen will, setzt GITHUB_TOKEN; dann gelten 5.000 Anfragen pro Stunde.

Zeitplan und Zustellung

Der Wächter läuft auf dem Server, nicht in n8n. Wenn n8n steht oder kaputt aktualisiert ist, soll die Meldung trotzdem kommen. Die Zeile in der crontab:

15 7 * * * cd /opt/update-waechter && /usr/bin/python3 waechter.py --kanal mail >> protokoll.log 2>&1

Geprüft haben wir das in einem Container mit python:3.12-alpine und dem dort mitgelieferten crond, mit derselben Zeile, aber minütlich statt um 7:15, und mit einem Inventar, in dem n8n, Nextcloud und Paperless schon auf dem vorgeschlagenen Stand waren. Der Lauf kam um 15:40:03, obwohl es 17:40 Uhr war: Der Container rechnet in UTC. Auf einem Server gilt die Zeitzone des Systems, timedatectl zeigt sie. Das Protokoll dieses Laufs:

[Update-Wächter] 0 Sicherheit, 1 neu (04.10.2026)
NEUE FASSUNGEN (einmalig)
- Nextcloud 34.0.4 -> 35.0.1

OHNE HANDLUNGSBEDARF HEUTE
- n8n 2.41.6: aktuell
- Paperless-ngx 3.2.1: aktuell
- PostgreSQL 17.11: aktuell

Der Rückgabewert ist 2 bei einem Sicherheitsbefund, 1, wenn nicht geprüft werden konnte, sonst 0. Wer die Meldung in ein Ticketsystem oder einen Chat schicken will, kann daran anknüpfen.

Die Mail geht über SMTP, mit den Zugangsdaten aus einer .env neben dem Skript. Ohne --kanal mail verschickt der Wächter nichts und schreibt nur nach meldungen/. Ausprobiert haben wir den Mailweg ausschließlich gegen einen lokalen Mailfänger, Mailpit in Docker, der Mails annimmt und nirgendwohin weiterleitet. Dort kamen die Tagesmeldung und, in einem eigenen Versuch mit absichtlich falscher API-Adresse, die Fehlermeldung „[Update-Wächter] konnte nicht prüfen (04.10.2026)“ an. Eine echte Mail ist bei keinem der Läufe verschickt worden.

Wer die Prüfung lieber in n8n sieht: Ein Schedule Trigger mit HTTP-Request-Knoten an dieselben Adressen würde gehen, gebaut haben wir es nicht. Den Wächter über einen Execute-Command-Knoten aufzurufen, scheitert schon daran, dass dieser Knoten in der 2er-Reihe ab Werk abgeschaltet ist, und es widerspricht dem Zweck: Der Wächter von n8n sollte nicht von n8n abhängen.

Was das nicht kann

• Er kennt nur Sicherheitsmeldungen, die das Projekt als GitHub Security Advisory veröffentlicht, und davon die letzten 50. Postgres meldet auf postgresql.org. Dort sagt der Wächter nur, dass es eine neue Kleinfassung gibt. Laut der Versionsrichtlinie von Postgres enthalten Kleinfassungen auch Sicherheitskorrekturen, und das Projekt empfiehlt, immer die aktuelle Kleinfassung der eigenen Hauptfassung zu betreiben.
• Er sieht, was eingetragen ist, nicht was läuft. Wer die Fassung am Server von Hand ändert und das Inventar vergisst, bekommt Meldungen zu einem Stand, den es nicht mehr gibt. Bei n8n liest er deshalb die .env, aus der auch Docker Compose liest.
• Er verlässt sich auf die Angaben der Projekte. Fehlt in einer Meldung die korrigierte Fassung, oder ist eure Reihe nicht genannt, meldet er das als Befund. Das kann zu viel melden, aber nicht zu wenig. Und er bewertet nicht, ob eine Lücke euch überhaupt trifft: Eine XSS-Lücke im Chat-Trigger betrifft nur, wer den Chat-Trigger nutzt. Diese Abwägung bleibt bei dem, der die Meldung liest.

Zum Nachbauen

Das Paket enthält den Wächter, das Inventar aus diesem Beitrag, die Vorlagen für Mail und Zeitplan, die Tests und die echten Meldungen aus unseren Läufen. Python 3 genügt, keine weiteren Pakete. Dann:

• waechter.py: der Wächter. Ohne Argument prüfen und nach meldungen/ schreiben, mit --nur-anzeigen nur anzeigen, mit --kanal mail zusätzlich per Mail.
• inventar.json und beispiel-n8n.env: das Inventar aus diesem Beitrag. Eure Programme eintragen, dann einmal mit --nur-anzeigen prüfen, ob jede Fassung richtig erkannt wird.
• .env.example: der SMTP-Zugang, als .env neben das Skript legen.
• crontab.txt: die Zeile für 7:15 Uhr.
• test_waechter.py: die Vergleichslogik mit den Fällen aus den echten Antworten vom 4. Oktober, auch dem falschen Vorschlag aus der Practice-Note. Läuft ohne Netz.
• beispiel-meldungen/: die Meldungen aus diesem Beitrag, mit Datum.
• AUFTRAG.md: die Regeln, nach denen der Wächter gebaut ist, als Übergabe an einen Agenten, wenn ihr ihn erweitern wollt.

Stand dieses Artikels

Gebaut und gegen die echte GitHub-API gelaufen am 4. Oktober 2026 zwischen 17:33 und 17:40 Uhr MESZ, mit Python 3.12.2 auf einem Mac. Alle Ausgaben in diesem Beitrag stammen aus diesen Läufen; die Meldung „05.10.2026“ ist am selben Nachmittag mit vorgegebenem Datum entstanden. Den Zeitplan haben wir in einem Container python:3.12-alpine mit dessen crond geprüft, die Mail gegen Mailpit 1.31.4 auf dem eigenen Rechner. Das Ratenlimit von 60 Anfragen pro Stunde haben wir am 4. Oktober in der GitHub-Dokumentation nachgelesen und in den Antwortköpfen gesehen. Die Uhrzeiten der n8n-Meldungen und die Zahl der Releases vom 21. September bis 2. Oktober haben wir gegen 18 Uhr desselben Tages von Hand aus der API gelesen.

Die Fassungen im Inventar sind Beispiele: n8n 2.39.8 und Postgres 17.11 aus dem Leitfaden, Nextcloud 34.0.1 und Paperless-ngx 3.2.0 ausgedacht. Wie Microsoft zu seinen Zahlen kommt, haben wir nicht nachvollzogen; sie stehen so in unserer News zum Lagebericht. Nicht geprüft: der Lauf auf einem echten Server mit dem cron-Dienst einer Linux-Distribution, der Versand über einen echten Mailanbieter, das Verhalten über Wochen mit wachsender zustand.json, der Weg mit GITHUB_TOKEN und Projekte, deren Fassungsnummern anders aufgebaut sind als die der vier hier.

Häufige Fragen