Anmelden
(Bild: janews/Shutterstock.com)
Die kriminelle Gruppe ShinyHunters greift die kritische Sicherheitslücke in Oracle PeopleSoft an, die zum Wochenende bekannt wurde.
Am Donnerstag vergangener Woche wurde eine kritische Codeschmuggel-Lücke in Oracle PeopleSoft bekannt. Die kriminelle Online-Bande ShinyHunters greift die Schwachstelle offenbar bereits an, warnen IT-Forscher. Auch die US-amerikanische IT-Sicherheitsbehörde CISA hat die Lücke in den „Known-Exploited-Vulnerabilities“ [1]-Katalog aufgenommen.
Oracle hatte außer der Reihe [2] der üblichen vierteljährlichen „Critical Patch Updates“ (CPU) sowie der neuen, in den Monaten dazwischen eingeschobenen „Critical Security Patch Updates“ (CSPU) vor der Sicherheitslücke gewarnt. Sie betrifft demnach Oracle PeopleSoft PeopleTools und möglicherweise Oracle PeopleSoft Enterprise Applications. Details sind unklar, jedoch können Angreifer aus dem Netz ohne vorherige Anmeldung mit HTTP-Paketen Schadcode einschleusen und ausführen (CVE-2026-35273, CVSS 9.8, Risiko „kritisch“). Betroffen sind die Versionen PeopleSoft Enterprise PeopleTools 8.61 und 8.62, Updates verlinkt Oracle in der Sicherheitsmitteilung [3], sie sind nach Anmeldung zugänglich.
IT-Forscher von Googles Tochterunternehmen Mandiant haben eine Analyse [4] zu den beobachteten Angriffen veröffentlicht. Demnach missbraucht die Cybergang ShinyHunters, auch als UNC6240 geführt, die Schwachstelle in Oracle PeopleSoft, um Systeme zu kompromittieren und die Betreiber um Lösegeld zu erpressen. Sie ziele auf Environment-Management-Hub-Endpoints (PSEMHUB). Die Angriffe laufen bereits seit dem 27. Mai 2026, ergänzen die IT-Forscher, es handelt sich also um den Missbrauch einer Zero-Day-Lücke.
Die Mandiant-Analysten haben eigenen Angaben zufolge weltweit mehr als 100 Organisationen kontaktiert, deren IP-Adressen mit verwundbaren Endpunkten korrelieren; ein Großteil liegt in den USA, etwas mehr als zwei Drittel davon im höheren Bildungswesen. Die IT-Forscher erörtern die Funde nach den Angriffen im Detail. Sie leiten daraus auch Gegenmaßnahmen ab, etwa die Zugriffsbeschränkung auf die Endpunkte „/PSEMHUB/*“, insbesondere „PSEMHUB/hub“ und „/PSIGW/HttpListeningConnector“ auf interne IP-Adressen – sofern das Deaktivieren des EMHub-Dienstes nicht in Frage kommt. Beschränkungen mit Web-Application-Firewalls seien unzureichend, da die sich überwinden ließen, erklären die IT-Forscher weiter. Admins sollen zudem Protokolldateien und Endpunkte überwachen und auf ausgehenden Traffic auf Port 445 achten. IT-Admins finden in der Analyse noch weiterreichende Hinweise auf erfolgreiche Angriffe (Indicators of Compromise, IOC), anhand derer sie ihre Systeme überprüfen können.
URL dieses Artikels:
https://www.heise.de/-11331861
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: GagoDesign/Shutterstock.com)
Hackerangriff auf staatliche Banken im Iran: Online-Zahlungen sind landesweit gestört – ein weiterer Schlag gegen Irans ohnehin fragile Infrastruktur.
Nach einem Cyberangriff auf mehrere staatliche Banken im Iran sind elektronische Dienstleistungen massiv gestört worden. Online-Zahlungen fielen zeitweise vollständig aus. Der Banken-Koordinationsrat des Landes bestätigte laut Wirtschaftsportal Eghtesad-News die Vorfälle. Das Problem sei inzwischen aber behoben und der Onlineverkehr wieder normalisiert.
In Teheran berichteten zahlreiche Augenzeugen, dass in Supermärkten, Restaurants und auch an Tankstellen plötzlich keine Online-Zahlungen mehr möglich waren. Viele Beträge wurden daraufhin notiert, um sie später zu begleichen. Betroffen waren insbesondere vier große staatliche Banken sowie zahlreiche Geldautomaten in der Hauptstadt.
Eine iranische Cybercrimegruppe hatte bereits am Samstag einen Angriff angekündigt. „Ein stiller Krieg entfaltet sich und Iran steht unter Cyberangriff“, erklärte die Gruppe Black Wolves auf ihrem Telegram-Kanal. Bereits 2022 war es während der Frauenproteste zu einem massiven Angriff auf die iranische Zentralbank gekommen.
Auch die Überwachungskameras des berüchtigten Evin-Gefängnisses in Teheran wurden damals gehackt und Aufnahmen veröffentlicht, die gewalttätige Übergriffe von Wachpersonal auf politische Gefangene zeigten. Die Cyberangriffe gelten als Form des digitalen Protests gegen das islamische System im Iran.
Erst seit zweieinhalb Wochen sind Online-Zahlungen im Iran überhaupt wieder möglich. Zuvor haben die Menschen hier 88 Tage lang unter der längsten landesweiten Internetsperre gelebt, die es in der Weltgeschichte jemals gegeben hat [1]. Nach dem Beginn der israelischen und US-amerikanischen Luftangriffe auf den Iran hatte das Regime die eigene Bevölkerung weitestgehend vom Internet abgeschnitten [2]. Der Online-Handel stand nahezu vollkommen still, hunderttausende Unternehmen waren nach dpa-Informationen betroffen. Auch die IT-Branche litt unter der Situation. Laut Netblocks lag die landesweite Internetkonnektivität bei rund einem Prozent des normalen Niveaus.
Ein ganz freies Internet wie hierzulande gibt es im Iran auch heute nicht. Staatliche Filter verhindern den Zugriff auf bestimmte Seiten, etwa Social Media. Mit einem VPN-Dienst lässt sich das zwar umgehen, nach iranischen Gesetzen ist das aber illegal.
URL dieses Artikels:
https://www.heise.de/-11331525
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: momente/Shutterstock.com)
EU-Sicherheitsvorschriften für 5G-Mobilfunk sollen Spionage vorbeugen. Für Heimnetzwerke gibt es keine entsprechenden Regeln, kritisieren nun Hersteller.
Vier deutsche und ein litauischer Routerhersteller fordern scharfe Kontrolle importierter Internet-Netzwerkgeräte in Europa. Vorbild sollen die gegen chinesische Erzeugnisse gerichteten Sicherheitsvorschriften der EU für den 5G-Mobilfunk sein. „Router und Netzwerkgeräte müssen von der Politik ebenso stringent geschützt werden wie 5G-Netze“, heißt es in der Mitteilung des neu gegründeten Safenet-Verbands. Beteiligt sind die deutschen Unternehmen Fritz, Devolo, Lancom und TDT sowie Teltonika aus Litauen.
Wie das 5G-Instrumentarium der EU zielen die Forderungen auf chinesische Produkte, auch wenn diese in der Mitteilung nicht ausdrücklich genannt sind. Da Telekommunikationsgeräte von außen über das Netzwerk aktualisiert und gewartet werden können, gibt es Sorgen, dass staatliche chinesische Stellen dieses Einfallstor für Spionage und gegebenenfalls sogar Sabotage nutzen könnten, um Netzwerke im Konfliktfall stillzulegen.
Die Ampel-Koalition hatte den 5G-Mobilfunkanbietern vorgeschrieben, ab 2026 keine Komponenten der beiden chinesischen Hersteller Huawei und ZTE im Kernnetzwerk [1] mehr einzubauen.
Nach einer von den Firmen zitierten Studie laufen aber nur sieben Prozent des europäischen Internetverkehrs über den Mobilfunk, 93 Prozent hingegen über Router und Heimnetz-Gateways. Der Marktanteil chinesischer Hersteller in diesem Bereich beläuft sich demnach auf knapp 40 Prozent. Die fünf heimischen Unternehmen werfen der Politik vor, dass die EU-Märkte in diesem Bereich offen für außereuropäische Produkte seien, die strategische Abhängigkeiten erzeugten und Sicherheitsrisiken darstellten.
So haben die fünf Unternehmen drei Forderungen: Hersteller und Internetanbieter sollen ausweisen, wo Geräte und Firmware hergestellt und entwickelt werden. Behörden, Betreiber kritischer Infrastruktur und öffentlich finanzierte Einrichtungen sollen europäische Netzwerktechnologie nutzen. Und die EU soll neben dem 5G-Instrumentarium vergleichbare Sicherheitsvorschriften für Router und Netzwerktechnologie erlassen.
URL dieses Artikels:
https://www.heise.de/-11331799
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Arch Linux wehrt sich gegen eine Angriffswelle, die massenweise Paketbeschreibungen im inoffiziellen Arch User Repository mit Malware verseucht hat.
Das Arch User Repository (AUR) sieht sich einer umfangreichen Angriffswelle ausgesetzt. Die Angreifer haben Hunderte verwaiste Paketdefinitionen übernommen, um Malware ergänzt und in neuen Versionen veröffentlicht. Die Arch-Maintainer steuern mit einem Meldeaufruf [1] und einer groß angelegten Lösch-Aktion gegen, um bösartige Updates zu entfernen und von den Angreifern genutzte Accounts zu sperren.
Das AUR von Arch Linux [2] enthält keine Pakete im engeren Sinne, sondern Beschreibungen, sogenannte PKGBUILDs, mit denen Nutzer die Pakete selbst bauen können. Wenn eine Beschreibung offenbar nicht mehr gewartet wird, können Nutzer dies melden und sie wird nach einer Weile als verwaist markiert. Dann können beliebige Nutzer die Paketbeschreibung „adoptieren“ und ihre Wartung übernehmen.
Diesen Mechanismus nutzten die Angreifer aus: Sie übernahmen solche verwaisten Beschreibungen, ergänzten sie um eine Abhängigkeit für den JavaScript-Paketmanager npm und fügten einen Schritt nach der eigentlichen Software-Installation hinzu, der das npm-Paket „atomic-lockfile“ auf das System brachte. Atomic-Lockfile enthielt wiederum einen Prä-Installationsschritt [3], den npm befolgte und dabei die im npm-Paket mitgelieferte Datei „deps“ [4] ausführte. Bei deps handelt es sich einer ersten (KI-gestützten) Analyse [5] zufolge um einen Credential-Stealer, eine Malware, die diverse Arten von Zugangsdaten ausliest und an den Angreifer ausleitet. „deps“ kann sich außerdem im System festsetzen, bei ausreichenden Rechten die eigene Präsenz verschleiern und weitere Software nachladen.
Die Angreifer begeben sich offenbar in ein Katz-und-Maus-Spiel mit den Arch-Maintainern: Inzwischen läuft eine Variante des Angriffs, die statt npm den alternativen JavaScript-Paketmanager Bun einsetzt und damit das malware-verseuchte – aktuell bereits depublizierte – Paket js-digest [6] installiert.
Die Angriffswelle ist ein guter Anlass, darauf hinzuweisen, dass das Arch User Repository keine offizielle Softwarequelle für Arch Linux ist. PKGBUILDs werden vom Arch-Team nicht geprüft. AUR-Nutzer handeln auf eigenes Risiko, wenn sie Software aus dem AUR installieren, und sollten jedes Update selbst prüfen.
Allerdings wird Software aus dem AUR oft mit darauf spezialisierten Programmen installiert, sogenannten AUR-Helpern. Diese Hilfsprogramme automatisieren die mitunter komplizierten Bauschritte (AUR-Software wird oft beim Nutzer aus dem Quellcode kompiliert), sodass Nutzer weder Zeit noch spezielle Kenntnisse zur Installation benötigen. Das ist praktisch, verleitet aber dazu, Updates unbesehen durchzuwinken, weil der AUR-Helper ohnehin alle nötige Arbeit übernimmt oder man die vom Update vorgenommenen Änderungen schlicht nicht versteht.
In der aktuellen Angriffswelle kam hinzu, dass die Änderungen in den PKGBUILDs selbst nur die Inklusion eines JavaScript-Paketmanagers und die Installation einiger JavaScript-Pakete auswiesen. Je nach betroffener Software muss so eine Abhängigkeit nicht verdächtig erscheinen. Nutzer benötigen zumindest rudimentäre Kenntnisse der Softwareentwicklung, um den Paketmanager als deplatziert zu erkennen oder den JavaScript-Paketen nachzuspüren und dort die eigentliche Malware zu entdecken.
Arch-Nutzer, die sich dergleichen nicht zutrauen, sollten idealerweise keine Software aus dem AUR installieren. Grundsätzlich sollten AUR-Nutzer die zugehörige Mailingliste abonnieren [7], um Malware-Warnungen mitzubekommen, worauf auch das Arch-Wiki hinweist [8].
URL dieses Artikels:
https://www.heise.de/-11330029
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: jackpress/Shutterstock.com)
Nach Kritik an heimlich manipulierten Antworten rudert Anthropic zurück: Die Schranken von Fable 5 werden sichtbar – auf Kosten von mehr Fehlalarmen.
Anthropic reagiert auf die Kritik an den Schutzmechanismen seines neuen KI-Modells Fable 5 [1]. Das Unternehmen will umstrittene, verborgene Sicherheitsmaßnahmen künftig sichtbar machen und entschuldigt sich ausdrücklich für deren bisherige Umsetzung. Konkret geht es um Schutzmechanismen gegen sogenanntes Distillation – also den Versuch, die Ausgaben eines leistungsfähigen Sprachmodells zum Training konkurrierender KI-Systeme zu nutzen.
Die Kontroverse entzündete sich an einem Schutzverhalten von Fable 5, bei dem das Modell verdeckt auf Distillation-Anfragen reagierte. Anthropic sah ursprünglich einen unsichtbaren Mechanismus vor, der solche Versuche zur Modellentwicklung im Hintergrund erkennt und die Antworten gezielt verändert oder verschlechtert. Die Nutzer sollten davon nichts mitbekommen. Forscher und Entwickler kritisierten das als intransparent und warnten, dass solche verdeckten Eingriffe auch Tests und wissenschaftliche Untersuchungen des Modells verfälschen.
In einem Beitrag auf X [2] kündigt Anthropic nun eine Kurskorrektur an. Künftig behandelt das Unternehmen erkannte Distillation-Anfragen sichtbar. Statt Antworten heimlich zu verändern, fällt Fable 5 in solchen Fällen auf das ältere Modell Claude Opus 4.8 [3] zurück – genau wie es bereits bei den Schutzmaßnahmen für Cybersecurity und Biologie der Fall ist. Die Nutzer sollen dabei jedes Mal einen entsprechenden Hinweis sehen.
Für API-Kunden will Anthropic zudem den Grund einer Ablehnung explizit zurückgeben. Ein serverseitiger Fallback für API-Anfragen soll in den kommenden Tagen folgen. Damit lässt sich künftig erkennen, ob eine Antwort von Fable 5 oder vom Fallback-Modell stammt.
Das Unternehmen gibt zu, mit dem ursprünglichen Ansatz falsch gelegen zu haben. Sichtbare Schutzmechanismen lassen sich zwar leichter analysieren und gezielt umgehen, weshalb ihre Absicherung mehr Zeit kostet. Unsichtbare Schutzmaßnahmen lassen sich dagegen enger auf bestimmte Szenarien zuschneiden und verursachen weniger Fehlalarme. Aus diesem Grund habe man sich zunächst für den verdeckten Ansatz entschieden, um Fable 5 schnell und sicher bereitzustellen.
Rückblickend sei das die falsche Entscheidung gewesen, schreibt Anthropic. Die Nutzer sollten nachvollziehen können, welche Schutzmaßnahmen aktiv sind und warum. Dafür entschuldigt sich das Unternehmen ausdrücklich.
Die Umstellung hat allerdings Nebenwirkungen. Um die Systeme trotzdem vor Jailbreaks abzusichern, müssen die zugrunde liegenden Klassifikatoren zunächst konservativer arbeiten. Das führt vorübergehend zu mehr Fehlklassifikationen.
Solche False Positives entstehen, wenn das Modell harmlose Anfragen fälschlich als riskant einstuft. Genau hier setzt ein Großteil der bisherigen Kritik an.
Die Ankündigung folgt nur wenige Tage auf heftige Kritik von Sicherheitsforschern [4] an Fable 5. Mehrere Experten beklagen, dass die Cybersecurity-Schranken des Modells nicht nur brisante Anfragen erfassen, sondern auch alltägliche Aufgaben aus Softwareentwicklung und IT-Sicherheit. Genannt wurden unter anderem Code Reviews, das Schreiben sicheren Codes, Schwachstellenanalysen, Incident Response oder schlicht das Lesen sicherheitsrelevanter Fachartikel.
Fable 5 ist die öffentlich verfügbare Variante von Anthropics neuem Spitzenmodell Mythos 5. Letzteres bringt keine vorgeschalteten Schutzmechanismen für Cybersecurity, Biologie, Chemie und Distillation mit.
In seiner Stellungnahme verspricht Anthropic auch Änderungen an den Cyber- und Bio-Safeguards. Die entsprechenden Klassifikatoren stelle man derzeit so ein, dass sie seltener bei harmlosen Anfragen anschlagen. Nutzer, die eine Fehlklassifikation vermuten, sollen diese melden – über Feedback-Funktionen in Claude Code und Claude.ai sowie über ein Einspruchsformular für API-Anfragen.
Ob die Anpassungen ausreichen, bleibt abzuwarten. An den Schutzmaßnahmen selbst hält Anthropic ausdrücklich fest – diese hatten die Kritiker allerdings auch nicht infrage gestellt.
URL dieses Artikels:
https://www.heise.de/-11330094
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Shutterstock / Skorzewiak)
Ubiquiti warnt vor teils kritischen Sicherheitslücken in UniFi OS. Aktualisierte Software steht bereit, um sie zu schließen.
In Ubiquitis UniFi OS und im UID Enterprise Agent klaffen fünf Sicherheitslücken, die Angreifern etwa das Einschmuggeln von Code, das Umgehen von Sicherheitsmaßnahmen oder unbefugten Zugriff auf Informationen ermöglichen. Der Hersteller hat aktualisierte Software veröffentlicht, die die Schwachstellen behebt.
In einer Sicherheitsmitteilung listet Ubiquiti [1] die einzelnen Lücken auf. Drei Sicherheitslücken gelten demnach als kritisch. Angreifer mit Zugang zum Netzwerk und niedrigen Berechtigungen können eine unzureichende Eingabeprüfung in UID Enterprise Agent missbrauchen, um Befehle auf anfälligen Hosts auszuführen (CVE-2026-47367, CVSS 9.9, Risiko „kritisch“). Dieselbe Beschreibung und Auswirkung betrifft UniFi OS auf UniFi-OS-Geräten und -Instanzen (CVE-2026-47370, CVSS 9.9, Risiko „kritisch“). Noch unkonkreter ist eine Schwachstelle vom gleichen Typ in UniFi-OS-Geräten und Instanzen, die Angreifer zur Rechteausweitung nutzen können (CVE-2026-47369, CVSS 9.9, Risiko „kritisch“).
Eine Path-Traversal-Schwachstelle können bösartige Akteure mit Netzwerkzugang ausnutzen, um sich auf diversen UniFi-OS-Geräten und -Instanzen unbefugt Zugang zu Daten zu verschaffen (CVE-2026-47368, CVSS 8.6, Risiko „hoch“). Zudem können Angreifer mit Zugriff auf das Netzwerk in bestimmten, nicht genannten Konfigurationen eine unzureichende Rechteprüfung missbrauchen, um unbefugt Änderungen an anfälligen UniFi-OS-Geräten vorzunehmen (CVE-2026-48610, CVSS 8.1, Risiko „hoch“).
Die Sicherheitslücken behebt Ubiquiti im UID Enterprise Agent 1.61.4 aus. Außerdem korrigieren UniFi OS Server, UDM, UDM-Beast, UDM-Pro, UDM-SE, UDM-Pro-Max, EFG, UDW, UDR, UDR7, UDR-5G, Express 7, UCK, UCKP, UCK-Enterprise, UNVR, UNVR-Pro, UNVR-Instant, ENVR, ENVR-Core, UNVR-G2, UNVR-G2-Pro, UCG-Ultra, UCG-Max, UCG-Industrial und UCG-Fiber 5.1.15 sowie UNAS-2, UNAS-4, UNAS-Pro, UNAS-Pro-4 und UNAS-Pro-8 5.1.16 sowie Express 4.0.15 die sicherheitsrelevanten Fehler.
Erst vor rund zwei Wochen hatte Ubiquiti Sicherheitslücken in UniFi OS [2]zu schließen. Dort kamen drei sogar auf die höchstmögliche Risikoeinstufung CVSS 10.0, mithin „kritisch“.
URL dieses Artikels:
https://www.heise.de/-11329967
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Diebstahl eines Smartphones.
(Bild: Donenko Oleksii / Shutterstock)
Zunehmend werden Handys direkt bei der Benutzung entwendet, damit sie noch im ungesperrten Zustand sind. In London gibt es dagegen nun ein Projekt mit Apple.
Die Londoner Stadtpolizei (Metropolitan Police, kurz Met) versucht, den wachsenden Handy-Diebstahl in der britischen Hauptstadt mit technischen Maßnahmen einzudämmen. Dazu arbeitet sie nun mit Apple zusammen, berichtet der örtliche Sender BBC. Laut Angaben von Polizeichef Mark Rowley teilt man unter anderem Daten mit dem iPhone-Hersteller, um ein „globales Bild“ der Situation zu erhalten. Es ginge darum, zu verhindern, dass gestohlene Geräte gelöscht und dann reaktiviert werden. „Dann bricht deren Wert zusammen und der Anreiz, sie zu stehlen, geht zurück.“
London leidet – wie viele andere Städte auch – seit Jahren unter einer Smartphone-Klau-Epidemie. Zuletzt werden die Diebe immer dreister: Sie versuchen, die Geräte direkt während ihrer Benutzung zu entwenden, damit sie noch entsperrt sind. Dabei werden die Geräte etwa mittels E-Bike oder Elektroroller von Personen entwendet, die an der Straße stehen. Alternativ kommt immer auch noch das Ausspionieren von PIN-Codes [1] vor dem Klau vor, so der BBC-Bericht [2]. Noch im vergangenen Jahr hatte die Met Apple dafür kritisiert [3], nicht mit den Gesetzeshütern beim Aufbau einer Datenbank gestohlener Geräte zusammenzuarbeiten – das ist nun offenbar vom Tisch.
Der Konzern scheint jedenfalls sensibilisiert zu sein: Apple hatte bereits mit iOS 17.3 im Jahr 2024 den sogenannten Stolen Device Mode (erweiterter Diebstahlschutz) [4] eingeführt, der allerdings erst seit diesem Jahr standardmäßig [5] auf allen Geräten mit iOS 26.4 oder höher aktiv ist. Dabei wird es Dieben erschwert, bei Kenntnis der PIN den Apple-Account zu übernehmen. Der Apple-Account ist wiederum der Schlüssel zu zahllosen weiteren Daten wie dem auf dem iPhone enthaltenen Passwortmanager, was unter anderem zu Kontoplünderungen führen konnte – oder dem Einsatz von Apple Pay zum Kauf von Produkten.
Die sogenannten Phone Snatcher, also Personen, die entsperrte Smartphones direkt von Benutzern klauen, nutzen laut Met bestimmte Software, die es ihnen ermöglicht, die Geräte zurückzusetzen. Apple will dieses Problem inzwischen gelöst haben, so Rowley. Zuletzt seien die meisten gestohlenen Geräte in London nicht mehr zurückgesetzt worden. Ein weiteres Problem, das bei Android bereits gelöst ist, bleibt die Tatsache, dass sich die iPhones nicht automatisch sperren, wenn die Diebe nur schnell genug sind.
Laut einem Medienbericht plant Apple hier, Diebstähle künftig zu erkennen [6], unter anderem durch die Bewegungssensoren, Bluetooth oder WLAN-Standort. Eine abrupte Entwendung würde dann dazu führen, dass sich ein Gerät automatisch sperrt. Bei Google nennt sich das Feature Theft Protection Lock [7]. Die Met will sich weiter mit Apple austauschen, um die Diebstahlfälle in London besser zu verstehen und womöglich weitere technische Maßnahmen zu empfehlen. Das Problem: Lassen sich Geräte nicht zurücksetzen, werden sie als Ersatzteilquelle verkauft – denn auch diese haben einen hohen Wert.
URL dieses Artikels:
https://www.heise.de/-11329578
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: JLStock/Shutterstock.com)
Ivanti warnt aktuell vor kritischen Sicherheitslücken in Sentry. Die CISA warnt vor Angriffen, Ivanti wiegelt jedoch ab.
Heckmeck um Sicherheitslücken mit Höchstwertung des Risikos in Ivantis Sentry: Die CISA und einige IT-Sicherheitsunternehmen warnen vor laufenden Angriffen. Ivanti wiegelt ab, es handele sich nur um Honeypots.
Während die CISA die fragliche Lücke [1] in den „Known-Exploited-Vulnerabilities“-Katalog (KEV) aufgenommen hat, hat Ivanti mit einer Aktualisierung der eigenen Sicherheitsmitteilung [2] reagiert. Konkret geht es um eine Schwachstelle in Sentry, durch die Angreifer aus dem Netz ohne vorherige Anmeldung Befehle ins Betriebssystem schmuggeln und damit beliebigen Code mit root-Rechten ausführen können (CVE-2026-10520 [3], CVSS 10.0, Risiko „kritisch“). Eine zweite Sicherheitslücke ermöglicht die Umgehung der Authentifizierung – bösartige Akteure aus dem Netz können ohne vorherige Anmeldung beliebige Administratorkonten erstellen und damit vollen Admin-Zugang erlangen (CVE-2026-10523 [4], CVSS 9.9, Risiko „kritisch“).
Betroffen ist die VPN-ähnliche Sicherheits-Gateway-Lösung in den Versionen 10.5.1, 10.6.1, 10.7.0 und älteren. Die bereitstehenden Aktualisierungen auf die Versionen 10.5.2, 10.6.2 und 10.7.1 bessern die Schwachstellen aus.
Die IT-Sicherheitsforscher der watchTowr Labs haben einen Proof-of-Concept-Exploit [5] veröffentlicht, der den Missbrauch der beiden Lücken demonstriert. Auch Rapid7 schließt in einer eigenen Analyse [6], dass sie wüssten, dass Angreifer das Produkt wahrscheinlich angreifen werden, da in der Vergangenheit mehrere Sentry-Lücken im CISA-Katalog der missbrauchten Schwachstellen gelandet sind.
Ivanti hat auf die Angriffsmeldungen reagiert. In der Sicherheitsmitteilung steht noch immer, dass Ivanti von keinen Missbrauchsfällen vor der Veröffentlichung der Meldung wüsste. Es gebe keinen öffentlichen Missbrauch der Schwachstelle, weshalb das Unternehmen auch keine Hinweise auf erfolgreiche Angriffe (Indicators of Compromise, IOC) geben könne. Die CISA habe die Lücke in den KEV aufgenommen, da es Berichte über Angriffsversuche auf Honeypots gebe. Zur Einschätzung sei wichtig zu wissen, dass der Missbrauch der Lücke CVE-2026-10520 Zugriff auf den Managementport 8443 benötige. Und Management-Interfaces sollten ohnehin niemals im Internet zugänglich sein, auch wenn Honeypots derartige Fehlkonfigurationen simulieren, um bösartiges Verhalten zu erkennen.
Die Einschätzung dürfte aber bereits überholt sein. Die Shadowserver Foundation teilt auf X [7] mit, dass ihre Scans 19 verwundbare Instanzen entdeckt habe, von denen mindestens zwei bereits mit Backdoors kompromittiert seien. Die IT-Forscher gehen davon aus, dass die anderen Instanzen inzwischen ebenfalls Angreifern zum Opfer gefallen sind.
Admins sollten sich von der Beschwichtigung nicht abhalten lassen, die verfügbaren Updates schnellstmöglich zu installieren.
Am Donnerstag wurden weitere Sicherheitslücken in Ivantis Endpoint Manager Mobile [8] bekannt. Sie gelten als hohes Risiko, Admins sollten auch hier rasch die Aktualisierungen anwenden.
URL dieses Artikels:
https://www.heise.de/-11329730
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Die neue Begrüßung auf der Seite von „AudiA6“
(Bild: Europol)
Strafverfolgungsbehörden haben in Georgien zwei mutmaßliche Betreiber des Kryptomixers „AudiA6“ festgenommen und mehrere Dienste stillgelegt.
Strafverfolgungsbehörden aus Deutschland, der Schweiz und zahlreichen anderen Staaten haben mit „AudiA6“ einen angeblich besonders häufig genutzten Dienst zur Geldwäsche von Kryptowährungen lahmgelegt. Das hat die europäische Polizeibehörde Europol bekannt gegeben und dabei erklärt, dass über den Dienst zwischen 2022 und 2025 mehr als 336 Millionen Euro geflossen sein sollen, um deren Herkunft zu verschleiern. Das Geld stammte demnach unter anderem aus Erpressungen mit Ransomware. Zwei mutmaßlich Verantwortliche mit ukrainischer und russischer Staatsangehörigkeit seien in Georgien festgenommen worden. Zudem hat die US-Staatsanwaltschaft Anklage erhoben [1] und die Auslieferung der Verdächtigen in die USA beantragt.
Sogenannte Kryptomixer wie „AudiA6“ vermischen Kryptowährungen, um so Verbindungen zwischen Sendern und Empfängern zu verschleiern [2]. Dafür verlangen die Verantwortlichen eine Provision. „AudiA6“ wurde laut Europol [3] in Cybercrime-Foren als professionelle Dienstleistung beworben, die sich durch Anonymität und Geschwindigkeit ausgezeichnet haben soll. Die Ermittlungen gegen den Dienst wurden demnach unter anderem von der polnischen Polizei vorangetrieben. Sie hat im September 2025 einen Ukrainer festgenommen, der damit in Verbindung stand. Eine Durchsuchung seiner Elektronikgeräte habe dann Hinweise auf weitere Personen zutage gefördert. Zudem seien Verbindungen zu 15 Ermittlungsverfahren in aller Welt gefunden worden.
Bei der Operation am Mittwoch wurden demnach jetzt nicht nur die zwei mutmaßlichen Administratoren des Diensts festgenommen. Laut Europol wurden drei Grundstücke durchsucht und mehr als 80 Fahrzeuge konfisziert. Kryptogeld im Wert von fast 700.000 Euro seien eingefroren, noch einmal über 86.000 beschlagnahmt worden. Zudem wurden Telegram-Accounts des Netzwerks blockiert und dessen Seiten im Darknet und im Internet sowie das Cybercrime-Forum „Dark2Web“ gesperrt. Ferner wurden zahlreiche Internet-Domains gesperrt und dutzende Server beschlagnahmt. Eine Reihe davon hat die Behörden jetzt öffentlich gemacht, damit Kryptogeldbörsen in Verbindung stehende Accounts identifizieren und sperren können.
URL dieses Artikels:
https://www.heise.de/-11329646
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Eine Rechteausweitungslücke in FreeBSD hat den Codenamen „Bumsrakete[tm]“ erhalten.
(Bild: heise medien)
Auch in FreeBSD haben IT-Forscher eine Sicherheitslücke gefunden, die die Rechteausweitung ermöglicht. Name: „Bumsrakete[tm]“.
In Linux haben kürzliche Rechteausweitungslücken für Furore gesorgt, die insbesondere mit schönen Codenamen wie „CopyFail“ [1], „DirtyFrag“ sogar mit eigenem Logo [2] oder „Fragnesia“ [3] Aufmerksamkeit erregten. IT-Sicherheitsforscher haben diese Schwachstellenklasse nun auch in FreeBSD entdeckt. Und mit einem Augenzwinkern den Codenamen „Bumsrakete[tm]“ dafür vergeben – laut Erklärung eine Rakete, die Bumm macht, Feuerwerk ist gemeint.
Auf einer eigens dafür eingerichteten Webseite mit der Domain bumsrake.de [4] erklären sie Details der Schwachstelle. Dabei schießen sie satirisch ein wenig über das Ziel hinaus und haben den Text in Donald-Trump-Sprachstil verfasst. Im Kern geht es jedoch darum, dass auch in FreeBSD aufgrund der Sicherheitslücke der Page Cache von Dateien im Speicher manipuliert werden kann, wodurch Angreifer etwa eine root-Shell öffnen können. Der Kernel nutzt mehrere Prüfungen, die allerdings aufgrund einiger Einschränkungen schlicht nicht greifen. Ähnlich wie unter Linux ist auch in FreeBSD Kryptografiecode im Kernel Auslöser für die Schwachstelle, die Beschreibung weist auf die AES-GCM-Entschlüsselung im Rahmen von Kernel TLS (KTLS) hin (CVE-2026-45257).
Laut FreeBSD-Sicherheitsmitteilung [5] können lokale Nutzer ohne weiterreichende Rechte im System, die Dateien lesen dürfen, deren Inhalt mit eigenem Content überschreiben, indem sie die Datei über eine Loopback-Verbindung mit aktiviertem KTLS schicken. Das verändert den Page Cache direkt, die Daten werden aufs Laufwerk geschrieben. Durch das Überschreiben von setuid-Binärdateien oder anderen vertrauenswürdigen Dateien gelingt dann die Rechteausweitung. Die komplette Übernahme des Systems ist möglich. Die IT-Forscher stellen auch einen Demo-Exploit bereit – IT-Verantwortliche sollten daher zügig ihre FreeBSD-Systeme absichern.
Durch das Upgrade der FreeBSD-base lässt sich die Lücke im aktuellen Zweig FreeBSD 15.0-RELEASE schließen. Der Aufruf
# pkg upgrade -r FreeBSD-base# shutdown -r +10min "Rebooting for a security update"
erledigt das. Auf Systemen, die nicht mit den base-Systempaketen aufgesetzt wurden, soll
# freebsd-update fetch# freebsd-update install# shutdown -r +10min "Rebooting for a security update"
Abhilfe schaffen. Es stehen zudem Quellcode-Patches bereit, die Admins anwenden können. Die Entdecker der Schwachstelle nennen als temporäre Gegenmaßnahme, bis ein neuer Kernel gebaut werden kann, das Setzen der Einstellung kern.ipc.mb_use_ext_pgs=0 in der Datei „/etc/sysctl.conf“. Das FreeBSD-Team wiederholt diesen Tipp jedoch nicht.
Betroffen sind FreeBSD 15.0, 14.x und 13.x. Die Versionen 12.x enthalten den verwundbaren Code noch nicht. Die Sicherheitsupdates stehen derzeit für FreeBSD 14.3, 14.4, und 15.0 sowie dem Release-Kandidaten von 15.1 zur Verfügung. IT-Verantwortliche sollen gegebenenfalls auf die unterstützten FreeBSD-Versionen migrieren.
Die Aufbereitung der Lücke als „Bumsrakete“ ist ein bissiger Seitenhieb auf die überhand nehmende Aufmerksamkeitsökonomie, wodurch Entdecker von Schwachstellen regelrechten Marketing-Aufwand treiben und den aufgedeckten Schwachstellen prägnante Namen geben oder schöne Logos dazu bauen. Die Vermischung des Ganzen mit Trump-Stil oder der Nutzung der Schriftart Comic Sans untermauert das. Die CVSS-Score-Berechnung zur Einschätzung des Risikos nutzen die Hinterleute auch gleich, um sich darüber lustig zu machen: Auf die mehrfache satte Höchstwertung 10 kommt noch ein Wert +3 hinzu: CVSS 13 von 10! Der auf „bumsrake.de“ angenommene Angriffsvektor [6] ergibt hingegen einen realen CVSS-Wert von 9.3, was dem Risiko „kritisch“ entspricht.
URL dieses Artikels:
https://www.heise.de/-11328722
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Rechner mit Intel-Logo: macOS 26 bleibt die letzte Version.
(Bild: Mamun_Sheikh / Shutterstock)
Mit macOS 27 ist das x86-Zeitalter bei Apple vorbei. Immerhin soll es noch über einen längeren Zeitraum Patches geben. Wie vollständig die sind – unklar.
Apple hat offizielle Angaben dazu gemacht, wie lange das Unternehmen für die letzte Intel-Version von macOS [1] noch Sicherheitsupdates ausliefern wird. Bekanntermaßen endet der offizielle Support für x86-Macs mit macOS 26 [2]. Das neue, im Herbst erscheinende macOS 27 [3] wird die alten Intel-Zöpfe endgültig abschneiden und nur noch auf Macs mit Apple Silicon, also ARM-Basis, laufen. Besitzer von Intel-Macs fragten sich daher, wie lange ihre Systeme vor Lücken abgedichtet bleiben.
Die Antwort findet sich gut versteckt in einem Supportdokument [4] für Personen, die ganze Mac-Flotten betreuen. Im Rahmen eines „WWDC26 App Management Updates“ für das Apple Platform Deployment, das in dieser Woche aktualisiert wurde, heißt es, Apple werde Sicherheitsupdates für Intel-Macs für „drei Jahre“ liefern. Das entspricht ungefähr dem, was der Konzern bislang macht: Es werden stets das jüngste Betriebssystem sowie die beiden Vorgänger mit Security-relevanten Patches versehen. So gibt es aktuell zusammen mit dem jüngsten macOS (Tahoe) auch stets Updates für Sequoia (macOS 15, von 2024) und Sonoma (macOS 14, von 2023). Tahoe, das letzte Intel-System, dürfte nun ähnlich weitergeführt werden. Auch mit neuen Versionen des Safari-Browsers ist zu rechnen, vermutlich ebenfalls mindestens drei Jahre lang.
Was zunächst gut klingt, hat allerdings auch Nachteile. Apple neigt dazu, nur jeweils für die jüngste Version seiner Betriebssysteme [5] auch wirklich alle Sicherheitslücken zu stopfen. Es gibt keine konkrete Ansage, welche Bugs ungefixt bleiben und vor allem warum. Hängt es vom Schweregrad ab? Ist es von den Ressourcen bei Apple abhängig? Angaben dazu macht der Konzern schlicht nicht. Immerhin: Stellt sich heraus, dass schwerwiegende Exploits kursieren, werden auch schon mal (noch) ältere Systeme mit Updates versorgt.
Für Nutzer mit Intel-Macs heißt das: Sie bleiben auf einem alten System. Auch die internen Fehlerbehebungen von macOS 27 erhalten sie nicht. Als Alternative bietet sich wie immer an, auf Linux zu wechseln [6], um ein jeweils aktuelles System zu haben. Doch für viele Nutzer dürfte das eine zu hohe Hürde sein. Ihnen bleibt nur übrig, auf einen Apple-Silicon-Mac zu aktualisieren.
Die letzten aktuellen Intel-Maschinen hatte Apple 2020 auf den Markt gebracht. Für bestimmte Modellvarianten wie den iMac mit 27 Zoll [7] bietet der Hersteller nach wie vor keinen Nachfolger mit ARM-Technik.
URL dieses Artikels:
https://www.heise.de/-11327980
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Artur Szczybylo/Shutterstock.com)
Zwei Sicherheitslücken bedrohen Ivanti Endpoint Manager Mobile. Sicherheitspatches schaffen Abhilfe.
Nutzen Angreifer Schwachstellen in der Geräteverwaltungssoftware Ivanti Endpoint Manager Mobile erfolgreich aus, können sie Schadcode ausführen oder sogar Befehle mit Root-Rechten absetzen.
In einer Warnmeldung führen die Entwickler aus [1], dass sie bislang keine Attacken dokumentiert haben. Eine Sicherheitslücke (CVE-2026-6973 „hoch“) betrifft die Konfigurationssteuerung. Dort können entfernte Angreifer, die aber bereits authentifiziert sein müssen, Schadcode auf Systeme schieben und ausführen.
Die Voraussetzungen sind im zweiten Fall identisch (CVE-2026-10727 „hoch“). An dieser Stelle können Angreifer Befehle mit Rootrechten ausführen. Die Entwickler versichern, die Sicherheitsprobleme in den Ausgaben 12.9.0.1, 12.8.0.3 und 12.7.0.2 gelöst zu haben.
Admins sollten die Updates zügig installieren. Cyberkriminelle haben Sicherheitslücken in Ivanti EPMM [2] in jüngster Vergangenheit häufiger angegriffen.
URL dieses Artikels:
https://www.heise.de/-11328488
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Anthropic)
Schon das Stichwort „Security Audit“ reicht: Forscher kritisieren Anthropics Fable 5, weil dessen Cybersecurity-Filter auch harmlose Anfragen ausbremsen.
Mehrere bekannte Sicherheitsforscher halten die Cybersecurity-Schranken von Anthropics neuem KI-Modell Fable 5 für zu scharf eingestellt. Sie berichten, dass die Schutzmechanismen nicht nur bei brisanten Anfragen anschlagen, sondern auch bei alltäglicher Arbeit aus Softwareentwicklung und IT-Sicherheit. Die Beispiele reichen vom Code Review über das Schreiben sicheren Codes bis hin zum Lesen eines Blogbeitrags zu einem Sicherheitsthema.
Fable 5 [1] ist die öffentlich verfügbare Variante von Anthropics neuem Spitzenmodell Mythos 5. Anders als Mythos bringt Fable vorgeschaltete Schutzmechanismen für Themen aus Cybersecurity, Biologie, Chemie sowie Distillation mit – Letzteres soll verhindern, dass das Modell zum Training konkurrierender KI-Systeme missbraucht wird. Stuft ein sogenannter Classifier eine Anfrage als heikel ein, beantwortet nicht Fable die Frage, sondern das ältere Modell Claude Opus 4.8. Damit will Anthropic verhindern, dass Angreifer die Fähigkeiten des Modells für Cyberattacken oder andere schädliche Zwecke ausnutzen. Laut Anthropics offizieller Ankündigung [2] sind die Safeguards bewusst konservativ kalibriert und treffen manchmal auch harmlose Anfragen.
Zu den Kritikern zählt Valentina „Chompie“ Palmiotti, Leiterin des Offensive-Research-Teams (XOR) bei IBM X-Force. Auf X schrieb sie [3], Fable lehne jede Anfrage ab, die auch nur am Rande mit Cybersecurity zu tun habe. Selbst harmlose Aufgaben wie das Lesen eines Blogbeitrags treffe es.
Damit beschreibt Palmiotti ein Problem, das die IT-Sicherheit als False Positive kennt: Ein Schutzmechanismus schlägt bei einer harmlosen Aktivität fälschlich Alarm. Genau diese Fehlklassifikationen werfen die Forscher den Schranken von Fable nun in großer Zahl vor.
Ähnlich äußerte sich der Cybersecurity-Experte Matt Suiche gegenüber TechCrunch [4]. Wer Fable um sicheren Code bitte, den behandle das Modell so, als gehe es um Cybersecurity statt um normale Softwareentwicklung. Suiche vermutet, dass die Filter vor allem auf Schlüsselbegriffe reagieren. Seine Kritik trifft einen Bereich, der für viele Entwickler zum Alltag gehört: sichere Authentifizierung, Schutz vor SQL-Injection oder das sichere Speichern von Zugangsdaten.
Auch der italienische Sicherheitsforscher Simone Margaritelli, in der Szene besser als „evilsocket“ bekannt, berichtet von Problemen. Auf X schrieb er [5], schon die Bitte um ein Code Review löse eine Rückstufung von Fable aus. Code Reviews gehören zu den Standardaufgaben professioneller Softwareentwicklung und helfen unter anderem dabei, Fehler und Sicherheitslücken früh zu erkennen.
Die Kritik beschränkt sich nicht auf einzelne Forscher. Der Entwickler Mehul Mohan schrieb auf X [6], Fable sei praktisch unbrauchbar, sobald Begriffe wie „cybersecurity“, „security audit“, „vulnerability“ oder die Bitte „help me make my app secure“ fielen. Diese Beispiele betreffen vor allem defensive Sicherheitsarbeit, also das Absichern eigener Systeme und Anwendungen.
Wie empfindlich die Filter reagieren, zeigen auch dokumentierte Fehlermeldungen. Der X-Nutzer @zeroxjf veröffentlichte einen Screenshot [7], in dem Fable einräumt: „Fable 5's safety measures flagged this message for cybersecurity or biology topics. They may flag safe, normal content as well. Switched to Opus 4.8.“ Anschließend verweigerte auch Opus 4.8 die Antwort und verwies auf ausgelöste Cybersecurity-Schutzmechanismen. Bemerkenswert ist vor allem der Hinweis, dass die Filter auch sichere, normale Inhalte erfassen können.
Ähnliche Beobachtungen kommen aus professionellen Sicherheitstests. Rob T. Lee, Chief AI Officer und Forschungsleiter des SANS Institute [8], berichtet, dass Fable bei seinen ersten Tests auch Aufgaben aus Incident Response, Detection Engineering und digitaler Forensik automatisch zurückgestuft hat. Beim SANS Institute handelt es sich um eine der bekanntesten Ausbildungs- und Forschungsorganisationen für IT-Sicherheit.
Explizit stellen die Forscher die Schutzmechanismen gegen Missbrauch nicht grundsätzlich infrage. Sie kritisieren aber, dass die Schranken so breit greifen, dass sie auch legitime Arbeit erfassen: Sicherheitsanalysen, Code Reviews, sicheren Code, Incident Response oder das Auswerten sicherheitsrelevanter Informationen. Ob es sich um Kinderkrankheiten einer neuen Schutzarchitektur handelt oder um ein grundsätzliches Problem bei der Abgrenzung von legitimer und schädlicher Sicherheitsarbeit, ist offen. Anthropic hat sich zu den Vorwürfen bislang nicht geäußert.
URL dieses Artikels:
https://www.heise.de/-11328448
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Tatiana Popova/Shutterstock.com)
In aktuellen Versionen haben die OpenSSL-Entwickler insgesamt 18 Sicherheitslücken geschlossen.
Die freie Software OpenSSL für SSL/TLS-Implementierungen ist verwundbar. Der Großteil der nun geschlossenen Schwachstellen ist mit dem Bedrohungsgrad „niedrig“ eingestuft. Es kann aber auch Schadcode auf Geräte gelangen. Bislang gibt es keine Hinweise auf Attacken. Das kann sich aber jederzeit ändern, sodass Admins mit der Installation der reparierten Ausgaben nicht zu lange zögern sollten.
Im Sicherheitsbereich der OpenSSL-Website listen die Entwickler die Sicherheitslücken auf [1]. Davon ist nur eine Schwachstelle (CVE-2026-45447) mit dem Bedrohungsgrad „hoch“ eingestuft. Sie steckt in der PKCS7_verify()-Funktion.
Daran können Angreifer mit einer präparierten PKCS#7-Signatur ansetzen. Bei deren Verifizierung kommt es zu einem Speicherfehler (use-after-free) und es kann Schadcode auf Systeme gelangen. Die Beschreibung der Lücke liest sich so, als seien Attacken aus der Ferne möglich.
Durch das Ausnutzen der verbleibenden Schwachstellen können Angreifer unter anderem Abstürze auslösen (etwa CVE-2026-34183 „mittel“). Ein Fehler in AuthEnvelopedData vom Cryptographic Message Service sorgt dafür, dass von Angreifern kompromittierte Nachrichten verarbeitet werden.
Außerdem können Angreifer signierte Nachrichten mit dem RSA-Schlüssel eines Opfers entschlüsseln (CVE-2026-42768 „niedrig“). Auch der Tausch eines Root-Zertifikats durch Angreifer ist vorstellbar (CVE-2026-42769 „niedrig“).
Die Enwickler versichern, die Sicherheitslücken in den folgenden Versionen geschlossen zu haben:
URL dieses Artikels:
https://www.heise.de/-11328258
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Pavel Ignatov/Shutterstock.com)
Nicht alle Unternehmenskunden von Microsofts Maildienst sind betroffen. Ein Prüfdienst schafft Klarheit und zeigt die möglichen Auswirkungen.
Ein Konfigurationsfehler bei Exchange Online, den Sicherheitsforscher auf den Namen „Ghost-Sender“ getauft haben, erlaubt Spammern und Cyberkriminellen, gefälschte E-Mails an den Schutzmaßnahmen des Anbieters vorbeizuschleusen. Microsofts Sicherheitsabteilung erklärte sich für nicht zuständig – Kunden müssen sich selbst kümmern.
Nutzt ein Unternehmen einen Dienst zur Mailfilterung oder für andere Aufgaben und hat diesen im DNS als MX-Eintrag (Mail eXchange) eingetragen, gehen alle Mails zunächst dorthin. Nach der Bearbeitung durch den externen Dienst leitet dieser die E-Mails an Exchange Online (EXO) weiter, um sie den Empfängern zuzustellen. Dabei ignoriert EXO dann jedoch übliche Maßnahmen gegen Mailspoofing wie SPF und DMARC und kippt auch offensichtlich gefälschte E-Mails bei den Empfängern ab.
Das liegt im Zusammenspiel der Exchange-Online- und der externen Mailserver begründet und ist ein Konfigurationsfehler bei deren Verschaltung. Wie die Entdecker von Infoguard erläutern, gibt es mehrere Methoden der Fehlerbehebung: Man könne einen sogenannten „partner organization connector“ konfigurieren oder per Mailregeln alle E-Mail in Quarantäne verschieben, deren Header X-MS-Exchange-Organization-AuthAs nicht auf Internal gesetzt und zudem die IP-Adresse des einliefernden Mailservers unbekannt ist.
Microsofts Reaktion auf den Fehler – den heise security mit dem kostenlos verfügbaren Testprogramm [1] nachvollziehen konnte – war befremdlich. Das Microsoft Security Response Center (MSRC) – aktuell mal wieder mit Sicherheitsforschern über Kreuz [2] – wies die Infoguard-Forscher nach ihrer Meldung am 21. April 2026 ab: Es handele sich weder um eine sicherheitsrelevante Schwachstelle noch um einen Fall fürs MSRC. Daraufhin kontaktierten die Schweizer den Kundendienst des Redmonder Softwarehauses und erhielten eine Bestätigung: Tags zuvor habe man eine großangelegte Versandaktion gefälschter E-Mails festgestellt, das Problem werde also bereits von Missetätern ausgenutzt.
Dennoch passierte nichts, „Ghost-Sender“ funktioniert bis heute. Dabei tragen E-Mails mit gefälschten Absenderadressen (die in Outlooks Mailoberfläche sogar das passende Profilbild tragen) ein hohes Risiko für Betrügereien aller Art, speziell die als „Business Email Compromise [3]“ bekannte Masche.
Administratoren, die Exchange Online mit vorgelagertem Filterdienst nutzen, sollten ihre Konfiguration daher zügig auf Anfälligkeit prüfen [4] und gegebenenfalls eine der empfohlenen Gegenmaßnahmen ergreifen – in Redmond scheint man derzeit nicht der Ansicht zu sein, wegen „Ghost-Sender“ handeln zu müssen.
URL dieses Artikels:
https://www.heise.de/-11327666
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Portrait Image Asia / Shutterstock.com)
Namhafte Banken wie die Sparkassen warnen zwar vor Phishing, nutzen aber selbst Phishing-artige Domains. Es ginge sicher besser.
Wieder einmal findet sich im Posteingang wie fast jeden Tag eine E-Mail, konkret von der Sparkasse, die auf ein Gewinnspiel im Zusammenhang mit Wero [1] als Zahlungsangebot hinweist. Im aktuellen Fall könnten Empfänger unter der Domain „gewinnspiel-sparkasse.de“ mehr herausfinden und teilnehmen. Der Rest der Mail sieht absolut professionell und korrekt aus, die Ansprache erfolgt mit Vornamen, selbst der zuständige Kundenberater wird genannt. Dennoch ruft die Domain Unwohlsein hervor – so sehen die typischen Phishing [2]-Domains auch aus.
Eine erste schnelle Prüfung erfolgt durch Eingabe des Begriffs „whois“ mit der gesuchten Domain in der Suchmaschine. Google schaltet vor reguläre Suchergebnisse eine KI-generierte Antwort. Die liefert einen Absatz, dass das die offizielle Gewinnspiel-Domain der Sparkassen sei. Dahinter ist unscheinbar eine Quell-URL zu finden, die ihrerseits auf „mehr-sparkasse.de“ verweist – was abermals ein Kandidat für typische Phishing-URLs ist.
Weitere Such-Iterationen führen dann dazu, dass die Sparkassen ihre offizielle Gewinnspiel-Seite benennen. Aber die Verwirrung wird schnell größer:
(Bild: Screenshot / heise medien)
Die URL soll auf einmal nicht mehr zur Sparkasse gehören, wie laut Googles KI-Exzerpt offizielle Sparkassen-Seiten offenbar angeben.
Da Suchmaschinen oftmals Malware-Werbung unter den „Sponsored Links“, also als bezahlte Werbung einblenden und auch Inhalte von diesen Seiten für ihre Antworten verwerten, ist der KI-Antwort an der Stelle eher nicht zu vertrauen. Ohnehin sind diese Zusammenfassungen mit einer inakzeptabel hohen Fehlerquote versehen, das dürfte hier ebenfalls der Fall sein.
Die Indizienlage ist dadurch bis hier nicht eindeutig. Weiterhin erwähnenswert: Die Gewinnspiel-Domain wird bei Hetzner gehostet. Dort kann sich jeder eine Webseite mit beliebigen (freien) Domains einrichten. Die Seite liegt nicht bei der Finanz Informatik, dem IT-Dienstleister der Sparkassen, der auch die Domain „sparkasse.de“ in eigenen Rechenzentren betreibt. Das weckt ebenfalls Zweifel, da das eher für Phishing statt für ein reguläres Angebot der Sparkassen spricht.
Die Nutzung derartiger Domains stumpft die Nutzerinnen und Nutzer ab. Die gewöhnen sich daran, dass betrügerische URLs wie „portorueckzahlung-post.de“ echt sein könnten. Seriöse Unternehmen, die oftmals in Phishing-Angriffen imitiert werden, erziehen ihre User also entgegen ihren eigenen Warnhinweisen dazu, blindlings solchen Links zu folgen. Schlimmer noch: Die Banken sind die Ersten, die Rückzahlungen verweigern, sofern Kunden und Kundinnen auf solches Phishing hereinfallen.
Abhilfe wäre eigentlich sehr einfach zu schaffen. Das Internet kennt Subdomains. Also so etwas wie „www“ vor dem Seitennamen. Die lassen sich nicht einfach von Dritten registrieren, wie die potenziellen Phishing-Domains. Vorschlag für seriöse URLs wären im konkreten Fall etwa „gewinnspiel.sparkasse.de“ oder „mehr.sparkasse.de“.
Unsere Anfrage diesbezüglich beim Deutschen Sparkassen- und Giroverband (DSGV) blieb mehr als 24 Stunden, bis zum Meldungszeitpunkt, unbeantwortet. Eine Positionierung reichen wir beim Eintreffen nach.
Auch andere Banken und namhafte Unternehmen arbeiten mit solchen Domains in der Kundenkommunikation. Das verhindert, dass Tipps wie „prüfen Sie die URLs“ sinnvoll umsetzbar sind. Als Beispiel kann auch die Telekom herhalten. Die setzt als Absender-Domain in Marketing-Kommunikation beispielsweise „dialog-telekom.de“ [3] ein. Auch da läuten nach altem Brauch bei eingesessenen IT‘lern die Alarmglocken. Es gibt zahlreiche Beispiele. Die Deutsche Bahn setzt für die Nacherhebung beim Fahrpreis auf die Domain „db-fn.de“.
Wahrscheinlich geht die Nutzung derartiger Domains auf die Auslagerung an Marketing-Unternehmen zurück. Die Unternehmen und Banken müssen jedoch auch, wenn es um Werbung geht, auf ihren seriösen Domains bleiben. Andernfalls wirken die Phishing-Warnungen ein wenig wie Heuchelei. Der Sicherheitshinweis, dass Nutzerinnen und Nutzer bitte die Domains in der Kommunikation prüfen sollen, ist aufgrund des Verhaltens auch der großen Unternehmen jedoch komplett hinfällig und unbrauchbar.
URL dieses Artikels:
https://www.heise.de/-11327434
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: GitHub)
Mit npm v12 schließt GitHub einen zentralen Angriffsweg: Installationsskripte aus Abhängigkeiten laufen ab Juli 2026 nur noch nach ausdrücklicher Freigabe.
Mit npm v12 schafft GitHub mehrere sicherheitskritische Standardeinstellungen des Node.js-Paketmanagers ab. Die für Juli 2026 angekündigte Hauptversion führt Installationsskripte aus Abhängigkeiten künftig nicht mehr automatisch aus. Auch Git- und Remote-Abhängigkeiten installiert npm nur noch, wenn Entwickler sie ausdrücklich freigeben. Damit will GitHub einen der wichtigsten Angriffswege in der Software-Lieferkette schließen: die automatische Codeausführung während eines npm install.
npm ist der Standard-Paketmanager des Node.js-Ökosystems und gehört zu den meistgenutzten Paketverwaltungen überhaupt. Moderne Anwendungen ziehen oft Hunderte oder Tausende direkte und indirekte Abhängigkeiten nach. Entsprechend groß ist die Angriffsfläche. Seit Jahren warnen Sicherheitsforscher vor Angriffen auf die Lieferkette [1], bei denen Schadcode über übernommene Pakete, gestohlene Maintainer-Konten oder manipulierte Installationsskripte in Entwicklungsumgebungen gelangt. Besonders gefährlich sind Mechanismen, die schon beim Installieren eines Pakets Code ausführen [2] – oft, bevor Entwickler die Anwendung überhaupt gestartet haben.
Genau hier setzt die wichtigste Neuerung von npm v12 an. Künftig führt der Paketmanager Installationsskripte aus Abhängigkeiten standardmäßig nicht mehr aus. Das betrifft die Lifecycle-Skripte preinstall, install und postinstall. Auch native Erweiterungen, die npm bislang automatisch über node-gyp kompiliert, baut der Paketmanager nicht mehr ohne Freigabe. Dasselbe gilt für bestimmte prepare-Skripte aus Git-, Datei- oder verlinkten Abhängigkeiten.
Bislang genügt ein einfaches npm install, um solche Skripte automatisch auszuführen. Viele Pakete nutzen den Mechanismus für legitime Zwecke, etwa um zusätzliche Binärdateien herunterzuladen oder native Komponenten zu kompilieren. Dieselbe Funktion gilt aber seit Jahren als attraktiver Angriffsweg: Über ein manipuliertes Installationsskript lässt sich Schadcode bereits während der Installation ausführen. Der Code kann zum Beispiel Umgebungsvariablen auslesen, Zugangsdaten abgreifen oder weitere Schadsoftware nachladen.
An die Stelle des automatischen Ausführens tritt ein Modell mit Freigabeliste. Entwickler bestimmen künftig selbst, welche Pakete ihre Installationsskripte ausführen dürfen. Diese Freigaben hinterlegt npm im Projekt, sodass Teams sie zusammen mit dem Quellcode versionieren können.
Wer früh umstellen will, kann das bereits tun: Schon npm 11.16.0 warnt vor Skripten, die der Paketmanager künftig blockiert. Mit dem Befehl npm approve-scripts --allow-scripts-pending lässt sich prüfen, welche Abhängigkeiten betroffen wären; mit npm approve-scripts lassen sich die vertrauenswürdigen Pakete anschließend freigeben.
Auch beim Umgang mit Git-Abhängigkeiten zieht npm die Zügel an. Pakete, die direkt aus einem Git-Repository stammen, blockiert der Paketmanager künftig standardmäßig; Entwickler müssen solche Quellen ausdrücklich erlauben. GitHub begründet den Schritt mit einem Angriffsweg, über den sich aus einer Git-Abhängigkeit heraus Code ausführen ließ – selbst dann, wenn Installationsskripte eigentlich unterdrückt waren. Hinzu kommt, dass sich Git-Abhängigkeiten generell schwerer kontrollieren lassen als Pakete aus dem regulären npm-Registry.
Eine ähnliche Hürde gilt künftig für Remote-Abhängigkeiten, also Pakete, die direkt von einer URL stammen, etwa als TAR-Archiv per HTTPS. Auch sie installiert npm nur noch nach ausdrücklicher Freigabe. Solche Abhängigkeiten umgehen die übliche Registry-Infrastruktur und erschweren es, ihre Herkunft nachzuvollziehen. GitHub will so verhindern, dass externe Quellen unbemerkt in die Abhängigkeitskette geraten.
Mehr Sicherheit bedeutet für Entwickler und Unternehmen zunächst mehr Aufwand. Wer bislang auf Installationsskripte, Git-Abhängigkeiten oder externe Paketquellen setzt, muss seine Build- und CI/CD-Prozesse prüfen und die nötigen Komponenten freigeben. GitHub rät, schon jetzt auf npm 11.16.0 oder neuer zu wechseln und die ausgegebenen Warnungen auszuwerten.
Alle Probleme der JavaScript-Lieferkette löst npm v12 allerdings nicht. Schadcode, der direkt im Anwendungscode eines Pakets steckt [3], gelangt weiterhin auf die Systeme. Auch kompromittierte Maintainer-Konten, Typosquatting oder verwundbare Bibliotheken fängt der neue Ansatz nicht ab. Für die Sicherheit von Entwicklungs- und Build-Umgebungen dürfte er dennoch eine der weitreichendsten Änderungen der vergangenen Jahre sein.
Weitere Details nennt GitHub im Changelog-Eintrag zu den anstehenden Breaking Changes für npm v12 [4].
URL dieses Artikels:
https://www.heise.de/-11327518
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Angreifer können unter anderem an Schadcode-Schwachstellen in ColdFusion und Dreamwaver ansetzen.
An diesem Patchday gelten zwei „kritische“ Sicherheitslücken mit Höchstwertung in Adobe Campaign Classic als am gefährlichsten. Darüber kann Schadcode auf PCs gelangen und Systeme vollständig kompromittieren. Sicherheitsupdates stehen zum Download bereit. Bislang gibt es keine Berichte, dass Angreifer die Lücken bereits ausnutzen.
Wie aus einer Warnmeldung hervorgeht [1], weisen die Campaign-Classic-Schwachstellen (CVE-2026-48303, CVE-2026-47938) den maximalen CVSS Score 10 von 10 auf. Wie Schadcode-Attacken im Detail ablaufen könnten, ist bislang nicht bekannt. Davon sind Linux und Windows bedroht. Die Entwickler versichern, die Sicherheitsprobleme in v7: 7.4.3 build 9396 gelöst zu haben.
ColdFusion 2023 und 2025 sind über sechs von Adobe als „kritisch“ eingestufte Lücken angreifbar. Davon sind einem Beitrag zufolge alle Plattformen betroffen [2]. So können Angreifer etwa Schadcode ausführen (CVE-2026-47928), Sicherheitsmaßnahmen umgehen (CVE-2026-47932) oder sich höhere Nutzerrechte verschaffen (CVE-2026-47929). Hier schaffen ColdFuison 2023 Update 20 und ColdFusion 2025 Update 9 Abhilfe.
Als „kritisch“ gelten dem Softwarehersteller zufolge auch zwei Schwachstellen (CVE-2026-34691, CVE-2026-34693) in Experience Manager Forms für alle Plattformen. Hier kann in Form von Stored- und Reflected-XSS-Attacken Schadcode auf Systeme gelangen.
Mit 56 Stück hat Adobe die meisten Lücken in Experience Manager geschlossen. Hier helfen die Versionen AEM Cloud Service (CS) Release 2026.05, 6.5 LTS Service Pack 2 und 6.5 Service Pack 25.
Weitere Informationen zu bedrohten und reparierten Versionen finden Admins in den offiziellen Warnmeldungen. [3]
URL dieses Artikels:
https://www.heise.de/-11326790
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Tatoh/Shutterstock.com)
Frankreichs Digitalstelle DINUM räumt ein Datenleck beim Regierungs-Messenger Tchap ein. Angreifer konnten ein Konto kompromittieren.
Die französische staatliche Digitalstelle DINUM untersucht einen Einbruch in ein Konto des Regierungs-Messengers Tchap. Der oder die Angreifer haben demnach Zugriff auf Chats und Nachrichten sowie Informationen von tausenden Nutzern erlangt.
Das teilt das französische Regierungsportal numerique.gouv.fr [1] mit. Demnach konnten die Angreifer am 7. Juni 2026 ein Nutzerkonto beim verschlüsselten Instant-Messaging-Dienst Tchap kompromittieren. Da der Dienst private Chats und Nachrichten verschlüsselt, können die Angreifer selbst im Fall einer Konto-Kompromittierung lediglich auf unverschlüsselte öffentliche Chats und Nachrichten zugreifen, erklärt die Behörde. Es seien Berichten zufolge 73.467 Nutzerinnen und Nutzer betroffen, was knapp neun Prozent der Nutzerbasis entspreche.
Nach dem Vorfall schaltete sich die ANSSI, Frankreichs nationales Cybersicherheitszentrum und BSI-Pendant, ein und untersuchte den Vorfall. Die Kompromittierung konnte dabei bestätigt und Schutzmaßnahmen ergriffen werden; das Ausmaß des Vorfalls wurde ermittelt. Die IT-Sicherheitsexperten haben das unterwanderte Konto gesperrt. Bei der Untersuchung kam heraus, dass zu den möglicherweise offengelegten Daten Vor- und Nachname, E-Mail-Adresse, Unternehmen und Avatar der Nutzerinnen und Nutzer gehören. Die privaten Chats seien hingegen geschützt.
Die Untersuchungen gingen weiter, erklärt die Behörde. Es sollen noch Ereignisprotokolle ausgewertet werden, um herauszufinden, auf welche Chats und auf welche weiteren Daten die Angreifer Zugriff hatten. Im digitalen Untergrund bieten die Angreifer die angeblich abgegriffenen Daten an. Wie ein Post von Dark Web Intelligence auf X [2] zeigt, geht es angeblich um 73.467 Nutzerkonten, mehr als 640.000 Nachrichten, 876 Chat-Räume und knapp 60.000 Mediendateien mit einem Umfang von 13,5 GByte. Zudem sollen klassifizierte Dokumente enthalten sein. Das hat die Untersuchung bislang jedoch nicht bestätigt.
Frankreichs als sicherer Messenger für die Regierung konzipierter Tchap-Dienst, der auf Matrix basiert, hatte bereits zum Start im Jahr 2019 mit einer Sicherheitslücke zu kämpfen. Einem Hacker gelang es, unbefugt ein Konto in dem Dienst anzulegen [3], obwohl er nicht zur Regierung gehört, was eigentlich durch entsprechende Mail-Domains sichergestellt werden sollte. Die Lücke wurde damals in kürzester Zeit nach der Meldung durch den Entdecker geschlossen.
URL dieses Artikels:
https://www.heise.de/-11326766
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Unter anderem eine kritische Kernel-Schwachstelle bedroht Windows 11. Zusätzlich schließt Microsoft Ende Mai bekannt gewordene Zero-Day-Lücken.
Am Patchday im Juni stuft Microsoft zahlreiche Sicherheitslücken in etwa Azure, M365, Exchange Online, Office und Windows als „kritisch“ ein. In vielen Fällen können Angreifer aus der Ferne ohne Authentifizierung Schadcode ausführen und Systeme vollständig kompromittieren.
Unter den nun geschlossenen Schwachstellen finden sich auch die BitLocker-Zero-Day-Lücken YellowKey (CVE-2026-45585 „mittel“) und GreenPlasma (CVE-2026-50507 „mittel“), die ein Sicherheitsforscher mit dem Pseudonym Nightmare Eclipse offengelegt hat [1]. Nutzen Angreifer diese Lücken erfolgreich aus, können sie die BitLocker-Festplattenverschlüsselung umgehen.
Der Forscher hat aber noch mehr Zero Days in petto und legte direkt nach dem Patchday die RoguePlanet getaufte Schwachstelle in seinem Blog offen [2]. Diese Lücke bedrohe Windows 10 und 11 im voll gepatchten Zustand. Ansatzpunkt ist erneut die Schutzsoftware Defender. Nach einer erfolgreichen Attacke sollen Angreifer mit Systemrechten dastehen. Ein Sicherheitsupdate steht noch aus.
Der Sicherheitsforscher verfügt über Proof-of-Concept-Code. Bislang gibt es keine Hinweise darauf, dass Angreifer die Schwachstelle bereits ausnutzen. Der anonyme Sicherheitsforscher hat eigenen Angaben zufolge noch weitere Zero Days in petto, die er eigentlich am 14. Juli veröffentlichen wollte. Weil er mit RoguePlanet zu viel zu tun hatte, verschiebt sich das jetzt aber. Einen konkreten Zeitraum nennt er derzeit nicht.
Offensichtlich war ein Fix für die bereits attackierte RedSun-Lücke [3] (CVE-2026-41091 „hoch“) in der Malware Protection Engine von Defender nicht ausreichend, sodass Microsoft Ende Mai noch einmal eine Aktualisierung nachgelegt hat [4]. In den Standardeinstellungen aktualisiert sich Defender automatisch. Die Korrektur listet Microsoft nun als zum Juni-Patchday gehörend auf.
Drei Schwachstellen in Windows (CVE-2026-49160 „hoch“, CVE-2026-50507 „mittel“, CVE-2026-45586 „hoch“) in HTTP.sys, BitLocker und Collaborative Translation Framework sind öffentlich bekannt und es können Attacken bevorstehen.
Drei „kritische“ Lücken bedrohen den Windows Kernel (CVE-2026-45657 [5]), Windows HTTP.sys (CVE-2026-47291 [6]) und Windows DHCP Client Service (CVE-2026-44815 [7]). An diesen Stellen können Angreifer Schadcode ausführen und Computer vollständig kompromittieren.
Weiterführende Informationen zu den an diesem Patchday geschlossenen Sicherheitslücken finden sich in Microsofts Security Update Guide [8].
URL dieses Artikels:
https://www.heise.de/-11326714
Links in diesem Artikel:
Copyright © 2026 Heise Medien
FreshRSS