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)

Das Unternehmen Vercel hat Next.js 16 veröffentlicht. Im React-Framework hat sich einiges getan: Der schnellere webpack-Nachfolger Turbopack ist nun im stabilen Status verfügbar und wird als Standard-Bundler verwendet, der React-Compiler-Support ist ebenfalls stabil und es gibt neue Features unter anderem für Caching, Routing und die Anbindung an das Model Context Protocol.

Stabile Features: Turbopack und React-Compiler-Support

Sowohl für Entwicklungs- als auch für Produktions-Builds hat Turbopack den stabilen Status erreicht. Als Standard-Bundler für alle Apps soll Turbopack bis zu zehnmal schnelleren Fast Refresh und zwei- bis fünfmal schnellere Builds ermöglichen.

Um Turbopack zu nutzen, ist in Next.js 16 keine weitere Konfiguration erforderlich. In Apps mit benutzerdefiniertem webpack-Setup können Developer weiterhin den älteren Bundler verwenden:

next dev --webpack
next build --webpack

Eine Neuerung, die bereits bei allen internen Vercel-Apps im Einsatz ist, hat Turbopack ebenfalls zu bieten: Als Beta unterstützt der Bundler Dateisystem-Caching während der Entwicklung. Er speichert Compiler-Artefakte zwischen Ausführungen, um deutlich schnellere Compile-Zeiten bei Neustarts zu erreichen – insbesondere in großen Projekten. Das Beta-Feature lässt sich in der Konfiguration aktivieren:

const nextConfig = {
  experimental: {
    turbopackFileSystemCacheForDev: true,
  },
};
 
export default nextConfig;

Anfang des Monats ist der React Compiler 1.0 erschienen, und Next.js 16 bietet dafür integrierten Support – jetzt im Status stable. Der Support ist dennoch standardmäßig deaktiviert, solange das Next.js-Team noch weitere Daten sammelt. Entwicklerinnen und Entwickler, die die Option aktivieren, müssen offenbar mit längeren Kompilierungszeiten in Entwicklung und Builds rechnen, weil der React Compiler Babel verwendet.

Neue Features für MCP und Caching

Neben der Stabilisierung von Features hat Next.js 16 weitere Neuerungen zu bieten. Dazu zählt Next.js DevTools MCP, eine Integration mit dem Model Context Protocol (MCP) für das KI-gestützte Debugging mitsamt Kontexteinblicken in eine Next.js-Anwendung. Neu sind auch die Cache Components, ein Set von Features, um das Caching in Next.js expliziter und flexibler zu gestalten. Sie bringen die neue "use cache"-Direktive, mit der sich Seiten, Komponenten und Funktionen cachen lassen.

Auf Details zu diesen und weiteren Features in Version 16 geht das Next.js-Team in einem Blogeintrag ein.

(mai)

Mit BentoPDF 1.0.0 steht ab sofort ein neues Open-Source-Werkzeug für die PDF-Verarbeitung bereit. Besonderen Wert legen die Entwickler auf eine lokale Datenverarbeitung ohne Cloud-Anbindung. Das erste Major Release bringt zahlreiche Funktionen für professionelle Workflows mit.

Zu den wichtigsten Updates gehört die Posterize-Funktion, die große PDFs in mehrere kleinere Dokumente für Posterdrucke aufteilt. Die Linearize-Funktion optimiert PDFs für schnelles Web-Viewing durch progressive Ladeoptimierung. Hinzu kommen Bulk-Operationen: Mehrere PDFs lassen sich gleichzeitig komprimieren oder in einzelne Seiten zerlegen.

Das Tool entfernt automatisch leere Seiten aus Dokumenten und bietet einen Interleave-Merge-Modus, bei dem mehrere PDFs verzahnt zusammengeführt werden – praktisch etwa beim Scannen von Vorder- und Rückseiten. Zudem können Dateien als Anhänge direkt in PDFs eingebettet werden.

Verbesserte OCR und Performance-Optimierungen

Zudem haben die Entwickler seit der Betaphase die OCR-Funktionen grundlegend überarbeitet. Hier sind Whitelist-Zeichensätze für präzisere Texterkennung neu hinzugekommen. Die Performance bei Split-, Merge- und Komprimierungsvorgängen hat das Projekt optimiert und den Speicherverbrauch bei Bulk-Operationen reduziert.

Für die Bereitstellung stehen verschiedene Docker-Konfigurationen bereit, die sich sowohl für Entwicklungsumgebungen als auch für Produktivbetrieb eignen. Die überarbeitete Docker-Compose-Konfiguration soll die Einrichtung von BentoPDF erleichtern. Nutzer von Unraid finden ein vorgefertigtes Template für die Integration in ihre Infrastruktur.

Das Projekt steht auf GitHub zur Verfügung, wo interessierte Nutzer ebenfalls eine vollständige Liste der unterstützten Features finden. Die vollständigen technischen Details und Installationsanleitungen finden sich in der Projektdokumentation.

(fo)