<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="de">
  <title>Apexly Aktuelles</title>
  <subtitle>Neue Sicherheitslücken, Regeln und Fristen für Website-Betreiber – kurz erklärt, mit Quelle.</subtitle>
  <link rel="self" type="application/atom+xml" href="https://apexly.de/aktuelles.xml"/>
  <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html"/>
  <id>https://apexly.de/aktuelles.xml</id>
  <updated>2026-10-26T08:04:00Z</updated>
  <author><name>Apexly</name><uri>https://apexly.de/</uri></author>
  <entry>
    <title>PHP-Lücke „php2shell“: Version prüfen und auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 aktualisieren</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#php2shell"/>
    <id>https://apexly.de/aktuelles.html#php2shell</id>
    <published>2026-10-26T08:04:00Z</published>
    <updated>2026-10-26T08:04:00Z</updated>
    <summary type="text">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.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Quellen: PHP-Entwickler (&lt;a href=&quot;https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w&quot; rel=&quot;noopener noreferrer&quot;&gt;GHSA-w8hw-w9fx-j79w&lt;/a&gt;, &lt;a href=&quot;https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp&quot; rel=&quot;noopener noreferrer&quot;&gt;GHSA-6wmf-4rv5-p3rp&lt;/a&gt;), NVD (&lt;a href=&quot;https://nvd.nist.gov/vuln/detail/CVE-2026-109618&quot; rel=&quot;noopener noreferrer&quot;&gt;CVE-2026-109618&lt;/a&gt;, &lt;a href=&quot;https://nvd.nist.gov/vuln/detail/CVE-2026-109619&quot; rel=&quot;noopener noreferrer&quot;&gt;CVE-2026-109619&lt;/a&gt;).&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/php2shell-check.html&quot;&gt;Jetzt prüfen: PHP2Shell-Check →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>Next.js: Update auf 16.4.1 oder 15.5.28 schließt zwei kritische Lücken und eine hohe</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#nextjs-oktober"/>
    <id>https://apexly.de/aktuelles.html#nextjs-oktober</id>
    <published>2026-10-26T08:03:00Z</published>
    <updated>2026-10-26T08:03:00Z</updated>
    <summary type="text">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.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Kritisch sind zwei Lücken, die ohne Anmeldung Codeausführung erlauben: erstens in &lt;code&gt;use cache&lt;/code&gt;-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).&lt;/p&gt;
&lt;p&gt;Quellen: &lt;a href=&quot;https://nextjs.org/blog/nextjs-security-update-october-14-2026&quot; rel=&quot;noopener noreferrer&quot;&gt;Next.js-Blog vom 14. Oktober 2026&lt;/a&gt;, Sicherheitsmeldungen &lt;a href=&quot;https://github.com/vercel/next.js/security/advisories/GHSA-673q-mjm6-r5xr&quot; rel=&quot;noopener noreferrer&quot;&gt;GHSA-673q-mjm6-r5xr&lt;/a&gt;, &lt;a href=&quot;https://github.com/vercel/next.js/security/advisories/GHSA-2464-fhr4-w9xw&quot; rel=&quot;noopener noreferrer&quot;&gt;GHSA-2464-fhr4-w9xw&lt;/a&gt; und &lt;a href=&quot;https://github.com/vercel/next.js/security/advisories/GHSA-p3m5-59mp-jv5r&quot; rel=&quot;noopener noreferrer&quot;&gt;GHSA-p3m5-59mp-jv5r&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/#checks&quot;&gt;Diese und weitere Prüfungen laufen im kostenlosen Scan mit →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>DMARC: Neuer Standard RFC 9989 — pct entfällt, Testphase mit t=y</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#dmarc-rfc9989"/>
    <id>https://apexly.de/aktuelles.html#dmarc-rfc9989</id>
    <published>2026-10-26T08:02:00Z</published>
    <updated>2026-10-26T08:02:00Z</updated>
    <summary type="text">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.</summary>
    <content type="html">&lt;p&gt;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 &lt;code&gt;pct&lt;/code&gt; 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 &lt;code&gt;t=y&lt;/code&gt;: Empfänger behandeln gefälschte Mails dann eine Stufe milder (reject wie quarantine, quarantine wie none); bei &lt;code&gt;p=none&lt;/code&gt; ändert sich nichts.&lt;/p&gt;
&lt;p&gt;Neu sind außerdem &lt;code&gt;np&lt;/code&gt; (Regel für nicht existierende Unterdomains) und &lt;code&gt;psd&lt;/code&gt;; die Zuordnung zur Organisationsdomain läuft über einen DNS-Baumlauf statt über die Public-Suffix-Liste. Empfänger, die noch RFC 7489 umsetzen, werten &lt;code&gt;pct&lt;/code&gt; weiterhin aus; unser Assistent schreibt für die Testphase deshalb &lt;code&gt;pct=0; t=y&lt;/code&gt;. Für den Weg zu &lt;code&gt;p=reject&lt;/code&gt; empfiehlt der Standard (Abschnitt 7.4), zuerst mindestens einen Monat &lt;code&gt;p=none&lt;/code&gt; und danach gleich lange &lt;code&gt;p=quarantine&lt;/code&gt; laufen zu lassen. Unser DMARC-Assistent und der Scanner kennen den neuen Standard.&lt;/p&gt;
&lt;p&gt;Quelle: &lt;a href=&quot;https://www.rfc-editor.org/rfc/rfc9989.html&quot; rel=&quot;noopener noreferrer&quot;&gt;RFC 9989 (Mai 2026)&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/dmarc-generator.html&quot;&gt;DMARC-Eintrag erstellen →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>Digital Omnibus: EU-Staaten legen Position fest — Cookie-Einwilligung bleibt Pflicht</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#digital-omnibus-rat"/>
    <id>https://apexly.de/aktuelles.html#digital-omnibus-rat</id>
    <published>2026-10-26T08:01:00Z</published>
    <updated>2026-10-26T08:01:00Z</updated>
    <summary type="text">Am 21. Oktober 2026 hat der Rat der EU seine Verhandlungsposition zum „Digital Omnibus“ beschlossen, einem Paket mit Änderungen an DSGVO, ePrivacy und Meldepflichten.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Quellen: &lt;a href=&quot;https://www.consilium.europa.eu/en/press/press-releases/2026/10/21/digital-rulebook-council-agrees-position-to-simplify-data-protection-privacy-and-cyber-reporting-rules/&quot; rel=&quot;noopener noreferrer&quot;&gt;Pressemitteilung des Rates vom 21. Oktober 2026 (englisch)&lt;/a&gt;, &lt;a href=&quot;https://netzpolitik.org/2026/eu-laender-einig-beim-daten-omnibus-mehr-ki-training-weniger-datenschutz/&quot; rel=&quot;noopener noreferrer&quot;&gt;netzpolitik.org vom 22. Oktober 2026&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/ratgeber/cookie-banner-ablehnen-button.html&quot;&gt;Was für Cookie-Banner heute gilt →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>Chrome 154: Vor dem Aufruf von http-Seiten fragt Chrome jetzt standardmäßig nach</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#chrome-154"/>
    <id>https://apexly.de/aktuelles.html#chrome-154</id>
    <published>2026-10-26T08:00:00Z</published>
    <updated>2026-10-26T08:00:00Z</updated>
    <summary type="text">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.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Quelle: &lt;a href=&quot;https://developer.chrome.com/release-notes/154&quot; rel=&quot;noopener noreferrer&quot;&gt;Chrome 154 Release Notes&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/#checks&quot;&gt;Diese und weitere Prüfungen laufen im kostenlosen Scan mit →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>Ab 27. September 2026: neue Regeln für Umweltwerbung und den Gewährleistungshinweis beim Warenverkauf</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#umweltwerbung-gewaehrleistung"/>
    <id>https://apexly.de/aktuelles.html#umweltwerbung-gewaehrleistung</id>
    <published>2026-09-19T08:01:00Z</published>
    <updated>2026-09-19T08:01:00Z</updated>
    <summary type="text">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).</summary>
    <content type="html">&lt;p&gt;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). &lt;strong&gt;Erstens&lt;/strong&gt; 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. &lt;strong&gt;Zweitens&lt;/strong&gt; 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.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/ratgeber/&quot;&gt;Mehr rechtliche Einordnungen im Ratgeber →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>WordPress-Lücke „wp2shell“: Update auf 6.8.6, 6.9.5 oder 7.0.2 prüfen</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#wp2shell"/>
    <id>https://apexly.de/aktuelles.html#wp2shell</id>
    <published>2026-09-19T08:00:00Z</published>
    <updated>2026-09-19T08:00:00Z</updated>
    <summary type="text">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.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/#checks&quot;&gt;Diese und weitere Prüfungen laufen im kostenlosen Scan mit →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>Mehrere kritische WordPress-Plugin-Lücken werden gerade aktiv ausgenutzt</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#plugin-luecken-september"/>
    <id>https://apexly.de/aktuelles.html#plugin-luecken-september</id>
    <published>2026-09-15T08:01:00Z</published>
    <updated>2026-09-15T08:01:00Z</updated>
    <summary type="text">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 …</summary>
    <content type="html">&lt;p&gt;In derselben Woche wurden gleich drei kritische Lücken in weitverbreiteten WordPress-Plugins bekannt, die unangemeldeten Angreifern das Hochladen von Schadcode erlauben: &lt;strong&gt;Elementor Pro&lt;/strong&gt; (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), &lt;strong&gt;Forminator Forms&lt;/strong&gt; (CVE-2026-15748, betrifft über 300.000 Websites) und &lt;strong&gt;Everest Forms&lt;/strong&gt; (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.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/#checks&quot;&gt;Diese und weitere Prüfungen laufen im kostenlosen Scan mit →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>CRA-Meldepflicht ist jetzt in Kraft — ENISA-Plattform live</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#cra-meldepflicht-in-kraft"/>
    <id>https://apexly.de/aktuelles.html#cra-meldepflicht-in-kraft</id>
    <published>2026-09-15T08:00:00Z</published>
    <updated>2026-09-15T08:00:00Z</updated>
    <summary type="text">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.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/ratgeber/&quot;&gt;Mehr rechtliche Einordnungen im Ratgeber →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>Chrome warnt ab Herbst 2026 automatisch vor HTTP-Websites</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#chrome-http-warnung-ankuendigung"/>
    <id>https://apexly.de/aktuelles.html#chrome-http-warnung-ankuendigung</id>
    <published>2026-08-30T08:02:00Z</published>
    <updated>2026-08-30T08:02:00Z</updated>
    <summary type="text">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.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/#checks&quot;&gt;Diese und weitere Prüfungen laufen im kostenlosen Scan mit →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>CRA: Meldepflicht für Software-Hersteller ab 11. September 2026</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#cra-meldepflicht-ankuendigung"/>
    <id>https://apexly.de/aktuelles.html#cra-meldepflicht-ankuendigung</id>
    <published>2026-08-30T08:01:00Z</published>
    <updated>2026-08-30T08:01:00Z</updated>
    <summary type="text">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.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/ratgeber/&quot;&gt;Mehr rechtliche Einordnungen im Ratgeber →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>Nur jede vierte Website hat eine wirksame Content-Security-Policy</title>
    <link rel="alternate" type="text/html" href="https://apexly.de/aktuelles.html#csp-nur-jede-vierte"/>
    <id>https://apexly.de/aktuelles.html#csp-nur-jede-vierte</id>
    <published>2026-08-30T08:00:00Z</published>
    <updated>2026-08-30T08:00:00Z</updated>
    <summary type="text">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.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://apexly.de/ratgeber/security-header.html&quot;&gt;Wie die wichtigsten Sicherheits-Header funktionieren →&lt;/a&gt;&lt;/p&gt;</content>
  </entry>
</feed>
