Laufend neue Sicherheitslücken – was heisst das für Vertec?

Ein (für mich jedenfalls) etwas unerwarteter Nebeneffekt der AI Revolution ist, dass im Jahr 2026 in immer kürzerem Abstand Sicherheitslücken auftauchen. Dies vor allem in Open Source Produkten, von denen man lange Jahre annahm, dass ihre Sicherheit durch die breite Verfügbarkeit des Quellcodes höher sei – nun merkt man, dass dem vielleicht schon so ist, dass aber AI Systeme auch den Quellcode systematisch nach Schwachstellen absuchen können. Solange dies Firmen sind wie OpenAI oder Anthropic, welche mit den Funden verantwortungsvoll umgehen, ist das ja erwünscht und gut – aber die Angreifer können auf die gleichen Mittel zugreifen, um sich Angriffsszenarien auf gefundene Schwachstellen zu überlegen.

Was heisst das nun für Vertec?

Ein Blick in die aktuellen Supportfälle zeigt, dass wir allein in den letzten 10 Tagen mit drei gravierenden Sicherheitslücken konfrontiert waren (PHP, Google Brotli, Linux Kernel), die auch mutmasslich sehr sichere Systeme (Linux) und Hersteller (Google) betreffen.

Unser Vorgehen ist dabei immer gleich:

1. Wir erfahren von neuen Schwachstellen über Online Medien. Heise Security ist dabei im deutschsprachigen Raum eine der ersten Anlaufstellen, aber man erfährt auch auf LinkedIn schnell von gravierenden Sicherheitslücken.
2. Wir analysieren sofort den möglichen Impact auf die Vertec Software und die von uns betriebene Infrastruktur. Dabei hilft uns der Überblick über unsere «Informationssicherheits-Assets», den wir durch die ISO 27001 Zertifizierung haben. Z.B. ist es offensichtlich, dass die Vertec Standardsoftware nicht auf PHP setzt, aber wie sieht es in umliegender, z.T. von Drittherstellern hergestellter und betriebener Software aus? Es stellte sich heraus, dass das Vertec Forum, welches auf Software von Woltlab aufgebaut ist, tatsächlich auf PHP setzt. Der Hersteller hat seine Software umgehend gepatcht, sobald der Patch verfügbar war.
3. Ist eine Komponente betroffen, die wir einsetzen (wie aktuell die gravierende Sicherheitslücke im Linux Kernel, CVE-2026-98432), schätzen wir mögliche Auswirkungen genauer ab und diskutieren Massnahmen. Aus den vorliegenden Informationen lässt sich schliessen, dass es erstens keine laufenden Angriffe gibt und zweitens ein Angriffszenario eine Einstellung benötigt, die bei uns nicht gesetzt ist (MPTCP). Weil eine Ausnutzung darum sehr unwahrscheinlich ist, haben wir von dramatischen Massnahmen, wie dem Runterfahren aller Cloud Dienste, abgesehen. Etwas, was übrigens von vielen gemacht wurde während der «PHP Krise» am 21. Oktober 2026.
4. Die Umsetzung. Diese hängt natürlich stark vom betroffenen System ab und ob es um eigene oder fremde Software geht. Bei eigener Software werden erkannte Schwachstellen mit einem nächsten Minor Release behoben. Beim aktuellen Linux Bug warten wir auf einen Patch unserer Ubuntu Distribution und spielen den so schnell wie möglich ein.

Unsere eigene Software lassen wir regelmässig extern pentesten und verarbeiten dann die Erkenntnisse. Das tun wir insbesondere für sämtliche neuen Features mit einem Exposure gegen aussen (2026 waren das z.B. Python 3, die neuen Webservices, und das OAuth Login für den MCP Server). Wir arbeiten dabei eng mit der Firma avantguard zusammen. Vor 2 Jahren sprach deren CEO, Jann Lemm, an der Vertec Anwendertagung.