Jedes Entwicklungsteam kennt dieses mulmige Gefühl in der Magengegend, wenn eine Sicherheitswarnung mit CVSS 9.2 für die Runtime eintrifft, auf der das eigene Backend läuft. Am 21. Oktober 2026 veröffentlichte das PHP-Projekt ein Notfall-Sicherheitsupdate. Das Backend von encrypted1on1 läuft auf PHP. Unsere Plattform wurde praktisch direkt nach Erscheinen des Patches aktualisiert. Doch dieser Vorfall war zugleich ein Praxistest für unsere Architektur: Warum selbst ein Server-Exploit die vertraulichen 1:1-Gespräche Ihrer Teams nicht gefährdete — und wo die ehrlichen Grenzen clientseitiger Verschlüsselung verlaufen.
Was passiert ist (und warum sofortiges Handeln nötig war)
Am 21. Oktober 2026 erschienen die PHP-Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 zur Behebung zweier kritischer Schwachstellen: CVE-2026-109618 und CVE-2026-109619. Beide sind mit einem CVSS-Score von 9.2 eingestuft und erlauben nicht authentifizierten Angreifern das Ausführen von beliebigem Code auf dem Server.
Sicherheitshinweise des CERT-EU und unabhängiger Experten machten deutlich, dass technische Details bereits öffentlich diskutiert wurden und funktionierende Exploits im Umlauf waren. Dies war kein Update für das nächste reguläre Wartungsfenster — hier war sofortiges Eingreifen gefordert.
encrypted1on1 läuft auf PHP 8.5 im offiziellen FrankenPHP-Container. Die gepatchten Basis-Images wurden noch am selben Abend auf Docker Hub bereitgestellt.
Was wir unternommen haben
Wir haben die gepatchten Container praktisch direkt nach Veröffentlichung auf unserer Infrastruktur ausgerollt:
- Unsere Plattform wurde auf Basis von PHP 8.5.12 neu gebaut und ohne Ausfallzeit neu gestartet.
- Keine Code-Änderungen erforderlich: Da unsere Produktions-Dockerfiles auf das Tag
php8.5verweisen, zog ein einfacher Container-Rebuild sofort die fehlerbereinigte PHP-Version ein. - Audit & Telemetrie: Eine vollständige Log- und Anomalieprüfung an unseren Edge-Proxies und Workern ergab keinerlei Anzeichen von Scans, Angriffsversuchen oder verdächtigen Aktivitäten vor oder während des Updates.
Warum 1:1-Notizen auf dem Server niemals lesbar waren — gepatcht oder ungepatcht
Genau in solchen Momenten zahlt sich eine kompromisslose Zero-Knowledge-Architektur aus.
In gewöhnlichen 1:1-Tools oder internen Firmen-Wikis (Notion, Google Docs, Slack, gängige HRIS) ist Remote Code Execution auf dem Server ein existenzieller Albtraum. Der Angreifer öffnet eine Shell, liest die Zugangsdaten der Datenbank aus der Umgebungsvariable aus und startet eine SQL-Abfrage. Auf einen Schlag liegt die gesamte vertrauliche Kommunikation offen: Versagensängste, Gehaltsstreitigkeiten, Überlastungssignale und ungeschminktes Feedback.
In encrypted1on1 ist der Server gegenüber Gesprächsinhalten blind. Sämtliche Gesprächsnotizen, Agendapunkte, persönliche Gedanken und Entwürfe werden direkt im Browser des Nutzers mit AES-GCM-256 verschlüsselt, bevor sie das Endgerät verlassen.
Unsere Datenbank speichert ausnahmslos Chiffretext:
- Antworten und persönliche Notizen beider Teilnehmer (sowohl Entwürfe als auch freigegebene Einträge);
- Kommentare, Vereinbarungen, Gesprächsthemen und Aufgaben;
- Private Notizen jedes Nutzers;
- Zwischenstände und Check-ins zu Entwicklungszielen.
Die kryptografischen Schlüssel zur Entschlüsselung werden auf den Endgeräten der Nutzer aus ihren Master-Passwörtern mittels speicherintensiver Argon2id-Ableitung erzeugt. Sie verlassen den Browser niemals unverschlüsselt. Der Server besitzt lediglich versiegelte Schlüsselumschläge, die er mathematisch nicht öffnen kann.
Selbst wenn ein Angreifer unsere komplette Produktions-Datenbank und sämtliche Dateispeicher kopiert hätte, besäße er nur wertlosen Chiffretext. Genau das ist der Kern unseres Ansatzes: Wir verlangen von Ihnen nicht das blinde Vertrauen, dass unsere Server niemals eine Sicherheitslücke aufweisen werden. Ein Fehler in PHP, einer C-Bibliothek oder unserem Code führt nicht dazu, dass persönliche 1:1-Gespräche offengelegt werden.
Die ehrliche Grenze: Was Ende-zu-Ende-Verschlüsselung leistet — und was nicht
Glaubwürdige Sicherheit entsteht durch technische Transparenz, nicht durch Marketingversprechen. Das sind die präzisen Grenzen unseres Bedrohungsmodells bei einer Serverkompromittierung:
1. Metadaten sind auf dem Server sichtbar. Die Verschlüsselung schützt den Inhalt Ihrer Gespräche. Für die Bereitstellung des Dienstes muss der Server jedoch Metadaten verarbeiten: Account-IDs, wer sich mit wem zu 1:1-Gesprächen trifft, den Rhythmus und die Zeitpunkte. Zudem werden aus organisatorischen Gründen wenige Rahmendaten unverschlüsselt geführt: Titel von Zielen, Zieldaten, Status sowie Fragen-Vorlagen des Unternehmens. Die vollständige Aufstellung finden Sie in unserem offenen Threat Model.
2. Verschlüsselung schützt gespeicherte Daten, nicht die künftige Codeauslieferung. encrypted1on1 ist eine Webanwendung: Ihr Browser lädt den JavaScript-Code vom Server. Gelingt es einem Angreifer, dauerhaften Zugriff auf den Webserver zu erlangen, könnte er theoretisch versuchen, künftige JavaScript-Dateien zu manipulieren, um Passwörter beim nächsten Login abzufangen. Dagegen schützen wir uns mit strengen CSP-Headern (Content-Security-Policy), unveränderlichen Container-Images und Subresource Integrity. Doch keine clientseitige Verschlüsselung der Welt kann verhindern, dass ein vollkommen kompromittierter Host versucht, manipulierten Code an künftige Besucher auszuliefern.
Die Quintessenz: Ende-zu-Ende-Verschlüsselung verwandelt einen potenziell verheerenden Datenabfluss Ihres gesamten Archivs in einen kontrollierten, operativen Patch-Vorgang. Das bisher Geschriebene bleibt mathematisch geschützt; das zeitnahe Einspielen von Patches sichert künftige Sitzungen ab. Beides gehört untrennbar zusammen.
Anleitung: So aktualisieren Sie Ihre Self-Hosted-Instanz
Wenn Sie encrypted1on1 mit unserem Docker-Setup betreiben, dauert das Update weniger als zwei Minuten und erfordert weder Migrationen noch Konfigurationsanpassungen.
Schritt 1: Gepatchtes Basis-Image abrufen.
Unser Deploy-Skript baut den App-Container, nutzt dabei aber unter Umständen den lokalen Docker-Cache. Ein expliziter Pull garantiert das Laden der bereinigten PHP-8.5.12-Basis:
docker pull dunglas/frankenphp:php8.5Schritt 2: Neu bauen und deployen.
Führen Sie das Standard-Deployment-Skript aus Ihrem Projektverzeichnis aus:
PROD_COMPOSE_FILE=docker-compose.prod.yml ./docker/prod/deploy.sh(Oder einfach ./docker/prod/deploy.sh, falls Ihre Umgebung die Compose-Datei bereits definiert).
Das Skript baut das Image mit Ihrem aktuellen Code, erstellt den Container neu, führt Migrationen aus, aktualisiert den Container-Cache und führt einen internen Integritätscheck durch.
Hinweis: Ein git pull des Anwendungscodes ist nicht zwingend erforderlich, wenn es Ihnen nur um das Sicherheitsupdate geht. Ein Rebuild auf dem frischen Basis-Image genügt vollkommen.
Schritt 3: PHP-Version im Container prüfen.
Überprüfen Sie kurz die aktive PHP-Version:
docker compose -f docker-compose.prod.yml --env-file .env.prod exec app php -vDie Ausgabe muss PHP 8.5.12 (oder höher) anzeigen.
Falls Sie encrypted1on1 ohne Docker betreiben, aktualisieren Sie die PHP-Pakete über die Paketverwaltung Ihres Betriebssystems und starten Sie den PHP-Worker (FrankenPHP oder PHP-FPM) neu, damit die alte Binärdatei aus dem Arbeitsspeicher entfernt wird.
Schlusswort: Vertrauen Sie auf Mathematik, nicht auf Versprechen
Sicherheitslücken werden wieder auftreten — in PHP, im Linux-Kernel, in OpenSSL oder in Browser-Engines. Kein Anbieter kann glaubhaft versprechen, dass seine Server niemals für ein kurzes Zeitfenster verwundbar sind.
Was wir versprechen können — und was Sie in unserem Open-Source-Code jederzeit selbst nachprüfen können — ist, dass die vertraulichen Gespräche Ihres Teams niemals dem Wohlwollen eines Servers ausgeliefert sind. Wenn Software wankt, hält Mathematik stand.
Fragen zu diesem Release oder zur kryptografischen Architektur? Diskutieren Sie mit uns auf GitHub.