Ghostscript-Lücke: Präparierte PDFs gefährden WordPress-Server

Eine kritische Lücke in Ghostscript macht hochgeladene PDF-Dateien zum Einfallstor für WordPress-Server. Wordfence führte vor, wie ein präpariertes Dokument ohne Anmeldung fremden Code startet, sobald WordPress daraus ein Vorschaubild erzeugt. Den Fix liefern Linux-Distribution und Hoster, nicht das Plugin-Verzeichnis.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Die Ghostscript-Lücke CVE-2026-39919 steckt in dem Programm, mit dem viele Linux-Server PDF-Seiten in Bilder umwandeln. Gefunden hat sie Argus, der KI-Agent von Wordfence, bei einer Prüfung von WordPress 7.1. Am 12. Oktober veröffentlichte der Sicherheitsanbieter die Details samt Codeausführung ohne Login auf einer eigens gebauten Testsite.^[1]

Das Wichtigste in Kürze

• CVE-2026-39919 ist ein Speicherüberlauf in Ghostscript 9.21 bis 10.07.1, behoben in 10.08.0 (CVSS 3.1: 9,8, vergeben von VulnCheck).^[2]
• WordPress dient nur als Transportweg: Der Core erzeugt seit Version 4.7 über Imagick Vorschaubilder von PDFs.
• Gefährdet sind Websites, auf denen Besucher oder Nutzer mit wenigen Rechten PDFs hochladen.
• Angriffe sind bislang nicht bekannt.

Wie gelangt ein PDF bis zu Ghostscript?

WordPress rendert PDF-Vorschauen nicht selbst. Beim Upload reicht der Core die Datei über die PHP-Erweiterung Imagick an ImageMagick weiter, das wiederum Ghostscript startet.^[1] Der Fehler sitzt im Decoder für JPEG-2000-Bilder: Bei einer bestimmten Bildgeometrie schreibt Ghostscript im dokumentierten Beispiel viermal so viele Daten in einen Puffer, wie dort Platz haben, und überschreibt dabei die interne Speicherverwaltung. Die Sandbox-Option von Ghostscript verhindert den Überlauf nicht.

Ein Standard-WordPress lässt anonyme Besucher keine PDFs in die Mediathek laden. Den Weg öffnen erst Formular-Plugins oder Mitgliederbereiche, über die Besucher und Konten mit wenigen Rechten Dateien hochladen. Die Lücke steht auf der Stufe Patch verfügbar: Exploits hat Wordfence nicht veröffentlicht, Hinweise auf Angriffe fand der Anbieter bis zum 12. Oktober nicht.

Warum hilft hier kein WordPress-Update?

Ghostscript gehört zum Betriebssystem oder zum Container-Image. Distributionen bauen den Fix oft in ihre ältere Version ein, die Versionsnummer allein verrät deshalb wenig: Ubuntu 22.04 meldet nach dem Update weiter 9.55.0, korrigiert ist erst die Paketrevision 9.55.0~dfsg1-0ubuntu5.14.^[4] Debian 13 hat den Fix im Sicherheits-Repository, Debian 12 führt der Debian-Tracker am 13. Oktober noch als anfällig.^[3]

Im August schloss WordPress 7.0.4 eine Upload-Lücke, die nur auf Servern mit Imagick und Ghostscript griff. Im September drang die Sicherheitsfirma Hacktron über eine Speicherlücke in der Bildbibliothek libheif bis zu OpenAI vor. Aufschlussreich ist der Build-Effekt: Die zwei Exploits von Wordfence scheiterten in 10.240 Versuchen an zehn anderen Linux-Umgebungen, liefen aber in allen vier Testaufbauten mit derselben Ghostscript-Programmdatei. Das größte Risiko tragen laut Wordfence deshalb Hoster und Agenturen, die viele Websites aus einem gemeinsamen Image betreiben.

Was sollten Betreiber jetzt tun?

Angreifbar ist eine Site laut Wordfence nur, falls vier Dinge zusammenkommen: PDF-Uploads von Fremden, eine daraus erzeugte Vorschau, Imagick auf dem Server und ein ungepatchtes Ghostscript.^[1] Der Website-Zustand im Dashboard zeigt, ob Imagick das PDF-Format kennt, über den Patch-Stand sagt er nichts.

• Paket prüfen: dpkg -s ghostscript oder rpm -q ghostscript zeigt die volle Revision für den Abgleich mit Ihrer Distribution.
• Hoster fragen: Bei Managed Hosting klärt nur der Anbieter, ob sein Ghostscript den Fix enthält. Einen Überblick über Managed-Hoster gibt der WordPress-Hosting-Vergleich.
• Container neu bauen: Bauen Sie Images ohne Cache auf aktueller Basis neu, ein Neustart genügt nicht.
• Übergang absichern: PDF-Uploads für Besucher abschalten oder PDFs in der ImageMagick-Richtlinie sperren.

Codeausführung auf dem Server öffnet Angreifern Formular- und Kundendaten. Die DSGVO verlangt Schutzmaßnahmen nach dem Stand der Technik (Art. 32), bei einem Einbruch, erkennbar etwa an unbekannten Admin-Konten, läuft die 72-Stunden-Meldefrist an die Aufsicht (Art. 33).^[5] Wie schnell Angreifer Upload-Lücken ausnutzen, zeigte zuletzt Bricksforge: Die Angriffe begannen kurz nach der Offenlegung.

FAQ: Ghostscript-Lücke: Präparierte PDFs gefährden WordPress-Server

Quellen

Mehr Newshunger?

• Avada Builder: kritische Lücke ohne Login, die fünfte seit Mai
• WPForms mit über 5 Millionen Installationen: dritte Lücke ohne Login in 15 Tagen
• Gravity Forms: Kritische Upload-Lücke ermöglicht Codeausführung ohne Login
• WordPress 7.1.3: das dritte Sicherheitsupdate in 19 Tagen
• Avada-Theme: Eine KI verkettet sechs Lücken zur Serverübernahme
• 18 Jahre alte NGINX-Lücke trifft jeden WordPress-Hoster