Aktualisiert am
Hacking durch JPEG-Dateien: Kann ein JPG wirklich Schadcode ausführen?
Ein Foto landet per E-Mail auf Deinem Rechner. Du öffnest es – und plötzlich ist der PC kompromittiert. Klingt nach einem typischen Internet-Horrorszenario. Ganz erfunden ist die Idee allerdings nicht.
JPEG- und JPG-Dateien können tatsächlich Teil eines Cyberangriffs sein. Entscheidend ist aber das Wort Teil. Ein gewöhnliches JPEG ist kein ausführbares Programm. Gefährlich kann es werden, wenn verwundbare Software das Bild verarbeitet, zusätzliche Programme versteckte Daten daraus extrahieren oder eine Datei lediglich so aussieht, als wäre sie ein harmloses Foto.
Und genau hier wird es interessant: Microsoft dokumentierte im Juli 2026 zwei beobachtete Angriffsketten des sogenannten ACR Stealers. In einer davon versteckten Angreifer eine Malware-Nutzlast in den Pixeln einer JPEG-Datei. Das Bild war dabei allerdings nicht der Anfang des Angriffs – sondern ein clever getarnter Transportbehälter innerhalb einer bereits laufenden Angriffskette.
Was kann ein JPG also wirklich? Und was gehört eher ins Reich der Cyber-Mythen?
Das Wichtigste vorab
- Eine normale JPEG-Datei ist kein ausführbares Windows- oder macOS-Programm. JPEG beschreibt die Bildkompression; typische Dateien liegen als JFIF- oder Exif-Container mit der Endung
.jpgbzw..jpegvor. - Manipulierte Bilder können jedoch Sicherheitslücken in Bilddecodern, Browsern, Vorschauprogrammen oder Serverdiensten ausnutzen.
- Bei Steganographie wird Schadcode in Bilddaten versteckt. Meist benötigt der Angreifer zusätzlich einen Loader oder ein Script, das diese Daten wieder aus dem Bild extrahiert.
- JPEG-Dateien können außerdem Teil sogenannter Polyglot-Dateien sein, die von unterschiedlichen Programmen unterschiedlich interpretiert werden.
- Besonders wichtig sind sichere Upload-Prozesse bei Websites, Cloud-Diensten, CMS und anderen Systemen, die fremde Bilder automatisch verarbeiten.
- Für Privatanwender bleibt ein vollständig aktualisiertes System einer der wichtigsten Schutzfaktoren.
🔴 Mythos
„Ein JPG ist nur ein Bild. Damit kann technisch nichts passieren.“
🟢 Fakt
Das Dateiformat selbst führt keinen Schadcode wie eine EXE-Datei aus. Trotzdem kann eine speziell präparierte Bilddatei zum Angriffsvektor werden – beispielsweise durch eine Sicherheitslücke in der Software, die das Bild decodiert, durch versteckte Daten innerhalb des Bildes oder als Bestandteil einer mehrstufigen Malware-Kampagne.
Die richtige Antwort lautet deshalb nicht einfach „JPEGs sind gefährlich“ oder „JPEGs sind sicher“, sondern:
Das Risiko entsteht aus dem Zusammenspiel von Datei, verarbeitender Software und Angriffskette.
Vier Wege, wie Bilder bei Angriffen eine Rolle spielen können
| Szenario | Was passiert? | Führt das JPG selbst Code aus? |
|---|---|---|
| Schwachstelle im Bilddecoder | Eine manipulierte Datei löst einen Programmfehler beim Verarbeiten des Bildes aus. | Indirekt – die Sicherheitslücke in der Software ist entscheidend. |
| Steganographie | Daten oder Schadcode werden innerhalb von Pixeln oder anderen Bildbereichen versteckt. | Nein. Ein anderes Programm muss die Nutzlast typischerweise extrahieren und ausführen. |
| Polyglot-Datei | Dieselbe Bytefolge wird von unterschiedlichen Programmen als unterschiedliche Formate gelesen – etwa als Bild und als HTML oder Script. | Nur unter bestimmten technischen Bedingungen, etwa bei falschem Content-Type oder MIME-Sniffing. |
| Unsichere Upload-Verarbeitung | Server, Plugins oder Metadaten-Tools verarbeiten eine manipulierte Datei mit einer verwundbaren Bibliothek. | Die serverseitige Verarbeitung ist der Angriffspunkt. |
Der aktuelle Fall: JPEG als Malware-Versteck im Jahr 2026
🚨 ACR Stealer: Der interessante Teil steckt im Ablauf
Microsoft Defender Experts berichteten am 16. Juli 2026 über verstärkte Aktivitäten des sogenannten ACR Stealers. Zwischen Ende April und Mitte Juni 2026 beobachteten die Sicherheitsforscher zwei vorherrschende Angriffsketten. Weitere Varianten derselben Malware-Familie gelten als wahrscheinlich.
Eine der beiden dokumentierten Ketten verwendete tatsächlich eine JPEG-Datei.
Doch der Ablauf ist entscheidend: Der Angriff begann nicht damit, dass jemand einfach ein Foto öffnete. Zunächst wurden Opfer über eine sogenannte ClickFix-Methode – oft über Malvertising oder manipulierte Suchergebnisse – dazu gebracht, einen schädlichen Befehl selbst auszuführen. Erst anschließend lud die Schadsoftware weitere Komponenten nach.
In der von Microsoft untersuchten JPEG-Variante startete der eingefügte Befehl typischerweise mshta.exe. Dieses Windows-Werkzeug lud remote bereitgestellten HTA-Inhalt. Darin enthaltenes VBScript dekodierte über COM-Objekte weiteres PowerShell. Erst dieses bereits laufende PowerShell-Script holte sich die Bilddatei.
Dafür wurde ein öffentlich erreichbares JPEG von einem Image-Hosting-Dienst heruntergeladen. In seinen Bildpixeln war eine verschlüsselte Nutzlast versteckt.
Das PowerShell-Script:
- lud das JPEG herunter,
- las versteckte Informationen aus den Bildpixeln,
- entschlüsselte und dekomprimierte die Daten,
- führte die rekonstruierte Nutzlast anschließend im Arbeitsspeicher aus (unter anderem über dynamisch aufgelöste Windows-APIs wie
VirtualAllocundCreateThread).
Das Ziel war der Diebstahl von Browser-Zugangsdaten, Cookies, Sitzungs- und Authentifizierungstoken sowie sensiblen Dokumenten – darunter PDFs, Microsoft-365-Dateien und Daten in synchronisierten Ordnern wie OneDrive oder SharePoint.
Das ist ein perfektes Beispiel dafür, warum die Aussage „Malware steckt in einem JPG“ zwar stimmen kann – aber leicht missverstanden wird.
Das JPEG war hier Tarnung und Transportweg. Ohne die vorherige ClickFix-Kette inklusive MSHTA und PowerShell wäre es zunächst einfach nur eine Datei mit versteckten Daten geblieben.
Quelle: Microsoft Security Research: ACR Stealer, 16. Juli 2026
Steganographie: Wenn Daten im Bild verschwinden
Steganographie ist keine Malware-Technik im engeren Sinn. Das Prinzip ist viel älter: Informationen werden so in anderen Daten versteckt, dass möglichst niemand bemerkt, dass überhaupt eine geheime Nachricht vorhanden ist.
Bei digitalen Bildern können Informationen beispielsweise innerhalb von Pixelwerten untergebracht werden. Kleine Veränderungen fallen dem menschlichen Auge häufig nicht auf.
🕵️ Das Bild ist dabei meist nur der Container
Angreifer können Steganographie verwenden, um verschlüsselte Konfigurationen, Scripts, ausführbaren Code oder andere Daten zu verstecken.
Damit daraus tatsächlich Schadsoftware wird, benötigt die Angriffskette normalerweise noch etwas anderes: einen Loader, ein Script oder bereits ausgeführten Schadcode, der weiß, wo und wie die versteckten Daten gelesen werden müssen.
MITRE führt Steganographie deshalb als eigene Technik unter T1027.003 im ATT&CK-Framework. Die Technik wurde zuletzt am 12. Mai 2026 überarbeitet und beschreibt ausdrücklich die Verwendung digitaler Medien wie Bildern zum Verbergen von Informationen.
Stegosploit: Das berühmte Bild, das mehr als ein Bild war
Ein häufig genanntes Beispiel ist Stegosploit von Sicherheitsforscher Saumil Shah, vorgestellt 2015 unter anderem auf der Black Hat Europe.
Stegosploit kombinierte zwei Techniken: Steganographie und sogenannte Polyglot-Dateien.
Exploit-Code konnte dabei innerhalb eines JPG- oder PNG-Bildes verborgen werden. Gleichzeitig wurde eine Datei so aufgebaut, dass sie auch Bestandteile von HTML und JavaScript enthielt beziehungsweise in einem geeigneten Kontext entsprechend interpretiert werden konnte.
⚠️ Wichtige Klarstellung
Das wird häufig verkürzt zu:
„Man muss nur das JPG im Browser öffnen und schon läuft JavaScript.“
So allgemein stimmt das nicht.
Ein normal ausgeliefertes JPEG mit korrektem MIME-Type image/jpeg wird von modernen Browsern als Bild behandelt. Stegosploit benötigte einen speziell konstruierten Polyglot-Aufbau und einen passenden Ausführungskontext.
Technisch heißt das: Dieselbe Bytefolge kann gleichzeitig als gültiges JPEG beginnen (typischer Startmarker FF D8) und an anderer Stelle HTML oder JavaScript enthalten. Ob daraus Code wird, entscheidet nicht das Bild allein, sondern wie die empfangende Software den Inhalt interpretiert – etwa über Content-Type, MIME-Sniffing oder weil die Datei ausdrücklich als HTML geladen wird.
Das eigentliche Sicherheitsproblem ist also nicht, dass jedes JPEG plötzlich eine HTML-Datei wäre, sondern dass Dateiformate und Content-Interpretation unter bestimmten Umständen clever kombiniert oder missbraucht werden können.
Quelle: Black Hat Europe 2015: Stegosploit – Exploit Delivery with Steganography and Polyglots (Saumil Shah)
Wenn nicht das Bild, sondern der Bilddecoder verwundbar ist
Die technisch gefährlichste Variante ist eine völlig andere: Das Bild muss überhaupt keinen „ausführbaren Schadcode“ im klassischen Sinn enthalten.
Stattdessen wird die Datei absichtlich so konstruiert, dass sie einen Fehler in einer Bildbibliothek provoziert.
Bilddecoder müssen komplexe Binärdaten verarbeiten. Fehler bei Speicherverwaltung, Größenberechnungen oder Datenstrukturen können dazu führen, dass speziell präparierte Dateien Speicherbereiche beschädigen. Unter bestimmten Bedingungen kann daraus sogar die Ausführung fremden Codes entstehen.
🚨 Aktuelles Beispiel: CVE-2026-3082 im GStreamer-JPEG-Parser
Ein Beispiel aus dem Jahr 2026 betrifft klassische JPEG-Dateien – also genau das Format, das üblicherweise als .jpg gespeichert wird.
CVE-2026-3082 ist ein Heap-Buffer-Overflow in GStreamer beim Parsen von Huffman-Tabellen in JPEG-Dateien. Laut Beschreibung kann eine speziell präparierte JPEG-Datei zur Absturz oder zur Codeausführung im Kontext des verarbeitenden Prozesses führen. Die Bibliothek muss das Bild dafür verarbeiten; der genaue Angriffsweg hängt von der jeweiligen Anwendung ab (Player, Thumbnail-Dienst, Messenger-Vorschau).
Genau das ist das Parser-Risiko in Reinform: Nicht das Foto „startet ein Programm“, sondern eine verwundbare Decoder-Bibliothek stolpert über präparierte Bilddaten.
Quelle: NIST NVD: CVE-2026-3082 · GStreamer Security Advisory 2026-0003
📌 Ergänzung: CVE-2016-8332 in OpenJPEG (JPEG 2000)
Ein älteres, gut dokumentiertes Beispiel ist CVE-2016-8332 aus dem Jahr 2016.
Die Schwachstelle befand sich in OpenJPEG 2.1.1 und betraf die Verarbeitung speziell präparierter JPEG-2000-Dateien. Ein Heap-Buffer-Overflow konnte laut NIST zu Speicherbeschädigung und letztlich zur Ausführung beliebigen Codes führen.
Wichtig dabei: JPEG 2000 ist technisch nicht identisch mit dem üblichen klassischen JPEG-Format. Der Fall bleibt trotzdem nützlich, weil er dasselbe Grundprinzip zeigt: Das Risiko sitzt im Parser, nicht in der Idee „ein Bild sei ein Programm“.
Der Nutzer musste die manipulierte Datei mit einer betroffenen Software öffnen beziehungsweise verarbeiten lassen.
Warum automatische Bildverarbeitung besonders interessant ist
Du musst ein Bild nicht einmal selbst doppelklicken, damit Software es verarbeitet.
Viele Anwendungen machen das automatisch:
- WordPress erzeugt Vorschaubilder (häufig über GD oder Imagick).
- Cloud-Dienste analysieren Metadaten.
- Messenger generieren Previews.
- Suchmaschinen und CMS indexieren Bilder.
- Galerien skalieren Fotos auf mehrere Auflösungen.
- Server prüfen EXIF- und andere Metadaten.
Damit vergrößert sich die Angriffsfläche. Jede Bibliothek, die fremde Dateien analysiert, decodiert oder konvertiert, verarbeitet potenziell nicht vertrauenswürdige Daten.
📦 ExifTool und GitLab zeigen das Problem sehr anschaulich
Bei CVE-2021-22204 konnte eine Schwachstelle in ExifTool beim Parsen präparierter DjVu-Daten zur Ausführung von Code führen.
Auch hier ist Präzision wichtig: Es handelte sich nicht um eine generelle „JPEG-EXIF-Lücke“. Die verwundbare Verarbeitung betraf das DjVu-Format.
Relevant wird der Fall trotzdem für Bild-Upload-Systeme, weil Metadaten-Werkzeuge Dateien automatisch untersuchen können – oft allein aufgrund der Dateiendung. Genau so geschah es bei CVE-2021-22205 in GitLab: Hochgeladene Dateien mit Bildendungen wurden an ExifTool durchgereicht. Die eigentliche Schwachstelle steckte im DjVu-Parser, der Angriffsweg war aber ein vermeintlicher Bild-Upload. Die Lücke wurde in freier Wildbahn ausgenutzt und steht im CISA-Katalog nachweislich ausgenutzter Sicherheitslücken.
Quellen: NIST NVD: CVE-2021-22204 · NIST NVD: CVE-2021-22205 · CISA Known Exploited Vulnerabilities Catalog
Was ein normales JPG nicht kann
🧠 Drei wichtige Missverständnisse
Ein JPG ist keine EXE-Datei.
JPEG definiert, wie Bildinformationen komprimiert werden. Ein korrekt behandeltes JPEG besitzt keinen vorgesehenen Mechanismus, mit dem es eigenständig Windows-Befehle startet oder Programme installiert.
Versteckter Code ist nicht automatisch ausgeführter Code.
Du kannst theoretisch fast beliebige Daten in oder an eine Datei hängen. Das bedeutet noch nicht, dass Betriebssystem oder Bildbetrachter diese Daten ausführen.
Eine Datei namens foto.jpg.exe ist kein JPEG.
Windows kann bekannte Dateiendungen ausblenden. Eine Datei, die scheinbar urlaub.jpg heißt, kann deshalb in Wirklichkeit einen anderen Dateityp besitzen. Entscheidend ist nicht das Icon und auch nicht allein der sichtbare Dateiname.
Wie groß ist das Risiko im Alltag?
Für einen Privatanwender mit aktuellem Betriebssystem, aktuellem Browser und aktueller Sicherheitssoftware ist das Risiko, durch das bloße Betrachten eines gewöhnlichen JPEGs kompromittiert zu werden, vergleichsweise gering.
Deutlich relevanter sind heute komplette Angriffsketten:
- Phishing-Mails,
- gefälschte Downloads,
- kompromittierte Websites,
- Social Engineering wie ClickFix,
- veraltete Programme oder Plugins,
- anschließend nachgeladene Malware.
Das Bild kann dabei Tarnung, Transportmedium oder Auslöser für eine Software-Schwachstelle sein. Es ist aber häufig nicht der eigentliche Einstiegspunkt.
| Situation | Einordnung |
|---|---|
| Normales Foto aus vertrauenswürdiger Quelle auf aktuellem System | Im Alltag normalerweise unkritisch. |
| Unverlangter Bildanhang einer unbekannten E-Mail | Vorsicht – vor allem wegen der gesamten Phishing-Kampagne. |
| Bild wird von veralteter Software verarbeitet | Erhöhtes Risiko, wenn bekannte Parser-Schwachstellen vorhanden sind. |
| Website verarbeitet beliebige Uploads automatisch | Für Betreiber sicherheitsrelevant und entsprechend abzusichern. |
| Eine Website fordert Dich auf, Befehle in PowerShell, Terminal oder „Ausführen“ einzufügen | Massives Warnsignal. Nicht ausführen. |
So schützt Du Dich als Anwender
🛡️ Die Maßnahmen mit dem größten praktischen Nutzen
- Halte Betriebssystem, Browser, Messenger, Bildbetrachter und andere Programme aktuell.
- Öffne unerwartete Anhänge nicht allein deshalb, weil sie wie ein harmloses Foto aussehen.
- Lass Dich von Websites niemals dazu verleiten, unbekannte Befehle in PowerShell, Terminal, Eingabeaufforderung oder den Windows-Ausführen-Dialog einzufügen.
- Lass den Echtzeitschutz Deines Betriebssystems aktiviert.
- Ignoriere Sicherheitswarnungen von Browser, SmartScreen oder Betriebssystem nicht einfach.
- Erstelle Backups wichtiger Daten und halte mindestens eine Kopie vom unmittelbar erreichbaren Produktivsystem getrennt.
- Prüfe bei verdächtigen Dateien den tatsächlichen Dateityp und nicht nur Name oder Symbol.
Microsoft Defender SmartScreen kann beispielsweise vor bekannten Phishing- und Malware-Seiten sowie potenziell schädlichen Downloads warnen.
Quelle: Microsoft Learn: Defender SmartScreen
Bild-Uploads in WordPress und Webanwendungen sicher verarbeiten
Für Entwickler und Betreiber von Websites ist die Frage noch interessanter. Wer fremde Dateien entgegennimmt, sollte grundsätzlich davon ausgehen, dass diese Dateien manipuliert sein können. Bei WordPress gilt das besonders, weil Themes und Plugins hochgeladene Bilder oft automatisch über GD oder Imagick in Vorschaugrößen umrechnen.
⚠️ Nur die Dateiendung zu prüfen reicht nicht
Eine Upload-Prüfung nach dem Muster „Dateiname endet auf .jpg“ bietet praktisch keinen ausreichenden Schutz.
Auch der vom Browser übertragene MIME-Type darf laut OWASP nicht als alleinige Sicherheitsprüfung verwendet werden, weil dieser Wert vom Client geliefert und manipuliert werden kann.
🔐 Sinnvolle Schutzmaßnahmen für Upload-Systeme
- Erlaube ausschließlich Dateitypen, die Deine Anwendung wirklich benötigt.
- Prüfe Erweiterung, MIME-Type und tatsächliche Dateistruktur serverseitig.
- Verwende erzeugte beziehungsweise zufällige Dateinamen statt vom Benutzer vorgegebener Namen.
- Begrenze Dateigröße und Bildabmessungen.
- Speichere Uploads möglichst außerhalb des direkt ausführbaren Webroots oder auf einem getrennten Dateidienst.
- Halte alle verwendeten Bild-, Metadaten- und Konvertierungsbibliotheken aktuell – inklusive Imagick, GD, libjpeg, ExifTool und GStreamer, falls im Einsatz.
- Verarbeite nicht vertrauenswürdige Dateien möglichst in einem eingeschränkten Prozess oder einer isolierten Umgebung.
- Setze Viren- beziehungsweise Malware-Scanning dort ein, wo es zum Risikomodell passt.
- Kodierung beziehungsweise Re-Encoding eines gültigen Bildes kann zusätzliche und versteckte Inhalte entfernen.
- Liefere Dateien mit dem korrekten Content-Type aus und verhindere unerwünschtes MIME-Sniffing.
OWASP empfiehlt ausdrücklich ein mehrstufiges Schutzkonzept. Keine einzelne Prüfung – weder Dateiendung noch Content-Type noch Dateisignatur – ist für sich allein ausreichend.
Quelle: OWASP File Upload Cheat Sheet
🌀 Warum Re-Encoding hilft – aber kein Zaubertrick ist
Wird ein hochgeladenes JPEG von einer vertrauenswürdigen Bildbibliothek vollständig decodiert und anschließend als neues JPEG gespeichert, verschwinden viele überflüssige Daten, angehängte Payloads oder ungewöhnliche Dateistrukturen.
Das ist eine starke zusätzliche Schutzschicht.
Allerdings gibt es einen kleinen Haken: Um das Bild neu zu kodieren, muss die Bibliothek zunächst das Original verarbeiten. Genau deshalb müssen auch diese Bibliotheken aktuell und möglichst isoliert betrieben werden.
JPEG ist nicht gleich SVG
Eine weitere häufige Verwechslung betrifft SVG-Dateien.
SVG ist kein klassisches Pixelbild wie JPEG oder PNG, sondern ein XML-basiertes Vektorformat. SVG kann je nach Verwendung aktive beziehungsweise browserrelevante Inhalte enthalten und besitzt deshalb ein anderes Sicherheitsprofil.
Wer auf einer Website ausschließlich Benutzerfotos benötigt, sollte SVG nicht einfach deshalb freigeben, weil es ebenfalls als „Bildformat“ gilt.
Häufige Fragen
Kann ich durch das Öffnen eines JPG gehackt werden?
Theoretisch ja, praktisch nur unter bestimmten Voraussetzungen. Dazu müsste beispielsweise die Software, die das Bild verarbeitet, eine ausnutzbare Schwachstelle besitzen. Bei einem aktuellen System ist ein normales JPEG kein Programm, das einfach selbstständig startet.
Kann Malware wirklich in einem JPEG versteckt werden?
Ja. Steganographie oder andere Verfahren können Daten innerhalb einer Bilddatei verstecken. Damit daraus ein erfolgreicher Angriff wird, muss normalerweise zusätzlich eine andere Komponente diese Daten extrahieren und ausführen.
Kann schon der Empfang eines Bildes gefährlich sein?
Software kann Bilder automatisch analysieren oder Vorschauen erzeugen. Existiert dort eine ausnutzbare Parser-Schwachstelle, kann theoretisch bereits diese Verarbeitung problematisch sein. Das ist einer der Gründe, warum Updates für Messenger, Browser und Betriebssystem wichtig sind.
Kann ein Virenscanner versteckte Malware erkennen?
Teilweise. Moderne Sicherheitsprodukte betrachten nicht nur statische Dateisignaturen, sondern unter anderem Verhalten, Prozesse, Netzwerkverbindungen und verdächtige Ausführungsketten. Steganographie kann statische Erkennung erschweren, macht einen Angriff aber nicht automatisch unsichtbar.
Sollte ich deshalb keine JPG-Anhänge mehr öffnen?
Nein. Eine pauschale Angst vor Bilddateien wäre übertrieben. Entscheidend sind Quelle, Kontext und ein aktuelles System. Bei unerwarteten E-Mails oder verdächtigen Nachrichten solltest Du allerdings unabhängig vom Dateityp vorsichtig sein.
🌀 Kontext & Einordnung
Die Schlagzeile „Hacker verstecken Malware in JPG-Dateien“ ist technisch möglich – aber ohne Erklärung schnell irreführend.
Man muss mindestens drei Dinge auseinanderhalten:
- Ein Bild kann versteckte Daten transportieren.
- Ein manipuliertes Bild kann eine Sicherheitslücke in einem Decoder auslösen.
- Eine Datei kann lediglich als Bild getarnt sein.
Das sind völlig unterschiedliche Angriffsmethoden.
Der Microsoft-Fall aus dem Jahr 2026 zeigt das besonders deutlich: Das JPEG enthielt tatsächlich eine versteckte Malware-Nutzlast. Die Infektion entstand jedoch nicht durch das normale Anschauen des Bildes. Eine zuvor gestartete ClickFix-Kette – über MSHTA und PowerShell – holte das JPEG gezielt ab, extrahierte den versteckten Inhalt und führte ihn anschließend aus.
Genau diese technische Einordnung fehlt leider häufig, wenn aus einem komplexen Angriff die griffige Überschrift „Virus im Foto“ gemacht wird.
✅ Fazit: Ja, ein JPEG kann gefährlich sein – aber anders, als viele denken
JPEG-Dateien sind nicht grundsätzlich gefährlich. Sie sind aber auch nicht automatisch außerhalb jeder Sicherheitsbetrachtung.
Manipulierte Bilder können Schwachstellen in Software ausnutzen. Sie können Daten oder Malware-Komponenten verstecken. Sie können als unauffälliger Transportkanal innerhalb einer größeren Angriffskette dienen.
Der dokumentierte ACR-Stealer-Fall von 2026 zeigt sogar sehr konkret, dass Angreifer JPEG-Pixel nutzen, um Payloads vor einer einfachen statischen Analyse zu verbergen.
Die wichtigste Erkenntnis lautet trotzdem:
Das Foto allein ist selten die ganze Attacke.
Aktuelle Software, ein vernünftig abgesichertes System, Vorsicht bei unerwarteten Anhängen und sichere Datei-Upload-Prozesse reduzieren das Risiko erheblich.
Aus dem Mythos „Mit Bildern kann nichts passieren“ wird deshalb kein neuer Mythos „Jedes JPG kann Dich hacken“.
Die Realität liegt – wie so oft in der IT-Sicherheit – dazwischen.
🔎 Quellen & weiterführende Informationen
- Microsoft Security Research: ACR Stealer – zwei beobachtete Angriffsketten, Juli 2026
- MITRE ATT&CK: T1027.003 – Steganography
- Black Hat Europe 2015: Stegosploit – Exploit Delivery with Steganography and Polyglots
- NIST NVD: CVE-2026-3082 – GStreamer JPEG-Parser
- GStreamer Security Advisory 2026-0003
- NIST NVD: CVE-2016-8332 – OpenJPEG / JPEG 2000
- NIST NVD: CVE-2021-22204 – ExifTool Remote Code Execution
- NIST NVD: CVE-2021-22205 – GitLab Bild-Upload / ExifTool
- CISA: Known Exploited Vulnerabilities Catalog
- OWASP Cheat Sheet Series: File Upload Security
- OWASP Cheat Sheet Series: Input Validation
- Microsoft Learn: Microsoft Defender SmartScreen
tiny-tool.de
tiny-tool.de