LONDON (IT BOLTWISE) – Eine Schwachstelle im AMD Auto Updater ermöglicht offenbar das Einschleusen von Schadcode per Remote Code Execution, wenn Angreifer Kommunikationswege manipulieren. Der Security-Researcher MrBruh meldete den Fehler frühzeitig, doch das Bug-Bounty-Programm stufte ihn zunächst als nicht förderfähig ein. Erst später folgte die öffentliche Offenlegung mit der CVE-Nummer CVE-2026-40677 und Empfehlungen für Updates betroffener Tools. Im Mittelpunkt steht nun auch die Frage, wie Hersteller mit solchen „Scope“-Fällen umgehen und welche Sicherheitswirkung selbst ausgeschlossene Bugs haben.
Bei AMDs „Auto Updater“ verdichten sich die Alarmzeichen zu einem klassischen Fall von Supply-Chain-Risiken, bei dem ein Updateprozess zum Einstiegspunkt werden kann. Laut den öffentlich diskutierten Details kann ein Angreifer, der auf dem gleichen Netzwerksegment sitzt oder den Kommunikationspfad mit verändert, legitime Update-Dateien durch bösartige Ausführdateien ersetzen. Das Entscheidende ist dabei weniger die Existenz einer einzelnen Lücke, sondern die Art, wie Updates technisch abgesichert (oder eben nicht abgesichert) sind: Eine korrekte Kette aus Transport- und Integritätsprüfungen ist in solchen Mechanismen nicht „nice to have“, sondern der Kern jeder Vertrauensannahme.
Der Auslöser der Diskussion: Das Auto-Update-Tool verwendet zwar HTTPS, um Aktualisierungsinformationen abzurufen. Für die tatsächlich heruntergeladene ausführbare Datei soll jedoch HTTP als URL genutzt werden. Damit fehlt im kritischen Teil der Kette die transportseitige Schutzwirkung, die man bei HTTPS erwartet. Der Researcher MrBruh gibt außerdem an, die heruntergeladene Komponente dekompiliert zu haben und dabei keine kryptografische Signaturprüfung vorgefunden zu haben, bevor die Datei direkt ausgeführt wird. Technisch bedeutet das: Ohne Signaturverifikation wird aus einem „Update“ im Schadensfall schnell ein „Ausführen fremder Logik“.
Aus Sicht der technischen Vergleichbarkeit lässt sich das Problem gut gegenüber „korrekten“ Update-Architekturen einordnen. In robusten Designs wird die Integrität typischerweise durch Signaturen (z. B. Public-Key-Kryptografie) abgesichert, nicht nur durch CRC-Checks. Ein CRC-32 kann zwar Fehler bei der Übertragung erkennen, ist aber keine Schutzmaßnahme gegen gezielte Manipulation. Genau hier prallen die Positionen aufeinander: MrBruh widerspricht der späteren Erklärung, die offenbar auf ein verändertes Update-Layering bei „Ryzen Master“ sowie auf eine Signaturprüfung rekurriert, während er in der Praxis wiederum nur einen CRC-32-Mechanismus gesehen haben will. Für Unternehmen ist das nicht akademisch: CRC-basierte Checks verhindern keine Angreifer-Tampering-Szenarien.
Auch der Prozess rund um die Meldung sorgt für Reibung. MrBruh habe die Schwachstelle am 27. Januar 2026 entdeckt und am 6. Februar 2026 an AMD gemeldet. Das Bug-Bounty-Programm, das Intigriti für AMD betreut, soll den Report noch am selben Tag geschlossen haben – mit der Begründung, der Fall sei „not eligible for a fix and not eligible for a bounty“. Solche „Scope“-Entscheidungen sind im Markt verbreitet, allerdings verschiebt sich die Diskussion hier in Richtung Wirkung: In Foren und Kommentaren wurde angemerkt, dass ein Bug-Bounty-Ausschluss nicht automatisch bedeutet, dass es keine echte Verwundbarkeit oder keinen realen Impact gibt. Diese Trennung zwischen Vergütung und Sicherheitsbehebung ist zwar formal möglich, kommunikativ aber oft schwer zu vermitteln.
Nachdem MrBruh seinen Blogbeitrag veröffentlicht hatte – die Nachricht entwickelte sich zu einem vielbeachteten Thema unter anderem bei Hacker News – soll PSIRT von AMD den Kontakt wieder aufgenommen haben. Dabei wurde laut Darstellung angekündigt, man werde die Validität intern bestätigen, eine CVE ausstellen und den Fehler beheben. Gleichzeitig sei AMD zeitweise darum gebeten worden, den Blogpost zu löschen bzw. bis zum Abschluss einer formalen Reaktion zu warten. Der Beitrag sei schließlich am 9. Juni 2026 erschienen, also 124 Tage nach der ursprünglichen Meldung. Für die Marktwirkung ist diese Zeitspanne relevant: Je länger eine Lücke in der „vor öffentlichen Details“-Phase bleibt, desto stärker wächst das Risiko, dass sich Angreifer-Workflows bereits darauf einstellen.
Als AMD die Schwachstelle später offiziell öffentlich machte, erhielt sie den Eintrag „AMD Auto Updater Vulnerability“ und die CVE-Nummer CVE-2026-40677. Betroffen seien demnach unter anderem AMD Management Console, AMD Ryzen Master sowie AMD µProf gewesen. Als kurzfristige Gegenmaßnahme empfiehlt AMD den Nutzern, Management Console auf Version 14.0.0 zu aktualisieren, Ryzen Master auf 2.14.3 und µProf auf Version 5.3 oder höher. Damit liefert AMD zumindest einen klaren Pfad zur Risikoreduktion. Dennoch bleibt die Debatte darum bestehen, ob die kommunikative Einordnung des Sicherheitsmechanismus – etwa welche Prüfungen exakt greifen – in der Öffentlichkeit präzise genug war.
Ein weiterer Punkt, der in der Diskussion hervorsticht: MrBruh beschreibt zusätzlich, dass der Auto Updater möglicherweise mit einer Redirect-Kette von „ati.com“ zu „drivers.amd.com“ nicht zuverlässig umgehen kann. Das könne theoretisch dazu führen, dass der Updateprozess abstürzt oder abbricht, bevor es überhaupt zur eigentlichen Ausführphase kommt. Damit entsteht eine widersprüchliche Lage: Entweder ist das Exploit-Szenario durch die Pipeline-Nachläufe stark eingeschränkt, oder der Fix müsste sowohl die Update-Mechanik als auch die Sicherheitskontrollen betreffen, was die Fehlerbehebung komplexer macht. Für Hersteller ist das ein typisches Dilemma zwischen „funktionale Robustheit“ und „verlässliche Sicherheitsgarantien“ im Updatepfad.
Im Markt trifft das auf eine wachsende Sensibilität für Update-Sicherheit, weil die moderne Angriffsfläche nicht mehr nur „Browser und E-Mail“ ist, sondern Prozesse, die mit Admin-Rechten laufen und häufig im Hintergrund aktualisieren. Genau deshalb wird in Communities auch argumentiert, dass ein Bug-Bounty-Ausschluss wegen „man-in-the-middle“ nicht automatisch die Relevanz des Problems entwertet. Anders formuliert: Selbst wenn der Rahmen einer konkreten Kampagne bestimmte Angriffsvarianten nicht vergütet, bleibt die Lücke eine reale Sicherheitsbedrohung, sobald sie in einer Produktkette nachweislich ausnutzbar ist. Als Gegenbeispiel wird oft auf andere Bug-Bounty-Setups verwiesen, die stärker nach „technischem Impact“ statt nach „Programmscope“ entscheiden.
Experten aus der Security-Community betonen in solchen Kontexten typischerweise, dass Hersteller nicht nur fixen, sondern auch ihre Sicherheitsannahmen transparent machen müssen. Eine kryptografische Signaturprüfung ist dabei nicht nur ein „Feature“, sondern ein Sicherheitsvertrag: Ohne sie ist selbst ein korrekt konfiguriertes TLS-Setup im kritischen Download-Schritt wertlos, wenn der Pfad für die ausführbare Datei auf HTTP springt. Gleichzeitig zeigt die Debatte, wie wichtig klare Kommunikationslinien zwischen Researchern, PSIRT und Bug-Bounty-Providern sind, damit „geschlossen“ nicht als „irrelevant“ verstanden wird. Das gilt auch für Compliance- und Governance-Aspekte: In vielen Organisationen ist der sichere Updateprozess Bestandteil interner Kontrollsysteme, die Auditierbarkeit und Nachvollziehbarkeit verlangen.
Für die Zukunft ist die wahrscheinlichste Entwicklung weniger eine einzelne „Endlösung“, sondern eine konsequente Verstärkung von Update-Workflows entlang der gesamten Lieferkette. Dazu gehört, dass Transport-URLs konsistent abgesichert werden, dass Redirects kontrolliert und signiert werden, und dass die Ausführphase an eine harte Integritätsprüfung gebunden ist. Unternehmen, die AMD-Tools oder ähnliche Auto-Update-Komponenten einsetzen, sollten die Empfehlung daher nicht nur als einmaliges Update verstehen, sondern als Anlass für einen Abgleich eigener Richtlinien: Welche Tools bekommen Admin-Rechte? Wie wird Update-Integrität verifiziert? Und wie schnell werden kritische Vendor-Infos intern verarbeitet? Die Debatte um CVE-2026-40677 kann so als Reminder dienen, dass Security-Boundaries in Update-Systemen oft zu spät überprüft werden.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "AMD Auto Updater: RCE-Lücke, verzögerte Meldung und Streit um Bug-Bounty-Regeln" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "AMD Auto Updater: RCE-Lücke, verzögerte Meldung und Streit um Bug-Bounty-Regeln" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »AMD Auto Updater: RCE-Lücke, verzögerte Meldung und Streit um Bug-Bounty-Regeln« bei Google Deutschland suchen, bei Bing oder Google News!