PHP: Auch WordPress braucht eine gepatchte Laufzeit
Seit dem 21. Oktober 2026 stehen Korrekturen für CVE-2026-109618 und CVE-2026-109619 bereit. Beide PHP-Lücken können Codeausführung ohne Anmeldung mit den Rechten des Web-Workers ermöglichen. Betroffen sind PHP-Installationen, die Webanfragen verarbeiten, darunter PHP-FPM und Apache mit mod_php. Ein aktuelles WordPress, Drupal oder Joomla ersetzt das PHP-Update nicht.
Die korrigierten Versionen sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Bei Distributions- oder Hostingpaketen den bestätigten Backport prüfen. PHP 8.1 und älter erhalten keine regulären Sicherheitsreleases mehr vom PHP-Projekt; hier sind ein nachgewiesener Anbieterfix oder der Wechsel auf eine unterstützte Version nötig.
Alle betroffenen Worker nach dem Update neu starten und die tatsächlich vom Webserver verwendete PHP-Version prüfen. Bei Managed Hosting den Patchnachweis vom Anbieter einholen. Konfigurationsänderungen bieten keinen vollständigen Schutz. Öffentlich erreichbare PHP-Dienste, die nicht rechtzeitig abgesichert werden können, vorübergehend aus dem Netz nehmen.
GitLab: Self-Managed-Instanzen sofort aktualisieren
CVE-2026-110264 betrifft GitLab CE und EE ab Version 7.0 bis zum jeweiligen Fix. Ein Integer Overflow im Compiler für reguläre Ausdrücke kann unter bestimmten Bedingungen Codeausführung ohne Anmeldung ermöglichen. GitLab bewertet die Lücke mit CVSS 3.1: 10,0.
Behoben ist sie in 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 und 19.5.1. Selbst betriebene Instanzen auf einen korrigierten Stand bringen und dabei den vorgesehenen Upgradepfad beachten. GitLab.com ist bereits gepatcht. Zusätzlich die Serverprotokolle auf auffällige Worker-Abstürze und gehäufte Fehler beim Org-mode-Rendering prüfen; ein installiertes Update schließt einen vorherigen Einbruch nicht aus.
LiteLLM: Version 1.107.0 als Sicherheitsvorfall behandeln
Am 21. Oktober wurden manipulierte Wheels von LiteLLM 1.107.0 über PyPI und betroffene Containerimages über Docker Hub sowie GHCR verteilt. Auch veränderliche Tags wie latest, main-latest und main-stable zeigten zeitweise auf betroffene Images. Entscheidend sind das tatsächlich installierte Artefakt und der verwendete Image-Digest.
Der Schadcode stiehlt Zugangsdaten und enthält einen Backdoor-Loader. Er kann bereits beim Python-Start ausgeführt werden, ohne dass die Anwendung LiteLLM importiert. Deshalb auf betroffenen Systemen nicht zuerst Python oder pip zur Diagnose oder zum Update starten.
Betroffene Umgebungen isolieren und Beweise sichern. Wenn Python mit dem manipulierten Paket lief oder ein betroffenes Image ausgeführt wurde, die Umgebung als kompromittiert behandeln und aus vertrauenswürdigen Artefakten neu aufbauen. Erreichbare Cloud-, CI/CD-, Datenbank- und Modellanbieter-Zugangsdaten von einem sauberen System aus sperren beziehungsweise rotieren. Ein Paket-Downgrade allein beseitigt weder gestohlene Secrets noch mögliche Persistenz.