Anmelden
(Bild: heise medien)
Durch Verkettung einer SQL-Injection- und einer API-Lücke können Angreifer Code einschleusen. WordPress hat ein Update veröffentlicht, die Finder einen Hotfix.
Sicherheitsforscher haben zwei Sicherheitslücken in WordPress gefunden, die sich zu einem Exploit verketten lassen und dann das Einschleusen von Schadcode ermöglichen. Administratoren des beliebten Blog-Systems sollten zügig updaten oder ein Mini-Plugin als Notfallflicken einspielen.
Eine kritische SQL-Injection-Lücke (CVE-2026-60137) hat einen CVSS-Wert von 9,1/10 und kann durch Angreifer aus der Ferne ausgenutzt werden. Die Lücke betrifft den author__not_in-Parameter von WP_Query, der nicht korrekt validiert wird.
Die zweite der beiden Sicherheitslücken haben die Forscher von Searchlight Cyber [1] entdeckt – und dem Trend gehorchend direkt mit einem Spitznamen versehen: „WP2Shell“. Die Sicherheitslücke mit der CVE-Kennung CVE-2026-63030 ist für sich genommen „nur“ mit einem hohen Risiko bedacht (CVSS 7.5/10) und basiert auf einem Fehler im REST-API des freien CMS. Nur wenige Details sind bekannt, doch der API-Endpunkt /wp-json/batch/v1 scheint der Schuldige zu sein.
Die Finder haben unter wp2shell.com [2] eine Prüfmöglichkeit für Blogbetreiber veröffentlicht. Sie erlaubt eine erste Einschätzung und enthält einen praktischen Flicken: Ein wenige Zeilen PHP-Code umfassendes WordPress-Plugin, das die schadhafte API-Route mit einer Authentifizierung versieht. Wer sein WordPress nicht sofort auf den neuesten Stand bringen kann – die empfohlene Vorgehensweise –, sollte zu diesem Behelf greifen.
Problematisch ist die Verkettung beider Lücken – sie führt zu einer Möglichkeit, Code ohne vorherige Anmeldung in verwundbare WordPress-Installationen einzuschleusen. Derlei Sicherheitslücken sind leicht automatisierbar und können etwa zu Großangriffen führen: Derzeit sind etwa 500 Millionen Installationen von WordPress im Internet zu finden.
Das WordPress-Team hat bereits reagiert und neue Versionen publiziert [3]:
Versionen vor WordPress 6.8 sind nicht betroffen. Admins sollten die Aktualisierung schnellstmöglich einspielen – es ist zu erwarten, dass Angreifer die Sicherheitsflicken mit KI-Hilfe analysieren und noch am Wochenende erste Exploitversuche starten.
Das freie CMS WordPress erfreut sich vor allem durch sein reichhaltiges Angebot an Vorlagen und Plugins großer Beliebtheit. Letztere sind häufiges Einfallstor für Sicherheitslücken [4], ein Fehler im Kern der Software ist mittlerweile seltener geworden.
URL dieses Artikels:
https://www.heise.de/-11369660
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Mehr Datenschutz, weniger Kosten: Was ist mit einem lokalen KI-Server möglich? Gibt es Einschränkungen oder überwiegen die Vorteile?
Egal, ob man gern ausufernde Gespräche mit einem Chatbot führt, jede Menge Bilder generiert oder Programmierprojekte mit KI umsetzen will: Die Token schwinden wie Eis in der Sonne und das Ganze geht schnell ins Geld. Mal ganz abgesehen davon, dass gerade im beruflichen Kontext Vorsicht geboten ist, welche Daten man an die Onlinedienste weitergibt.
Lokale KI-Modelle sind da die deutlich bessere Wahl: Die Kosten sind besser kalkulierbar, weil man nur in Hardware investieren und kein Abo bei KI-Firmen abschließen muss. So muss man nicht mehr jedes Token auf die Goldwaage legen. Und um den versehentlichen Abfluss von Daten braucht man sich dann keine Sorgen machen. Auch die Abhängigkeit sinkt: Wer die eigene Arbeit oder die eines Unternehmens von fremder KI-Infrastruktur abhängig macht, ist Preissteigerungen und Ausfällen schlicht ausgeliefert und kann nicht eben mal wechseln.
In dieser Folge des c’t uplink sprechen wir darüber, was mit einem lokalen KI-Server möglich ist, ab welcher Hardware das Spaß macht und welche coolen Dinge ein solcher KI-Server tun kann. Jan Mahn berichtet von seinen Erfahrungen beim Aufsetzen eines LLM-Servers für kleine Teams. [7] Dabei wird aus einer Linux-Maschine mit ordentlicher GPU ein KI-Server mit Open-Source-Software wie Ollama und Open WebUI. Er verrät auch, welche Hardware dafür nötig ist.
Jan-Keno Janssen wiederum hat für ein c’t-3003-Video mit agentischer KI experimentiert [8] und lässt Hermes Agent sein Linux-System konfigurieren oder das Hintergrundbild ändern. Im c’t uplink sprechen wir über die Möglichkeiten und auch darüber, welche Risiken agentische Systeme bergen.
► Mitdiskutieren auf dem heise & c't Discord-Server [9]
Zu Gast im Studio: Jan Mahn, Jan-Keno Janssen
Host: Liane M. Dubowy
Produktion: Tobias Reimer
URL dieses Artikels:
https://www.heise.de/-11367246
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Apple-Chef Tim Cook bei einer früheren Produktvorstellung.
(Bild: Apple)
Nvidia war dank KI-Chips ein Jahr lang das wertvollste Unternehmen. Doch Apple holte zuletzt stark auf.
Apple hat sich am Freitag nach mehr als einem Jahr den Titel des wertvollsten Unternehmens an der Börse zurückgeholt – zumindest für kurze Zeit. Den Ausschlag gab im frühen US-Handel ein Kursrückgang von knapp vier Prozent bei der Aktie des Chipkonzerns Nvidia, der zuletzt die Rangliste anführte. Danach kam Nvidia auf einen Börsenwert von etwa 4,84 Billionen Dollar, während es bei Apple rund 4,9 Billionen Dollar waren. Wenig später reduzierte sich das Minus der Nvidia-Aktie etwas und der Chipkonzern hatte die Nase wieder knapp vorn.
Die Aktie des iPhone-Konzerns hatte zuletzt deutlich zugelegt [1]. Auslöser dafür war unter anderem die Anfang Juni vorgestellte neue Version der Assistenzsoftware Siri mit Künstlicher Intelligenz. Sie wird allgemein im Herbst eingeführt, Testnutzer zeigten sich aber bereits beeindruckt. In der Europäischen Union wird es die neue Software auf iPhone und iPad zunächst nicht geben. Apple verweist auf Datenschutz-Bedenken wegen der europäischen Forderung, die Betriebssysteme für andere KI-Anbieter zu öffnen.
Beobachter sehen in der Aktie des iPhone-Konzerns eine Art „Hedge“ gegen die aufziehende KI-Blase: Apple fährt gute Gewinne mit Hardware und Diensten ein, ist aber gleichzeitig deutlich weniger in Rechenzentren und Dienstleister in dem Bereich investiert als die Konkurrenz. Mark Bronzo von Rye Strategic sieht es so: „Auf dem Markt tobt ein Kampf, und derzeit profitiert Apple davon, da es nicht in jenem Sturm steckt, in dem sich der Rest der KI-Branche befindet“, sagte er diese Woche der Finanznachrichtenagentur Bloomberg [2].
Die jetzige Entwicklung könnte maßgeblich das Bild von Tim Cooks letzten Monaten als Apple-CEO prägen. Dieser übergibt im September das Ruder an Hardware-Chef John Ternus [3].
Nvidia wurde vor rund einem Jahr zum Unternehmen mit dem höchsten Börsenwert dank der exorbitanten Nachfrage nach Chips des Konzerns für den Betrieb Künstlicher Intelligenz. Das Unternehmen knackte als Erstes auf der Welt die 5-Billionen-Dollar-Marke bei der Marktkapitalisierung [4]. Nur wenige Monate zuvor hatte Microsoft Apple von der Spitze verdrängt.
Zuletzt sorgte – wie schon einmal zuvor – ein neues chinesisches KI-Modell [5] für einen Kursdämpfer bei Nvidia. Anleger stellen sich darauf ein, dass Künstliche Intelligenz mit weniger Rückgriff auf Nvidia-Chips weiterentwickelt werden könnte als bisher angenommen. Chinesische KI-Firmen haben aktuell nur Zugang zu älteren und weniger leistungsstarken Nvidia-Chipsystemen. [6]
URL dieses Artikels:
https://www.heise.de/-11369742
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Natalia Klenova / Shutterstock.com)
Kleine, aber interessante Meldungshäppchen vom News-Buffet zu Git Browser, Microsoft, Mirantis, Google, Flux, JetBrains, W3C, Gradle und OllyGarden.
In unserem leckeren Häppchen-Überblick servieren wir alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:
FreshRSS go get github.com/microsoft/agent-framework-go lässt sich die Go-Implementierung des KI-Agenten-Toolkits einem Go-Projekt hinzufügen.Solltest du ein schmackhaftes Thema vermissen, freuen wir uns über deine Mail [17].
URL dieses Artikels:
https://www.heise.de/-11363727
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Matthias Parbel / KI / iX)
Zwei OpenTelemetry-Experten erklären, warum zu viele Daten schaden – und wie ein Top-down-Ansatz die Zuverlässigkeit der Observability rettet.
Terabytes an Logs, Metriken und Traces landen täglich in den Observability-Backends großer Unternehmen – ohne dass jemand genau sagen kann, wofür. Genau an dieser Stelle setzte der Eröffnungsvortrag der Online-Konferenz Mastering Observability im April 2026 [1] an. Unter dem Titel „Weniger Sammeln, mehr Verstehen – hin zu proaktivem Reliability Engineering“ argumentierten Severin Neumann und Juraci Paixão Kroehling, dass Observability kein Tool-Wettrüsten ist, sondern ein Engineering-Problem. Nicht die Datenmenge entscheidet, sondern ob sich damit die Fragen beantworten lassen, die für die Zuverlässigkeit verteilter Systeme wirklich zählen.
Beide Speaker bringen einschlägige Erfahrung mit: Neumann, Head of Community bei Bronto, sitzt im OpenTelemetry Governance Committee [2] und pflegt als Co-Maintainer die Dokumentation des Projekts. Kroehling ist Mitgründer und CEO von OllyGarden, einer OpenTelemetry-nativen Plattform mit Fokus auf Telemetrie-Qualität, ehemaliger Jaeger-Maintainer und Schöpfer zentraler OTel-Komponenten wie Collector Builder und Operator. Ihre gemeinsame These: Viele Organisationen betreiben angstgetriebene Datensammlung nach dem Motto „erst alles erfassen, später entscheiden“.
Die Folgen dieses „Telemetry Hoarding“ sind konkret: steigende Kosten für Storage, Egress, Ingestion und Verarbeitung, wachsendes Misstrauen gegenüber den eigenen Daten sowie eine längere Mean Time to Repair (MTTR). Statt proaktivem Reliability Engineering bleiben Teams im dauerhaften Fire-Fighting-Modus stecken. Observability definieren die Vortragenden schlicht als die Fähigkeit, Fragen zu stellen und belastbare Antworten zu erhalten – die drei Signale Logs, Metriken und Traces sind dafür nur das Fundament.
Als Denkmodell dient das „2-Uhr-Szenario“: Ein Service bricht mitten in der Nacht zusammen, betroffen sind Nutzer in einer anderen Zeitzone. Welche Frage würde das Bereitschaftsteam um zwei Uhr morgens stellen – und beantwortet die vorhandene Telemetrie sie überhaupt? Diese Perspektive verschiebt den Fokus von „Was können wir alles sammeln?“ hin zu „Was muss ich wissen, damit Nutzer ihr Ziel zuverlässig erreichen?“.
Der vorgestellte Ansatz arbeitet sich von oben nach unten vor: von kritischen Nutzertransaktionen wie Login, Checkout oder Payment über die Service-Grenzen bis hinunter zur Infrastruktur mit Datenbanken, Queues und Netzwerk. Bei den Metriken bilden die Golden Signals – Latency, Traffic, Errors und Saturation – den Einstieg. Alerts sollen nur für Kennzahlen entstehen, die direkt die Zuverlässigkeit der Nutzerziele betreffen, und jeder Alert muss actionable sein, also eine klare Zuständigkeit und erwartbare Maßnahme mit sich bringen.
Traces bilden nach Ansicht der Referenten das Fundament der Strategie. Statt alles zu erfassen, empfehlen sie strategisches Sampling entlang kritischer Kundentransaktionen und selektives Sampeln übriger Pfade, um Datenvolumen und Kosten im Griff zu behalten. Auto-Instrumentierung deckt Dependencies und unterstützende Dienste wie Datenbanken, Message-Broker und externe APIs ab, während code-basierte Instrumentierung den Geschäftskontext einfängt – mit Attributen wie order_value, tenant_id oder feature_flag. Logs wiederum sollen nur gespeichert werden, wenn sie Evidenz liefern, verknüpft mit Trace- und Span-IDs statt generischer Meldungen wie [Error] Transaction failed.
Praktisch heißt das für DACH-Enterprises mit ihren oft strengen Compliance-Anforderungen: Debug-Spam, duplizierte Retry-Logs und Detailmetriken ohne Bezug zu Nutzerzielen fliegen raus. In die Sammlung gehören dagegen Golden Signals der kritischen Transaktionen, trace-basierte Geschäftsprozesse, strukturierte Fehlerlogs und knappe Ressourcenzustandsmetriken. Ein Big-Bang-Umbau ist dafür nicht nötig – der Einstieg über ein oder zwei geschäftskritische Services und eine schrittweise Governance blockiert das Tagesgeschäft am wenigsten.
Ein zentraler Baustein sind die OpenTelemetry Semantic Conventions. Sie sorgen dafür, dass Teams, Tools und Cloud-Anbieter dieselben Begriffe auf dieselbe Weise verwenden. Drei Regeln bringen das auf den Punkt: Konsistenz (etwa einheitlich deployment.environment.name = "production" statt uneinheitlichem env = "live"), Einmaligkeit (ein Name bezeichnet exakt eine reale Sache, nicht zwei Services mit service.name = "api") und Beständigkeit (statt service.name = "checkout-v1" besser service.name = "checkout" plus separates service.version).
Diese Konventionen heben nicht nur das Signal-Rausch-Verhältnis, sie machen Telemetrie auch für Maschinen verständlich. Gerade KI-Agenten und LLM-gestützte Debugging-Workflows sind auf semantisch klare, konsistente Daten angewiesen, um Kausalitäten erkennen zu können. Fehlen einheitliche Konventionen, entsteht ein „Semantic Sprawl“, der Interoperabilität zwischen Backends und Cloud-Diensten erschwert und einen Anbieterwechsel ohne komplette Re-Instrumentierung nahezu unmöglich macht.
Für die Umsetzung nennen die Speaker mehrere schnelle Gewinne. Auf Collector-Ebene lässt sich viel Ballast abwerfen: Ein Audit reduzierte 236 Resource-Attribute auf 85 tatsächlich benötigte, also über 60 Prozent weniger. Connection-Retries, die 300 identische Log-Einträge produzieren, schrumpfen per Deduplizierung auf einen Eintrag pro Vorfall. Auf SDK-Ebene helfen deklarative Konfiguration in YAML statt Boilerplate-Code sowie einheitliche SDK-Wrapper pro Sprache. Tools wie OpenTelemetry Weaver und KI-gestützte Agenten prüfen Code und Telemetrie automatisiert gegen die Conventions.
Severin Neumann ist Head of Community bei Bronto. Er beschäftigt sich seit vielen Jahren mit Observability, verteilten Systemen und der Frage, wie Engineering-Teams komplexe Softwarelandschaften zuverlässig betreiben können. Severin ist Mitglied des OpenTelemetry Governance Committees sowie Co-Maintainer der OpenTelemetry-Dokumentation und engagiert sich aktiv in der Open-Source- und Cloud-Native-Community.
Juraci Paixao Kroehling ist Mitbegründer und CEO von OllyGarden, einer OpenTelemetry-nativen Plattform, deren Schwerpunkt auf der Qualität der Telemetriedaten liegt. Er ist Mitglied des OpenTelemetry Governance Committee, ehemaliger Jaeger-Maintainer und Entwickler zentraler OpenTelemetry-Komponenten, darunter der Collector Builder und der Operator. Als CNCF-Botschafter mit Sitz in Berlin leistet Juraci seit den Anfängen einen Beitrag zum Cloud-Native-Ökosystem.
URL dieses Artikels:
https://www.heise.de/-11362984
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise online / asp)
Mideas mobile Split-Klimaanlage lässt sich per Home Assistant bedienen und automatisieren. So lässt sich das Gerät sogar offline steuern.
Die PortaSplit von Midea [1] [1] ist im Hitzesommer 2026 heiß begehrt. Denn die mobile Split-Klimaanlage sorgt besonders in Haushalten, die keine fest installierte Klimaanlage nutzen können, für willkommene Abkühlung. Wir zeigen, wie man die PortaSplit mit Home Assistant effektiv in sein vorhandenes Smart Home integriert und noch mehr aus den Möglichkeiten der mobilen Klimaanlage herausholt.
Wer ohnehin schon auf Home Assistant setzt, kann damit alle wichtigen Funktionen der PortaSplit direkt im eigenen Dashboard steuern. Das Einbinden in die heimische Home-Assistant-Installation bietet aber mehr als nur kosmetische Vorteile. So kann der Nutzer die Sensoren aus seinem Smart Home verwenden, um die Klimaanlage zu steuern. Ein Temperaturfühler am anderen Ende des Raumes könnte etwa wertvollere Werte liefern als die internen Sensoren der PortaSplit oder ein Fenstersensor schaltet die Anlage automatisch ab, wenn ein Hausbewohner durchlüftet.
Dank Home Assistant drosseln Sie Leistung gezielt, wenn gerade weniger Strom von der eigenen PV-Anlage kommt. Oder lassen Sie Ihre smarten Ventilatoren anspringen, wenn die Klimaanlage startet, um die kühle Luft großflächig zu verteilen. Schließlich lässt sich die PortaSplit dank Home Assistant sogar offline nutzen, ohne Daten an Midea weiterzugeben.
URL dieses Artikels:
https://www.heise.de/-11348755
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Summit Art Creations / Shutterstock.com)
Die IDE ermöglicht die direkte Verwendung von GitHub Copilot und kann mit neuen Versionen der Programmiersprachen Java, Kotlin und TypeScript umgehen.
JetBrains hat IntelliJ IDEA 2026.2 veröffentlicht. In der zweiten Hauptversion des Jahres sind Support für das anstehende Release Java 27 ebenso wie für Kotlin 2.4 und TypeScript 7.0 enthalten. Neuerungen bietet die Entwicklungsumgebung auch im Bereich des KI-gestützten Codings.
Nicht nur das auf Java, Kotlin und weitere Programmiersprachen ausgelegte IntelliJ IDEA hat ein Versionsupdate erhalten, sondern auch zahlreiche weitere JetBrains-IDEs. Noch in der Release-Candidate-Phase für Version 2026.2 befinden sich ReSharper und Rider.
Erst kürzlich ist TypeScript 7.0 erschienen [1]. In dem neuen Release sind Compiler und Language Server in Go geschrieben, was gemäß dem Hersteller Microsoft deutliche Geschwindigkeitsvorteile bringen soll [2]. IntelliJ IDEA 2026.2 kann mit dem neuen Release umgehen, und im Test hat sich laut JetBrains dadurch die Projektladezeit auf der Kibana-Codebasis von etwa zwölf auf etwa drei Sekunden reduziert.
Daneben kann IntelliJ IDEA nun mit den stabilen Sprachfeatures von Kotlin 2.4, ebenfalls aus dem Hause JetBrains, umgehen – darunter explizite Backing-Felder und Kontextparameter. Die für Herbst 2026 geplante Programmiersprachenversion Java 27 unterstützt IntelliJ IDEA ebenfalls, denn aus der IDE heraus lassen sich Early Access Builds installieren.
Im Bereich künstliche Intelligenz hat JetBrains einige Neuerungen zu bieten. Dank einer Partnerschaft zwischen JetBrains und Microsoft ist GitHub Copilot nun nativ in IntelliJ IDEA integriert und out-of-the-box zugänglich. Die Auswahl erfolgt über den Agent Picker im Chat, und die Authentifizierung geschieht via OAuth und das GitHub-Nutzerkonto. Ein aktives GitHub-Copilot-Abo wird hierfür vorausgesetzt.
Das Entdecken, Installieren und Verwalten benutzerdefinierter Agenten-Skills ist nun innerhalb von IntelliJ IDEA ebenfalls möglich. Wie JetBrains ausführt, seien einige der nützlichsten Skills bereits enthalten und im Skills-Manager markiert. Ein weiteres Update betrifft die im Editor vorhandene KI-basierte Codevervollständigung: Nun können Entwicklerinnen und Entwickler ihre eigenen, OpenAI-kompatiblen Modellanbieter mit der IDE verbinden.
Darüber hinaus hat JetBrains über 1300 Bugfixes und Usability-Verbesserungen umgesetzt – darunter allein 140, die Freezes und andere Performanceschwierigkeiten beheben. Details zu den Neuerungen in IntelliJ IDEA 2026.2 finden sich in den „What’s New [3]“- und „What’s Fixed [4]“-Blogeinträgen.
Neben IntelliJ IDEA stattet JetBrains auch seine weiteren spezialisierten Entwicklungsumgebungen schrittweise mit Version 2026.2 aus. Beispielsweise legt die JavaScript- und TypeScript-IDE WebStorm einen starken Fokus auf das neue TypeScript 7.0, während PhpStorm unter anderem das Aufsetzen eines PhpStorm-MCP-Servers für Terminal-AI-Sessions beschleunigt.
Die Updates in WebStorm [5], PhpStorm [6], CLion [7], GoLand [8] und dem IntelliJ-Scala-Plug-in [9] in Versionsnummer 2026.2 lassen sich den jeweiligen Blogeinträgen entnehmen.
URL dieses Artikels:
https://www.heise.de/-11369167
Links in diesem Artikel:
Copyright © 2026 Heise Medien
VMware aktualisiert seine Software.
(Bild: heise online / dmk)
VMware warnt vor zum Teil kritischen Lücken im Avi Load Balancer. Angreifer können Authentifizierung und Autorisierung umgehen.
In VMwares Avi Load Balancer haben die Entwickler mehrere Sicherheitslücken ausgebessert. Sie erreichen teils kritische Risikoeinstufungen und ermöglichen Angreifern, etwa die Authentifizierung zu umgehen.
Broadcom warnt in einer Sicherheitsmitteilung [1] vor den Schwachstellen. Die gravierendste Schwachstelle ermöglicht bösartigen Akteuren mit Netzwerkzugriff auf die Avi-Controller-Oberfläche, den Authentifizierungsmechanismus zu umgehen (CVE-2026-47865, CVSS 9.8, Risiko „kritisch“). Wie genau sie das anstellen können und wo der Fehler liegt, erörtert Broadcom jedoch nicht. Eine Directory-Traversal-Schwachstelle (CVE-2026-47871, CVSS 8.8, Risiko „hoch“) bedroht ebenso wie eine Codeschmuggel-Lücke im Avi-Controller (CVE-2026-47867, CVSS 8.7, Risiko „hoch“) die Sicherheit des Load Balancers. Angemeldete Nutzer können ebenfalls auf nicht detailliertem Weg Schadcode einschleusen und ausführen (CVE-2026-47869, CVSS 8.7, Risiko „hoch“).
Außerdem können Angreifer auf einige Einstellungen im Avi-Controller unbefugt zugreifen (CVE-2026-47866, CVSS 8.3, Risiko „hoch“). Nutzer mit lokalem Zugriff können zudem ihre Rechte ausweiten und Code als root-User ausführen (CVE-2026-47868, CVSS 7.8, Risiko „hoch“). Das gelingt auch bösartigen angemeldeten Nutzern aus dem Netz (CVE-2026-47870, CVSS 7.1, Risiko „hoch“).
Broadcoms Entwickler stellen Updates in mehreren Entwicklungszweigen bereit. Die Lücken schließen die VMware Avi Load Balancer 32.1.2, 31.2.2-2p3 und 30.2.7. Wer noch die verwundbaren Stände 22.1.1 bis 22.1.7 nutzt, soll auf 30.2.7 migrieren.
Anfang Juni hatte Broadcom mehrere Cross-Site-Scripting-Lücken etwa in VMware Cloud Foundation [2] und weiteren Produkten gemeldet. Sie haben jedoch als Risiko-Bewertung „nur“ die Stufe „hoch“ erreicht. Um sie zu schließen, haben die Entwickler dort aktualisierte Software verteilt.
URL dieses Artikels:
https://www.heise.de/-11368661
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise online / dmk)
Windows Server 2022 fällt in 90 Tagen aus dem Mainstream-Support. Erweiterte Sicherheitsupdates gibt es bis 2031 – und danach ESU.
In 90 Tagen endet der Mainstream-Support für den Windows Server 2022, wodurch er aus dem regulären Update-Raster fällt. IT-Verantwortliche müssen daher aktiv werden und eine der möglichen Optionen nutzen.
Darauf weist Microsoft aktuell im Message-Center der Windows-Release-Health-Notizen [1] hin. Das Sicherheitsupdate im Oktober 2026 wird das letzte Mainstream-Support-Update sein. Danach geht der Server 2022 in den erweiterten Support [2] – Microsoft gibt an, dass dieser Sicherheitsupdates ohne zusätzliche Kosten umfasst, die monatlich bis zum 14. Oktober 2031 ausgeliefert werden. Wer danach weiter auf den alten Server setzen möchte, kann dann im Rahmen des Erweiterten-Sicherheits-Updates-Programms (ESU) noch längere Unterstützung ausschließlich mit Sicherheitspatches erhalten – dafür fallen dann allerdings Gebühren an.
Der Unterschied zwischen Mainstream- und erweitertem Support ist demnach [3], dass Windows Server 2022 keine Design- und Funktionsänderungen mehr erhält. Auch von den Nicht-Sicherheitsupdates ist Windows Server 2022 dann ausgenommen. Im Prinzip also das, was Admins im ESU-Programm erwartet, nur ohne Rechnung daran.
Microsoft nennt Windows Server 2025 als jüngstes Server-Betriebssystem im Long-Term-Servicing-Channel (LTSC). Um weiterhin in den Genuss des vollständigen Mainstream-Supports zu gelangen, empfiehlt Microsoft Admins, die Migration auf das neuere Server-OS jetzt zu planen.
Der Windows Server 2025 erschien Anfang November 2024 [4]. Er brachte etwa Hotpatching als neues Feature mit, wodurch nur noch vier Neustarts im Jahr anfallen sollen, anstatt jeden Monat einen Reboot zu erfordern. Der Server 2025 brachte auch erstmals OpenSSH als per Mausklick aktivierbaren Dienst mit, zudem soll er etwa SMB-Freigaben robuster und sicherer bereitstellen. Der Mainstream-Support-Zeitraum läuft bis Oktober 2029, woran sich fünf Jahre erweiterte Sicherheitsupdates anschließen. Die enden somit im Oktober 2034.
URL dieses Artikels:
https://www.heise.de/-11368549
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Right-Click-Trick: Malware umgeht Startverbot.
(Bild: Jamf)
Momentan kursiert ein neuer Mac-Datenschädling, der Zugangsdaten und Kryptowährungen klauen kann. Er tarnt sich als Apple-Software.
Aktuell wird eine neuartige macOS-Malware verbreitet, die versucht, sich als Apples CrashReporter zu tarnen. Das berichtet das Sicherheitsteam des MDM-Spezialisten Jamf. Der „CrashStealer“ getaufte Datenschädling ist ein klassischer Infostealer, versucht unter anderem, Daten zahlreicher bekannter Passwortmanager, das Apple-Schlüsselbund sowie Passwörter und Infos von Krypto-Wallets auf dem Mac abzugreifen. Außerdem gibt es eine integrierte Suchroutine, so Jamf, die die Dokumente- und Download-Ordner nach „Interessantem“ durchsucht.
Die Entwickler gehen dabei recht geschickt vor: Sie verschlüsseln die geklauten Dateien mittels AES-GCM und exfiltrieren sie dann via libcurl zu einem Command-and-Control-Server. Das Vorgehen erinnert an andere bekannte macOS-Infostealer wie Atomic, die native C++-Implementierung der Malware samt der Client-seitigen Verschlüsselung machten CrashStealer aber zu einer eigenen Datenschädlingsfamilie, so Jamf. Entdeckt wurde CrashStealer in einer via Web vertriebenen App namens Werkbit, die sich Nutzern als Meeting-Werkzeug verkauft, aber nichts mit einer gleichnamigen deutschen Software für den Mittelstand zu tun hat.
Die Fake-Werkbit-App soll zunächst über ein Apple-Zertifikat verfügt haben, die entsprechende „Developer Team ID“ wurde von Apple mittlerweile jedoch deaktiviert, nachdem Jamf den Schädling gemeldet [1] hatte. Dass Malware mit einer legitimen Developer-ID [2] ausgestattet ist, passiert leider immer wieder [3]. Damit gibt es dann beim Ausführen der Software keine Warnung. Allerdings versucht der Installer auch, um diese Gatekeeper-Verifizierung herumzukommen und nutzt Social Engineering, um Nutzer dazu zu bewegen, die App per Rechtsklick auszuführen – eine Methode, die Apple immer schwerer macht. Allerdings wäre die Maßnahme hier gar nicht notwendig gewesen, da das Zertifikat ja bestand.
Um an Daten zu gelangen, installiert CrashStealer parallel noch eine falsche CrashReporter-App, die so tut, als sei sie Apples CrashReporter, der bei Abstürzen auftaucht. Beim ersten Start verlangt die Fake-Anwendung vom Nutzer, ihr vollen SSD-Zugriff zu erteilen sowie ein Administratorpasswort einzugeben. Danach wird auf das Schlüsselbund zugegriffen und der Diebstahl beginnt. Jamf warnt davor, dass die Malware insgesamt sehr „sneaky“ implementiert wurde – und schwerer erkennbar sei als übliche Infostealer. Erste Hinweise kursierten seit Mai, aktive Installationen entdeckte Jamf noch im Juli.
Über die genauen Verbreitungswege ist wenig bekannt. Denkbar ist auch, dass die Anwendung für gezielte Angriffe auf bestimmte Personen gedacht war. Das falsche Werkbit verlangte nämlich eine „Meeting-ID“ in Form einer PIN, bevor die Installation begann. Der Infektionsprozess wäre wie folgt verlaufen: Ein Opfer bekommt eine Einladung für ein Meeting samt PIN, in der zum Download aufgerufen wird. Nach der Installation beginnt dann der Diebstahl.
URL dieses Artikels:
https://www.heise.de/-11367068
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Confidential Computing schützt Daten in fremden Clouds. Wir zeigen, wie die Erweiterung auf GPUs diese Technik auch für KI-Anwendungen nutzbar macht.
KI ist in vielen Unternehmen bereits zu einem alltäglichen Werkzeug geworden: Entwickler arbeiten damit an ihrem Code, Fachabteilungen durchsuchen Dokumente, Support-Teams automatisieren Antworten und Analysten fassen große Datenmengen zusammen. Dadurch landen in KI-Systemen aber auch vielfältige Informationen, die bisher oft im eigenen Netz geblieben wären: Quellcode, Kundendaten, Geschäftsgeheimnisse und dergleichen mehr.
Wie bei klassischen Clouddiensten ergibt sich daraus ein grundsätzliches Datenschutzproblem: Man muss den KI-Betreibern vertrauen. Das ändert sich auch nicht, wenn man vertraglich festhält, was ein Anbieter mit den Daten (nicht) tun darf und etwa die Einstellungen des Systems so setzt, dass sie KI-Training auf eigenen Daten untersagen. Grundsätzlich können Servicebetreiber und Clouddienstleister Prompts, also Anfragen an die KI samt allem Kontext, und auch die Antworten einsehen – etwa weil lokale Gesetze sie dazu zwingen.
Unter dem Begriff Confidential AI, also vertrauliche KI, versteht man KI-Verarbeitung in der Cloud, die sensible Daten nicht nur vor Externen, sondern auch vor dem Serviceanbieter und dem Cloudbetreiber schützen soll. Grundlage dafür ist Confidential Computing: eine Technik, die Daten nicht nur bei der Speicherung und Übertragung schützt, sondern auch während der Verarbeitung. Apple zum Beispiel geht mit Private Cloud Compute, kurz PCC, genau diesen Weg [7] [7]. PCC soll KI-Anfragen, die zu groß oder zu komplex für das lokale Gerät sind, in der Cloud verarbeiten, ohne die klassische Vertrauensbeziehung zum Cloudbetreiber einzugehen.
URL dieses Artikels:
https://www.heise.de/-11329114
Links in diesem Artikel:
Copyright © 2026 Heise Medien
OpenAI-Chef Sam Altman: Keine E-Mail unter dieser Nummer?
(Bild: jamesonwu1972/Shutterstock.com)
Apple behauptet in seiner Klage wegen des Diebstahls von Geschäftsgeheimnissen, OpenAI habe nicht reagiert. Dort verweist man nun auf Verwechselungsprobleme.
Der Rechtsstreit zwischen Apple und OpenAI um angeblich beim iPhone-Hersteller entwendete Geschäftsgeheimnisse [1] hat offenbar auch damit zu tun, dass eine Einigung vor Einschaltung der Gerichte aufgrund von Tippfehlern scheiterte. Das berichtet der US-Nachrichtensender NBC News. In seiner Klage [2] behauptet Apple unter anderem, dass der Konzern von OpenAI keine Antwort auf anwaltliche Beschwerden erhalten habe. Doch offenbar hat einer von Apples externen Rechtsberatern dabei in E-Mails zwei Personen (sowie deren Adressen) verwechselt, sodass es OpenAI nicht möglich gewesen sein soll, adäquat zu reagieren.
Die Schreiben aus anonymer – vermutlichen OpenAI-naher – Quelle liegen NBC News [3] vor. Apples Anwalt hat darin offenbar die Namen „Chang“ und „Wang“ verwechselt, was man bei OpenAI dann nicht zuordnen konnte. Der korrekte Name der Person ist Chang Liu, ein ehemaliger Ingenieur bei Apple, der auch nach Abgang und Anheuern bei OpenAI weiter Kontakte zu mindestens einer Mitarbeiterin des iPhone-Konzerns gehalten haben soll.
Liu teilte dieser Person, die mittlerweile selbst bei OpenAI arbeitet, mit, Apple habe eine Lücke in einem Fileserver gelassen – über diesen sollen laut Apple dann Daten abgeflossen sein. „LOL, ich habe herausgefunden, dass ich auf [den Netzwerkspeicher] zugreifen kann, das ist so lustig“, schrieb Liu demnach. Präsentationen, Hardware-Designs, Testprozeduren und Herstellungsdetails seien daraufhin heruntergeladen worden, wie Apples Sicherheitsabteilung herausgefunden haben will. Liu wurde, ebenso wie OpenAI-Hardware-Chef Tan Tang (ebenfalls Ex-Apple) und OpenAI selbst, von Apple persönlich verklagt.
Laut NBC News sollen OpenAI und Apple zunächst über die Vorwürfe kommuniziert haben. Doch nach den Namensfehlern wurde die Verbindung (offenbar durch OpenAI) gekappt. Apple hat sich laut Bericht bereits im Februar bei OpenAI gemeldet. Nach dem Ende der Kommunikation kam es dann zur Einreichung der Klage. Ob Apples Fehler nun Auswirkungen darauf haben werden, ist unklar. Der Konzern möchte nicht nur Schadenersatz von der KI-Firma, sondern auch erreichen, dass OpenAI seine Geschäftsgeheimnisse nicht für eigene Produkte verwenden kann.
Über 400 ehemalige Apple-Mitarbeiter – vom höheren Management [4] bis hin zu diversen Hard- und Software-Experten – wurden von OpenAI angelockt, standardmäßig mit lukrativen Gehältern und Aktienoptionen. Laut Apples Klage versuchten OpenAI-Mitarbeiter bereits in Bewerbungsgesprächen, Informationen der Apple-Mitarbeiter zu erhalten. Angeblich wurde gar vorgeschlagen, Prototypen und Bauteile mitzubringen.
Der Rechtsstreit könnte sich Beobachtern zufolge über mehrere Jahre ziehen. OpenAI plant, seine ersten Hardware-Produkte, darunter einen smarten Lautsprecher [5] und später wohl auch ein eigenes Handy, in diesem oder kommenden Jahr vorzustellen. Apples Klage könnte das Projekt nun ausbremsen – auch weil Mitarbeiter fürchten, in den Rechtsstreit verwickelt zu werden. Zudem dürfte es OpenAI schwerer fallen, weitere Apple-Mitarbeiter anzuwerben und Partner in der Lieferkette zu finden. Auch die bislang recht sorglose Managementkultur könnte sich ändern, schreibt Bloomberg [6]. Bei OpenAI ist auch Apples Ex-Designchef Jony Ive tätig [7], der viele Mitarbeiter von Apple anlocken konnte.
URL dieses Artikels:
https://www.heise.de/-11367416
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Meta-Brille: Bald „First class“ auf dem iPhone dank EU?
(Bild: JLStock/Shutterstock.com)
Ähnlich wie AirPods und andere Apple-Produkte sollen auch Zubehöranbieter mit dem iPhone kommunizieren. Zu Metas Brillen und VR-Headsets gibt es nun neue Infos.
Auf einer nur für Entwickler zugänglichen Seite stellt Apple Informationen zur Verfügung, wie Hardware von Meta künftig mit iPhone und iPad interagieren sollen. Apple ist aufgrund der Regulierung durch den Digital Markets Act (DMA) [1] gezwungen, Third-Party-Geräte ähnlich gut an seine zwei regulierten Gerätefamilien anzubinden, wie dies bereits bei eigenen Produkten wie AirPods, Airtags oder der Apple Watch der Fall ist. Die Pläne dürften bis zum kommenden Jahr umgesetzt werden. Explizit benannt sind die VR-Headset-Serie Meta Quest sowie die Brillen der Meta-Ray-Ban-Glasses-Serie. Die Seite „Interoperability Requests in the EU“ für Entwickler ist nur mit einem Developer-Account zugänglich.
Meta wünscht sich [2] (Developer-Account erforderlich) explizit, dass User Meta-Hardware direkt pairen und dieses Pairing dann auch auf anderen im Besitz befindlichen iPhones und iPads automatisch nutzen kann – und zwar durch „die Koordination über Metas eigene Cloud-Dienste“. Die Bitte der Facebook-Mutterfirma kam Ende Oktober 2025, Apple reagierte einige Tage später mit einem „Eligibility Review“.
Aktueller Stand der Dinge ist, dass die Entwicklungsarbeiten bei Apple noch bis iOS 27 und iPadOS 27 dauern. Allerdings noch nicht in den ersten, ab Herbst zur Verfügung stehenden Versionen. Stattdessen nennt Apple einen Zeitraum im Frühjahr 2027 – mit welcher Version ist noch unklar. Dann sollen Third-Party-Anwendungen Zugriff auf das notwendige kryptografische Material erhalten, um ein Pairing abzusichern. „Apple entwickelt derzeit ein Protokoll, mit dem ein Apple-Gerät einen sicheren Sitzungsschlüssel ableiten kann, der zur Authentifizierung und Verschlüsselung der Übertragungsverbindung zwischen dem Apple-Gerät und einem Zubehörteil eines Drittanbieters dient.“
Die Synchronisation mit anderen Apple-Geräten ist dabei vorgesehen – ob tatsächlich über die Cloud des jeweiligen Herstellers, bleibt offenbar abzuwarten. Meta meldete sich zuletzt im März bei Apples Entwicklerteam. Dabei ging es um die Frage, ob das notwendige AccessorySetupKit (ASK) von Apple den ganzen Bildschirm übernehmen muss oder nicht. Meta hätte hier gerne eine einfachere Lösung – den direkten Start der eigenen App.
Unterdessen gibt es Neuigkeiten in Sachen DMA-Öffnung von KI-Systemen: Google wird von der EU nun gezwungen, sein Android-Betriebssystem vollständig für Assistenten eigener Hersteller zugänglich [3] zu machen. Apple versucht derzeit, genau dies zu verhindern und hat deshalb auch Siri AI zunächst nicht in die EU [4] gebracht.
URL dieses Artikels:
https://www.heise.de/-11367394
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Tap-to-Pay-Funktion mit dem iPhone.
(Bild: Apple)
Lange setzte Apple sogar bei Apple Pay in seinen Stores auf Bezahlterminals. Nun wechselt das Unternehmen auf interne Technik.
Dogfooding nennt man es, wenn ein Unternehmen Technik, die man seiner Kundschaft anbietet, auch selbst einsetzt. Apple versucht das nun bei seinem Tap-to-Pay-Bezahlsystem [1], das schon seit mehreren Jahren auf iPhones ab dem Modell X zur Verfügung steht. Laut einem Bericht werden bisherige Bluetooth-Terminals und andere Sonderlocken-Hardware innerhalb der Ladenkette des Konzerns aussortiert. Kunden sollen direkt im Apple Retail Store am Handy des Mitarbeiters via NFC-Kreditkarte sowie anderen NFC-Verfahren wie Apple Pay bezahlen können. Teilweise ist das bereits umgesetzt, nun erfolgt ein flächendeckender Rollout, schreibt die Finanznachrichtenagentur Bloomberg.
Tap-to-Pay gibt es in Deutschland bereits seit 2024 [2]. Apple arbeitet dazu mit verschiedenen Bezahldiensten zusammen. Der in iPhones integrierte NFC-Kartenchip wird dabei zum Auslesen von Karten genutzt, die Buchung direkt über eine Zahlungsanbieter-App abgewickelt. Unternehmen, die das anbieten [3], sind SumUp, viva.com, die Sparkassen oder MyPOS. Händler müssen mit diesen einen Vertrag schließen und zahlen dann prozentuale Gebühren, teilweise auch Monatstarife.
Für Endkunden ohne geschäftliche Basis ist die Funktion allerdings nicht gedacht, man kann also nicht einfach ein Konto eröffnen, um dann von Freunden Kreditkartenzahlungen zu akzeptieren. Dennoch ist die Funktion nützlich, da man zuvor stets ein angebundenes Kartenterminal eines externen Anbieters benötigt hatte, wie es auch Apple einsetzte.
Zwar begann die Umstellung auf Tap-to-Pay in Apples Ladengeschäften [4] bereits vor einigen Jahren, doch das dabei verwendete iPhone 14 machte manchmal Probleme, so dass die Terminals weiterhin mitgeführt wurden. Der Grund: Die Geräte sollen Probleme mit Kreditkarten aus Metall gehabt haben, beispielsweise die Platin-Karten von American Express. Diese waren teilweise gar nicht lesbar.
Hinzu kam, dass man die Stelle des NFC-Lesers genau treffen musste, ein Problem, das Nutzer etwa auch von Tools wie der AusweisApp [5] (und dem oben angebrachten RFID-Leser) kennen. Neuere Modelle wie das iPhone 16 lesen allerdings zuverlässiger und sollen auch mit Metallkarten zurechtkommen. Das sei der Grund, warum Apple nun die externen Terminals ausrangiere, schreibt Bloomberg [6].
URL dieses Artikels:
https://www.heise.de/-11367380
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Manuel Masiero / KI / iX)
100 Prozent Code Coverage und alle Tests grün geben kein verlässliches Korrektheitsurteil. Hinter dieser Beobachtung steckt mehr als nur Pech.
Geht es um Codequalität, ist die Code Coverage eine besonders verführerische Metrik. Sie ist leicht zu erheben, in Pipelines durchzusetzen und scheint auf den ersten Blick eine objektive Aussage darüber zu treffen, wie gründlich ein System getestet ist. Bei näherer Betrachtung zeigt sich aber, dass das Testen selbst an fundamentale Grenzen stößt, an denen auch die ausgefeilteste Coverage-Messung nichts ändern kann. Das Halteproblem aus Teil 2 [1] spielt dabei eine neue Rolle und wie wir in Teil 3 [2] gesehen haben, lässt sich Codequalität ohnehin nicht in eine einzige Zahl pressen.
Vor einigen Jahren entwickelte ein Entwicklungsteam meines Unternehmens eine Implementierung des Chord-Algorithmus [3], eines klassischen Verfahrens für strukturierte Peer-to-Peer-Netzwerke. Chord organisiert die teilnehmenden Knoten in einem virtuellen Ring und erlaubt es, Key-Value-Paare effizient zu speichern und wiederzufinden, auch wenn Knoten kommen und gehen. Das Team arbeitete sorgfältig: Alle Unit-Tests waren grün, die Code Coverage lag bei 100 Prozent.
Trotzdem hatte die Implementierung einen Bug. Wurde ein Knoten im laufenden Netzwerk abgeschossen, stürzten die übrigen Knoten dominoartig ab. Das Problem lag nicht im Code eines einzelnen Knotens, sondern im Zusammenspiel mehrerer Knoten. Bestimmte Konstellationen, in denen Nachrichten zwischen Knoten in einer ungünstigen Reihenfolge eintrafen, führten zu logischen Widersprüchen, die beim Betrachten eines einzelnen Knotens nicht erkennbar waren. Die Tests deckten jede einzelne Funktion vollständig ab, aber sie testeten nicht das, was am Ende den Ausfall verursachte.
Diese Erfahrung steht stellvertretend für ein viel allgemeineres Phänomen. Tests können viele Bugs finden, aber sie können nicht garantieren, dass keine mehr da sind. Und das ist nicht nur eine pragmatische Einschränkung, sondern hat tiefer liegende Ursachen.
Code Coverage misst, wie viel Prozent des Codes durch Tests ausgeführt werden. Eine Zeile, die mindestens einmal im Rahmen eines Tests durchlaufen wird, gilt als abgedeckt. Das klingt zunächst sinnvoll, denn nicht ausgeführter Code ist mit Sicherheit nicht getestet. Die Umkehrung gilt aber nicht: Ausgeführter Code ist nicht automatisch geprüfter Code.
Ein einfaches Beispiel zeigt das Problem. Eine Funktion gibt eine Liste sortiert zurück. Ein Test ruft diese Funktion mit einer beliebigen Liste auf, prüft aber nicht das Ergebnis. Die Coverage-Messung stellt fest, dass alle Zeilen der Funktion durchlaufen wurden, und meldet 100 Prozent Abdeckung. Trotzdem hätte die Funktion auch eine zufällige Permutation zurückgeben können, ohne dass der Test es bemerkt hätte. Coverage misst Ausführung, nicht Verifikation.
Doch selbst wenn die Tests ihre Ausgaben gewissenhaft prüfen, bleibt eine zweite Lücke. Coverage misst die Strukturen des Codes, nicht die Interaktionen zwischen Komponenten. Im Chord-Beispiel waren die einzelnen Funktionen jedes Knotens vollständig abgedeckt, aber das Zusammenspiel mehrerer Knoten in spezifischen zeitlichen Konstellationen war es nicht. Was Coverage nicht erfasst, ist die kombinatorische Explosion der möglichen Reihenfolgen, in denen Nachrichten ausgetauscht werden, in denen Threads parallel laufen, in denen Knoten verbunden oder getrennt sind. Eine Coverage von 100 Prozent ist deshalb keine Aussage über die Korrektheit des Systems, sondern eine Aussage darüber, dass kein Code übersehen wurde.
Diese strukturelle Asymmetrie zwischen Tests und Korrektheit hat Edsger Dijkstra bereits 1969 auf einer NATO-Konferenz zur Softwaretechnik in einem inzwischen berühmten Satz auf den Punkt gebracht: Testing shows the presence, not the absence of bugs [9]. Wenig später formulierte er die ausführlichere Variante in seinen „Notes on Structured Programming“: Programmtests können benutzt werden, um die Anwesenheit von Fehlern zu zeigen, niemals aber deren Abwesenheit.
Die Aussage klingt banal, hat aber weitreichende Konsequenzen. Ein Test, der einen Bug findet, beweist die Existenz dieses Bugs. Ein Test, der keinen Bug findet, beweist nichts darüber, ob weitere Bugs existieren. Die übliche Beweisstruktur in den Naturwissenschaften, dass das Ausbleiben eines Gegenbeispiels die Hypothese stützt, gilt hier nur in sehr eingeschränktem Sinne. Solange nicht alle möglichen Eingaben und Zustände durchgetestet wurden, bleibt jeder Bereich eine potenzielle Fehlerquelle. Und alle möglichen Eingaben und Zustände durchzutesten, ist in praktisch jedem nicht-trivialen Programm aussichtslos.
Schon einfache Funktionen haben mehr mögliche Eingabekombinationen, als sich vollständig durchprobieren lassen. Eine Funktion, die drei Ganzzahlen mit jeweils 32 Bit entgegennimmt, hat 2 hoch 96 mögliche Eingabekombinationen, ungefähr 80 Quadrillionen. Selbst bei einer Milliarde Tests pro Sekunde würde es mehr als zwei Billionen Jahre dauern, alle Kombinationen zu testen, ein Vielfaches des Alters des Universums. Und das ist eine triviale Funktion. Sobald Strings, Listen oder beliebige Objekte als Eingaben hinzukommen, wird der Eingaberaum buchstäblich unendlich groß.
Dieses Phänomen wird als Zustandsraumexplosion bezeichnet. Bei zustandsbehafteten Programmen, also fast jedem realen System, kommt eine weitere Dimension hinzu: Das Verhalten hängt nicht nur von der aktuellen Eingabe ab, sondern auch vom internen Zustand, der wiederum durch frühere Eingaben geprägt ist. Eine Webanwendung mit zwanzig Sessions, jeweils mit unterschiedlich gesetzten Variablen, hat einen Zustandsraum, der sich nicht mehr sinnvoll überschauen lässt. Bei verteilten Systemen wie im Chord-Beispiel multipliziert sich der Zustandsraum eines einzelnen Knotens mit der Anzahl der Knoten und ihrer möglichen Kommunikationsmuster. Was beim Einzelknoten noch handhabbar wirkte, wird im Verbund unbeherrschbar.
Die übliche Antwort auf dieses Problem heißt Äquivalenzklassen. Statt jede Eingabe einzeln zu testen, werden Eingaben in Klassen zusammengefasst, die aus Sicht des Programms gleich behandelt werden sollten. Statt alle ganzen Zahlen zu testen, reichen ein typischer positiver Wert, ein typischer negativer Wert, die Null und die Grenzwerte. Das ist pragmatisch und meistens ausreichend, aber es setzt voraus, dass die Klassenbildung korrekt ist, dass also alle relevanten Fälle erkannt wurden. Genau hier liegen viele Bugs verborgen: in den Fällen, deren Eigenständigkeit niemand erkannt hat.
Selbst wenn sich der Eingaberaum vollständig durchprobieren ließe, bliebe eine zweite, oft übersehene Frage. Woher weiß ein Test, was die richtige Ausgabe ist? Diese Frage ist als Orakel-Problem in der Testtheorie bekannt. Ein Test besteht im Kern aus zwei Teilen: einer Eingabe und einer Erwartung an die Ausgabe. Die Eingabe lässt sich automatisch generieren, die Erwartung im Allgemeinen nicht.
Bei mathematischen Funktionen mag das Orakel offensichtlich sein. Eine Sortierfunktion soll eine sortierte Liste liefern, das lässt sich prüfen. Eine Quadratwurzel soll eine Zahl liefern, die mit sich selbst multipliziert die Eingabe ergibt. Bei realen Anwendungen ist die Lage komplizierter. Was ist die richtige Antwort einer Suchmaschine auf eine bestimmte Anfrage? Was ist die richtige Reihenfolge in einem Newsfeed? Was ist die richtige Empfehlung in einem Webshop? In all diesen Fällen gibt es kein objektives Orakel, sondern nur Heuristiken, Spezifikationen, Geschäftsregeln, manchmal nur menschliches Urteil. Tests können diese Orakel approximieren, aber sie sind selbst eine Quelle möglicher Fehler.
Im Chord-Beispiel zeigt sich das Orakel-Problem in einer besonders perfiden Variante. Die einzelnen Funktionen jedes Knotens hatten klar definierte Erwartungen, und die Tests prüften diese Erwartungen korrekt. Aber das richtige Verhalten des Systems beim Ausfall eines Knotens war nirgendwo als Orakel formuliert, weil niemand explizit darüber nachgedacht hatte. Tests können nur prüfen, was jemand vorher als Erwartung formuliert hat. Was niemand erwartet, kann auch niemand testen.
Aus Teil 2 dieser Serie [12] ist das Halteproblem [13] bereits bekannt: Alan Turing hat 1936 bewiesen, dass es kein allgemeines Verfahren geben kann, das für ein beliebiges Programm und eine beliebige Eingabe entscheidet, ob das Programm terminiert oder in eine Endlosschleife gerät. Im Kontext des Testens taucht dieses Resultat in einer subtileren Variante auf.
Wenn ein Test einen Code aufruft, dann muss die Test-Infrastruktur entscheiden, wann sie diesen Aufruf abbricht. Bleibt das Programm einfach hängen, läuft auch der Test ewig. Das übliche Mittel ist ein Timeout: Nach einer bestimmten Zeit gilt der Test als fehlgeschlagen. Dieses Vorgehen ist eine Heuristik, kein Beweis. Ein Test mit Timeout kann nicht zwischen einem Programm, das in einer Endlosschleife steckt, und einem Programm, das einfach nur sehr lange braucht, unterscheiden. Beide werden gleichermaßen als Fehler gemeldet, oder beide als Erfolg, je nach Konfiguration. Die fundamentale Unentscheidbarkeit des Halteproblems schlägt hier auf eine ganz praktische Frage durch: Wie lange darf ein Test laufen, bevor er als gescheitert gilt?
Eine verwandte Konsequenz betrifft die Generierung von Tests. Werkzeuge, die Tests automatisch erzeugen wollen, müssen entscheiden, welche Pfade durch den Code überhaupt erreichbar sind. Diese Entscheidung ist im Allgemeinen ebenfalls unentscheidbar, was aus Rice’s Theorem [14] folgt, das bereits in Teil 2 eine Rolle spielte. Praktische Werkzeuge nähern sich dem mit Heuristiken an, aber sie können nicht garantieren, alle relevanten Pfade zu finden.
Trotz dieser fundamentalen Grenzen gibt es Verfahren, die deutlich mehr leisten als klassisches Beispiel-basiertes Unit-Testing. Sie verfolgen unterschiedliche Strategien, um den Eingaberaum strukturiert zu erschließen, auch wenn er sich nicht vollständig durchprobieren lässt.
Beim Property-based Testing [15] werden nicht einzelne Beispiele getestet, sondern Eigenschaften, die für alle Eingaben gelten sollen. Statt zu prüfen, dass das Sortieren der Liste [3, 1, 2] das Ergebnis [1, 2, 3] liefert, wird die Eigenschaft formuliert, dass das Ergebnis einer Sortierung dieselben Elemente enthält wie die Eingabe und in aufsteigender Reihenfolge vorliegt. Das System generiert dann automatisch eine große Zahl zufälliger Eingaben und prüft die Eigenschaft. Wird ein Gegenbeispiel gefunden, versucht das Werkzeug, es zu einem minimalen Fall zu reduzieren, der den Bug noch zeigt. Property-based Testing wurde mit dem Werkzeug QuickCheck für Haskell [16] populär und ist inzwischen für viele Programmiersprachen verfügbar.
Beim Fuzzing [17] wird das System mit zufällig generierten oder mutierten Eingaben bombardiert, oft mit dem Ziel, Abstürze, Sicherheitslücken oder unerwartete Zustände zu finden. Moderne Fuzzer nutzen Coverage-Informationen, um Eingaben zu bevorzugen, die neue Codepfade auslösen, und arbeiten sich auf dem Weg systematisch in den Eingaberaum vor. Fuzzing hat zahlreiche schwerwiegende Bugs in weitverbreiteten Bibliotheken aufgedeckt, etwa in Browsern, Bildverarbeitungs-Bibliotheken und Kryptographie-Implementierungen.
Beim Mutation Testing [18] schließlich werden nicht die Programme, sondern die Tests selbst getestet. Das Werkzeug nimmt kleine Änderungen am Quellcode vor, etwa wird ein Plus zu einem Minus, ein Größer-als zu einem Kleiner-als, eine Bedingung negiert. Anschließend werden die Tests gegen den derart mutierten Code laufen gelassen. Wenn die Tests die Mutation nicht bemerken, ist das ein Hinweis darauf, dass die Tests die betroffene Stelle nicht wirklich prüfen, sondern den Code nur durchlaufen lassen. Mutation Testing schließt damit genau die Lücke, die Coverage offenlässt: Es misst nicht, ob Code ausgeführt wurde, sondern ob seine Korrektheit tatsächlich überprüft wird.
All diese Verfahren erweitern die Möglichkeiten des Testens erheblich. Aber keines von ihnen löst das fundamentale Problem. Property-based Testing kann unendlich viele Eingaben nicht in endlicher Zeit prüfen, sondern nur stichprobenartig. Fuzzing findet viele Bugs, aber nicht alle. Mutation Testing prüft die Tests, aber das Orakel-Problem bleibt. Die Verfahren machen Tests besser, aber sie heben die Grenzen nicht auf.
Der Weg vom Chord-Beispiel über Code Coverage, Dijkstras Bonmot, Zustandsraumexplosion, Orakel-Problem und Halteproblem zeigt eine durchgängige Linie. Tests können niemals beweisen, dass ein Programm korrekt ist. Sie können nur Vertrauen aufbauen. Dieses Vertrauen ist nicht wertlos, im Gegenteil: Es ist der pragmatische Ausweg aus einer Reihe theoretischer Unmöglichkeiten. Aber es darf nicht mit einem Beweis verwechselt werden.
Was diese Einsicht in der Praxis bedeutet, lässt sich in wenige Punkte fassen. Tests sollten so geschrieben werden, dass sie aussagekräftige Eigenschaften prüfen, nicht nur Code zur Ausführung bringen. Eine hohe Coverage ist ein notwendiges, aber kein hinreichendes Kriterium für gute Tests. Verschiedene Testarten ergänzen sich, denn Unit-Tests, Integrationstests, End-to-End-Tests, Property-based Tests und Fuzzing decken jeweils unterschiedliche Klassen von Fehlern ab. Und vor allem: Wenn ein System produktiv geht, sollte das Vertrauen in die Tests durch Mechanismen ergänzt werden, die mit den verbleibenden Fehlern umgehen können. Monitoring, Observability, Circuit Breaker, Rollback-Strategien und Chaos Engineering sind keine Eingeständnisse mangelnder Testqualität, sondern Ausdruck der Einsicht, dass Tests allein nicht reichen können.
Im Chord-Beispiel war die Lehre genau diese: Die Tests selbst waren nicht falsch, sie hatten nur einen anderen Geltungsbereich als das Team angenommen hatte. Erst der Betrieb mit mehreren Knoten und gezielt herbeigeführten Ausfällen brachte das Problem zutage. Das ist kein Versagen des Testens, sondern eine Konsequenz seiner prinzipiellen Grenzen.
Eine andere Klasse von Grenzen, die in dieser Serie noch nicht behandelt wurde, betrifft nicht die Entscheidbarkeit, sondern die Effizienz. Es gibt Probleme, die theoretisch lösbar sind, für die aber kein praktikabler Algorithmus bekannt ist. Im nächsten Teil geht es um eine der wichtigsten offenen Fragen der theoretischen Informatik, die zugleich eine sehr konkrete Bedeutung für den Alltag von Entwicklerinnen und Entwicklern hat: P versus NP.
URL dieses Artikels:
https://www.heise.de/-11355919
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Pincasso / Shutterstock.com)
Die neue Methode FindByThumbprint() sucht ein digitales Zertifikat anhand des SHA-Fingerabdrucks.
In der Klasse X509Certificate2Collection existiert eine neue Methode FindByThumbprint(), um ein digitales Zertifikat anhand des SHA-Fingerabdrucks mit einem bestimmten SHA-Algorithmus zu finden.
Bisher gab es zur Suche nach Zertifikatsfingerabdrücken die Methode Find():
X509Certificate2Collection coll =
store.Certificates.Find(X509FindType.FindByThumbprint, thumbprint, false);Diese Methode hat immer nach Fingerabdrücken mit dem SHA-1-Algorithmus gesucht. Da SHA-2-256 (SHA256) und SHA-3-256 die gleiche Länge haben, bestand Verwechselungsgefahr. Das löst nun die neue Methode FindByThumbprint(), in der man den SHA-Algorithmus angeben kann.
Folgender Beispielcode zeigt den Einsatz von FindByThumbprint():
public void SearchCertificateByFingerprint()
{
CUI.Demo(nameof(SearchCertificateByFingerprint));
CUI.H2("Zertifikat suchen im Store");
string thumbprint = "B9749C08E0D33C5643B7DE067A0B365870B9A9A9";
X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
// Alt: Sucht immer nach SHA1-Thumbprint
//X509Certificate2Collection coll = store.Certificates.Find(X509FindType.FindByThumbprint, thumbprint, false);
// neu: Auswahl des Hash-Algorithmus
X509Certificate2Collection coll = store.Certificates.FindByThumbprint(HashAlgorithmName.SHA256, thumbprint);
if (coll.Count == 0)
{
CUI.Warning($"Zertifikat mit Thumbprint {thumbprint} nicht gefunden.");
}
foreach (var item in coll)
{
Console.WriteLine(item.IssuerName.Name + ": " + item.Thumbprint + " -> " + item.SignatureAlgorithm.FriendlyName);
}
}
URL dieses Artikels:
https://www.heise.de/-11368310
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Christian Horz/ Shutterstock.com)
Trügerische Wahlfreiheit: Das GModG streicht Vorgaben, baut aber eine potenzielle Kostenfalle auf. Was die Gasheizung in den kommenden Jahren teuer macht.
Nach monatelangem Hickhack haben Bundestag und Bundesrat das Gebäudemodernisierungsgesetz (GModG) Anfang Juli 2026 verabschiedet. Die verpflichtende 65-Prozent-Vorgabe für erneuerbare Energien entfällt – künftig darf man also auch wieder klassische Gas- und Ölheizungen einbauen.
Ganz ohne Vorgaben kommen aber auch die nicht davon: Über die sogenannte Biotreppe muss dem Gas ab 2029 schrittweise ein steigender Anteil Biokraftstoffe beigemischt werden. Für Hauseigentümer klingt das zunächst nach einem pragmatischen Mittelweg zwischen Klimaschutz und Wahlfreiheit – oder wie die Bundesregierung es nennt – Technologieoffenheit.
Wie teuer dieser „Pragmatismus“ über 20 Jahre werden könnte – im Vergleich zu Wärmepumpe und Fernwärme – und welche Entwicklungen die Kosten einer fossilen Heizung künftig noch stärker beeinflussen könnten, zeigt dieser Artikel anhand der Gasheizung und Biomethan.
URL dieses Artikels:
https://www.heise.de/-11348650
Links in diesem Artikel:
Copyright © 2026 Heise Medien
TSMCs Komplex im US-amerikanischen Arizona. Drumherum ist reichlich Platz für weitere Werke vorhanden.
(Bild: Taiwan Semiconductor Manufacturing Co., Ltd.)
Der Weltmarktführer TSMC will weitere Halbleiterwerke in den USA bauen. Dafür stehen weitere 100 Milliarden US-Dollar bereit.
Der weltweit größte Chipauftragsfertiger TSMC erhöht die Investitionen in den USA ein weiteres Mal: von zuletzt geplanten 165 Milliarden US-Dollar auf nunmehr bis zu 265 Milliarden. Dafür will das Unternehmen mehrere Halbleiterwerke zur Herstellung von Chips sowie Packaging-Werke zur weiteren Verarbeitung bauen.
Die Ankündigung erfolgte im Rahmen der Analystenkonferenz zu den jüngsten Geschäftszahlen (Transkript bei Seeking Alpha [1]). TSMC-Chef C.C. Wei hielt sich zum genauen Umfang und dem Zeitrahmen aber bedeckt. Denkbar wären etwa vier weitere Werke, sagte er.
Ein Blick auf TSMCs Kapitalausgaben (Capital Expenditures, Capex) zeigt, wie lange sich die Investitionen hinziehen können: Jüngst hat die Firma das Capex-Budget fürs Jahr 2026 auf 60 Milliarden bis 64 Milliarden US-Dollar erhöht. Neben den US-Werken entstehen aber auch 13 neue in Taiwan, ein neues in Japan und auch das ESMC-Werk in Deutschland [2] ist noch nicht fertiggestellt, ebenso laufen noch andere Bauprojekte in den USA.
Bisher hat TSMC ein erstes Halbleiterwerk in Phoenix, Arizona, fertiggestellt, in dem Chips aus der 4-Nanometer-Generation vom Band laufen. AMD etwa lässt dort Epyc-Serverprozessoren herstellen [3] und Nvidia Blackwell-Beschleuniger. Für Apple ist dieses Werk wenig geeignet; in Taiwan produziert TSMC für Apple dieses Jahr bereits Prozessoren mit 2-nm-Technik.
Ein zweites Halbleiterwerk für 3- und 2-nm-Chips [4] befindet sich derzeit am selben Standort im Bau und soll ab 2028 den Betrieb aufnehmen. Im April 2024 kündigte TSMC drei weitere Halbleiterwerke [5] für Arizona an. Im März 2025 folgte eine weitere Ankündigung mit zusätzlichen Halbleiterwerken [6], ersten eigenen US-Packaging-Standorten und einem Forschungszentrum.
TSMC plant sogenanntes Advanced Packaging in den USA, bei dem mehrere Chiplets und Speicherstapel auf einem gemeinsamen Träger verheiratet werden. Bisher hat TSMC diese Weiterverarbeitung in den USA lokalen Partnern wie Amkor überlassen.
Die neu angekündigten Halbleiterwerke dürften für 2030 oder später gedacht sein. Vermutlich wird TSMC auch da nicht seine modernste Fertigungstechnik in die USA bringen. Wei ließ sich nur auf „2 Nanometer oder besser“ festnageln, nicht aber auf eine feste Zusage neuerer Technik. In Taiwan will TSMC 2029 mit A13 und A12 mehr als eine Fertigungsgeneration weiter sein.
„Ich gehe davon aus, dass die Nachfrage von heute an – wahrscheinlich bis 2029 oder 2030 – sehr stark sein wird“, sagte Wei. „Ob es zwischendurch zu einem Rückgang kommen wird oder nicht, weiß ich nicht so genau. Aber der Trend deutet meiner Meinung nach darauf hin, dass wir Zeugen einer Art neuer Industrie werden, einer neuen KI-Industrie.“
URL dieses Artikels:
https://www.heise.de/-11367592
Links in diesem Artikel:
Copyright © 2026 Heise Medien
iOS 27: Viele kleine nützliche Neuerungen.
(Bild: Apple)
iOS 27, iPadOS 27, macOS 27 und Co. stehen zum Download bereit, wenn auch nur als öffentliche Beta. Ein Überblick der verwendbaren Geräte – und wichtige Tipps.
Die seit dieser Woche verfügbaren Public Betas von iOS 27, iPadOS 27, macOS 27, watchOS 27, tvOS 27, visionOS 27 sowie der neuen HomePod Software 27 [1] (plus Beta-Firmware für AirPods) verlocken zahlreiche Interessierte, Apples Vorabversionen zu installieren. Einen Hands-on-Bericht dazu lesen Sie hier. [2] Doch bevor man damit loslegt, sollte man sich sein Vorgehen gut überlegen. Läuft die Beta überhaupt auf meinem Gerät? Habe ich eine Test-Hardware, die ich verwenden kann? Mit welchen Daten sollte ich testen? Und wie werde ich die Beta später gegebenenfalls wieder los? Ein Überblick zu den wichtigsten Fragen.
Beim iPhone geht es bei Generation 11 beziehungsweise SE der dritten Generation los. Beim iPad Pro sind es alle 11-Zoll-Modelle ab der 2. Generation, alle 12,9-Zoll-Modelle ab der 4. Generation, alle iPad-Air-Geräte ab Generation 4, das Standard-iPad ab Generation 9 und das iPad mini ab Generation 6. Beim Mac muss es eine Maschine mit Apple Silicon [3] sein, Intel-Macs sind raus. Die Apple Watch benötigt mindestens Series 9, SE 3 oder Ultra 2 [4], beim Apple TV geht es ab der zweiten Version des 4K-Modells (von 2021) los. visionOS-Geräte werden vollständig unterstützt (M2 und M5).
Grundsätzlich gilt, dass man keinesfalls Produktivgeräte nutzen sollte, so verlockend das auch erscheinen mag. Betas können Datenverluste erzeugen [5] und andere Probleme bereiten, die man auf der täglich in Verwendung befindlichen Hardware nicht sehen möchte. Am sichersten ist es daher, ein eigenes Betagerät aufzusetzen, etwa ein älteres iPhone oder einen älteren Mac. Wer gänzlich auf Nummer sicher gehen will, nutzt für die Beta einen eigenen Apple-Account, um iCloud-Probleme [6] zu vermeiden. Ein Nachteil ist bei alledem, dass man Siri AI [7] dann nicht mit Echtdaten ausprobieren kann. Es ist aber leicht, sich Informationen von seinem Produktivgerät auf die Test-Hardware zu kopieren.
Vor jeglicher Installation eines neuen Betriebssystems sollte stets ein aktuelles Backup angelegt werden, auf dem iPhone am besten verschlüsselt [8] über den Mac, auf dem Mac etwa via Time Machine oder Werkzeuge wie Carbon Copy Cloner [9]. Setzen Sie für die Public Beta ein Testgerät neu auf, was Sie, wie erwähnt, tun sollten, ist das nicht unbedingt notwendig, kann aber dennoch sinnvoll sein.
Wenn Sie, wie oben empfohlen, mit einem Testgerät arbeiten, müssen Sie die Beta nicht löschen. Sie können einfach den gesamten Betazyklus durchlaufen, bis dann (wahrscheinlich) im September die jeweilige Finalversion vorliegt, die auch auf Produktivhardware landen darf. Sobald sich die Finalversion ankündigt, schalten Sie den Bezug der Betaversion in den Systemeinstellungen einfach ab. Sollten Sie wirklich ein Downgrade vornehmen wollen, lässt sich dafür auf iPhone und iPad der Wiederherstellungsmodus über einen Mac oder PC mit anschließendem Einspielen des Backups [10] verwenden. Ähnlich läuft es am Mac [11], hier gibt es einen eigenen Wiederherstellungsmodus auf dem Gerät selbst. Eine Apple Watch wird über die Apple-Watch-App auf dem iPhone wiederhergestellt, Hinweise zur Wiederherstellung von Apple-TV-Geräten listet Apple hier [12]. Der Prozess ist jeweils langwierig – nicht nur die Wiederherstellung, sondern auch das Einspielen des Backups. Das führt uns erneut zur Empfehlung, für Public Betas ein eigenes Testgerät zu verwenden.
URL dieses Artikels:
https://www.heise.de/-11364187
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Pincasso / Shutterstock.com)
Neben mehr Einsatzgebieten für Discriminated Unions bietet die Preview weitere Möglichkeiten zur asynchronen Validierung und Neues für die Prozessverwaltung.
Union Types, die C#-Implementierung von Discriminated Unions mit dem neuen Schlüsselwort union, hat Microsoft in .NET 11.0 Preview 3 [1] eingeführt. Mit der neu erschienenen Preview 6 [2] können Entwicklerinnen und Entwickler Union Types nun an verschiedenen Stellen in .NET-Bibliotheken nutzen:
anyOf zum Einsatz (siehe Abbildung). Community-Bibliotheken für OpenAPI wie Swashbuckle und NSwag können damit aber noch nicht umgehen.
Die in C# 14.0 eingeführten Erweiterungsblöcke [5] mit dem Schlüsselwort extension für bestehende Klassen, die bisher nur Methoden, Properties und Operatoren ergänzen konnten, können nun in C# 15.0 auch Indexer zu bestehenden Klassen hinzufügen.
Das folgende Listing zeigt einen Erweiterungsblock in der Klasse ListExtensions, die zum generischen Typ List<T> einen Indexer hinzufügt, der Zeichenketten als Parameter entgegennimmt. Im Standard gibt es dort nur einen Indexer für Ganzzahlen.
using System;
using System.Collections.Generic;
using System.Text;
namespace NET11_Console.C_;
extension<T>(List<T> list)
{
public T this[string index]
{
get
{
// Prüfe, ob der Index ein gültiger Integer ist
if (!Int32.TryParse(index, out int i)) return default(T);
// Prüfe, ob der Index innerhalb der Grenzen der Liste liegt
if (i > list.Count - 1) return default(T);
// liefere den Wert aus der Liste
return list[i];
}
}
}
}Listing 1: Extension für List<T>, die einen Indexer mit einem Zeichenkettenparameter ergänzt
So verwendet man den neuen Indexer:
List<string> Prio = ["A", "B", "C"];
Console.WriteLine(Prio["1"]); // B
Console.WriteLine(Prio["42"]); // NULL
Console.WriteLine(Prio["unsinn"] == null); // trueMicrosoft hatte bereits in .NET 11.0 Preview 5 [6] asynchrone Validierung in Blazor eingebaut. Nun in Preview 6 lässt sich die asynchrone Validierung auch außerhalb von Blazor in anderen Anwendungsarten nutzen. Dazu hat Microsoft die Klasse System.ComponentModel.DataAnnotations.Validator um die vier Methoden ValidateObjectAsync(), TryValidateObjectAsync(), ValidatePropertyAsync() und ValidateValueAsync() erweitert. Zuvor gab es nur Pendants ohne Async im Namen [7].
Zudem gibt es für asynchrone Validierungsregeln eine neue Basisklasse AsyncValidationAttribute in Ergänzung zur bestehenden Basisklasse ValidationAttribute. Das Listing zeigt einen aussagekräftigen Ausschnitt aus einem Beispiel:
using System.ComponentModel.DataAnnotations;
namespace NET11_Console.FCL;
/// <summary>
/// Datenklasse
/// </summary>
public class Rechnung
{
[Required]
public int ID { get; set; }
[Range(0.01, double.MaxValue, ErrorMessage = "Betrag muss größer als 0 sein.")]
public double Betrag { get; set; }
[Required]
[StringLength(14, MinimumLength = 8)]
[RegularExpression(@"^[A-Z]{2}[A-Z0-9]+$")]
[ValidVatNumber] // asynchrone Validierungsregel!
public string SteuerNummer { get; set; } = "";
}
/// <summary>
/// Asynchrone Validierungsregel
/// </summary>
public sealed class ValidVatNumberAttribute : AsyncValidationAttribute
{
// Synchronous IsValid. This attribute validates asynchronously only.
protected override ValidationResult? IsValid(object? value, ValidationContext context) =>
throw new InvalidOperationException("Validate this attribute with IsValidAsync.");
protected override async Task<ValidationResult?> IsValidAsync(
object? value, ValidationContext context, CancellationToken cancellationToken)
{
var ok = await new TaxBL().ValidateVatID(value.ToString());
if (ok)
{
return ValidationResult.Success;
}
else
{
return new ValidationResult("Unbekannte Steuernummer.");
}
}
}
public class FCL11_AsyncValidation
{
public async Task Run()
{
CUI.Demo(nameof(FCL11_AsyncValidation));
var re = new Rechnung() { ID = 123, SteuerNummer = "DE12345678", Betrag = 0.0d };
var context = new ValidationContext(re);
var results = new List<ValidationResult>();
// Asynchrone Validierung
await Validator.TryValidateObjectAsync(re, context, results, validateAllProperties: true);
if (results.Count > 0)
{
CUI.Error("Gefundene Fehler: " + results.Count);
foreach (var result in results)
{
CUI.LI(result.ErrorMessage, ConsoleColor.Red);
}
}
else
{
CUI.Success("Rechnungsobjekt ist einwandfrei!");
}
}
}Listing 2: Asynchrone Validierung
Das Listing gibt aus:
Gefundene Fehler: 2
Auch in ASP.NET Core Minimal Web-APIs ist nun asynchrone Validierung möglich. Dazu muss man, wie in .NET 10.0 eingeführt, im Startcode builder.Services.AddValidation() aufrufen. Danach können Entwicklerinnen und Entwickler Objekte mit asynchronen Validatoren verwenden, zum Beispiel die oben schon verwendete Klasse Rechnung:
app.MapPost("/CheckInvoice", (Rechnung re) =>
{
new TaxBL().Process(re);
return Results.Ok(re);
});Dieser HTTP-Request
POST {{NET10_WebAPIMinimal_HostAddress}}/CheckInvoice
Content-Type: application/json
{
"ID": 123,
"SteuerNummer": "DE12345678"
}führt dann zur Antwort:
{
"title": "One or more validation errors occurred.",
"status": 400,
"errors": {
"Betrag": [
"Betrag muss größer als 0 sein."
],
"SteuerNummer": [
"Unbekannte Steuernummer."
]
}
}Wenn der Aufruf AddValidation() vergessen wird, findet keine Validierung statt und es gibt für den Aufrufer auch keinen Laufzeitfehler, der auf die fehlende Validierung hinweist.
In den Release Notes [8] werden die klassischen Controller-basierten Web-APIs nicht erwähnt. Ein Schnelltest ergab, dass dort in Preview 6 die Übergabe eines Objekts mit asynchroner Validierung zu einem Laufzeitfehler führt: „System.InvalidOperationException: Validate this attribute with IsValidAsync.“ Ebenso wenig funktionieren bislang Union Types in Operationen in Controller-basierten Web-APIs.
Seit .NET 8.0 können Entwicklerinnen und Entwickler mit ShortCircuit() beziehungsweise MapShortCircuit() bereits bei Web-APIs deklarieren, dass ein Endpunkt zur Leistungsoptimierung ohne Verwendung aller genutzten Middleware-Komponenten (etwa Authentifizierung, CORS, Protokollierung, Komprimierung oder Durchsatzbegrenzung) direkt aufgerufen werden soll. In .NET 11.0 kann man dies nun auch deklarativ mit der neuen Annotation [ShortCircuit] erreichen.
Das geht in Minimal Web-APIs
app.MapGet("/Info",
[ShortCircuit] () => "ASP.NET Core WebAPI Controller in .NET " +
System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription);und ebenso in Controller-basierten Web-APIs:
public class PersonController : ControllerBase
{
[HttpGet]
[Route("/Info")]
[ShortCircuit]
public IActionResult Get()
{
return Content("ASP.NET Core WebAPI Controller in .NET " + System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription, "text/plain");
}
}ASP.NET-Core-basierte Web-APIs unterstützen seit .NET 11.0 Preview 2 [9] die OpenAPI Specification in der Version 3.2. In .NET 10.0 war es Version 3.1. Vor Preview 6 war Version 3.2 nicht im Standard aktiv, sondern musste im Startcode aktiviert werden:
builder.Services.AddOpenApi(options =>
{
options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_2;
});Am 16.6.2026 hat Microsoft bekanntgegeben, dass ab Preview 6 die Version 3.2 der Standard ist [10].
Eine Rückstufung auf Version 3.1 ist möglich:
builder.Services.AddOpenApi(options =>
{
options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_1;
});Bei ASP.NET Core SignalR können Clients nun eine Verbindung abbrechen, auch wenn diese kein Streaming verwendet:
public class WorkHub : Hub
{
public async Task NameDerOperation(CancellationToken cancellationToken)
{
await Task.Delay(TimeSpan.FromMinutes(5), cancellationToken);
}
}
…
using var cts = new CancellationTokenSource();
var ergebnis = connection.InvokeAsync("NameDerOperation", cts.Token);
…
cts.Cancel();{
"title": "One or more validation errors occurred.",
"status": 400,
"errors": {
"Betrag": [
"Betrag muss größer als 0 sein."
],
"SteuerNummer": [
"Unbekannte Steuernummer."
]
}
}Microsoft hat bereits in Preview 4 [11] und Preview 5 [12] Erweiterungen für die Prozessverwaltung gebracht. Auch Preview 6 bietet hier Neuerungen: Entwicklerinnen und Entwickler können Prozesse nun direkt im Zustand „Suspended“ starten. Dafür gibt es in der Klasse ProcessStartInfo die neue Boolean-Eigenschaft StartSuspended und in der Klasse SafeProcessHandle die Methode Resume(), siehe Listing.
public async Task StartSuspended()
{
CUI.Demo(nameof(StartSuspended));
var startInfo = new ProcessStartInfo("notepad.exe") { StartSuspended = true };
using var process = Process.Start(startInfo)!;
CUI.Print(DateTime.Now.ToLongTimeString() + ": Neuer Prozess mit ID #" + process.Id + " ist gestartet!");
CUI.Print(IsProcessSuspended(process) ? "Prozess ist ausgesetzt." : "Prozess läuft!");
await Task.Delay(2000);
process.SafeHandle.Resume();
CUI.Print(IsProcessSuspended(process) ? "Prozess ist ausgesetzt." : "Prozess läuft!");
}Listing 3: Einen Prozess ausgesetzt starten
Die Klasse SafeProcessHandle bietet außerdem die neuen Methoden Open() und TryOpen(), um einen Prozess anhand der ID direkt anzusprechen. In der Klasse Process gibt es die neue Methode TryGetProcessById(), die im Gegensatz zur bestehenden ProcessById() den Wert false liefert, anstatt eine Ausnahme auszulösen, wenn kein Prozess mit der angegebenen ID existiert.
In Blazor können Developer in der eingebauten Komponente <Virtualize> den Nutzerinnen und Nutzern einer Webanwendung nun ermöglichen, leicht zu bestimmten Elementen in der Liste zu scrollen. Dafür gibt es die neue Eigenschaft InitialIndex für die Startposition und die neue Methode ScrollToIndexAsync() für eine Bewegung zur Laufzeit, siehe Listing.
@page "/VirtualizeScrolling"
@inject NavigationManager nav
@inject ITVisions.Blazor.BlazorUtil util
@rendermode InteractiveServer
<Headline BlazorType="@this.RendererInfo.Name">
Scrolling bei <Virtualize>
</Headline>
<input type="number" min="0" max="1000" @bind="Index" />
<button @onclick='GoToIndex'>GoToIndex</button>
<button @onclick='GoToTop'>GoToTop</button>
<hr />
<div class="row">
<div class="col">
<div class="table table-striped sticky-grid">
<Virtualize TItem="IndexedFlight" Items="IndexedFlights" InitialIndex="100" @ref="list" Context="item">
<div>
Flug #@(item.Index + 1):
#@item.Flight.FlightNo:
@item.Flight.Departure → @item.Flight.Destination
</div>
</Virtualize>
</div>
</div>
</div>
@code {
public sealed record IndexedFlight(
int Index,
BO.WWWings.Flight Flight);
private List<BO.WWWings.Flight> FlightSet;
private List<IndexedFlight> IndexedFlights = [];
private Virtualize<IndexedFlight> list = default!;
public int Index { get; set; }
protected override void OnInitialized()
{
DA.WWWings.WwwingsV1EnContext ctx = new();
FlightSet = ctx.Flights.ToList();
IndexedFlights = FlightSet
.Select((flight, index) => new IndexedFlight(index, flight))
.ToList();
}
private async Task GoToTop() => await list.ScrollToIndexAsync(0);
private async Task GoToIndex() => await list.ScrollToIndexAsync(Index);
}Listing 4: InitialIndex und ScrollToIndexAsync() bei <Virtualize>
Entwicklerinnen und Entwickler können in Blazor nun Client-Einstellungen, die bisher per JavaScript erfolgen mussten, im C#-Startcode der Anwendung vornehmen. Dazu gibt es eine neue Methode WithBrowserOptions(), die man nach dem Hinzufügen der gewünschten Render-Modi (zum Beispiel AddInteractiveServerRenderMode()) aufruft. Als Parameter gibt man ein Objekt des Typs BrowserOptions mit. In BrowserOptions gibt es die Unterobjekte Ssr (für statisches serverseitiges Rendering), Server (für Blazor Server) und WebAssembly (für Blazor WebAssembly):
app.MapRazorComponents<App>()
.AddInteractiveServerRenderMode()
.AddInteractiveWebAssemblyRenderMode()
.AddAdditionalAssemblies(typeof(Client._Imports).Assembly)
// Neu in .NET 11.0: Client-Einstellungen können in der Program.cs-Datei konfiguriert werden.
.WithBrowserOptions(options =>
{
options.LogLevel = LogLevel.Warning;
options.Ssr.PreserveDom = true;
options.Server.ReconnectionMaxRetries = 10;
options.Server.ReconnectionRetryInterval = TimeSpan.FromSeconds(1.5);
options.Server.ReconnectionDialogId = "components-reconnect-modal";
options.WebAssembly.ApplicationCulture = "de-de";
options.WebAssembly.EnvironmentName = "Staging";
options.WebAssembly.EnvironmentVariables["Version"] = "1.2";
});
app.Run();Alternativ können Entwicklerinnen und Entwickler diese Einstellungen per Komponente <ConfigureBrowser> in App.razor setzen:
<!DOCTYPE html>
<html lang="en">
…
<body>
<Routes @rendermode="InteractiveServer" />
<ReconnectModal />
<ConfigureBrowser Options="bo">
</ConfigureBrowser>
<script src="@Assets["_framework/blazor.web.js"]"></script>
</body>
</html>
@code
{
BrowserOptions bo = new()
{
LogLevel = LogLevel.Warning,
Ssr =
{
PreserveDom = true
},
Server =
{
ReconnectionMaxRetries = 10,
ReconnectionRetryInterval = TimeSpan.FromSeconds(1.5),
ReconnectionDialogId = "components-reconnect-modal"
},
WebAssembly =
{
ApplicationCulture = "de-DE",
EnvironmentName = "Staging",
EnvironmentVariables =
{
["Version"] = "1.2"
}
}
};
}In Blazor wurde außerdem das in .NET 11.0 Preview 1 [13] eingeführte Steuerelement <EnvironmentBoundary> in <EnvironmentView> umbenannt. Ebenso umbenannt hat Microsoft die Methode GetUriWithHash() in der Klasse NavigationManager: Sie heißt nun GetUriWithFragment().
Der in .NET 11.0 Preview 5 [14] eingeführte neue LINQ-Operator FullJoin() besitzt nun auch eine Implementierung in Entity Framework Core, sodass eine direkte Umsetzung in SQL möglich ist.
Aus diesem LINQ-Befehl mit FullJoin() zwischen Flügen und Piloten
var fluegeUndPiloten = ctx.Flights.IgnoreQueryFilters()
.FullJoin(
ctx.Pilots,
f => f.PilotPersonId,
p => p.PersonId,
(f, p) => new
{
FlightNo = f != null ? f.FlightNo : 0,
Departure = f != null ? f.Departure : "n/a",
Destination = f != null ? f.Destination : "n/a",
FlightDate = f != null ? f.FlightDate : DateTime.MinValue,
PilotId = f != null && f.PilotPersonId != null ? f.PilotPersonId.ToString() : "n/a",
GivenName = p != null ? p.Employee.Person.GivenName : "n/a",
p.Employee.Person.Surname,
}).Where(x => x.Surname == null)
.Take(20)
.ToList();erzeugt Entity Framework Core dann diesen SQL-Befehl:
SELECT TOP(@p) CASE
WHEN [f].[FlightNo] IS NOT NULL THEN [f].[FlightNo]
ELSE 0
END AS [FlightNo], CASE
WHEN [f].[FlightNo] IS NOT NULL THEN [f].[Departure]
ELSE N'n/a'
END AS [Departure], CASE
WHEN [f].[FlightNo] IS NOT NULL THEN [f].[Destination]
ELSE N'n/a'
END AS [Destination], CASE
WHEN [f].[FlightNo] IS NOT NULL THEN [f].[FlightDate]
ELSE '0001-01-01T00:00:00.000'
END AS [FlightDate], CASE
WHEN [f].[FlightNo] IS NOT NULL AND [f].[Pilot_PersonID] IS NOT NULL THEN CONVERT(varchar(11), [f].[Pilot_PersonID])
ELSE 'n/a'
END AS [PilotId], CASE
WHEN [p].[PersonID] IS NOT NULL THEN [p0].[GivenName]
ELSE N'n/a'
END AS [GivenName], [p0].[Surname]
FROM [Operation].[Flight] AS [f]
FULL JOIN [People].[Pilot] AS [p] ON [f].[Pilot_PersonID] = [p].[PersonID]
LEFT JOIN [People].[Employee] AS [e] ON [p].[PersonID] = [e].[PersonID]
LEFT JOIN [People].[Person] AS [p0] ON [e].[PersonID] = [p0].[PersonID]
WHERE [p0].[Surname] IS NULLSeit Entity Framework Core 10.0 konnte man einen Full Join erreichen, indem man LeftJoin() und RightJoin() kombiniert hat. Vor Version 10.0 musste man noch umständlicher GroupJoin() und SelectMany() verwenden.
Einige der Kommandozeilenbefehle des .NET SDK laufen nun nicht mehr auf Basis des Just-in-Time-Compilers, sondern mit Native AOT:
dotnet --versiondotnet --infodotnet --helpdotnet (Befehl) --helpdotnet --cli-schemadotnet sln listdotnet sln migratedotnet sln removeBei dotnet test gibt es nun den Parameter --no-dependencies zum Vermeiden der Übersetzung von Projektreferenzen, analog zu dotnet build --no-dependencies. Analog gibt es bei dotnet test nun auch --use-current-runtime (abgekürzt --ucr).
Zur Auswahl des Test-Runners können Entwicklerinnen und Entwickler nun eine Umgebungsvariable setzen, statt eines Eintrags in der global.json-Datei, zum Beispiel
export DOTNET_TEST_RUNNER=Microsoft.Testing.Platform
dotnet testDer Standard-Test-Runner ist weiterhin der ältere VSTest-Runner. Die Umgebungsvariable hat höhere Priorität [15] als ein Eintrag in der global.json-Datei.
Die mitgelieferte Projektvorlage für xUnit-basierte Tests besitzt nun einen Parameter --xunit-version, um die Version 3 von xUnit zu wählen. Hier ist dann die Microsoft Testing Platform der Standard.
dotnet new xunit --xunit-version v3Alternativ können Entwicklerinnen und Entwickler noch das ältere VSTest erzwingen:
dotnet new xunit --xunit-version v3 --test-runner VSTest
Für NUnit-basierte Tests gibt es nun ebenfalls die Projektvorlagenoption --test-runner.
Bei File-based Apps (C#-Scripting ohne Projektdatei) funktioniert die in Preview 3 eingeführte Direktive [16] #:include nun auch ohne diese Einstellung:
#:property ExperimentalFileBasedProgramEnableIncludeDirective=trueZudem können Entwicklerinnen und Entwickler #:include nicht nur für C#-Quellcodedateien, sondern auch für kompilierte DLLs verwenden:
#:include ./Bibliothek.dllFür das in Preview 5 eingeführte #:ref ist aber noch diese Zeile in File-based Apps notwendig:
#:property ExperimentalFileBasedProgramEnableRefDirective=trueDie sechste Vorschauversion von .NET 11.0 gibt es kostenlos zum Download [17]. .NET 11.0 soll am 10. November 2026 erscheinen und einen Standard-Term Support von zwei Jahren erhalten.
Die iX und der dpunkt.verlag werden in Kooperation mit den bekannten .NET-Experten von www.IT-Visions.de [18] die fertige Version am 17. November in einem ganztägigen Online-Event präsentieren: betterCode() .NET 11.0 [19].
URL dieses Artikels:
https://www.heise.de/-11366944
Links in diesem Artikel:
Copyright © 2026 Heise Medien
