CVE-2026-67211 in OpenNLP
Zusammenfassung
von VulDB • 11.09.2026
OOM-Dienstverweigerung (Denial of Service) durch unbegrenzte Vorab-Größenfestlegung von Maps in Apache OpenNLP SymSpellModelSerializer
Betroffene Versionen:
- 3.0.0-M4 - 3.0.0-M5
(Die Erweiterung opennlp-spellcheck wurde in Version 3.0.0-M4 eingeführt. Die Releases der Reihen 1.x und 2.x enthalten den betroffenen Code nicht.)
Beschreibung:
Die Methode `SymSpellModelSerializer.create()` liest zwei mit Vorzeichen versehene 32-Bit-Ganzzahlen (unigramCount und bigramCount) aus einem binären SymSpell-Modellstream und übergibt jeden Wert direkt an `LinkedHashMap.newLinkedHashMap()`, nachdem lediglich geprüft wurde, dass er nicht negativ ist. Es wird keine Obergrenze angewendet, sodass der Zählerwert vollständig vom Angreifer gesteuert werden kann, wenn die Modelldatei aus einer nicht vertrauenswürdigen Quelle stammt.
Eine manipulierte .bin-Modelldatei, bei der entweder das count-Feld auf `Integer.MAX_VALUE` (oder einen anderen Wert groß genug, um den verfügbaren Heap zu erschöpfen) gesetzt ist, führt dazu, dass die Map mit einer Kapazität von 2^30 Einträgen vorab dimensioniert wird. Das überdimensionierte Backing-Array wird beim ersten Aufruf von `put()` in diese Map alloziert und fordert je nach Aktivierung komprimierter Oops (compressed oops) 4–8 GB an Speicher an, woraufhin der Ladevorgang mit einem `OutOfMemoryError` fehlschlägt. Da sich die Zählerfelder unmittelbar hinter einem Header fester Größe befinden (Magic-Number, Formatversion, drei UTF-Zeichenketten, Konfigurationsfelder und die Edit-Distance-Kennung), zahlt der Angreifer keine nennenswerten Kosten für die Dateigröße zur Weaponisierung eines Payloads: Eine Datei von deutlich unter 100 Bytes plus einem einzigen echten Eintrag reicht aus, um eine JVM zum Absturz zu bringen, die diese lädt.
Jeder Codepfad, der ein SymSpell-Modell deserialisiert, ist betroffen, darunter `SymSpellModels.deserialize(InputStream)`, `SymSpellModels.fromBytes(byte[])`, das Laden von Modellen über den Klassenpfad mittels `SymSpellModelResolver.resolveByLanguage(String)`, das Befehlszeilentool CorrectTextTool sowie das Laden von Modell-Archiven durch den registrierten ArtifactSerializer. Die Erweiterung opennlp-spellcheck ist im offiziellen OpenNLP-Binärpaket enthalten.
Die praktische Auswirkung ist eine Dienstverweigerung (Denial of Service) gegen Prozesse, die SymSpell-Modelldateien aus nicht vertrauenswürdigen oder halb-vertrauenswürdigen Quellen laden.
Abhilfe:
- Benutzer der 3.x-Reihe sollten auf Version 3.0.0-M6 aktualisieren.
Hinweis: Die Korrektur wendet eine Obergrenze für beide Zählerfelder an, die vor der Vorab-Dimensionierung der Map überprüft wird; negative Werte oder solche, die diese Grenze überschreiten, führen zum Auslösen einer `IOException` und zu einem schnellen Fehlschlagen des Lesevorgangs ohne große Allokation. Die Obergrenze entspricht dem bestehenden Limit `AbstractModelReader.MAX_ENTRIES`, das zuvor eingeführt wurde und durch die aktuelle Änderung für öffentliche Sichtbarkeit (public visibility) freigegeben wird, damit Serializer, die ihr eigenes Binärformat implementieren, es gemeinsam nutzen können. Das Standard-Limit beträgt 10.000.000, was weit über den Eintragszahlen legitimer SymSpell-Wörterbücher liegt, aber deutlich unter jedem Wert, der eine Heap-Erschöpfung gefährden würde. Bereitstellungen, die tatsächlich das Laden größerer Wörterbücher benötigen, können das Limit beim JVM-Start erhöhen, indem sie die Systemeigenschaft `OPENNLP_MAX_ENTRIES` auf den gewünschten positiven Integer setzen (z. B. `-DOPENNLP_MAX_ENTRIES=50000000`); ungültige oder nicht-positive Werte fallen auf den Standardwert zurück. Beachten Sie, dass diese Eigenschaft mit dem Limit des Model-Readers geteilt wird und deren Erhöhung beide Lockerungen bewirkt.
Benutzer, die keine sofortige Aktualisierung vornehmen können, sollten alle SymSpell-.bin-Modelldateien als nicht vertrauenswürdigen Eingabedaten behandeln, es sei denn, ihre Herkunft ist verifiziert, und sollten das Laden von Modellen vermeiden, die von Endbenutzern bereitgestellt oder aus Drittanbieter-Repositories ohne Integritätsprüfungen abgerufen wurden.
VulDB is the best source for vulnerability data and more expert information about this specific topic.