- Fehler 1: Reicht ein WordPress- oder Plugin-Update, um dich vor PHP2Shell zu schützen?
- Fehler 2: Läuft auf deinem Server wirklich die gepatchte PHP-Version?
- Fehler 3: Sind Workarounds und WAF ein vollständiger Schutz?
- Fehler 4: Gibt es für PHP-Versionen unter 8.2 wirklich gar keine Updates?
- Fehler 5: Ist Extended Support günstiger als ein Upgrade?
- Fehler 6: Reicht ein Patch auf PHP 8.2.35, obwohl der Support am 31.12.2026 endet?
- Was kann dir kein Chatbot sagen? So gehen wir bei milkycode mit PHP2Shell vor
- FAQ
- Was ist PHP2Shell und wie gefährlich ist die aktuelle PHP-Sicherheitslücke?
- Welche PHP-Versionen sind von CVE-2026-109618 und CVE-2026-109619 betroffen?
- Welche PHP-Version schließt die Lücke?
- Gibt es einen Patch für PHP 7.4, 8.0 oder 8.1?
- Warum schaltet mein Hoster oder meine Agentur meine Website ab?
- Wo sehe ich, welche PHP-Version meine Website nutzt?
- Auf welche PHP-Version sollte ich upgraden: 8.3, 8.4 oder 8.5?
- Referenzen
PHP2Shell: 6 Fehler bei der PHP-Sicherheitslücke vom 21.10.2026 und warum wir alte PHP-Versionen ggf. abschalten müssen
Key Takeaways
- Am 21.10.2026 erschienen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 (The PHP Group, 2026).
- Die PHP Sicherheitslücke PHP2Shell erlaubt Codeausführung ohne Anmeldung. Das BSI bewertet sie 2026 mit CVSS v4.0 9.2 (BSI, 2026).
- Für PHP 7.4 bis 8.1 gibt es nur Quell-Backports oder LTS-Fixes.
- Für PHP 5.x bis 7.3 gibt es keine Updates. Solche Websites nehmen wir ggf. vorübergehend vom Netz.
- PHP 8.2 erreicht am 31.12.2026 sein End of Life.
Transparenzhinweis: Recherchestand: 21.10.2026. Grundlage sind die BSI-Cybersicherheitswarnung 2026-297981-1032, das Security-Advisory auf php.net, CERT-EU Advisory 2026-018 und Analysen von Sansec und Huntress. Dazu kommen Preisangaben von Extended-Support-Anbietern und unsere eigenen Erfahrungen aus dem Patch-Rollout.
Die Lage entwickelt sich weiter. Wir aktualisieren den Artikel, sobald neue Fakten vorliegen. Eine KI hat bei der Gliederung unterstützt. Fakten und Bewertungen hat das milkycode-Team geprüft.
Im Jahr 2026 läuft PHP auf rund 75 % aller Websites mit bekannter serverseitiger Sprache. Das zeigen W3Techs-Daten, zitiert von HeroDevs in „PHP End-of-Life Dates: Support Timeline for Every Version (2026)“ (HeroDevs, 2026). Die PHP Sicherheitslücke PHP2Shell betrifft also fast jede Firmenwebsite. Hier sind die sechs häufigsten Fehler vom Patch-Tag.
Fehler 1: Reicht ein WordPress- oder Plugin-Update, um dich vor PHP2Shell zu schützen?
Nein. Ein WordPress-, Shopware- oder Plugin-Update schließt PHP2Shell nicht, denn die Lücke steckt im PHP-Interpreter selbst. Im Jahr 2026 bewertet das BSI in seiner Cybersicherheitswarnung 2026-297981-1032 beide CVEs mit CVSS v4.0 9.2 (BSI, 2026). Du musst die PHP-Laufzeit aktualisieren.
Warum passiert der Fehler? Viele kennen nur das CMS-Backend mit seinem Update-Button. Die PHP-Version liegt aber beim Hoster oder Server-Admin. Dein WordPress kann topaktuell sein und trotzdem auf einem verwundbaren PHP laufen.
Laut php.net ist jede Installation betroffen, die Webanfragen bedient:
- PHP-FPM
- mod_php
- php-cgi
- FrankenPHP
- LiteSpeed
Bei mod_php ist das Risiko am höchsten. Dort greift der Exploit, bevor überhaupt Anwendungscode läuft. Im Oktober 2026 stuft das BSI die Lage in derselben Warnung 2026-297981-1032 mit Kritikalität 3/Orange ein und verlangt unverzügliches Handeln (BSI, 2026).
Dazu kommt das Tempo. Die Details waren laut Huntress schon am 20.10. durchgesickert. Sansec berichtet unter Berufung auf Cloudflare von Angriffen noch vor dem Release. Die PHP Sicherheitslücke PHP2Shell ist also kein theoretisches Problem.
Deine Lösung: Frag deinen Hoster oder deine Agentur, ob die PHP-Laufzeit gepatcht wurde. Bei Managed Hosting von milkycode übernehmen wir das für dich. Mehr dazu findest du bei unseren WordPress-Websites und WordPress-Hosting.
Fehler 2: Läuft auf deinem Server wirklich die gepatchte PHP-Version?
Oft nicht, denn viele prüfen an der falschen Stelle. Sicher sind laut The PHP Group im „PHP News Archive 2026, Security advisory“ (Stand 21.10.2026) nur PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 (The PHP Group, 2026). Zeigt php -v eine neue Version, kann PHP-FPM trotzdem die alte ausliefern.
| Versionszweig | Sichere Version ab | Status (Oktober 2026) |
|---|---|---|
| PHP 8.5 | 8.5.12 | offizielles Release |
| PHP 8.4 | 8.4.27 | offizielles Release |
| PHP 8.3 | 8.3.36 | offizielles Release |
| PHP 8.2 | 8.2.35 | offizielles Release, EOL 31.12.2026 |
CLI vs. Web-SAPI: Was ist der häufigste Prüffehler?
CLI- und Web-PHP sind oft getrennte Binaries oder Pakete. Die Kommandozeile sagt also wenig über deine Website.
[PRACTICAL EXAMPLE] So prüfst du richtig: Ruf eine phpinfo()-Seite auf oder öffne den Website-Zustand im WordPress-Backend. Starte nach dem Update PHP-FPM oder Apache neu, etwa mit systemctl restart php8.3-fpm. Erst danach lädt der Server das neue Binary. Lösch die phpinfo()-Datei nach der Prüfung wieder.
Was gilt für Docker, CI und Paketquellen?
Docker- und CI-Images musst du neu bauen und neu ausrollen. Nur das Base-Image-Tag zu ändern, reicht nicht.
Achte auch auf Fremd-Repositories. Laut php.net gab es am Release-Tag noch keine Remi-Pakete. Gleich deshalb die Backports deiner Distribution ab (Debian, Ubuntu, RHEL). Bei Plesk und cPanel kommen die Pakete vom Hersteller. Prüf dort jede PHP-Handler-Version einzeln.
Fehler 3: Sind Workarounds und WAF ein vollständiger Schutz?
Workarounds senken das Risiko, ersetzen aber kein Update. Im Jahr 2026 empfiehlt The PHP Group im „PHP News Archive 2026, Security advisory“ als Übergang, post_max_size auf 8M ohne bzw. 32M mit Datei-Uploads zu begrenzen (The PHP Group, 2026). Sicher wird die Installation dadurch nicht.
Warum passiert der Fehler? Workarounds sind schnell gesetzt. Sie vermitteln ein trügerisches Gefühl von Sicherheit.
php.net nennt drei Maßnahmen:
- Anpassung von
memory_limit - ein niedriges
post_max_size session.upload_progress.enabled=0
Alle drei wirken nur teilweise gegen die PHP Sicherheitslücke PHP2Shell.
Ein typischer Fehler ist die falsche Ebene. Viele setzen die Werte per ini_set() oder .user.ini. Das greift bei dieser Lücke zu spät oder gar nicht. Konfiguriere die Werte deshalb serverweit in der php.ini und starte den Dienst neu.
Auch eine Web Application Firewall (WAF) hat Grenzen. Sie filtert bekannte Muster. Neue Exploit-Varianten können sie umgehen.
Das BSI warnt, dass KI-gestützte Werkzeuge Patches binnen Stunden in Exploits umwandeln können. WAF-Signaturen kommen da oft nicht hinterher.
Deine Lösung: Nutz Workaround und WAF nur als Brücke bis zum Patch. Setz dir dafür eine feste Deadline, am besten in Tagen statt Wochen.
Fehler 4: Gibt es für PHP-Versionen unter 8.2 wirklich gar keine Updates?
Die pauschale Aussage stimmt so nicht. Im Jahr 2026 hat das PHP-Sicherheitsteam laut „PHP News Archive 2026, Security advisory“ für drei Legacy-Zweige (7.4, 8.0, 8.1) minimale Quell-Backports bereitgestellt (The PHP Group, 2026). Offizielle Releases gibt es nicht. Für PHP 5.x und 7.0 bis 7.3 gibt es keine Fixes.
Warum passiert der Fehler? Seit dem Support-Ende von PHP 8.1 gilt alles unter 8.2 als „tot“. Das ist zu grob.
Warum drei Gruppen statt einer starren Grenze?
| Gruppe | Versionen | Was es gibt | Was du tust |
|---|---|---|---|
| A | PHP 8.2 bis 8.5 | offizielle Releases | sofort einspielen |
| B | PHP 7.4 bis 8.1 | Quell-Backports, Distributionen, LTS-Anbieter | nur mit geprüftem Fix weiterbetreiben |
| C | PHP 5.x bis 7.3 | keine Fixes | Upgrade oder vorübergehende Abschaltung |
In Gruppe B helfen Distributionen und LTS-Anbieter wie Freexian, maxcluster oder IONOS. Die Backports sind sonst nur zum Selbstkompilieren gedacht.
Wann ist eine Abschaltung wirklich nötig?
Im Oktober 2026 hält das BSI in der Warnung 2026-297981-1032 fest, dass alle PHP-Versionen bis mindestens PHP 5 verwundbar sind (BSI, 2026). Für Gruppe C nennt das BSI die vorübergehende Trennung vom Internet ausdrücklich als Option.
Unser Vorgehen: Wir prüfen jedes System einzeln. Abgeschaltet wird nur, wenn weder Patch noch Backport verfügbar ist. Und immer erst, nachdem wir dich informiert haben. Die PHP Sicherheitslücke PHP2Shell ist für uns kein Grund für pauschale Entscheidungen.
Fehler 5: Ist Extended Support günstiger als ein Upgrade?
Kurzfristig oft ja, langfristig selten. Im Oktober 2026 verlangt IONOS laut eigener Preisliste 7,81 € (PHP 8.1) bis 15,62 € (PHP 7.4, 8.0) monatlich. Das zitiert Winning Solutions in „PHP 8.4 Update“ (Winning Solutions, 2026). Das kauft Zeit, löst aber keine Kompatibilitätsprobleme.
| Option | Laufende Kosten | Schützt CMS/Shop? | Dauerlösung? |
|---|---|---|---|
| IONOS Extended Support | 7,81 € bis 15,62 €/Monat | nein | nein |
| Extended Support anderer Hoster | je nach Anbieter | nein | nein |
| Upgrade auf PHP 8.4 | einmaliges Projekt | teilweise, je nach Shop-Version | ja |
Warum passiert der Fehler? Die Monatsgebühr wirkt klein im Vergleich zu einem Upgrade-Projekt.
Es gibt aber versteckte Kosten. Backports kommen bei Extended-Support-Anbietern teils später. Genau diese Zeitspanne ist bei PHP2Shell kritisch.
Außerdem bleiben veraltete Shop- und CMS-Versionen ohne Sicherheitsupdates. Extended Support schützt nur die PHP-Ebene.
Unsere Faustregel: Extended Support ist eine Brücke von wenigen Monaten. Er braucht einen festen Upgrade-Termin und ist kein Dauerzustand.
Die Ergebnisse können je nach Codebasis variieren. Eine Kostenschätzung lohnt sich deshalb vor der Entscheidung. Wie wir solche Projekte angehen, liest du unter Webentwicklung und PHP-Upgrades.
Fehler 6: Reicht ein Patch auf PHP 8.2.35, obwohl der Support am 31.12.2026 endet?
Nein, du hast sonst in zehn Wochen das nächste Problem. Im Jahr 2026 nennt The PHP Group in „PHP: Supported Versions“ den 31.12.2026 als Support-Ende für PHP 8.2 (The PHP Group, 2026). PHP 8.4 erhält Updates bis Ende 2028, PHP 8.5 bis Ende 2029. Plane das Upgrade gleich mit.
Warum passiert der Fehler? Nach dem Notfall-Patch wirkt das Thema erledigt. Dabei steht das php 8.2 end of life kurz bevor. Die PHP Sicherheitslücke PHP2Shell zeigt, was ohne Updates passiert.
Warum ist PHP 8.4 für die meisten die pragmatische Wahl?
PHP 8.4 läuft schon lange stabil. Viele Shop-Systeme und Plugins sind darauf getestet. PHP 8.5 bringt ein Jahr mehr Support, aber manche Erweiterungen hinken noch hinterher.
Wie prüfst du Shop- und CMS-Kompatibilität vor dem Wechsel?
Der Shop gibt die Grenze vor. Aus den Herstellerangaben und unserer Projektpraxis ergibt sich folgendes Bild. Prüf die aktuellen Anforderungen deiner Version trotzdem vor jedem Wechsel beim Hersteller.
| System | Höchste unterstützte PHP-Version |
|---|---|
| Shopware 5.7 | PHP 8.2 |
| Magento 2.4.6 | PHP 8.1/8.2 |
| WooCommerce | getestet bis PHP 8.4 |
Daraus folgt: Manche Kunden brauchen ein Shop- oder CMS-Upgrade, nicht nur einen PHP-Wechsel.
Unser empfohlener Pfad:
- Staging-Kopie anlegen.
- Auf PHP 8.4 testen.
- Plugins und Themes prüfen.
- Live-Wechsel deutlich vor dem 31.12.2026.
Für Legacy-Individualsoftware planen wir eine eigene Roadmap. Mehr dazu unter Legacy-Anwendungen mit Zend Framework modernisieren.
Was kann dir kein Chatbot sagen? So gehen wir bei milkycode mit PHP2Shell vor
Ein Chatbot mit älterem Wissensstand kennt den 21.10.2026 nicht. Im Jahr 2026 meldete Cloudflare laut Sansec („PHP2Shell: Critical PHP RCE“) erste Angriffe um 07:43 UTC, also vor dem Release (Sansec, 2026). Hier zeigen wir dir, wie wir als Kölner Agentur und Hoster reagiert haben.
Die Zeitleiste des Patch-Tags
- 20.10.2026: Details zur Lücke sickern durch (Huntress, 2026).
- 21.10.2026, 07:43 UTC: erste Angriffe laut Cloudflare-Daten, zitiert von Sansec.
- 21.10.2026, 13:30 UTC: Release der Fixes laut CERT-EU „Security Advisory 2026-018“, also vor dem angekündigten Termin um 14:00 UTC (CERT-EU, 2026).
- Danach: unser Rollout auf alle betreuten Systeme, soweit möglich.
Unsere Priorisierung
[PRACTICAL EXAMPLE] Wir sind nach Risiko vorgegangen, nicht nach Kundennummer:
- Systeme mit mod_php, weil der Exploit dort vor dem Anwendungscode greift.
- PHP-FPM-Systeme.
- Shops mit Kundendaten vor reinen Info-Websites.
Die genaue Zahl gepatchter Systeme und die Dauer tragen wir nach Abschluss des Rollouts nach. Schätzungen veröffentlichen wir bewusst nicht.
Wie wir dich informieren
Du bekommst von uns eine Nachricht mit deiner PHP-Version und dem Status. Bei Gruppe C nennen wir dir eine Frist, bevor wir abschalten.
Wir besprechen mit dir die Optionen: Upgrade, Extended Support oder vorübergehende Trennung. Nach dem Upgrade schalten wir die Website gemeinsam mit dir wieder frei und prüfen die Funktionen.
Welche Pflichten hast du in Deutschland?
Das BSI nennt die vorübergehende Netztrennung ausdrücklich als Option. Wurde ein Shop mit Kundendaten kompromittiert, kann eine DSGVO-Meldepflicht entstehen. Die Frist dafür liegt bei 72 Stunden nach Kenntnis.
Die Verantwortung verteilt sich oft auf drei Rollen: Agentur, Hoster und Shopbetreiber. Wer was schuldet, hängt von deinen Verträgen ab. Hol dir dafür bitte individuelle Rechtsberatung.
Kompromittierungsprüfung nach dem Patch
Laut BSI gibt es noch keine verbindlichen Indicators of Compromise. Ein Patch schließt die Tür, wirft aber keinen Eindringling hinaus. Unser Monitoring achtet deshalb auf:
- Webshells in Upload- und Cache-Ordnern
- neue Admin-Konten im CMS oder Shop
- geänderte Dateien seit dem 20.10.
- ungewöhnliche Abstürze von PHP-Workern
Unsere Entscheidungsmatrix
[UNIQUE INSIGHT] Die Versionsgruppe allein reicht für eine Entscheidung nicht. Erst zusammen mit dem Shop-Typ wird klar, was zu tun ist.
| Versionsgruppe | Info-Website | Shop mit Kundendaten |
|---|---|---|
| A (8.2 bis 8.5) | patchen, Upgrade auf 8.4 planen | sofort patchen, Logs prüfen |
| B (7.4 bis 8.1) | Backport oder LTS, Upgrade bis Jahresende | Backport sofort, sonst Abschaltung erwägen |
| C (5.x bis 7.3) | Abschaltung nach Frist, Upgrade | Abschaltung zeitnah, Forensik prüfen |
Die PHP Sicherheitslücke PHP2Shell trifft also nicht jeden gleich. Bei unserem Magento-SaaS-Projekt Promotional Webshop und anderen Referenzen und Case-Studies siehst du, wie unterschiedlich PHP-Stacks sein können.
Grenzen, Alternativen & professionelle Beratung
Die Lage ist dynamisch. Neue Exploit-Varianten oder Nachbesserungen am Patch sind möglich. Unsere Matrix ist eine Orientierung, und die Ergebnisse können je nach System variieren.
Es gibt Alternativen zur Abschaltung. Dazu zählen Extended Support, eine WAF als Brücke und die Backports deiner Distribution. Alle drei kaufen Zeit, ersetzen aber kein Upgrade.
Hast du den Verdacht, dass dein System kompromittiert wurde? Dann zieh Forensik-Experten hinzu. Bei Kundendaten gehört auch dein Datenschutzbeauftragter früh ins Boot. Wir unterstützen dich technisch, ersetzen aber keine Rechtsberatung.
Du willst wissen, wo dein System steht? Buch ein kostenloses Erstgespräch zum PHP-Upgrade oder sprich uns einfach an. Neue Entwicklungen findest du in unseren weiteren Sicherheits-News von milkycode.
FAQ
Was ist PHP2Shell und wie gefährlich ist die aktuelle PHP-Sicherheitslücke?
Die PHP Sicherheitslücke PHP2Shell umfasst CVE-2026-109618 und CVE-2026-109619. Angreifer können damit ohne Anmeldung Code auf deinem Server ausführen. Das BSI bewertet beide in seiner Warnung von 2026 mit CVSS v4.0 9.2 und Kritikalität 3/Orange. Erste Angriffe gab es laut Cloudflare-Daten schon vor dem Release. Handle also sofort und warte nicht auf den nächsten Wartungstermin.
Welche PHP-Versionen sind von CVE-2026-109618 und CVE-2026-109619 betroffen?
Laut BSI-Warnung von 2026 sind alle PHP-Versionen bis mindestens PHP 5 verwundbar. Betroffen ist jede Installation, die Webanfragen bedient. Dazu gehören PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed. Bei mod_php ist das Risiko am höchsten. Sicher sind nur die gepatchten Releases vom 21.10.2026 oder geprüfte Backports.
Welche PHP-Version schließt die Lücke?
Laut php.net schließen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 die Lücken. Diese Releases erschienen am 21.10.2026. Wichtig ist, dass die Web-SAPI diese Version nutzt, nicht nur die Kommandozeile. Starte PHP-FPM oder Apache nach dem Update neu. Bau Docker-Images komplett neu.
Gibt es einen Patch für PHP 7.4, 8.0 oder 8.1?
Teilweise. Das PHP-Sicherheitsteam hat minimale Quell-Backports für diese drei Zweige bereitgestellt. Offizielle Releases gibt es aber nicht. Du kannst selbst kompilieren oder Fixes von Distributionen und LTS-Anbietern wie Freexian, maxcluster oder IONOS nutzen. Ein Weiterbetrieb ist nur mit geprüftem Fix sinnvoll. Plane trotzdem das Upgrade.
Warum schaltet mein Hoster oder meine Agentur meine Website ab?
Für PHP 5.x und 7.0 bis 7.3 gibt es keine Fixes. Eine solche Website bleibt offen für Angriffe. Das BSI nennt die vorübergehende Trennung vom Internet ausdrücklich als Option. Bei milkycode schalten wir nur ab, wenn weder Patch noch Backport verfügbar ist. Wir informieren dich vorher und nennen dir eine Frist.
Wo sehe ich, welche PHP-Version meine Website nutzt?
In WordPress findest du die Version unter Werkzeuge und Website-Zustand. In Shopware und Magento zeigt die Systeminfo im Backend die Version. Alternativ hilft eine phpinfo()-Seite, die du danach wieder löschst. Verlass dich nicht auf php -v. Die Kommandozeile nutzt oft ein anderes Binary als deine Website.
Auf welche PHP-Version sollte ich upgraden: 8.3, 8.4 oder 8.5?
Für die meisten ist PHP 8.4 die pragmatische Wahl. Laut php.net-Seite „Supported Versions“ (Stand 2026) bekommt es Sicherheitsupdates bis Ende 2028. PHP 8.5 läuft bis Ende 2029, aber nicht jedes Plugin ist schon bereit. PHP 8.3 ist möglich, bringt aber weniger Puffer. Teste dein System vorher auf einer Staging-Kopie.
Referenzen
- Bundesamt für Sicherheit in der Informationstechnik (BSI): „PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit (BITS-H 2026-297981-1032)“, 2026. Behördliche Cybersicherheitswarnung, abgerufen am 21.10.2026. https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2026/2026-297981-1032.pdf?__blob=publicationFile&v=3
- The PHP Group (php.net): „PHP News Archive 2026, Security advisory: Critical RCE vulnerabilities“, 2026. Offizielles Hersteller-Advisory, abgerufen am 21.10.2026. https://www.php.net/archive/2026.php
- The PHP Group (php.net): „PHP: Supported Versions“, 2026. Offizielle Support-Zeitleiste, Stand Oktober 2026. https://www.php.net/supported-versions.php
- CERT-EU: „Security Advisory 2026-018: Critical Vulnerabilities in PHP“, 2026. Sicherheitshinweis der EU-Institutionen, abgerufen am 21.10.2026. https://cert.europa.eu/publications/security-advisories/2026-018
- Sansec: „PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)“, 2026. Kommerzielle Sicherheitsforschung mit Cloudflare-Telemetrie, abgerufen am 21.10.2026. https://sansec.io/research/php2shell
- Huntress: „Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities“, 2026. Analyse zur Leak-Vorgeschichte, abgerufen am 21.10.2026. https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
- Winning Solutions: „PHP 8.4 Update (IONOS-Preise für Extended Support)“, 2026. Sekundärquelle zur IONOS-Preisliste, abgerufen im Oktober 2026. https://www.winning-solutions.de/php-update/
- HeroDevs: „PHP End-of-Life Dates: Support Timeline for Every Version (2026)“, 2026. Kommerzieller Blog mit W3Techs-Daten, Eigeninteresse beachten, abgerufen im Oktober 2026. https://www.herodevs.com/blog-posts/php-end-of-life-dates-support-timeline-for-every-version-2026
- University of Reading, Department of Languages and Cultures: „Research in German studies“, 2026. Akademische Hintergrundquelle zur deutschsprachigen Fachkommunikation, kein Beleg für technische Zahlen, abgerufen im Oktober 2026. https://www.reading.ac.uk/languages-cultures/research/german-studies
Mehr über unsere Arbeit mit PHP findest du unter PHP-Entwicklung und Projekte von milkycode und auf unserer Seite über uns.
Schreibe einen Kommentar