Fix Required on Schallberts Blog

PHP2shell: Kritische Sicherheitslücken

Schallbert — Wed, 21 Oct 2026

Schritt 1 Erkennen: Wir haben ein Problem.

TLDR: PHP hat ganz aktuell zwei kritische Schwachstellen, die Remote Code Execution ermöglichen. Ihre IDs: CVE-2026-109618 und CVE-2026-109619. Da ihre Ursachen nicht im Frontend sondern in der Engine stecken, hilft nur ein Update auf PHP 8.5.12, 8.4.27, 8.3.36, oder 8.2.35.

“PHP nutze ich nicht auf meiner Website”, denke ich, als ich heute Vormittag die folgende Nachricht erhalte:

“Hi, kurzer Hinweis: Gegebenenfalls […] alles was php nutzt, erstmal abklemmen, […] Patch kommt später heute.”

Oder bin ich doch betroffen…? Immerhin nutze ich eine managed Nextcloud-Instanz, und Nextcloud ist doch u.A. in PHP geschrieben…? Während ich diese Zeilen schreibe, wird ein Fix für Nextcloud verfügbar. Alles muss also sehr schnell gehen. Heute werden unter Garantie viele Überstunden gemacht.

Status 21.10.2026, 10:30 MESZ

Spulen wir zehn Stunden zurück. Es gibt noch keinen Fix. Die Information über die CVEs wurde geleakt und ist jetzt selbst bereits ein paar Stunden alt. Laut Wikipedia nutzen 69% aller Websites PHP. Das Ausnutzen einer so hochkritischen Lücke (Score 9.2) bei einer derart weitverbreiteten Technologie hat erwartbar massive Auswirkungen. Entsprechend nervös ist “das Internet”.

“[…] organisations should consider isolating internet-facing applications from public networks until a fix is applied and verified. CERT-EU, pulled 21.10.2026, 10:40

Interessant, die Empfehlung ist also ernsthaft “erstmal vom Netz nehmen”.

Schritt 2 Sofortmaßnahmen: Nextcloud vom Netz trennen

Um einem möglichen Angriff zuvor zu kommen versuche ich folglich, meine Instanz vom Netz zu nehmen. Dafür logge ich mich bei meinem Hoster ein, wechsle auf das Tab “Einstellungen”, und klicke auf den Reiter ownCloud Console. Dies ist Nextclouds command-line interface.

Dort muss ich feststellen, dass kein Befehl zum Abschalten oder de-publishing zur Verfügung steht. Also wähle ich den Nächstbesten:

occ maintenance:mode --on

Ich versetze meine Instanz also in den Wartungsmodus. Dies verhindert neue Logins und friert die Datenbank ein. Anschließend lese ich mich ein wenig in die CVEs ein um herauszufinden, ob mein Schritt genügt.

Tut er wohl nicht.

In verschiedenen Foren und auf HackerNews erfahre ich, dass eine nicht authentisierte Anfrage bereits den Angriff auslösen kann, bevor überhaupt PHP-Code auf der Serverseite ausgeführt wird.

Es ist also egal, in welchen Zustand ich meine Instanz versetze - solange sie am Netz ist, bleibt sie angreifbar.

Schritt 3 Vorläufige Eindämmung: Nextcloud-Instanz deaktivieren lassen

Ich finde auch mit Hilfe diverser Online-Suchanfragen keinen Weg, meine mangaged-Instanz abzuschalten. Ich überlege kurz, die Namensauflösung und das DNS-Routing zu killen. Mir wird aber schnell klar: Bis sich das durchpropagiert, ist der Fix längst draußen.

Status 21.10.2026 11:43 MESZ

Ich schreibe also ein Support-Ticket an meinen Hoster mit der Bitte um Hilfe beim Herunternehmen meiner Instanz.

Status 21.10.2026 12:01 MESZ

Ich erhalte eine Mail vom Hoster!

Tatsache, ich kann die Instanz nicht mehr erreichen und erhalte eine ERR_CERT_COMMON_NAME_INVALID-Meldung. Klicke ich diese weg, erscheint REQUESTED PAGE LOCKED. Gute Arbeit. Die Reaktionszeit meines Anbieters inlusive Rückmeldung an den Kunden betrug 18min.

Nun wechsle ich den Modus vom Akteur zum Beobachter. Ich sehe erste Exploit-Versuche (oder zumindest Beteuerungen davon) im Web und muss an eine Folie eines Vortrages denken (Zeitstempel 11:24), den ich vor kurzem gesehen habe: Security in the LLM age.

Dort zeigt ein Linux-Kernel Sachverständiger, dass wir in 2026 im Schnitt sieben Tage vor einem Patch in betroffener Software bereits Exploits in freier Wildbahn sehen.

discover --> disclose --> patch --> deploy

Diese traditionelle Ereigniskette funktioniert nur bei “langsamen” Angreifern gut. Wir benötigen etwas, um wieder vor die Lage zu kommen.

Schritt 4 Beobachten der Situation: Verfügbarkeit des Patches, Einspielen erster Betreiber

Laut Hackernews wird der Patch um etwa 16:00 MESZ verfügbar. Ich besorge mir den RSS-Feed meines Hosters und warte auf Meldung.

Status 21.10.2026 14:20 MESZ

Auch das Bundesamt für Sicherheit in der Informationstechnik hat einen BSI-IT-Sicherheitshinweis herausgegeben, wo mit der “Kritikalität 3/Orange” vor der Lücke gewarnt und folgendes angemerkt wird:

“Der Patch für die Schwachstelle ist heute 16 Uhr deutscher Zeit (14:00 UTC) angekündigt und sollte unverzüglich zu diesem Zeitpunkt installiert werden.” - BSI, 21.10.2026

Status 21.10.2026 16:34 MESZ

Mein Hoster meldet, dass die Patches nun verfügbar seien und mit der Implementierung begonnen würde. Betroffen sind nicht nur die Nextcloud-Instanzen, sondern auch seine komplette Administrationsoberfläche sowie sein Webmailer.

Status 21.10.2026 19:52 MESZ

Mein Hoster meldet Vollzug für die von ihm betriebenen Webhosting-Angebote und Managed Servers.

Status 21.10.2026 22:40 MESZ

Die Hetzner-Anwendung KonsoleH, über die ich meine Nextcloud-Instanz verwalte, ist down.

Status 21.10.2026 23:00 MESZ

KonsoleH ist wieder live (und gepatcht).

Schritt 5 Erkenntnis und Schlussfolgerung

Was lerne ich aus den Ereignissen dieses turbulenten Tages? Wie gehe ich in Zukunft mit Sicherheitslücken um? Und wie erkenne ich überhaupt, dass ein Problem vorliegt?

Nicht nur der Service als Ganzes ist angreifbar sondern auch seine Komponenten. –> Kenne alle Komponenten und achte auf Schwachstellen und Patches!
Die Gegenspieler sind (durch LLMs) unglaublich schnell geworden. –> Rechne mit Exploit vor Patch-Verfügbarkeit!

Eine Liste geeigneter Quellen für Verwundbarkeiten, Neuigkeiten und Patches stelle ich mir gerade zusammen. Sobald die Liste stabil ist, werde ich darüber berichten.

Schritt 6 Aktionen

Sensible Daten wenn möglich aus dem Netz nehmen. Gedankengang: Was wäre, wenn das weg kommt? Reicht Verfügbarkeit im LAN/Intranet?
Besseres Monitoring und Abuse detection sind nur konsequent: Früh erkennen, früh sperren, früh melden, früh abschalten, sofort patchen.
Standardbezugsquellen für Informationen zu verwendeter Software besorgen. CVE-List-Scanner bauen? HackerNews-Filter?

Nachtrag: 22.10.2026 09:30 MESZ

Der Hoster hat meine Nextcloud-Instanz gepatcht und wieder online genommen. Alle Systeme normal. Es gibt nun auch einen Wikipedia-Eintrag zum Thema, der sehr aktuell gehalten wird.

Kritische Schwachstellen bei Gitea (und Forgejo)

Schallbert — Sun, 04 Oct 2026

Gewahrwerdung

Wie so oft beginnt auch diese Geschichte mit einem Netzwerk der menschlichen Kommunikation. Dieser unersetzliche Austausch hat schon viel zur Sicherheit der Software beigetragen, mit der ich diesen Blog betreibe. Nun kann ich eine weitere Sicherheitslücke schließen. Aber der Reihe nach.

Gitea als Angriffsziel

Ich hörte, dass die selbst gehostete Versionsverwaltungslösung Gitea eines meiner Bekannten Ziel einer Attacke geworden ist. Hierbei wurde eine RCE (Remote Code Execution) möglich und tatsächlich auch ausgeführt.

Warum ist Gitea ein attraktives Ziel?

Diebstahl von (Firmen)geheimnissen: Bei Zugriff auf Repositories ist vertraulicher Quellcode gefährdet, offengelegt zu werden.
Abfluss von Zugangsdaten: Wird ein größeres Produkt mit Schnittstellen in Gitea verwaltet, sind API keys, Konten und Passwörter in Gefahr, falls sie unverschlüsselt vorliegen. Abhilfe schaffen Tools wie git-secret; sie werden aber durch Einführen zusätzlicher Komplexität noch nicht flächendeckend eingesetzt.
Klassische Rechteeskalation: Unter Umständen kann man durch Ausbruch aus der Gitea-Software die ganze Maschine übernehmen.
Nutzen des runner: Schafft man es den Runner zu kapern, kann man auch ohne erweiterte Rechte Ressourcen der Hostmaschine in Beschlag nehmen und für eigene Zwecke missbrauchen (Stichwort Cryptominers in CI/CD).

Was ist eine RCE?

Eine Remote Code Execution ist ein erfolgreicher Angriff, bei dem nicht autorisierter Code ohne Zutun von Besitzer oder Administration der befallenen Ressource aus der Ferne über das Netzwerk eingespielt und ausgeführt werden kann.

Das Gitea-Ökosystem

Als Versionsverwaltung und forge gehört zum Basisumfang von Gitea die Möglichkeit, webbasiert und kollaborativ Software zu entwickeln und zu bauen. Daher ist vorgesehen, dass sich Nutzer registrieren und unter Umständen sogar Aktionen ausführen können, damit Software automatisiert gebaut und/oder ausgeliefert werden kann.

Genau dieses automatische Nachladen und Ausführen von Code kann böse Folgen haben, wenn Sicherheitslücken in der Verwaltungssoftware selbst bestehen.

Verwundbarkeit durch offene Registrierung

Lässt man als Betreiberin die Registrierung neuer Accounts (“self-registration”) in Giteas Konfiguration auf dem Standardwert DISABLE_REGISTRATION = false, so können sich Nutzerinnen selbst einschreiben, eigene Repository anlegen, issues aufmachen und alles tun, was ohne Adminrechte möglich ist.

Hat man zusätzlich noch den Standardwert REQUIRE_SIGNIN_VIEW = false gesetzt, können auch unauthentisierte Besucher öffentliche Repositories sehen, die Seiten von Gitea browsen und vor allem die öffentliche API des Gitea Endpoints ansprechen.

Verwundbarkeit durch Standardkonfiguration für Reverse Proxies

In der Standardkonfiguration des Gitea Docker image vertraut Gitea <V1.26.3 allen Proxies.

# gitea/app.ini

[security]
REVERSE_PROXY_LIMIT = 1
REVERSE_PROXY_TRUSTED_PROXIES = * # This is a vulnerability!

Die Sicherheitslücken

Womit haben wir es hier zu tun? Mit mehreren kritischen Sicherheitslücken des Ausmaßes 9.8/10 CVSS score, von denen es bekannte Fälle der Ausnutzung gibt.

Exkurs: Die CVSS-Bewertung

Zur Einordnung der Bewertung von “kritisch”: Die CVSS-Kriterien sind ähnlich aufgebaut wie in der klassischen Gefahren- und Risikoanalyse, einem Zweig der Ingenieurswissenschaften. Anders als dort liegt der Fokus allerdings nicht in der Analyse möglicher Fehlerfälle, Schweregrad, Eintritts- und Ausfallwahrscheinlichkeit oder Detektierbarkeit, sondern auf dem Schwierigkeitsgrad der Ausnutzung und möglicher Auswirkungen.

Bedeutung der CVSS-Einzelwerte

Je höher der CVSS-Wert, desto einfacher ist die Sicherheitslücke auszunutzen und desto gravierender sind mögliche Folgen hinsichtlich der Datensicherheitskriterien (Confidentiality, Integrity, Availability).

Das Bild oben zeigt eine Konstellation, in der eine mögliche Attacke aus der Ferne (Netzwerk) mit geringem Aufwand (Complexity, meint Systemhärtung) ohne Randbedingungen (Requirement, z.B. das Anfahren einer vulnerablen Stelle im Code, Vorhandensein eines bestimmten Zustandes des angegriffenen Systems, Auslösen einer race condition etc.), ohne zusätzliche Rechte (als Gast ohne Authentisierung oder Autorisierung) oder Interaktion mit dem User oder der Administratorin des Systems durchgeführt werden kann.

Das wäre für sich genommen noch nicht schlimm, wenn niemand das System benötigt Score 0.0 und nichts Interessantes darauf gespeichert ist. Liegen dort allerdings sensitive Daten Confidentiality, 8.7 oder zum Beispiel eine Datenbank, deren Werte sich nun manipulieren lassen Integrity, 8.7, oder wird auch nur die Verfügbarkeit von benötigten Daten eingeschränkt Availability, 8.7, befindet man sich bereits im Bereich High.

Mit diesem Wissen nehmen wir nun den Transfer auf die kritischen Lücken von Gitea vor.

CVE-2026-20896: Authentication bug in Gitea through reverse-proxies

Kommt ein Angreifer hinter den Reverse Proxy (oder ist gar kein Reverse Proxy vorgeschaltet), kann er eine Anfrage mit X-WEBAUTH-USER im Header direkt an die Gitea-Instanz senden und sich für einen Reverse Proxy ausgeben. Ist Gitea gleichzeitig darauf eingestellt, allen reverse proxies zu vertrauen REVERSE_PROXY_TRUSTED_PROXIES = *, so geht es davon aus, dass bereits authentisiert wurde und eine gültige Session vorliegt. Der Angreifer erhält also Nutzerrechte mit Schreibzugriff auf Repositories, obwohl er nicht mal einen Account angelegt hat.

Das eigentliche Lücke ist hier das unhinterfragte Vertrauen gegenüber dem Sender des Headers ohne weiteren Abgleich mit einem Session Token oder ähnlichem; das Annehmen desselben von fremden Quellen erzeugt lediglich die Verwundbarkeit.

Für diesen Bug gibt es Belege für bereits erfolgte Attacken.

CVE-2026-59774: File-read flaw for anything the Gitea Service Account can read

Diese kritische Sicherheitslücke basiert auf einer unzureichenden Eingabeprüfung des eingebauten Textrenderers von Gitea für org-mode Dateien. Eine detaillierte Beschreibung des Vektors und zu möglichen Wegen eines Angriffs kann auf Saytam Rastogis hervorragendem Blog nachgelesen werden.

Kurzgesagt kann sich ein Angreifer mit Zugriff auf zumindest ein öffentliches Repository eine bösartige .org-Datei zusammenbasteln, mit deren Hilfe er Giteas Konfiguration app.ini auslesen und damit auf darin enthaltene Secrets zugreifen kann, welche ihm erweiterte Rechte zugestehen oder ihn zumindest lateral auf dem System bewegen lassen.

Dies kann laut hacker news und Giteas eigenen Leuten zufolge beispielsweise auch dazu ausgenutzt werden, die Registration Token eines Runners auszulesen und selbigen zu übernehmen.

CVE-2026-60004: RCE allowing attacker with ordinary user rights to execute arbitrary shell commands as the Gitea OS user.

Diese Sicherheitslücke ist deswegen besonders schlimm, weil sie zusätzlich eine privilege escalation ermöglicht.

“The vulnerability in question is CVE-2026-60004 (CVSS score: 9.8), a case of remote code execution that allows an attacker with ordinary write access to a repository to execute arbitrary shell commands as the Gitea OS user.” thehackernews, Aug-2026

Das Ausnutzen dieser Lücke kann den Angreifer also die gesamte Gitea-Instanz übernehmen lassen, sofern er Schreibzugriff auf irgendein (evtl. sogar öffentliches) Repository hat.

Das Lagebild

Es gibt noch weitere kritische Sicherheitslücken, allerdings könen sich Angreifer mit einer Kombination der obigen Darstellungen ohne großen Aufwand

Als normale User auf dem Gitea-System bewegen, ohne sich registriert zu haben, und ohne SSH-Zugriff zu benötigen
Sich als Gitea-Service User ausgeben
Actions übernehmen oder sogar Workflows injizieren und ausführen
Mit etwas Mehraufwand die gesamte Instanz übernehmen, verschlüsseln, Lösegeld verlangen usw.

Was mein Bekannter erlebt hat betraf die Punkte eins und drei. Der Angriff wurde sehr wahrscheinlich automatisiert ausgeführt, nachdem das Internet auf verwundbare Instanzen gescannt worden war.

Zusammengefasst kann man im vorliegenden Fall von einer Mass-Exploitation Campaign für Cryptomining ausgehen.

Der Cryptominer

Bei meinem Bekannten wird folgende Datei als statisch gelinkte Executable (!) auf dem System abgelegt: gitea/data/gitea/sys_health_s3 Der Hash der Datei legt seiner Ansicht nach nahe, dass ein XMRig cyptominer als bösartige Payload eingesetzt wurde, der mit pool.hashvault.pro kommuniziert und dabei einen Großteil der verfügbaren CPU-Leistung für sich beansprucht.

Noch größerer Schaden möglich

Sogar für den auslegungsüberschreitenden Stöfall habe ich ein aktuelles (Sep-2026) Beispiel auf Hackernews finden können: Diebstahl von Quellcode, Sammlung von Zugangsdaten, Privilege escalation bis hin zum root-Zugriff auf das betroffene System.

Wie entdecke ich einen Angriff?

Schlimmstenfalls gar nicht. Sind Profis zielgerichtet am Werk, können allenfalls die Logdateien zum Zeitpunkt direkt nach dem Einbruch Aufschluss geben. Im Falle, dass man sie sofort liest und interpretieren kann. Aber ich schweife ab¹.

Dannoch sollte man sich folgende Fragen stellen:

Betreibe ich eine vulnerable Gitea-Version (<1.27.2)?
Verzichte ich auf eine Monitoring-Lösung, die bei Auffälligkeiten warnt?
Liegt eine ungewöhnlich hohe CPU-Last des Systems vor (Deutet auf Kryptominer-Befall hin)?
Für diesen konkreten Miner kann man zusätzlich nachsehen, ob auf dem System folgende Datei zu finden ist:

find / -name '.sys_health_s3' 2>/dev/null

Beantwortet man sich nur eine dieser Fragen mit ja, ist zügiges Handeln angebracht. Dabei ist durch den Schweregrad der Sicherheitslücken das gesamte Hostsystem als kompromittiert anzusehen, insbesondere wenn der Gitea-Container oder ein eventuell eingebundener Runner rootful läuft, also mit dem Docker Socket ausgestattet wurde.

Bei Befall: Quarantäne

Nächste Schritte: Sofort die betroffene Maschine isolieren und vom Netz nehmen. Die Container herunterfahren, Hostmaschine durchbooten und Updates nachladen. Aschließend die Docker Registry auf Stand bringen und über die Logdateien (Zeitstempel!) ermitteln, ob andere Teile des Systems betroffen sind. Für weitere Details siehe mein Artikel über einen selbsterlebten Angriff auf Gitea.

Lösungen

Gitea Updaten!

Gitea muss dringend auf eine Version >1.27.1 gebracht werden. Dafür kann beispielsweise die docker-compose.yml geändert und die Container danach durchgebootet werden:

# docker-compose.yml
gitea:
 image: gitea/gitea:latest
 container_name: gitea

Weitere Informationen zu aktuellen Fixes finden sich auf Giteas Blog. Der Major Release auf Version 27 löst eine ellenlange Liste an kritischen Sicherheitslücken. Ich habe in diesem Artikel nur ein paar davon herausgepickt, da sie mein direktes Umfeld betreffen und ihre Ausnutzung bekannt ist.

Gitea und Runner `rootless` ausführen

Führt das Ausnutzen einer Sicherheitslücke zum Verlust von Gitea oder dem Action Runner, sollte nicht auch noch das Hostsystem kompromittiert werden. Der Betrieb in einem Container kann den Schadensumfang deutlich reduzieren. Das Aufsetzen einer rootless-Lösung habe ich daher hier beschrieben.

Zusätzliche Maßnahmen (Härtung)

CVE-2026-20896: Netzwerkzugriff erschweren

Bei den folgenden Schritten folge ich der Empfehlung von d00ftech.

Einfügen des Adressraumes des selbst verwendeten Reverse Proxy. Dafür gilt erst einmal herauszufinden, unter welcher Adresse der Reverse Proxy im Netzwerk erreichbar ist. Auf meinem Server beispielsweise laufen Gitea und Reverse Proxy (Caddy) in Docker. Daher finde ich die IP-Adresse wie folgt:

docker inspect caddy \
 --format='{{range $name, $network := .NetworkSettings.Networks}}{{$name}}: {{$network.IPAddress}}{{"\n"}}{{end}}'
caddy-proxy: 172.20.0.2

Dieser Wert wird nun in der gitea/app.ini eingetragen:

[security]
REVERSE_PROXY_LIMIT = 1
REVERSE_PROXY_TRUSTED_PROXIES = 172.20.0.2/32

Direkten Netzwerkzugriff auf Gitea unter Umgehung des eigenen Reverse Proxy blockieren. Dazu darf der Port von Gitea (meist 3000) nicht in der Portfreigabe beispielsweise der Docker-Konfiguration erscheinen:

# docker-compose.yml
services:
 gitea:
 ports:
 - "3000:3000" # remove this!

CVE-2026-59774: Gitea updaten!

Es gibt zwar die Möglichkeit, den org-mode renderer in der app.ini zu deaktivieren (Siehe Gitea Documentation zum Thema), der weitaus bessere Weg ist aus meiner Sicht aber das Update von Gitea selbst!

CVE-2026-60004: Falls möglich Self-Registration abschalten

Der eigentliche Fix ist nur durch ein Update der Gitea-Version möglich. Für kleinere Instanzen mit wenigen Usern mag es zusätzlich zweckmäßig erscheinen, die Selbstregistrierung für neue User abzuschalten. Sie müssen eine Registrierung von nun an bei den Administratoren anfragen (sofern sie nicht eine der anderen oben beschriebenen CVEs ausnutzen).

# gitea/app.ini
[service]
DISABLE_REGISTRATION = true

Weitere hilfreiche Einstellungen sind:

REGISTER_EMAIL_CONFIRM = true # Requires user's email to be confirmed for registration to complete
ENABLE_OPENID_SIGNUP = false # Disallow logons via external API
REQUIRE_SIGNIN_VIEW = true # Force users to login before they can view content or use the public API

Ausblick und Fazit

Versionsverwaltungen sind sehr atttraktive Ziele für gleich einen ganzen Strauß an Angreifertypen: Von Cryptominern wegen der Möglichkeit der Ressourcenübernahme über Ransomware-Gruppen wegen der Quellcodedateien und möglicher Zugangsdaten bis hin zu hochprofessionellen, zielgerichteten Angreifern und staatlichen Akteuren dadurch, dass die Software eine Art Infrastruktur darstellt.

Daher:

“Alle Patches einspielen. Immer. Sofort. Ohne Ausnahmen.” - Felix von Leitner, sagt aber auch das BSI

Was mich ein wenig ratlos zurücklässt ist die schiere Zahl und Kritikalität der gestopften Sicherheitslücken (35 CVEs binnen eines Monats laut Giteas eigenem Blog!). Aus meiner blauäugigen Sicherheitsperspektive ist diese Lösung ein Schweizer Käse und ich bin mir nicht sicher, ob ich Gitea weiter betreiben sollte.

Sofort: Härtung durchführen

Na klar: Gitea auf latest bringen und die oben beschriebenen Härtungsmaßnahmen durchführen.

Kurzfristig: Automatische Updates

In den nächsten Tagen und Wochen werde ich mich damit beschäftigen, die Docker Registry automatisch nach Updates für meine Software zu durchsuchen und sie ebenso automatisch auf meinem Server auszurollen. Blog-Post folgt!

Mittelfristig: Her mit Monitoring

Ich werde mich auf die Suche machen nach einer kleinen und leichten Monitoring-Lösung, die Auffälligkeiten wie “CPU-Last ungewöhnlich hoch seit HH:MM:SS” meldet und healthchecks durchführen und überwachen kann. Dabei darf sie selbst kein Einfallstor dastellen, muss also praktisch ohne Rechte auskommen. Ob das wohl einfach möglich ist?

Mittelfristig 2: Weg mit den Secrets

Unverschlüsselte Secrets haben in Repositories nichts verloren. Selbst auf dem Server selbst ist eine .env-Datei, die dort herumliegt, als nicht mehr sicher zu werten. Auch hier werde ich mir Gedanken machen und entsprechend berichten, wenn ich eine Lösung ausgerollt habe.

Mittelfristig 3: News-Feeds einrichten

Hierunter fallen Abos z.B. von Newslettern oder RSS-Feeds idealerweise aller meiner Softwareanbieter, IT-Security-Institutionen oder -Journalisten und weiteren Quellen, aus denen ich Sicherheitslücken, Patches und Maßnahmen zur Systemhärtung entnehmen kann.

Langfristig: Mit Leuten weiterhin ins Gespräch gehen

Es endet wie es beginnt. Bevor ich Probleme mit meiner Software lösen kann, bevor ich überhaupt von den Problemen weiß, ja genau da! Ganz am Anfang, bevor ich überhaupt entschieden habe, welche Software ich einsetze, da stehen: Andere Menschen.

Leute, die ich fragen kann, um Hilfe bitten kann. Deren Zeit ich in Anspruch nehmen darf für eigene Belange. Die ich zum Beispiel per Messenger aus dem Nichts heraus anschreibe und aus ihrem Fokus reiße.

Leute, die sich besser auskennen als ich, die einen anderne Blick auf die Dinge haben, oder deren Meinung ich interessant finde.

Kolleginnen, auch Ehemalige, Bekannte und Freunde, Familie, die ich zufällig oder zielgerichtet auf einen Austausch treffe. Auf einen Kaffee, ein Eis, ein Kaltgetränk, zum Musizieren oder für einen Brettspielnachmittag.

Leute, die mir trotz der Unterbrechung und doofer Fragen freundlich und geduldig helfen. Die vielleicht kurz mit den Augen rollen, mir die Dinge dann aber doch noch ein weiteres mal erklären. Die meine Monologe, kritische Nachfragen und gelegentliche Gegenrede irgendwie tolerieren.

Leute, mit denen ich in einen Austausch treten kann, der am Ende hoffentlich beiden Seiten nützt.

Bei euch allen möchte ich mich bedanken. Mit Leuten wie euch wird alles viel einfacher. Auch der Betrieb dieses Blogs, wo so viel meiner Zeit hineingeht. Ich kann mit euch Entscheidungen diskutieren, erfahren wie ihr Dinge gemacht habt und warum genau so, die Perspektiven wechseln. Und neue Ideen entwickeln.

Bitte bleibt mir erhalten.

Verweis an “Fefe” Felix von Leitner. Zitat: “Annahmen […]: Wir werden angegriffen. Wir merken es zeitnah. Aller Erfahrung nach: Nein, tun wir nicht. Typischer Zeitraum vor Entdeckung von blinden Passagieren: Ein halbes bis fünf Jahre.” - aus dem Vortrag Hackback, Link führt zu Codeberg. ↩︎