ApostropheCMS: Import-Archive können Serverspeicher erschöpfen und Denial-of-Service verursachen

Prüfungsumfang und Grenzen der Nachweise

Paket: @apostrophecms/import-export, Version 3.7.0.

Geprüfter Release-Tag: @apostrophecms/import-export@3.7.0, Commit 9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce (September 30, 2026).

Aktueller geprüfter Main-Zweig: 5ce3732be0ebdebb4db0f8ef160c81e8671157e6.

Der Importer, der Gzip-Extraktor, die Import-Berechtigungsprüfung und die grundlegende Berechtigungsimplementierung weisen keine Unterschiede zwischen diesem Release-Tag und dem geprüften Main-Zweig auf. Dieses Follow-up ist eine statische Überprüfung der Problembehebung. Die ursprünglichen End-to-End-Reproduktionen wurden nicht gegen das neueste Release wiederholt und es wurde keine bereitgestellte Website getestet. Die aktuelle Ausnutzbarkeit und die Auswirkungen müssen daher noch von den Maintainern validiert werden; die nachfolgenden Beobachtungen belegen, dass die gemeldeten Sicherheitsprüfungen im öffentlichen Quellcode weiterhin fehlen. Das ursprüngliche per E-Mail versandte PDF enthält das ursprüngliche Reproduktionsmaterial. Bitte beziehen Sie sich auf diesen bestehenden privaten Anhang.

Extraktion von Import-Archiven weist keine Ressourcenkontingente und Fehlerbereinigung auf

Der aktuelle Gzip-Extraktor fängt Schreibfehler am Zielort ab und wartet auf den Abschluss des Schreibvorgangs; diese Teile des ursprünglichen Berichts sollten nicht mehr als unverändert betrachtet werden. Die Import-Routen erfordern nun außerdem einen angemeldeten Benutzer vor der Verarbeitung großer Uploads, wie durch GHSA-86wm-68pq-5jwq abgedeckt.

Allerdings schreibt extract() entpackte Archiveinträge weiterhin ohne Quoten pro Eintrag, Quoten für aggregierte dekomprimierte Bytes oder Begrenzungen der Eintragsanzahl. Das Parsen von Archiven geht der Autorisierung des Dokumenttyps immer noch voraus. Wenn die Extraktion oder das Parsen fehlschlägt, benachrichtigt und wirft import() den Fehler erneut vor dem späteren Aufruf von storage.remove(), ohne eine bedingungslose Bereinigung innerhalb dieses Lebenszyklus. Das gemeldete Restrisiko besteht in einem übermäßigen Speicherverbrauch und verbleibenden Extraktions-/Staging-Artefakten aus authentifizierten Importen. Das Abfangen von Schreibfehlern und das Erzwingen einer Anmeldung setzen kein Speicherbudget durch.

Vorgeschlagene Behebung: Konfigurierbare Streaming-Quoten basierend auf tatsächlich dekomprimierten Bytes hinzufügen, Einträge und zulässige Eintragstypen begrenzen, gleichzeitige Importe beschränken und lokale sowie uploadfs-Artefakte bei jedem Fehler bereinigen. Fortsetzungs-Artefakte sollten nur unter expliziter Zuordnung, Ablaufzeit und Gesamtspeicherlimits beibehalten werden.

Quellverweise:

• Gzip extractor)
• Import lifecycle and cleanup)
• Related authentication fix)

Koordination

Vivek R / Winfunc Ursprüngliches Meldeteam: Mufeed VH / Winfunc