Amazon Web Services hat für seinen Monitoring-Dienst CloudWatch eine neue Funktion zur automatischen Erstellung von Incident-Reports angekündigt. Laut AWS können Kunden damit innerhalb weniger Minuten umfassende Post-Incident-Analyseberichte generieren. Das Timing der Veröffentlichung ist bemerkenswert: Sie erfolgt kurz nach dem schweren Ausfall der AWS-Infrastruktur, der zahlreiche Dienste auch von anderen Anbietern lahmlegte.

Die neue CloudWatch-Funktion sammelt automatisch Telemetriedaten, Nutzeraktionen während der Fehlersuche sowie Systemkonfigurationen und fügt diese zu einem strukturierten Bericht zusammen. Laut AWS umfassen die generierten Reports Executive Summaries, detaillierte Zeitverläufe der Ereignisse, Impact-Assessments und konkrete Handlungsempfehlungen. Das System korreliert dabei die verschiedenen Datenquellen, um ein möglichst vollständiges Bild des Vorfalls zu zeichnen.

CloudWatch ist Amazons zentrale Plattform für die Echtzeitüberwachung von Cloud-Ressourcen und -Anwendungen. Der Dienst bietet laut AWS-Dokumentation eine systemweite Übersicht über die Anwendungsperformance, operative Systemgesundheit und Ressourcenauslastung. Die neue Incident-Report-Funktion erweitert dieses Monitoring jetzt um eine strukturierte Nachbetrachtung von Störfällen.

Das Versprechen: Automatisch immer besser

Die automatisch erstellten Berichte sollen IT-Teams helfen, wiederkehrende Muster zu erkennen und präventive Maßnahmen zu implementieren. AWS verspricht, dass Kunden durch die strukturierte Post-Incident-Analyse ihre operative Aufstellung kontinuierlich verbessern können. Die Funktion erfasst dabei kritische Betriebstelemetrie, Servicekonfigurationen und Untersuchungsergebnisse automatisch – manuelle Zusammenstellungen entfallen. Inwiefern dies jetzt bereits bei Amazons jüngstem Ausfall intern geholfen haben könnte, bleibt jedoch offen. Nach den versprochenen wenigen Minuten lagen hierbei jedenfalls keine gesicherten Informationen vor.

Die neue CloudWatch-Funktion ergänzt die kürzlich eingeführte KI-gestützte Fehleranalyse in CloudWatch Investigations. Diese nutzt generative KI zur Diagnose und automatischen Ursachenanalyse von Betriebsproblemen. Die Integration mit AWS Systems Manager soll die Komplexität von Cloud-Umgebungen bei der Fehlerbehebung reduzieren. Laut AWS ist der Dienst in mehreren Regionen verfügbar, darunter Europe (Frankfurt). Die Kosten entsprechen denen von CloudWatch Investigations, für die Funktion gelten keine zusätzlichen Aufpreise.

(fo)

Vitest liegt in der neuen Hauptversion 4.0 vor. Updates gibt es unter anderem für den Browser Mode, den Umgang mit dem End-to-End-Testing-Framework Playright und das Debugging mit der Visual-Studio-Code-Erweiterung.

Bei Vitest handelt es sich um ein Testing-Framework auf Basis des Frontend-Build-Tools Vite.js, das einen Fokus auf Schnelligkeit legt. Beide sind quelloffen verfügbar, jedoch arbeitet das Vite-Team derzeit auch an dem kommerziellen Angebot Vite+, das eine einheitliche JavaScript-Toolchain darstellen soll.

Browser Mode stabil verfügbar

Der Browser Mode ist ein Feature der Vitest-API, das bislang als experimentell gekennzeichnet war und nun den stabilen Status erreicht hat. Damit lassen sich Tests nativ im Browser ausführen.

Um einen Provider festzulegen, ist nun die Installation eines separaten Pakets notwendig: @vitest/browser-playwright, @vitest/browser-webdriverio oder @vitest/browser-preview. Damit können Developer einfacher mit benutzerdefinierten Optionen arbeiten, und sie können auf die Kommentare /// verzichten.

Visuelles Regressionstesten im Browser Mode

Der Browser Mode erhält darüber hinaus eine neue Funktion: Visual Regression Testing. Das bedeutet, Vitest erstellt Screenshots von UI-Komponenten und Seiten und vergleicht diese mit Referenzbildern, um unbeabsichtigte visuelle Änderungen festzustellen. Das Visual Regression Testing lässt sich durch die Assertion toMatchScreenshot ausführen, wie das Entwicklungsteam demonstriert:

import { expect, test } from 'vitest'
import { page } from 'vitest/browser'

test('hero section looks correct', async () => {
  // ...the rest of the test

  // capture and compare screenshot
  await expect(page.getByTestId('hero')).toMatchScreenshot('hero-section')
})

Updates für die Anbindung an Playwright und VS Code

Vitest 4.0 bringt ein Update für die Verwendung mit dem End-to-End-Testing-Framework Playwright: Es kann nun Playwright Traces generieren, wenn die trace-Option in der test.browser-Konfiguration gesetzt ist, oder mithilfe der Option --browser.trace=on, in der sich auch off, on-first-retry, on-all-retries oder retain-on-failure festlegen lassen. Die erstellte Trace-Datei lässt sich mit dem Playwright Trace Viewer öffnen. In der Extension für Visual Studio Code gibt es ebenfalls eine Neuerung: Dort lässt sich nun der „Debug Test“-Button beim Ausführen von Browser-Tests nutzen.

Die komplette Liste der Änderungen führt das Vitest-Team im Changelog auf und geht in einem Blogeintrag detaillierter auf die wichtigsten Neuerungen ein. Da es einige Breaking Changes gibt, empfiehlt es Entwicklerinnen und Entwicklern, vor einem Upgrade die Migrationsanleitung zu beachten.

(mai)

Die Rust-Library async-tar enthält eine Schwachstelle, die es Angreifern ermöglicht, versteckte Inhalte in tar-Archiven einzuschleusen.

Das auf sichere Laufzeitumgebungen spezialisierte Unternehmen Edera hat den Fehler veröffentlicht und ihm den etwas dramatischen Namen TARmageddon gegeben. Das Unternehmen hatte einen eigenen Fork der Library gepflegt, der inzwischen archiviert ist, aber noch einen Patch erhält.

Die Library async-tar dient dazu, tar-Archive asynchron zu lesen und zu schreiben. Sie ist deutlich performanter als die synchron arbeitende tar-Library für Rust.

Der zugehörige CVE-Eintrag (Common Vulnerabilities and Exposures) CVE-2025-62518 hat den Schweregrad „hoch“ mit dem Wert 8,1 von 10.

Fork ohne Patch: Zeit zum Wechseln

Auch wenn sich der CVE-Eintrag auf die Library astral-tokio-tar bezieht, betrifft die Schwachstelle die Library async-tar und deren Forks. Der am weitesten verbreitete Fork tokio-tar, mit über 7 Millionen Downloads im Rust-Paketmanager crates.io, wird seit zwei Jahren nicht mehr gepflegt. Damit bleibt er weiter verwundbar.

Wer tokio-tar nutzt, sollte auf den Fork astral-tokio-tar oder eine andere Alternative wie die nicht asynchrone tar-Library wechseln. Der Fork astral-tokio-tar hat mit Version 0.5.6 ein Update erhalten, das die Schwachstelle behebt.

Verwirrung in den Headern

Der Fehler liegt in der Verarbeitung der Header für die tar-Dateien. async-tar verarbeitet sowohl das ustar- als auch das PAX-Format. Wenn eine Datei Header für beide Formate enthält, kommt es zur Inkonsistenz: Der Parser nutzt die im ustar-Header angegebene Größe, während für andere tar-Werkzeuge die PAX-Werte gelten.

Wenn der PAX-Header die richtige Dateigröße angibt, ustar aber mit der Größe 0 angegeben ist, springt der Parser nicht weiter, sondern verarbeitet den Inhalt verschachtelter Archive, die aber andere tar-Werkzeuge nicht als solche erkennen und damit auch nicht untersuchen.

Der Blogbeitrag zu der Schwachstelle zeigt das in folgendem Kurzbeispiel:

Expected by scanner/validator:
Entry 1: "outer-file.txt"
Entry 2: "inner-tar-file.tar" (0 bytes per ustar, but N bytes in PAX)
Entry 3: "next-file.txt"

Actually extracted by tokio-tar:
Entry 1: "outer-file.txt"
Entry 2: "inner-tar-file.tar" (0 bytes per ustar)
Entry 3: "inner-file1.txt" (from inner TAR)
Entry 4: "inner-file2.txt" (from inner TAR)
Entry 5: "next-file.txt" (continues normally)

Der Parser von async-tar verarbeitet die verschachtelten Dateien als reguläre Inhalte des Archivs.

Als theoretisches Angriffsszenario führt der Beitrag den Python-Paketmanager uv auf, der ebenso von Astral stammt wie der inzwischen gepatchte Fork astral-tokio-tar. Vor dem Patch der in uv genutzten Library hätten Angreifer versteckten Schadcode über ein verschachteltes tar-Archiv einschmuggeln können.

Stabile Patches

Edera hat den Bug vor zwei Monaten entdeckt. Anschließend hat das Team einen Patch erstellt und die Maintainer der Libraries informiert. Die Libraries astral-tokio-tar und krata-tokio-tar haben den Patch erhalten, und der Maintainer von async-tar hat den Fehler selbst behoben. Allerdings finden sich im Paketmanager crates.io für async-tar und krata-tokio-tar nach wie vor etwa ein Jahr alte Versionen ohne Patch.

Dass der Bug erst jetzt veröffentlicht wurde, liegt an dem Embargo von 60 Tagen seit Edera den Maintainern den Bug gemeldet hat.

(rme)