Admins, die mit Gogs Git-Service-Server selbst hosten, sollten die Software umgehend über einen Workaround vor Attacken schützen. Ein Sicherheitsupdate ist bislang nicht verfügbar. Angreifer nutzen die Schadcode-Sicherheitslücke schon seit Juli vergangenen Jahres aus.

Auch hierzulande gibt es verwundbare Server. Nun hat sich die US-Sicherheitsbehörde CISA eingeschaltet und bestätigt die Attacken.

Hintergründe

Wie aus einem Beitrag von Wiz-Sicherheitsforschern aus dem Dezember vergangenen Jahres hervorgeht, haben sie bereits im Juli 2025 erste Attacken beobachtet. Im November gab es ihnen zufolge dann eine zweite Angriffswelle. Im Dezember sprachen sie von weltweit mehr als 1400 öffentlich über das Internet erreichbare Instanzen. Davon sollen mehr als 700 bereits über die Lücke (CVE-2025-8110 „hoch“) attackiert worden sein.

In welchem Umfang die Attacken ablaufen und wann ein Sicherheitsupdate kommt, ist bislang unklar. In ihrem Beitrag führen die Forscher aus, an welchen Parametern Admins bereits attackierte Instanzen erkennen können. Darunter fallen etwa IP-Adressen der Payload-Server.

Attacken sind aber nur für authentifizierte Angreifer möglich. Das ist allerdings keine allzu große Hürde: Standardmäßig ist die Registrierung auf Gogs-Servern nämlich aktiv. Ist das gegeben und die Instanz öffentlich über das Internet erreichbar, sind Attacken möglich.

Im Anschluss umgehen Angreifer den Schutz einer eigentlich geschlossenen Lücke (CVE-2024-55947) und überschreiben mittels eines Symlink-Angriffs Dateien, um anschließend Schadcode auszuführen. Wie das im Detail abläuft, führen die Sicherheitsforscher in ihrem Beitrag aus.

Server schützen

Bislang ist unklar, wann ein Sicherheitspatch erscheint. Um Attacken einzudämmen, müssen Admins die Registrierung abschalten und den Zugriff auf Gogs-Server per VPN auf vertrauenswürdige IP-Adressen einschränken.

(des)

Am Samstagabend des vergangenen Wochenendes kam es in Halle (Saale) offenbar zu einem Auslösen der Sirenen. Dabei handelte es sich um einen Fehlalarm. Der geht mutmaßlich auf einen „externen Angriff“ zurück.

Darüber hat die Stadt Halle in einer Mitteilung auf ihrer Webseite informiert. „Nach dem Sirenen-Fehlalarm vom Samstagabend gibt es nun erste Erkenntnisse zur Ursache“, erklären die Autoren der Nachricht. Man müsse demnach „mit einer hohen Wahrscheinlichkeit von einem externen Angriff auf das System“ ausgehen. Die Sirenen wurden weder von der Stadt Halle, noch durch das Land Sachsen-Anhalt oder den Bund ausgelöst.

„Die Stadt Halle (Saale) hat die notwendigen Maßnahmen zur Sicherung des Sirenen-Systems ergriffen und Anzeige bei der Polizei erstattet“, führt sie weiter aus. Sie habe zudem die nötigen Maßnahmen zur Sicherung des Sirenen-Systems ergriffen und polizeilich Anzeige erstattet. „Alle Sirenen im Stadtgebiet sind vor äußeren Zugriffen geschützt und alarmfähig“, versichern die Autoren.

Stadt-Webseite von Halle (Saale) ebenfalls gestört

Die Webseite www.halle.de der Stadt war am Samstagabend offenbar auch zeitweise nicht erreichbar. Die Zugriffszahlen, ausgelöst durch den Sirenen-Fehlalarm, waren ungewohnt hoch und führten zu einer Überlastung der Server. Einen Überlastungsangriff (DDoS, Distributed Denial of Service) kann die Stadt Halle mit „hoher Wahrscheinlichkeit“ ausschließen. Auch hier hat die Stadt nachgesteuert, „um die Funktionsfähigkeit der Webseite auch bei hohen Zugriffszahlen zu gewährleisten.“

Genauere Details nennt die Stadt Halle nicht. Im Jahr 2018 wurden jedoch etwa Sicherheitslücken in den Notfallalarmsystemen des Herstellers ATI Systems bekannt, die Angreifern das Auslösen von Fehlalarmen erlaubten. Welches System Halle (Saale) einsetzt, ist nicht bekannt, aber derart alte Schwachstellen sollten hoffentlich behoben sein. In Dallas kam es 2017 zu einem ähnlichen Vorfall, bei dem Cyberkriminelle die Alarmsirenen mitten in der Nacht ausgelöst hatten.

(dmk)

Am Januar-Patchday 2026 hat SAP 17 neue Sicherheitsnotizen herausgegeben. Sie behandeln vier als kritisches Risiko und vier als hochriskant eingestufte Sicherheitslücken in der Business-Software.

Die Patchday-Übersicht von SAP listet die einzelnen Meldungen auf. Am schwersten wiegt demnach eine SQL-Injection-Schwachstelle in SAP S/4HANA Private Cloud and On-Premise (Financials – General Ledger) (CVE-2026-0501, CVSS 9.9, Risiko „kritisch“). In SAP Wily Introscope Enterprise Manager (WorkStation) können Angreifer aus dem Netz hingegen Schadcode einschleusen (CVE-2026-0500, CVSS 9.6, Risiko „kritisch“). Außerdem können bösartige Akteure in SAP S/4HANA (Private Cloud and On-Premise) eigenen Code injizieren (CVE-2026-0498, CVSS 9.1, Risiko „kritisch“). Eine gleichlautende Schwachstelle betrifft SAP Landscape Transformation (CVE-2026-0491, CVSS 9.1, Risiko „kritisch“).

Hochriskante SAP-Schwachstellen

In der Datenbank von SAP HANA können Angreifer außerdem eine Rechteausweitungslücke missbrauchen (CVE-2026-0492, CVSS 8.8, Risiko „hoch“). In SAP Application Server for ABAP and SAP NetWeaver RFCSDK können sie Befehle ans Betriebssystem einschleusen (CVE-2026-0507, CVSS 8.4, Risiko „hoch“). In der SAP Fiori App (Intercompany Balance Reconciliation) finden sich drei Sicherheitslücken, von denen mindestens eine mit CVSS-Wert 8.1 als Risiko „hoch“ gilt (CVE-2026-0511, CVE-2026-0496, CVE-2026-0495). Schließlich meldet SAP noch eine fehlende Autorisierungsprüfung in SAP NetWeaver Application Server ABAP and ABAP Platform (CVE-2026-0506, CVSS 8.1, Risiko „hoch“).

Sieben weitere Schwachstellen haben von SAPs Entwicklern die Einordnung als mittleres Risiko erhalten. Zwei Sicherheitslücken betrachten sie zudem als niedrigen Bedrohungsgrad.

IT-Verantwortliche sollten die bereitstehenden Aktualisierungen zeitnah anwenden, um die Angriffsfläche ihrer IT-Landschaft zu reduzieren. Zum vergangenen Patchday im Dezember 2025 hatte SAP 14 Sicherheitsnotizen veröffentlicht. Davon wurden drei als kritisches Sicherheitsrisiko klassifiziert.

(dmk)