Aktuelles zu Website-Sicherheit und DSGVO

26. Oktober 2026

PHP-Lücke „php2shell“: Version prüfen und auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 aktualisieren

Am 21. Oktober 2026 haben die PHP-Entwickler zwei kritische Lücken im PHP-Kern veröffentlicht (CVE-2026-109618 und CVE-2026-109619, beide CVSS 9,2 nach Version 4.0). Nach ihren Angaben lässt sich damit ohne Anmeldung über gewöhnliche Webanfragen Code auf dem Server ausführen. Am leichtesten gelingt das bei Apache mit mod_php, wo die Entwickler einen vollständigen Angriff gegen die Standardeinstellungen nachgewiesen haben; bei PHP-FPM sind die Fehler ebenfalls erreichbar, einen vollständigen Angriff haben sie dort bisher nicht gezeigt.

Betroffen sind laut NVD PHP-Versionen ab 5.4 (CVE-2026-109619) beziehungsweise ab 7.3 (CVE-2026-109618) bis unterhalb von 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Für PHP 8.1 und älter gibt es kein offizielles Update, dort helfen nur Pakete des Hosters oder der Linux-Distribution. Das Update ist nach Aussage der Entwickler die einzige vollständige Lösung. Unser neuer PHP2Shell-Check liest ohne Anmeldung aus, welche Version dein Server meldet — und sagt ehrlich, wenn sie versteckt ist: Das heißt nicht, dass sie sicher ist.

Quellen: PHP-Entwickler (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp), NVD (CVE-2026-109618, CVE-2026-109619).

Jetzt prüfen: PHP2Shell-Check →

26. Oktober 2026

Next.js: Update auf 16.4.1 oder 15.5.28 schließt zwei kritische Lücken und eine hohe

Am 14. Oktober 2026 hat das Next.js-Team ein außerplanmäßiges Sicherheitsupdate veröffentlicht (16.4.1 und 15.5.28); zwei der Korrekturen waren wegen verzögerter Zulieferer-Updates aus dem September-Release verschoben worden. Wer Next.js betreibt, sollte auf 16.4.1 beziehungsweise 15.5.28 oder neuer aktualisieren; von außen ist die Version meist nicht erkennbar.

Kritisch sind zwei Lücken, die ohne Anmeldung Codeausführung erlauben: erstens in use cache-Funktionen, die mehrere typisierte Arrays zurückgeben (App Router mit Cache Components; nur Version 16.0.0 bis 16.4.0, kein Ausweichen möglich), zweitens in der Bildoptimierung bei SVG-Dateien (CVE-2026-96889; Linux mit glibc; Next.js 10.0.0 bis 15.5.27 und 16.0.0 bis 16.4.0; als Zwischenlösung hilft sharp ab 0.35.5). Dazu kommt eine hohe Lücke: Mit präparierten Anfragen lässt sich ein App-Router-Server mit mindestens einer Server Action lahmlegen (ab Version 13.0.0).

Quellen: Next.js-Blog vom 14. Oktober 2026, Sicherheitsmeldungen GHSA-673q-mjm6-r5xr, GHSA-2464-fhr4-w9xw und GHSA-p3m5-59mp-jv5r.

Diese und weitere Prüfungen laufen im kostenlosen Scan mit →

26. Oktober 2026

DMARC: Neuer Standard RFC 9989 — pct entfällt, Testphase mit t=y

Im Mai 2026 hat die IETF DMARC neu gefasst: RFC 9989 ersetzt zusammen mit RFC 9990 (Berichte) und RFC 9991 (Einzelmeldungen) den bisherigen Standard RFC 7489. Das Prozent-Tag pct entfällt, weil es laut Standard in der Praxis meist nur bei 0 und 100 sauber umgesetzt wurde. Für eine Testphase gibt es stattdessen t=y: Empfänger behandeln gefälschte Mails dann eine Stufe milder (reject wie quarantine, quarantine wie none); bei p=none ändert sich nichts.

Neu sind außerdem np (Regel für nicht existierende Unterdomains) und psd; die Zuordnung zur Organisationsdomain läuft über einen DNS-Baumlauf statt über die Public-Suffix-Liste. Empfänger, die noch RFC 7489 umsetzen, werten pct weiterhin aus; unser Assistent schreibt für die Testphase deshalb pct=0; t=y. Für den Weg zu p=reject empfiehlt der Standard (Abschnitt 7.4), zuerst mindestens einen Monat p=none und danach gleich lange p=quarantine laufen zu lassen. Unser DMARC-Assistent und der Scanner kennen den neuen Standard.

Quelle: RFC 9989 (Mai 2026).

DMARC-Eintrag erstellen →

26. Oktober 2026

Digital Omnibus: EU-Staaten legen Position fest — Cookie-Einwilligung bleibt Pflicht

Am 21. Oktober 2026 hat der Rat der EU seine Verhandlungsposition zum „Digital Omnibus“ beschlossen, einem Paket mit Änderungen an DSGVO, ePrivacy und Meldepflichten. Für Website-Betreiber ist vor allem wichtig: Die Cookie-Regeln sollen in der ePrivacy-Richtlinie bleiben, statt in die DSGVO zu wandern, und die Einwilligung bleibt der Grundsatz. Den Vorschlag der Kommission, die Auswahl über ein zentrales Browser-Signal zu steuern, lehnt der Rat ab.

Dafür soll die Liste der Zwecke wachsen, für die keine Einwilligung nötig ist; genannt werden die Erbringung eines Dienstes, die Reichweitenmessung und die Sicherheit des Endgeräts. Nach Berichten von netzpolitik.org soll nach einer Entscheidung vier Monate lang nicht erneut gefragt werden dürfen; Deutschland, Österreich und Estland stimmten gegen die Ratsposition. Wichtig: Das ist erst eine Verhandlungsposition, kein Gesetz. Das Parlament hat seine Position noch nicht festgelegt (nach netzpolitik.org im Februar erwartet), danach folgen die Verhandlungen. Bis dahin gelten § 25 TDDDG und die DSGVO unverändert: Tracking- und Marketing-Cookies brauchen weiterhin eine echte Einwilligung.

Quellen: Pressemitteilung des Rates vom 21. Oktober 2026 (englisch), netzpolitik.org vom 22. Oktober 2026.

Was für Cookie-Banner heute gilt →

26. Oktober 2026

Chrome 154: Vor dem Aufruf von http-Seiten fragt Chrome jetzt standardmäßig nach

Seit dem 22. September 2026 ist Chrome 154 verfügbar. Nach den Release Notes fragt Chrome ab dieser Version standardmäßig nach, bevor es eine Seite über das unverschlüsselte http lädt („Ask before HTTP“); Administratoren können das über die Richtlinie HttpsOnlyMode ändern. Wer seine Seite noch ohne HTTPS ausliefert, riskiert, dass Besucher vor dem ersten Aufruf eine Warnung sehen und abspringen. Der Scanner prüft, ob die Seite per HTTPS erreichbar ist und ob http automatisch auf https umleitet.

Quelle: Chrome 154 Release Notes.

Diese und weitere Prüfungen laufen im kostenlosen Scan mit →

19. September 2026

Ab 27. September 2026: neue Regeln für Umweltwerbung und den Gewährleistungshinweis beim Warenverkauf

Am 27. September 2026 treten die Kernregeln zweier Gesetzesänderungen in Kraft, beide ohne Übergangsfrist; einzelne Teile gelten schon seit dem 19. Juni 2026 (BGBl. 2026 I Nr. 43 und Nr. 28). Erstens ergänzt das UWG seine schwarze Liste der Geschäftspraktiken, die gegenüber Verbrauchern immer unzulässig sind. Verboten sind dann unter anderem: Nachhaltigkeitssiegel, die weder auf einem Zertifizierungssystem mit unabhängiger Prüfung beruhen noch staatlich festgesetzt sind; allgemeine Umweltaussagen wie „umweltfreundlich“ oder „grün“, wenn keine anerkannte hervorragende Umweltleistung nachgewiesen wird (etwa durch das EU-Umweltzeichen) — nennt die Werbung dagegen klar und hervorgehoben auf demselben Medium, worauf sich die Aussage genau bezieht, gilt sie als spezifisch und fällt nicht unter dieses Verbot; die Aussage, ein Produkt sei dank Kompensation von Treibhausgasen klimaneutral, emissionsverringert oder klimapositiv; sowie bestimmte irreführende Angaben zu Softwareaktualisierungen, Haltbarkeit und Reparierbarkeit von Waren. Zweitens müssen Unternehmer, die Waren an Verbraucher verkaufen — online wie im Laden (ausgenommen Alltagsgeschäfte, die sofort erfüllt werden) —, den einheitlichen EU-Hinweis auf das gesetzliche Gewährleistungsrecht in hervorgehobener Weise zeigen, bevor der Verbraucher seine Vertragserklärung abgibt, online also bevor er bestellt. Gewährt der Hersteller eine kostenlose Haltbarkeitsgarantie von mehr als zwei Jahren für die gesamte Ware und teilt er das dem Händler mit, muss der Händler zusätzlich das einheitliche Garantie-Label zeigen. Für rein digitale Produkte gilt die harmonisierte Mitteilung nicht; dort besteht eine eigene, schlichte Hinweispflicht auf das Gewährleistungsrecht. Das Garantie-Label muss online zusätzlich unmittelbar vor dem Absenden der Bestellung erscheinen (§ 312j Abs. 2 BGB); für den Gewährleistungshinweis selbst sagt das Gesetz nur „in hervorgehobener Weise“, wo genau er im Shop stehen muss, ist also nicht festgelegt.

Mehr rechtliche Einordnungen im Ratgeber →

19. September 2026

WordPress-Lücke „wp2shell“: Update auf 6.8.6, 6.9.5 oder 7.0.2 prüfen

Am 17. Juli 2026 hat WordPress zwei Lücken im Kern geschlossen (CVE-2026-60137 und CVE-2026-63030), die zusammen Codeausführung ohne Anmeldung erlauben. Betroffen sind laut WordPress.org die Versionen 6.8 (nur die erste Lücke) und 6.9; nach Angaben von Rapid7 und Tenable auch 7.0.0 und 7.0.1. Behoben sind sie in 6.8.6, 6.9.5 und 7.0.2. Die US-Behörde CISA hat beide Lücken am 21. Juli in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen, es gab breites Scanning mit öffentlichen Exploits. WordPress hat automatische Sicherheitsupdates erzwungen — wer sie abgeschaltet hat, sollte unter Dashboard → Aktualisierungen die installierte Version prüfen. Ein Cache oder eine Firewall ersetzt das Update nicht. Der kostenlose Scan gleicht die WordPress-Version mit der Schwachstellendatenbank ab, sofern die Seite sie im Quelltext nennt.

Diese und weitere Prüfungen laufen im kostenlosen Scan mit →

15. September 2026

Mehrere kritische WordPress-Plugin-Lücken werden gerade aktiv ausgenutzt

In derselben Woche wurden gleich drei kritische Lücken in weitverbreiteten WordPress-Plugins bekannt, die unangemeldeten Angreifern das Hochladen von Schadcode erlauben: Elementor Pro (CVE-2026-32475, CVSS 9.8, wird bereits aktiv ausgenutzt — rund zwei Drittel der 10 Millionen Installationen laufen noch auf einer verwundbaren Version ≤ 4.2.1, Fix ist 4.2.2), Forminator Forms (CVE-2026-15748, betrifft über 300.000 Websites) und Everest Forms (CVE-2026-19598, über 100.000 Websites). Unser Scanner prüft Plugin-Versionen bewusst nicht automatisch mit — sie lassen sich von außen nur unzuverlässig erraten, und ein falscher Alarm schadet mehr als gar keiner. Wer eines dieser Plugins einsetzt, sollte die installierte Version im WordPress-Backend jetzt von Hand prüfen.

Diese und weitere Prüfungen laufen im kostenlosen Scan mit →

15. September 2026

CRA-Meldepflicht ist jetzt in Kraft — ENISA-Plattform live

Die am 30. August angekündigte Meldepflicht nach Artikel 14 des Cyber Resilience Act gilt seit dem 11. September 2026 tatsächlich: Hersteller von Software mit digitalen Elementen müssen eine aktiv ausgenutzte Schwachstelle binnen 24 Stunden an die zuständige Behörde melden. ENISA hat dafür die zentrale „Single Reporting Platform“ (SRP) freigeschaltet — sie läuft, wie mehrere unabhängige Quellen bestätigen. Die volle CRA-Pflicht (technische Dokumentation, CE-Kennzeichnung, Bußgelder) greift erst ab dem 11. Dezember 2027; bis dahin bleibt eine versäumte Meldung folgenlos, außer dass das BSI betroffene Nutzer dann selbst informieren darf.

Mehr rechtliche Einordnungen im Ratgeber →

30. August 2026

Chrome warnt ab Herbst 2026 automatisch vor HTTP-Websites

Google rollt die Funktion „Always Use Secure Connections“ in zwei Stufen aus: seit April 2026 für Nutzer mit aktiviertem Enhanced Safe Browsing, ab Chrome 154 für alle. Chrome 154 wird ab dem 22. September 2026 ausgeliefert, Google selbst nennt für die Umstellung den Oktober 2026. Wer noch kein HTTPS eingerichtet hat, dessen Besucher bekommen dann vor dem ersten Aufruf der Seite eine Warnseite vorgeschaltet, die sich übergehen lässt. Betroffen sind nur öffentlich erreichbare Seiten, interne Netzwerke (Router, Firmen-Intranet) bleiben ausgenommen.

Diese und weitere Prüfungen laufen im kostenlosen Scan mit →

30. August 2026

CRA: Meldepflicht für Software-Hersteller ab 11. September 2026

Ab diesem Datum greift Artikel 14 des Cyber Resilience Act: Wer Software mit digitalen Elementen ausliefert, muss eine aktiv ausgenutzte Schwachstelle binnen 24 Stunden an die zuständige Behörde melden. Betroffen sind Hersteller von Software-Produkten (z. B. WordPress-Plugins, Apps) — reine Websites ohne ausgeliefertes Produkt fallen nicht darunter.

Mehr rechtliche Einordnungen im Ratgeber →

30. August 2026

Nur jede vierte Website hat eine wirksame Content-Security-Policy

Aktuelle Erhebungen zu HTTP-Sicherheitsheadern zeigen: Bei den meistbesuchten Websites weltweit setzen weniger als 25 % eine Content-Security-Policy ein, die tatsächlich vor eingeschleustem Code schützt. Rund 40 % fehlt selbst der einfache Basisschutz X-Content-Type-Options. Eine korrekt konfigurierte CSP verhindert die meisten Skript-Einschleusungen zuverlässig — auch wenn an anderer Stelle der Seite eine Lücke besteht.

Wie die wichtigsten Sicherheits-Header funktionieren →