Kritische PHP-Lücken: Experten warnen vor langfristigen Folgen
Zwei kritische Sicherheitslücken in PHP setzen Unternehmen und Betreiber von Webanwendungen unter Handlungsdruck. Sicherheitsexperten sehen in PHP2Shell nicht nur ein akutes Patch-Problem, sondern auch einen Wendepunkt für das Schwachstellenmanagement: KI beschleunigt die Entdeckung und mögliche Ausnutzung von Sicherheitslücken, während veraltete Systeme und komplexe IT-Abhängigkeiten die Abwehr erschweren.
Die unter dem Namen PHP2Shell bekannt gewordenen Schwachstellen CVE-2026-109618 und CVE-2026-109619 betreffen eine der am weitesten verbreiteten Technologien für Webanwendungen. Angreifer können die Sicherheitslücken unter bestimmten Voraussetzungen aus der Ferne ausnutzen und Schadcode ohne vorherige Authentifizierung ausführen. Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) hat eine entsprechende Cybersicherheitswarnung veröffentlicht und empfiehlt, betroffene Systeme umgehend zu aktualisieren oder gegebenenfalls vorübergehend vom Netz zu nehmen.
Die Folgen reichen weit über klassische Websites hinaus. PHP findet sich auch in Verwaltungsoberflächen, eingebetteten Anwendungen und industriellen Umgebungen. Zugleich wirft der Vorfall grundsätzliche Fragen auf: Wie schnell können Unternehmen ihre betroffenen Systeme identifizieren? Was geschieht mit Anwendungen, für die keine Sicherheitsupdates mehr verfügbar sind? Und wie verändert künstliche Intelligenz das Verhältnis zwischen Angreifern und Verteidigern?
Vertreter führender Unternehmen und Organisationen der IT-Sicherheitsbranche ordnen PHP2Shell aus unterschiedlichen Perspektiven ein.
Norbert Pohlmann, Vorstand IT-Sicherheit im eco – Verband der Internetwirtschaft e.V.
„PHP2Shell ist mehr als ein weiterer Patch-Day. Wenn ein Baustein, der hinter einem Großteil aller Websites steckt, eine kritische Lücke hat, wackelt ein Teil der digitalen Infrastruktur.
KI hilft heute nicht nur Verteidigern beim Finden von Schwachstellen. Sie ermöglicht Angreifern auch, aus Updates in kürzester Zeit funktionierende Exploits zu bauen. Das Zeitfenster zwischen Patch und erstem Angriff schrumpft. Hersteller, Hoster und Betreiber brauchen deshalb belastbare Schwachstellenprozesse und eine koordinierte Offenlegung, die auf dieses Tempo ausgelegt ist.
Außerdem gilt: Open-Source-Software wie PHP ist das Fundament des Internets. Wer wirtschaftlich davon profitiert, sollte ihre Sicherheit als Teil der eigenen Resilienz verstehen und nachhaltig unterstützen. Kritische Software braucht ausreichend Entwickler und verlässliche Ressourcen für Wartung und Sicherheitsprüfung, nicht nur Einzelprojekte.“
Ismael Valenzuela, Vice President, Labs, Threat Research and
Intelligence bei Arctic Wolf
„Eine der wichtigsten Erkenntnisse aus PHP2Shell ist, dass KI unsere Vorstellung davon verändert, welche Schwachstellen sich tatsächlich ausnutzen lassen. Einige dieser Schwachstellen existierten bereits seit mehr als einem Jahrzehnt.
Verändert hat sich nicht der zugrunde liegende Code, sondern die Fähigkeit, diese Schwachstellen aufzuspüren und daraus funktionsfähige Exploits zu entwickeln.
Die potenziellen Auswirkungen sind enorm. PHP kommt auf rund 70 Prozent aller Websites zum Einsatz, bei denen die serverseitige Programmiersprache bekannt ist. Damit ist ein erheblicher Teil der geschäftlichen und kommerziellen Infrastruktur des Internets potenziell gefährdet, was sofortiges Handeln erfordert. Das bedeutet zwar nicht, dass all diese Websites tatsächlich betroffen oder angreifbar sind. Es verdeutlicht jedoch, wie weit verbreitet diese Technologie ist und warum Unternehmen schnellstmöglich prüfen müssen, inwieweit ihre Systeme betroffen sind.
KI macht anspruchsvolle Sicherheitsforschung für einen größeren Personenkreis zugänglich. Das ist eine gute Nachricht für die Verteidigerseite. Allerdings müssen wir davon ausgehen, dass auch Angreifer von diesen Möglichkeiten profitieren werden. Wir müssen uns von der Vorstellung verabschieden, dass Schwachstellenmanagement lediglich darin besteht, eine Sicherheitslücke zu identifizieren, ihren Schweregrad zu bewerten und auf einen Patch zu warten. Entscheidend ist vielmehr, wie schnell wir erkennen können, welche Systeme betroffen sind, wie hoch das damit verbundene Risiko ist und wie sich verhindern lässt, dass die Kompromittierung eines einzelnen Systems zu einem weitaus größeren Sicherheitsvorfall führt.“
Sai Molige, Senior Manager of Threat Hunting bei Forescout
„PHP2Shell könnte ein Ereignis in der Größenordnung von Log4Shell werden, allerdings aus einem anderen Grund. Bei Log4j bestand das Hauptproblem darin, eine Bibliothek zu finden, von der man gar nicht wusste, dass man sie im Einsatz hatte.
Bei PHP wird man einen Großteil der vergessenen Infrastruktur zwar finden, für viele dieser Systeme wird es aber keinen Fix vom Hersteller geben.
Die nachhaltige Lehre aus Log4j lautet: Unternehmen sollten die Frage ‚Wie schnell können wir feststellen, wo wir X betreiben?‘ als eigene, messbare Fähigkeit begreifen, getrennt davon, wie schnell sie patchen.
Anfällige Infrastruktur aufzuspüren, ist allerdings nur der erste Schritt. Gibt es für ältere Systeme keinen Fix oder hängen sie von einem Update des Herstellers ab, müssen Unternehmen ihre Angriffsfläche verkleinern, unnötige Verbindungen einschränken und betroffene Systeme isolieren, während sie die Behebung planen.
KI ist sehr gut darin, Variantenanalysen durchzuführen, wenn sie einen Referenzpunkt hat. Das senkt den Aufwand und das nötige Fachwissen. Dadurch könnte die Zahl der Angriffsversuche auf diese kritischen Schwachstellen steigen, auch wenn viele davon nie zu einem funktionierenden Exploit werden.
Typische Orte, an denen vergessenes PHP häufig zu finden ist:
Hersteller-Appliances mit PHP-basierten Admin-Oberflächen: NAS-Geräte, manche Firewalls und VPN-Portale, Drucker, Steuerungen für die Gebäudetechnik sowie OT/ICS-HMIs mit Web-Frontend. Unternehmen können diese Geräte nicht selbst patchen und müssen auf die Hersteller warten. Das kostet Zeit.
Mitgelieferte Laufzeitumgebungen: Control Panels und kommerzielle Softwarepakete bringen oft eine eigene PHP-Binärdatei mit, die für den Paketmanager des Betriebssystems unsichtbar ist.
Container mit veralteten Base-Images: Der Host ist aktuell, das Image von 2021 nicht.
Marketing-Microsites, Kampagnenseiten und die Infrastruktur übernommener Unternehmen: Sie laufen oft auf Hosting-Konten, die per Kreditkarte an der IT vorbei bezahlt werden.
Admin-Tools auf Entwicklungs- oder Jump-Servern: phpMyAdmin, Roundcube, Nextcloud.
Origin-Server hinter einem CDN oder einer WAF, die weiterhin direkt erreichbar sind: Damit werden die Regeln am Netzwerkrand unbemerkt ausgehebelt.
Unternehmen, die sich Sorgen um ihre Gefährdung machen, sollten vorrangig betroffene Systeme identifizieren, unnötige Erreichbarkeit von außen reduzieren und den Empfehlungen der Hersteller zur Behebung oder zu kompensierenden Maßnahmen folgen. Um alle PHP-Installationen in ihrer Umgebung zu finden, sollten Teams mehrere Methoden kombinieren: externe Scans der Angriffsfläche, Paketmanager auf Host-Ebene, Container- oder SBOM-Scans und die Analyse des Netzwerkverhaltens.
Unternehmen, die von einer Kompromittierung ausgehen, sollten auf exponierten Hosts alle Secrets austauschen, Multipart-Anfragen am Netzwerkrand filtern, ausgehenden Datenverkehr von Web-Worker-Prozessen einschränken und End-of-Life-Hosts isolieren. Zudem sollten sie nach klassischen Mustern von Web-Shells suchen: php-fpm, httpd oder apache2, die sh, bash, curl, wget oder base64 starten; neue oder veränderte .php-Dateien in Web-Root-Verzeichnissen sowie ausgehende Verbindungen von Web-Worker-Prozessen.“
Mathieu Rigotto, CISO bei Filigran
„Eine koordinierte Offenlegung dient genau dazu, Vorfälle wie diesen zu vermeiden. Nun, da der Exploit öffentlich ist, besteht die oberste Priorität darin, die eigene Angriffsfläche zu kennen: Welche PHP-Endpunkte sind tatsächlich über das Internet erreichbar, einschließlich vergessener Altsysteme, und könnten bestehenden Schutzmaßnahmen im Weg stehen? An zweiter Stelle stehen Ownership und Auswirkungen. Jedes exponierte System benötigt einen Verantwortlichen, der sofort handeln kann, sowie ein Verständnis dafür, was eine Kompromittierung bedeuten würde, unabhängig davon, ob es um Kundendaten, Anmeldedaten oder einen Einstiegspunkt in das interne Netzwerk geht. Dieser Kontext ist enorm wichtig, denn Schweregrad-Bewertungen allein stufen jeden PHP-Server gleich ein. Was wir hier wieder vor Augen geführt bekommen, ist:
Notfälle wie dieser testen nicht, wie schnell Organisationen Sicherheitshinweise lesen; sie testen, ob sie ihre Gefährdung bereits kannten, bevor der Sicherheitshinweis veröffentlicht wurde.“
Udo Fink, Leiter Cybersicherheit Zentraleuropa bei DXC Technology
„Die aktuellen PHP-Sicherheitslücken zeigen, wie schnell Unternehmen durch Schwachstellen in weitverbreiteten Softwarekomponenten unter Handlungsdruck geraten. Es ist zu befürchten, dass KI-Modelle neuester Generation in den nächsten Monaten eine Vielzahl kritischer Schwachstellen finden und ausnutzen werden. Wiederkehrende Prüfungen und Schutzmaßnahmen lassen sich auf Dauer nicht allein durch zusätzliches Personal bewältigen; Automatisierung und KI-Agenten können die Teams entlasten.
Entscheidend ist nun eine schnelle Installation der verfügbaren Updates. Das setzt voraus, dass bekannt ist, wo PHP installiert ist. Vor der Installation müssen Patches auf mögliche Abhängigkeiten und Auswirkungen überprüft werden. Zudem stehen Sicherheitsupdates oft nur für aktuelle Versionen bereit. Systeme, die nicht kurzfristig aktualisiert werden können, benötigen klar priorisierte Maßnahmen zur Risikominderung, etwa zusätzliche Überwachung, Zugriffsbeschränkungen oder die vorübergehende Isolation betroffener Komponenten.
Eine durchgängige Cybersecurity muss fester Bestandteil der Unternehmensstrategie sein. Dabei müssen einige zusätzliche Dimensionen beachtet werden:
Governance: Wirksame Sicherheit braucht eine durchdachte Sicherheitsarchitektur, klare Zuständigkeiten und Risikomanagement einschließlich Lieferkettenrisiken. Dazu gehören Mitarbeiterschulungen und ein Wiederanlaufplan für den Ernstfall.
Mehrschichtiges Schutzkonzept (Defense in Depth): Netzwerksegmentierung, Zero Trust sowie ein konsequentes Identitäts- und Berechtigungsmanagement helfen, Angriffsflächen zu reduzieren und Schäden zu begrenzen.
Sicherheit in der Softwareentwicklung: Viele Sicherheitslücken entstehen in der Softwareentwicklung. Daher ist ein starker Fokus auf Sicherheit in jeder Phase des Lebenszyklus der Software notwendig. Dabei sollten KI-basierte Systeme zum frühzeitigen Auffinden von Schwachstellen zum Einsatz kommen.
KI-gestützte Überwachung: Ein klassisches Security Operations Center (SOC) mit Analysten, Schichtbetrieb und manueller Prüfung von Alarmen hält mit der Vielzahl von Bedrohungen und Angriffen kaum noch Schritt. KI-Agenten unterstützen Analyse und Priorisierung und können vorab freigegebene Gegenmaßnahmen ausführen. Menschen entscheiden über kritische Eingriffe und tragen die Verantwortung.
Ein wenig in die Zukunft geschaut zeichnet sich ein IT-Betriebsmodell mit starker Unterstützung durch KI-Agenten ab. KI-Agenten können betroffene Systeme und die Ausnutzbarkeit von Schwachstellen schneller erkennen, Updates oder andere Schutzmaßnahmen empfehlen und automatisiert umsetzen.
Die Schlussfolgerung ist klar: Cyberresilienz erfordert deutlich mehr als schnelle Updates.
Um mit der zunehmenden Geschwindigkeit KI-gestützter Bedrohungen Schritt zu halten, muss auch die Cyberabwehr stärker auf Automatisierung und KI-Unterstützung setzen – unter menschlicher Kontrolle.“
Shane Barney, CISO von Keeper Security
„Das Ausmaß unterscheidet dies von einem routinemäßigen Patch-Zyklus. PHP bildet die Grundlage von Websites, die gleichermaßen von Konzernen, öffentlichen Einrichtungen und Ein-Personen-Unternehmen betrieben werden und die meisten derer, die diese Websites betreiben, sind keine Sicherheitsspezialisten. Sie verlassen sich darauf, dass Hosting-Anbieter, Plugins und Agenturen auf dem Laufenden bleiben und viele lernen diese Woche zum ersten Mal etwas über PHP.
Die Schwachstellen blieben jahrelang in weit verbreitetem Code verborgen, bis KI-Tools sie aufdeckten. OpenAI, dessen Modell bei der Aufdeckung half, rechnet damit, dass ähnliche Funde in den kommenden Monaten stark zunehmen werden, da KI den erforderlichen Aufwand, um eine komplexe Schwachstelle in einen funktionierenden Angriff umzuwandeln, weiter verringert.
Das Patchen ist nur der erste Schritt. Bei jeder Website, die vor dem Fix der Schwachstelle angreifbar war, sollte überprüft werden, wer Zugriff sowohl auf die Website als auch auf interne Systeme innerhalb der Organisation hat.
Sicherheitsteams sollten nicht mehr genutzte Administratorkonten entfernen, das Prinzip der geringsten Berechtigungen anwenden, um den Zugriff einzuschränken, Passwörter vorsorglich ändern und jede Anmeldung durch eine Multi-Faktor-Authentifizierung schützen.“
Mark Molyneux, Field CTO bei Commvault
„KI wird helfen, Software sicherer zu gestalten, aber erst mal wird sie die IT-Risikolage erhöhen. Denn die kritischen PHP-Lücken beweisen: KI deckt Fehler in Kerndiensten auf, die Millionen von Systemen weltweit angreifbar machen. Da kann die Abwehrmauer noch so hoch sein. Daher ist es heute wichtiger denn je, sich darauf zu konzentrieren, die Folgen erfolgreicher Attacken einzudämmen. Weitere kritische Lücken sind zu erwarten.
Für die Internetwelt ist es gut und wichtig, dass diese Fehler gefunden wurden, und es sind Patches verfügbar, die diese Lücken schließen. Jedem User ist zu empfehlen, diese kritischen Updates so schnell es geht aufzuspielen. Denn die KI hilft den Aggressoren, Angriffe gegen diese Lücken schnell und qualitativ hochwertig zu entwickeln. Das Sicherheitsrisiko ist dementsprechend hoch.
Auf die IT-Teams weltweit kommt viel Arbeit zu. Sie werden bei einer gleichzeitigen Flut von Vorfällen Patches testen, priorisieren und ausrollen müssen. Eine mögliche Konsequenz wird sein, manche Lücken für eine Weile akzeptieren zu müssen, weil andere gravierender sind und es wichtiger ist, diese zuerst zu schließen.
Das Risiko erfolgreicher Attacken ist dadurch erhöht. Dieses Phänomen wird andauern, denn durch KI werden neue Lücken in weltweit millionenfach genutzten Software-Lösungen und Diensten gefunden werden. Angriffsprävention allein wird dem nicht gerecht. Denn Angreifer werden Wege finden, durch Lücken an den Abwehrmauern vorbei in Firmennetze einzudringen.
Die IT-Teams müssen in dieser KI-getriebenen Welt akzeptieren, dass ihre Abwehr versagt und sie erfolgreich angegriffen werden. Sie müssen sich auf diese Situation vorbereiten. Es wird essenziell sein, diesen Automatismen ebenfalls Workflows gegenüberzustellen, welche die Folgen einer erfolgreichen Attacke eindämmen und die IT-Systeme strukturiert wiederherstellen.
Diese Prozesse für mehr Cyberresilienz heißen ResOps. Diese organisatorische Disziplin verankert Resilienz fest in den täglichen operativen Betrieb. Sie führt Organisationen weg von passiven, reaktiven Backup-Strategien hin zu einem aktiven, kontinuierlichen Modell. ResOps folgt dabei einer zentralen Frage: Können die Teams jeden kritischen Dienst genau jetzt wiederherstellen – mit voller Gewissheit und nachweislich?
Entscheidend ist nicht, wie selbstsicher ein Unternehmen behauptet, Angriffe abwehren zu können, sondern wie überzeugend es seine Wiederherstellungsfähigkeit nachweist.
Geschützte Backups, klare Wiederherstellungsprioritäten und regelmäßige Tests machen Cyberresilienz zu mehr als einem Versprechen: zu einer nachweisbaren Fähigkeit. Wenn die Prävention versagt, kommt es auf diese Fähigkeit an.“
Patrick Münch, Mitgründer und CSO bei Mondoo
„Alle konzentrieren sich auf 14:00 Uhr UTC und darauf, den Patch einzuspielen.
Nach allem, was bisher bekannt ist, gilt der Fix aber nur für PHP 8.2 bis 8.5. Wer 7.4, 8.0 oder 8.1 einsetzt, bekommt keinen Patch, weder heute noch später.
Und diese alten Versionen sind immer noch weit verbreitet. Meist stecken sie in einer internen Anwendung, die ein Entwickler vor Jahren gebaut hat. Sie läuft noch, also will niemand sie anfassen. Unsere „State of Vulnerabilities“-Studie hat gezeigt, dass die Systeme, die Angreifer tatsächlich ins Visier nehmen, im Schnitt schon seit 4,4 Jahren keinen Support mehr bekommen. Das ist also kein Randphänomen.
Für diese älteren Systeme gilt: Wenn die Anwendung keine Fortschrittsanzeigen für Uploads nutzt (und viele tun das nicht), setzt in der php.ini session.upload_progress.enabled auf Off und startet neu. Das funktioniert ab PHP 5.4. Die PHP-Dokumentation selbst empfiehlt ohnehin, die Funktion abzuschalten, wenn man sie nicht braucht. Bisher hat allerdings niemand bestätigt, dass das diese Schwachstellen wirklich blockiert. Es verschafft euch vielleicht ein wenig Spielraum, mehr nicht. Bevor die CVEs dokumentiert und Patches veröffentlicht sind, solltet ihr eure PHP-Installationen erfassen und priorisieren. PHP kann auch in Software und Tools stecken, die ihr nutzt. Dann heißt es: aktualisieren, vom Internet trennen oder abschalten. Mir ist es viel lieber, ihr trefft diese Entscheidung heute Nachmittag als erst dann, wenn funktionierende Exploits im Umlauf sind.“
Satnam Narang, Senior Staff Research Engineer bei Tenable
„Tenable Research stuft diese Schwachstellen als „Vulnerabilities of Concern“ ein – die höchste Risikokategorie im Rahmen unseres Vulnerability-Watch-Programms. Diese Einstufung ist besonders schwerwiegenden Sicherheitslücken vorbehalten. Im vorliegenden Fall ist vor allem die weite Verbreitung von PHP ausschlaggebend: Schätzungen zufolge kommt die Skriptsprache bei fast 70 Prozent aller Websites zum Einsatz, deren serverseitige Programmiersprache bekannt ist. Hinzu kommt, dass PHP auch Bestandteil zahlreicher Content-Management-Systeme und anderer weitverbreiteter Anwendungen ist. Welche PHP-Versionen dabei jeweils verwendet werden, lässt sich aus dieser Zahl allerdings nicht ableiten. Genau das erschwert die Einschätzung der tatsächlichen Betroffenheit.
Die Schwachstellen befinden sich direkt in PHP. Damit sind grundsätzlich alle Installationen gefährdet, die Webanfragen verarbeiten. Bei erfolgreicher Ausnutzung ermöglichen sie Angreifern die Ausführung von Schadcode aus der Ferne, ohne dass eine Authentifizierung erforderlich ist. CVE-2026-109619 kann darüber hinaus zur Offenlegung von Speicherinhalten führen.
Angesichts ihrer enormen Reichweite und Tragweite zählen diese Sicherheitslücken zu den folgenschwersten seit Log4Shell.
Bemerkenswert ist auch, dass sie mithilfe von KI entdeckt wurden – ein deutlicher Hinweis darauf, wie leistungsfähig entsprechende Modelle inzwischen sind.
Eine weitere Besonderheit betrifft die Veröffentlichung. Ursprünglich war eine koordinierte Offenlegung geplant. Nachdem die CVE-Kennungen jedoch vorzeitig durchgesickert waren, wurde der Veröffentlichungstermin um einen Tag vorgezogen. Anschließend gelangten weitere technische Details an die Öffentlichkeit, die die Entwicklung von Proof-of-Concept-Exploits beschleunigten. Die PHP Foundation erklärte zum Zeitpunkt der Veröffentlichung, ihr seien noch keine funktionsfähigen Exploits bekannt. Inzwischen gibt es allerdings bereits Berichte über erste Ausnutzungsversuche. Es dürfte daher nicht lange dauern, bis auch Angreifern einsatzfähige Exploits zur Verfügung stehen.
Wie aufwendig die Behebung der Schwachstellen ist, hängt stark von der jeweiligen Systemumgebung ab. Anbieter von Linux-Distributionen und langfristig unterstützten Versionen wurden vorab informiert. Hier ist deshalb mit zeitnahen Sicherheitsupdates zu rechnen, möglicherweise innerhalb weniger Stunden oder Tage. Bei weniger verbreiteten Paketquellen kann es länger dauern. Besonders schwierig ist die Lage bei PHP-Versionen, deren Support bereits ausgelaufen ist. Hier kann die Bereitstellung von Patches Wochen oder Monate dauern – sofern überhaupt noch Aktualisierungen erscheinen. Langfristig problematisch sind zudem Produkte, in die PHP fest integriert ist. Deren Nutzer sind darauf angewiesen, dass die jeweiligen Hersteller entsprechende Updates bereitstellen. Während cloudbasierte Systeme in der Regel schneller aktualisiert werden können, müssen Administratoren bei selbst gehosteten Anwendungen und On-Premises-Systemen die Installation der Patches eigenständig planen und durchführen.“
Létitia Combes, Geschäftsführerin und Co-Gründerin von BxC Security
„Die beiden kritischen PHP-Sicherheitslücken stellen nicht nur für klassische IT-Systeme, sondern auch für industrielle Produktionsumgebungen ein erhebliches Risiko dar. Denn PHP kommt auch in der Operational Technology (OT) zum Einsatz, etwa in Managementoberflächen von Firewalls, industriellen Steuerungen, Fernwartungsportalen oder Monitoring-Systemen.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt, betroffene Systeme schnellstmöglich zu aktualisieren oder gegebenenfalls vorübergehend vom Netz zu nehmen.
In der OT ist dies jedoch nicht immer ohne Weiteres möglich. Die Abschaltung einzelner Komponenten kann den Produktionsbetrieb beeinträchtigen.
Zudem sind Unternehmen bei vielen industriellen Geräten auf Firmware-Updates der Hersteller angewiesen, die möglicherweise erst nach mehreren Wochen verfügbar sind.
Industrieunternehmen sollten daher zunächst prüfen, welche Systeme betroffen sind, und insbesondere Komponenten an der Schnittstelle zwischen IT und OT absichern. Wo Sicherheitsupdates nicht unmittelbar verfügbar sind, müssen zusätzliche Schutzmaßnahmen greifen. Dazu gehören eingeschränkte Zugriffsrechte, eine konsequente Netzwerksegmentierung sowie die kontinuierliche Überwachung auf verdächtige Aktivitäten.“
Gastbeitrag von Norbert Pohlmann, Ismael Valenzuela, Sai Molige, Udo Fink, Shane Barney, Mark Molyneux, Patrick Münch, Satnam Narang, Létitia Combes
Kommentare