Letzte Woche saß ich bei einem Maschinenbauer in der Region — 180 Mitarbeitende, Eigenentwicklung für Auftragsmanagement, .NET 8 Backend. Der Entwickler, der mich durch den Code geführt hat, ein guter Mann, zeigt mir stolz ihre CI-Pipeline. Sauber. Tests grün. Deployment automatisiert. Dann frage ich: "Wann habt ihr zuletzt eure NuGet-Abhängigkeiten aktualisiert?"
Stille.
"Na ja, wir haben da einen festen Stand, den wir nicht anfassen. Sonst bricht was."
Ich nicke. Das höre ich in drei von vier Mandaten. Und dann zeige ich ihnen, was gerade in ihrer packages.lock.json steht.
Was Jimmy Bogard gerade released hat
AutoMapper 16.1.1 ist ein Patch-Release — also eigentlich nichts Spektakuläres. Jimmy Bogard, der Maintainer, hat zwei Probleme gefixt, die es in sich haben.
Erstens: Ein Thread-Deadlock. Microsoft hat interne Sync-APIs für Verschlüsselung deprecated. Das hat dazu geführt, dass AutoMapper unter Last in ein klassisches Sync-over-Async-Problem gelaufen ist — Thread-Starvation, Locking, im schlimmsten Fall ein eingeforener Request-Pool. Der Fix ist kein sauberes Async-Refactoring (das wäre ein größerer Eingriff), sondern ein deutlich sichererer Umgang mit dem verbleibenden Sync-over-Async-Pattern.
Zweitens, und das ist das Ernstere: Eine Sicherheitslücke. Wenn du mit AutoMapper zyklische oder selbstreferenzielle Objektgraphen mappst — also Objekte, die sich in irgendeiner Form gegenseitig referenzieren — konnte das zu unkontrollierter Rekursion führen. Stack Exhaustion. Denial of Service. Die CVE läuft unter GHSA-rvv3-g6hj-g44x, und Bogard schreibt explizit: Wer mit nicht vertrauenswürdigen oder angreifer-kontrollierten Objektgraphen arbeitet, ist betroffen. Upgrade jetzt.
Beide Findings wurden responsible disclosed — einmal von @t0m-4, einmal von @skdishansachin. Guter Prozess, saubere Kommunikation.
Wie das in einem KMU wirklich landet
Lass mich ehrlich sein: Die meisten .NET-Projekte in Unternehmen zwischen 30 und 300 Mitarbeitenden haben AutoMapper irgendwo drin. Nicht weil das eine bewusste Entscheidung war, sondern weil der erste Entwickler, der das Projekt aufgebaut hat, es kannte. Das ist kein Vorwurf — AutoMapper löst ein echtes Problem. DTOs mappen nervt, und wenn man es nicht automatisiert, macht jeder sein eigenes Copy-Paste-Chaos.
Jetzt zum Deadlock: Der trifft dich dann, wenn deine Anwendung unter Last läuft und gleichzeitig Kryptographie-Operationen involviert sind. In vielen KMU-Anwendungen ist das latent vorhanden — Login-Flows, verschlüsselte Felder in der DB, Token-Validierung. Du wirst den Bug nicht in der Entwicklungsumgebung sehen, du wirst ihn im Produktivsystem entdecken, wenn Montag früh alle gleichzeitig einloggen. Ich habe das dreimal live erlebt. Es ist kein schöner Morgen.
Der DoS durch zyklische Objektgraphen klingt erstmal akademisch. Ist es aber nicht. Ich kenne zwei Szenarien aus Mandaten, wo das konkret relevant wird:
Szenario 1: Du liest Daten aus einer externen API und mappst sie direkt durch AutoMapper in dein internes Modell. Die externe API liefert valide JSON, aber mit verschachtelten Referenzen, die dein Mapping nicht erwartet. Passiert öfter als du denkst — besonders bei ERP-Integrationen mit älteren Systemen.
Szenario 2: Du hast Entity Framework-Objekte mit Navigation Properties, und irgendwo hat jemand vergessen, die Lazy Loading Proxies sauber zu konfigurieren. Dann entstehen zirkuläre Referenzen im Objektgraph, und AutoMapper dreht sich im Kreis.
Das zweite Szenario ist so verbreitet, dass ich es fast als KMU-Standard bezeichnen würde.
Was mir in Bogards Analyse fehlt
Jimmy Bogard schreibt präzise und technisch korrekt. Er richtet sich aber an .NET-Entwickler, die täglich mit solchen Paketen arbeiten und den Kontext haben, um die Tragweite einzuschätzen.
Was fehlt:
Konkrete Risikoeinschätzung nach Einsatzszenario. Bogard schreibt "Applications that process untrusted or attacker-controlled object graphs may be impacted." Das ist präzise, hilft aber dem Entwickler in einem Mittelstandsbetrieb nicht, der nicht weiß, ob seine Anwendung "attacker-controlled object graphs" verarbeitet. Die Antwort: Wenn irgendwas aus einer externen Quelle kommt — API-Response, Import-Datei, Web-Formular — und das durch AutoMapper läuft, bist du potenziell betroffen.
Hinweis auf Test-Strategie. Wie prüfe ich, ob ich betroffen bin, bevor ich upgrade? Ein kurzes Script, das die eigene Mapping-Konfiguration auf zyklische Profile testet, wäre Gold wert für Teams ohne dedizierten Security-Engineer. Den gibt es im Artikel nicht — verständlich, das sprengt den Scope eines Release-Posts, aber für KMU-Teams eine echte Lücke.
Migrationspfad für ältere Versionen. Manche Teams haben AutoMapper 12 oder 13 im Einsatz und können nicht trivial auf 16.x upgraden, weil das Library-Breaking-Changes mitbringt. Was tun die? Bogard adressiert das nicht.
Meine konkrete Empfehlung
Wenn AutoMapper in deinem Projekt steckt — und du weißt es nicht genau — dann jetzt:
grep -r "AutoMapper" ./src --include="*.csproj" -l
Und dann schau in deine packages.lock.json oder Directory.Packages.props, welche Version du ziehst.
Wenn du unter 16.1.1 bist: Upgrade heute. Nicht nächste Woche. Nicht "wenn wir Zeit haben". Heute.
Die Begründung für dein Management: Security Advisory GHSA-rvv3-g6hj-g44x, DoS-Potenzial durch externe Inputs. Das ist keine theoretische Gefahr, wenn ihr externe Datenquellen habt. Und wer hat die nicht.
Falls du auf einer älteren Major-Version feststeckst und nicht upgraden kannst: Prüf, ob du Mappings hast, die externe Objekte verarbeiten. Wenn ja, müsst ihr kurzfristig manuelle Validierung vor dem Mapping-Schritt einbauen — das schützt euch bis zum geplanten Upgrade-Fenster.
Zum Deadlock: Der trifft euch unter Last. Wenn ihr keinen Lasttest macht — und die meisten KMU machen das nicht, das ist kein Vorwurf, sondern eine Ressourcenfrage — dann simuliert wenigstens einen parallelen Login-Stress lokal, bevor ihr das nächste Deployment macht. JMeter, k6, oder auch einfach 10 Browser mit F5-Hammer auf den Login-Endpunkt. Grob, aber zeigt das Problem.
Eins noch: Wenn euer Team sagt "wir haben keine Zeit für Dependencies", dann habt ihr ein strukturelles Problem. Updates einzuspielen kostet zwei Stunden. Den Deadlock-Postmortem-Montag kostet euch zwei Tage und das Vertrauen eurer Anwender. Ich rechne das in jedem Mandat vor, und es überzeugt jedes Mal.
Der vollständige Original-Beitrag von Jimmy Bogard: AutoMapper 16.1.1 Released
Wenn du wissen willst, wie das bei euch konkret aussieht — welche Dependencies ihr wirklich prüfen müsst, wie ihr ein Update-Prozess einführt, der nicht im Sand verläuft — dann lass uns reden.
— Bernhard