Node.js, Java und Python: aktuelle Schwachstellen und Leitfaden zur Behebung

Quellen überprüft am 23. Oktober 2026 (UTC) Abdeckungszeitraum: 25. Juli – 23. Oktober 2026, mit Schwerpunkt auf Neuankündigungen und nachfolgenden Patches von September bis Oktober. Zielgruppe: Ingenieure und Sicherheitsbeauftragte, die Node.js-, Java-, Python-Dienste, Container, Build-Pipelines und Entwicklungsumgebungen warten.

Dieser Artikel fasst aktuelle wichtige Sicherheitsrisiken in den Laufzeiten Node.js, Java und Python, Standardbibliotheken sowie gängigen Server-Frameworks und -Abhängigkeiten zusammen und bietet Auswirkungsumfang, behobene Versionen, temporäre Abhilfemaßnahmen, Patch-Auswahl und Überprüfungsmethoden.

Bewerten Sie die Auswirkungen anhand von Komponentenversionen, aktivierten Funktionen und zugänglichen Einstiegspunkten. Fakten zur Sicherheitslücke stammen aus offiziellen Hinweisen; Daten beziehen sich auf die öffentliche Offenlegung, sofern nicht ausdrücklich auf eine frühere Patch-Veröffentlichung hingewiesen wird. Wir schließen nicht auf unbestätigte Exploit-Bedingungen, CVSS-Scores oder Exploits in freier Wildbahn. Bereitstellungshinweise werden als Implementierungshinweise bezeichnet.

TL;DR: Sanierungsprioritäten

Aktualisieren Sie zuerst die Laufzeit, die den Dienst tatsächlich hostet. Aktualisieren Sie den entsprechenden Node.js-Zweig auf mindestens 22.23.4 / 24.22.1 / 26.12.1. Dienste, die Node 24 verwenden, können innerhalb derselben Hauptversion oder einer späteren Version , die dieselben Fixes enthält, auf24.22.1 aktualisiert werden. S1 S2
Node-Anwendungsabhängigkeiten separat aktualisieren. Für Next.js verwenden Sie 15.5.28 / 16.4.1 als Upgrade-Basislinie; Wenn Sie React Server Components unabhängig verwenden, überprüfen Sie das tatsächlich installierte react-server-dom-*-Paket. Nur die Aktualisierung der Node-Binärdatei deckt diese Framework-Schwachstellen nicht ab. S8 S9 S10 S11 S12
Java: Deckt beide Aktualisierungsrunden ab. Installieren Sie einen Hersteller-Build, der sowohl den Notfall-Zertifikat-Vertrauensfix CPU vom 20. Oktober als auch den CVE-2026-91403-Notfallfix für die Zertifikatsvertrauensstellung vom 21. Oktober abdeckt. Siehe Abschnitt 2.2 für Oracle JDK 11-27 Out-of-Band-Versionen; Überprüfen Sie andere Distributionen anhand ihrer eigenen Sicherheitspakete und vollständigen Build-Nummern. Aktualisieren Sie den entsprechenden Tomcat-Zweig auf 9.0.123 / 10.1.61 / 11.0.27. S16 S17 S18 S20 S21 S22 S23
Python : Aktualisieren Sie den Interpreter, die Anwendungspakete und die Zertifikatspakete separat. Siehe Abschnitt 2.3 für Dolmetscher-Grundlinien; certifi empfiehlt ≥ 2026.10.19 , pip ≥ 26.2.2 , bei der Verwendung uv ≥ 0.13.4 . Jeder vorhandene Venv muss überprüft werden. Für wrap_bio() verwandte Codes, korrekt und nicht leer server_hostname muss ebenfalls übergeben werden. S29 S30 S31 S33 S35 S36 S37
Wenn ein sofortiges Upgrade nicht möglich ist, reduzieren Sie die Gefährdung an den relevanten Einstiegspunkten. Priorisieren Sie das Stoppen nicht vertrauenswürdiger Brotli-Dekodierung, beeinträchtigter Bild-/Paging-/Archivierungsverarbeitung und das Isolieren problematischer LDAP- oder Authentifizierungseinträge; Überprüfung der TLS-Zertifikate und Hostnamen. Eingehendes WAF kann keine ausgehenden Pfade abdecken, z. B. Anwendungen, die böswillige komprimierte Antworten abrufen. S3 S11 S25 S27 S30 S32
Neu erstellen, alte Prozesse ersetzen und über echte Servicepfade überprüfen. Sperrdatei und Image-Digest speichern, Anwendung und Image neu erstellen, Ersatz für alle Worker/JVM/Container bereitstellen; Überprüfen Sie den tatsächlichen Prozess, den Abhängigkeitsbaum, den Trust Store und die Geschäftsregressionstests. Eine neuere Befehlszeilenversion allein stellt nicht sicher, dass die Behebung abgeschlossen ist.
Wenn LiteLLM 1.107.0 installiert oder ausgeführt wurde, befolgen Sie die Verfahren zur Reaktion auf Vorfälle. Das Projekt bestätigte die Freigabekompromittierung am 21. Oktober. Isolieren Sie betroffene Umgebungen, untersuchen Sie sie in einer sauberen Umgebung, erstellen Sie die offengelegten Anmeldeinformationen neu und rotieren Sie sie. Starten Sie Python/pip nicht in einer verdächtigen Umgebung, um es zuerst zu überprüfen. Einzelheiten finden Sie in Abschnitt 9. S41

1. Schwachstellenübersicht und Risikobewertung

1.1 Priorisierung der Sanierung nach tatsächlicher Gefährdung

Bei den unten aufgeführten Bereitstellungsprioritäten handelt es sich um Implementierungsrichtlinien. Die Schweregradbezeichnungen folgen jedem Anbieter, einschließlich der Important-Bewertung von Apache. CVSS 3.1 und 4.0 sind unterschiedliche Bewertungssysteme; Ordnen Sie die Probleme nicht allein nach der Punktzahl.

Ökosystem / Schicht	Schlüsselthemen	Offizielle Note oder verifizierte Punktzahl	Vorrangige Bereitstellung
Node.js native Abhängigkeit	CVE-2026-111497: Brotli ist außerhalb des zulässigen Bereichs geschrieben und es besteht die Gefahr von RCE	Node：High	Dekodieren Sie die Brotli-Daten S1 S3 im externen Anforderungstext oder in der externen Antwort
Node.js TLS / DNS	CVE-2026-105482, 105483, 106069: Parsing und Identitätsüberprüfung sind inkonsistent	High	URL Crawl, Proxy, Webhook, dynamische Zieladresse S1 S5 S6
Node.js HTTP/2	CVE-2026-56846, 56848: Speicher erschöpft und UAF	High	Node verarbeitet nicht vertrauenswürdigen HTTP/2-Verkehr S7 direkt
React / Next.js	RSC / `use cache` typed arrays RCE	Critical；CVSS 4.0 9.5	Server RSC, zugehörige Cache-Komponenten und Datenpfad S9 S10
Next.js Bildoptimierung	CVE-2026-96889: SVG Bildverarbeitung RCE	Critical；CVSS 4.0 9.5	Instanzen auf glibc Linux, die nicht vertrauenswürdige Bilder S11 verarbeiten können
Next.js Server Actions	Eine speziell gestaltete Anfrage führt dazu, dass CPU erschöpft ist	High；CVSS 4.0 8.2	App Router und mindestens ein Server Action S12
Java TLS Vertrauen	CVE-2026-91403: Vertrauen Sie weiterhin dem betroffenen Zwischenprodukt CA	CVSS 3.1 9.1	TLS/API Szenario S17 mit betroffener Vertrauenskette
Tomcat	JNDIRealm-Authentifizierungsumgehung, HTTP/2-Cross-Request-Verwechslungen, AJP-Antwortverlust	Important	Entspricht dem Realm / Connector / async Servlet-Pfad S21 S22 S23
Spring for GraphQL	CVE-2026-59285: Paging-Deserialisierung RCE	High	Jackson 2 + Connection Paging + ausnutzbarer Klassenpfad S25
Spring Security	CVE-2026-59270: Eingebettete bekannte Verwaltungsidentität LDAP offengelegt	Critical	Der eingebettete LDAP ist aktiviert und der Überwachungsport ist für den Angreifer S27 zugänglich
CPython `ssl`	CVE-2026-19445: Der Kontextwechsel von SNI führt zu UAF	Critical	Python beendet TLS selbst und erfüllt die Kontextlebenszyklusbedingung S29
CPython `ssl`	CVE-2026-19553: Überprüfung überspringen, wenn der Hostname fehlt	High	`wrap_bio()` / Zugehöriger asynchroner Aufruf fehlt erwarteter Hostname S30
CPython `tarfile`	CVE-2026-82049: Umgehung der Kombination aus festem Link und symbolischem Link	High	Nicht vertrauenswürdiges TAR-Archiv S32 automatisch extrahieren
Django / GeoDjango	CVE-2026-15307: Schreibdatei für räumliche Abfragen, SSRF, unter der Bedingung RCE	High	Räumliche Abfragen oder verwandte Verwaltungsschnittstellen, die nicht vertrauenswürdige Eingaben akzeptieren S38
Python-Zertifikatabhängigkeit	certifi: emSign-bezogenes Zertifikatsmisstrauen	Critical; GHSA, keine bekannt CVE	Das TLS-Client- und Paketverwaltungstool S36 S37 verwendet weiterhin das betroffene CA bundle

Abkürzungen: RCE steht für Remote Code Execution, UAF steht für Use-After-Free und SSRF steht für Server-Side Request Forgery. Die direkten Berechtigungen von RCE sind normalerweise die Berechtigungen des Prozesses, der die Anwendung hostet, und können nicht automatisch den Root-Berechtigungen entsprechen.

Empfohlene Reihenfolge: behandelt zuerst RCE, das extern erreichbar ist und die Bedingungen, Authentifizierungsumgehung, benutzerübergreifende Datenlecks und Zertifikatauthentifizierungsprobleme erfüllt; Planen Sie gleichzeitig Aktualisierungen für den öffentlich zugänglichen Einstiegspunkt DoS. Es ist nicht erforderlich, Angriffsnutzlasten in der Produktion auszuführen, um die Ausnutzbarkeit nachzuweisen. Es bestehen Abhängigkeiten, Codepfade sind erreichbar und Angriffsbedingungen sind erfüllt. Dies sind drei Punkte, die separat geprüft werden müssen.

1.2 Drei leicht zu verwechselnde Grenzen

Runtimes und Abhängigkeiten separat aktualisieren. Sicherheitsupdates für Node, JDK, CPython reparieren eigenständige Installationen von Next.js, Spring, Django nicht automatisch. certifi oder native Erweiterungen.
Der Behebungsschwellenwert unterscheidet sich von der aktuellen Bereitstellungsbasislinie. Es ist nicht garantiert, dass der erste Patch für eine Schwachstelle im August neue Probleme von September bis Oktober abdeckt. Abschnitt 2 verwendet verifizierte Folgeaktualisierungen als Umsetzungsziel.
Unterscheiden Sie eine Schwachstelle von einer tatsächlichen Kompromittierung der Lieferkette. Bei häufigen Schwachstellen eliminieren Patches zukünftige Angriffspfade; Wenn bösartige Pakete ausgeführt wurden, müssen die Auswirkungen von Anmeldeinformationen und Persistenz untersucht werden. LiteLLM von Abschnitt 9 ist das offiziell bestätigte Ereignis. S41

Ob es bestätigte Ausbeutungen in freier Wildbahn gibt, sollte auf offiziellen Offenlegungen basieren. Der Anbieter hat die Ausnutzungsaktivitäten nicht erwähnt und kann nicht nachweisen, dass es sich nicht um einen Angriff handelt; Die Behebung sollte auf der Grundlage der tatsächlichen Angriffsfläche erfolgen.

2. Schnelle Überprüfung der festen Version und der Bereitstellungsbasislinie

Verweis: 2.1 Node.js、React、Next.js

Komponente/Zweig	Empfohlene Basisversion	Gebrauchsanweisung
Node.js 22.x	22.23.4	Sicherheitsveröffentlichung S1 S2 am 21. Oktober
Node.js 24.x	24.22.1	Gilt für den 24.x-Zweig; 24.22.0 enthält nicht den Sicherheitspatch S1 S2 vom 21. Oktober
Node.js 26.x	26.12.1	Sicherheitsversion im selben Batch S1 S2
Node.js 20 und frühere Upstream-Zweige	Migrieren Sie zu einem unterstützten Zweig	Node 20 akzeptiert diesen Upstream-Fix nicht; Der erweiterte Support des Herstellers muss separat überprüft werden S3
Next.js 15.x	15.5.28	Aktualisiert am 14. Oktober S8
Next.js 16.x	16.4.1	Wie oben S8
Eigenständiger RSC 19.0 / 19.1 / 19.2 / 19.3-Zweig	19.0.9 / 19.1.10 / 19.2.9 / 19.3.1	Überprüfen Sie die drei `react-server-dom-*`-Pakete separat; Schauen Sie sich nicht nur die oberste Schicht `react` S10 an
Next hat tatsächlich `sharp` geladen	≥0.35.5	Offizielle Bedingungen für die vorübergehende Behebung der Schwachstelle SVG; ersetzt nicht andere Next.js-Patches S11

Node listet offiziell die betroffenen Wartungszweige für die Schwachstelle vom Oktober auf, stellt jedoch nicht die ursprünglich eingeführte Patchversion Stück für Stück bereit, sodass die genaue Startversion jeder Schwachstelle nicht allein anhand des Wartungszweigbereichs bestimmt werden kann. Geben Sie bei der Bereitstellung Vorrang der Verwendung der oben genannten Version desselben Zweigs oder einer Folgeversion, von der bestätigt wurde, dass sie dieselben Fixes enthält.

2.2 Java: Oktober CPU plus Out-of-Band-Zertifikatsaktualisierung

Diese Tabelle gilt für Oracle JDK. Die zweite Spalte deckt nur den CPU vom 20. Oktober ab; der dritte beinhaltet die Out-of-Band-Veröffentlichung vom 21. Oktober. Die CPU-Versionen allein decken nicht alle hier besprochenen Java-Risiken ab. S16 S17 S18

Zweig	20. Oktober CPU	Oracle wurde am 21. Oktober außerhalb der Band veröffentlicht
11	11.0.33	11.0.33.0.2
17	17.0.21	17.0.21.0.2
21	21.0.13	21.0.13.0.2
25	25.0.5	25.0.5.0.2
27	27.0.1	27.0.1.0.2
8	8u511	Die öffentliche Release-Tabelle zeigt immer noch 8u511; Der spezifische Sicherheitsaufbau und die Reparatur der Vertrauenskette müssen überprüft werden und können nicht allein anhand der kurzen Versionsnummer bestimmt werden

**Java 8 muss anhand der vollständigen Build-Informationen überprüft werden:**Oracle In der Warnung wird 8u511 als betroffene Version aufgeführt, und in der Release-Liste werden nachfolgende Updates mit demselben Kurznamen aufgeführt. Anhand der kurzen Versionsnummer „8u511“ allein lässt sich der Patch-Stand nicht unterscheiden. Sie sollten die spezifischen Korrekturen für den Sicherheitsaufbau und die Vertrauenskette bestätigen. S17 S18

Temurin , Corretto , Zulu , Microsoft Build of OpenJDK , Release-Version OpenJDK usw., überprüfen Sie anhand ihrer jeweiligen Ankündigungen und vollständigen Paket-/Build-Nummern. Zum Beispiel das offizielle Veröffentlichungsprotokoll von Adoptium gibt an, dass der relevante Build neu gepackt wird, um das hinzuzufügen eMudhra Fix; Der gleiche Name der Upstream-Version bedeutet nicht, dass der Paketinhalt derselbe ist. Der .0.2 Suffixregeln für Oracle kann nicht automatisch auf andere Verlage übertragen werden. S20

Java Anwendungskomponenten	Empfohlene Basisversion	Bemerkungen
Tomcat 9 / 10.1 / 11	9.0.123 / 10.1.61 / 11.0.27	Überprüfen Sie Zweig für Zweig; Tomcat 10.0 hat die Wartung S21 S22 S23 gestoppt
Spring for GraphQL 2.0.x	2.0.5（OSS）	Kommerzieller Support ist auch 2.0.4.1 S25
Spring Security 7.1 / 7.0	7.1.1 / 7.0.7（OSS）	Entspricht der im August angekündigten Mindestfixversion; Sie müssen vor der Bereitstellung das nachfolgende Sicherheitsbulletin S27 S28 prüfen
Spring Security 6.5 / 6.4 / 5.8 / 5.7	6.5.12 / 6.4.19 / 5.8.28 / 5.7.26	Die Ankündigung wird als kommerzieller Support-Fix aufgeführt; Die Migration wird bewertet, wenn keine entsprechende Unterstützung vorhanden ist und nicht davon ausgegangen werden kann, dass Maven Central kostenlos verfügbar ist. S27

Spring-Upgrades sollten die Mindestversionen und Kompatibilitätslinien des Projekts Spring Boot BOM, Java berücksichtigen. Erzwingen Sie nicht direkt alle Spring-Module auf die gleiche Nummer, nur um einen Patch zu erhalten.

2.3 CPython, Django und Zertifikatabhängigkeiten

Die zweite Spalte der folgenden Tabelle konzentriert sich auf die im September bekannt gegebene Emission TLS; Die Zweigunterschiede für tarfile werden im Abschnitt 5.3. angezeigt. Mit den Veröffentlichungen vom 21. Oktober wurden auch die gebündelten Zertifikatstools aktualisiert, sodass die letzte Spalte diese späteren Bereitstellungsbasislinien enthält. S29 S30 S33 S35

CPython-Zweig	Sicherheitsbatch-Mindestversion vom September	Empfohlene Bereitstellungsbasislinie
3.10	3.10.22	Letzte Veröffentlichung von Upstream, EOL; Veranlassen Sie die Migration oder überprüfen Sie die Unterstützung der Release-Erweiterung S34
3.11	3.11.17	3.11.17 und aktualisieren Sie pip/certifi in jeder Umgebung einzeln
3.12	3.12.15	3.12.15 und aktualisieren Sie pip/certifi in jeder Umgebung einzeln
3.13	3.13.16	3.13.17
3.14	3.14.8	3.14.9
3.15	Die endgültige 3.15.0-Version enthält beide TLS-Fixes S31 S47	3.15.1

Die Upstream-Sicherheitsversionen von 3.11 und 3.12 dürfen nur im Quellcode veröffentlicht werden; Überprüfen Sie bei Verwendung des Betriebssystempakets die Backport-Beratung des Anbieters und die vollständige Paketversion. Es besteht keine Notwendigkeit, das System Python zwangsweise durch eine selbst kompilierte Version zu ersetzen. S33 S34

unabhängige Abhängigkeit	Empfohlene Basisversion	Beschreibung
Django 5.2 / 6.0 / 6.1	5.2.18 / 6.0.9 / 6.1.2	Nachträgliche Korrektur S38 S39 am 6. Oktober einbauen
certifi	≥2026.10.19	Der anfängliche Patch GHSA ist .18; PSF empfiehlt .19, um die Kompatibilität für nicht betroffene Zertifikate S36 S37 zu gewährleisten
pip	≥26.2.2	Die integrierte Kopie von certifi muss separat aktualisiert werden S35 S37
uv (falls verwendet)	≥0.13.4	Aktualisieren Sie S37 entsprechend der tatsächlichen Installationsmethode

Diese Baselines decken die aufgeführten Fixes ab. Ein weiteres Problem mittlerer Schwere in tar_filter wurde am 22. Oktober bekannt gegeben. Mit Stand vom 23. Oktober 2026 wurde eine offizielle Wartungsversion, die diesen Fix enthält, noch nicht bestätigt; Daher kann nicht davon ausgegangen werden, dass 3.13.17 / 3.14.9 / 3.15.1 alle Tarfile-Probleme abgedeckt hat. Siehe Abschnitt 5.4. S40

2.4 Verifizierung der Verteilungs-Backports

Implementierungsprinzipien, die für Ubuntu, Debian, RHEL und andere Softwarepakete gelten:

Notieren Sie die Betriebssystemversion, die Repository-Quelle, die vollständige Paketversion und die Nummer des Sicherheitsbulletins des Anbieters.
Bestätigen Sie, dass die Empfehlung das spezifische CVE abdeckt und ein festes Paket für die entsprechende Distributionsversion identifiziert.
Vergleichen Sie die vom tatsächlich laufenden Prozess geladenen Binärdateien/Bibliotheken, nicht nur die Upstream-Kurzversion.
Wenn es keine Hinweise auf einen Hersteller-Patch gibt, lassen Sie es „zu bestätigen“ und ziehen Sie nicht den einzigen Schluss, dass die Versionsnummer alt oder neu aussieht.

Es gibt Unterschiede in den apt/RPM-Paketversionen und Backport-Strategien verschiedener Distributionen. Das Sicherheitsbulletin und die vollständige Paketversion jeder Distribution sollten maßgebend sein.

3. Node.js / JavaScript-Ökosystem: Ursachenanalyse und Behebung

3.1 CVE-2026-111497: Nativer Decoder Brotli schreibt außerhalb der Grenzen

Offenlegung: 2026-10-21; Node offizielle Note: High. Betroffene Builds von Node 22.x, 24.x, 26.x erfordern die Installation des Patch-Abschnitts 2.1. Node In der Ankündigung wird kein numerischer CVSS-Score aufgeführt. S1

Das Problem tritt in der nativen Dekodierungslogik auf, wenn der fehlerhafte komprimierte Brotli-Stream verarbeitet wird, was zu Schreibvorgängen außerhalb der Grenzen führen kann. Die offizielle Beschreibung von Vercel bestätigt, dass die Forschungsdemonstration Prozessspeicherlecks und die Befehlsausführung beinhaltet. Ob ein Angreifer den Decoder erreichen kann, hängt davon ab, ob die Anwendung oder Abhängigkeit die von ihr kontrollierten Daten tatsächlich dekodiert. S3

Beide Richtungen müssen gleichzeitig überprüft werden:

inbound: Das-Framework oder die Middleware dekomprimiert automatisch den vom Benutzer übermittelten Brotli-Anforderungstext.
**outbound:**HTTP Clients, Image Grabber usw. greifen auf vom Angreifer kontrollierbare Quellen zu und dekomprimieren den zurückgegebenen Inhalt automatisch.

Durch das Deaktivieren der Brotli-Komprimierung von an Browser gesendeten Antworten wird kein Decodierungseinstiegspunkt entfernt. Der eingehende WAF-Schutz deckt außerdem nicht Anwendungen ab, die externe Antworten abrufen und dekodieren. S3

**Patch-Richtung:**Node Verschieben Sie den Upstream-Fix Brotli in die native Abhängigkeit und ergänzen Sie die Überprüfung des illegalen Decodierungsstatus und die Fehlerweitergabe. Wenn Sie eine selbst kompilierte Version pflegen, sollten Sie die offizielle Sicherheitsversion oder den vollständigen Patch des passenden Zweigs verwenden. Sie können nicht einfach die Versionsangabe eines JavaScript-Pakets ändern. S4

Vorläufige Implementierungsvorschläge: stoppt unnötige, nicht vertrauenswürdige Brotli-Dekodierung; Überprüfen Sie das automatische Dekomprimierungsverhalten der Middleware und des HTTP-Clients. Wenn das Unternehmen dieses Format akzeptieren muss, schließen Sie die Verarbeitung so schnell wie möglich in der gepatchten Umgebung ab. Das Anpassen von Accept-Encoding ist lediglich ein Verhandlungsakt und sollte nicht allein als Beweis dafür dienen, dass eine böswillige Reaktion blockiert wurde.

3.2 TLS / DNS drei High: Das Verifizierungsobjekt stimmt nicht mit dem tatsächlichen Ziel überein

Alle drei wurden am 21. Oktober bekannt gegeben, wobei der offizielle Upgrade-Schwellenwert im Abschnitt 2.1. S1 festgelegt ist

Kennung	Problem bestätigt	Betroffene Filialen
CVE-2026-105482	`dns.resolve` Kürzung von Namen, die NUL enthalten	22.x / 24.x / 26.x
CVE-2026-105483	IP in voller numerischer Form führt dazu, dass die Überprüfung des Zertifikat-Hostnamens umgangen wird	24.x / 26.x
CVE-2026-106069	Ein Hostname, der lose als IP interpretiert werden kann, führt zur Umgehung der TLS-Überprüfung	22.x / 24.x / 26.x

DNS Der Kern des Problems besteht darin, dass die von der oberen Schicht überprüfte Zeichenfolge sich von dem tatsächlich von der unteren Schicht analysierten Namen unterscheidet. Der offizielle Patch lehnt NUL beim Parsing-Eintrag ab und fügt eine Regressionsabdeckung hinzu. S6

TLS Zwei Elemente betreffen die Namensnormalisierung, die Konsistenz der IP-Interpretation und den Zertifikatsabgleich. Patch, damit nicht standardmäßige IP-Eingaben abgelehnt oder korrekt verarbeitet werden, um eine Verwechslung des tatsächlichen IP-Endpunkts mit der Zertifikatdomänenidentität zu vermeiden. S5

Aktuelle Vorschläge zur Fehlerbehebung für : geben der Überprüfung des Codes des empfangenden Benutzers URL, des dynamischen Proxy-Ziels oder der Webhook-Adresse Vorrang; einheitliche Standardisierung und Zulassungslistenbeurteilung, lehnt NUL/Steuerzeichen ab, bestätigt, dass legale IPv4, IPv6 und internationalisierte Domänennamen weiterhin funktionieren. Ob SSRF weitergebildet werden kann, erfordert die Anwendung von Linknachweisen, die nicht direkt aus dem Namen CVE abgeleitet werden können.

Verwenden Sie NODE_TLS_REJECT_UNAUTHORIZED=0 oder rejectUnauthorized: false nicht, um Prüfsummenfehler nach dem Upgrade zu beseitigen. Die Adresse, das Zertifikat und die Geschäftskonfiguration sollten korrigiert werden.

3.3 Juli HTTP/2 High – Probleme mit Risiko- und Berechtigungsmodellen

Die folgenden im Juli offengelegten Sachverhalte müssen noch in die Untersuchung einbezogen werden. Es wird empfohlen, bei der Bereitstellung direkt die Baseline der Oktober-Sicherheitsversion im Abschnitt 2.1 zu verwenden. S7

CVE	Ursachen und Wirkungen	Erste feste Version
CVE-2026-56846	Der beibehaltene HTTP/2 header-Block ist nicht ordnungsgemäß im `maxSessionMemory`-Budget enthalten und kann den Speicher erschöpfen. Auswirkung 22.x / 24.x	22.23.2 / 24.18.1
CVE-2026-56848	HTTP/2 tritt während der Paketsammlung erneut in den Sendepfad ein und verursacht einen Heap UAF; Auswirkung 22.x / 24.x / 26.x	22.23.2 / 24.18.1 / 26.5.1
CVE-2026-58043	`--permission` Die Übereinstimmung mit der Pfadpräfixgrenze ist zu weit und es kann auf Dateien außerhalb der zulässigen Liste zugegriffen werden.	Identisch mit den drei Wartungszeilen oben

Alle drei sind offiziell High. Bei den ersten beiden Punkten wird vorrangig geprüft, ob HTTP/2 von Node selbst verarbeitet wird. Das dritte Element hat nur dann eine entsprechende Bedeutung, wenn das Berechtigungsmodell verwendet und auf diese Grenze zurückgegriffen wird. Nicht alle Berechtigungsmodellelemente können als Netzwerk RCE beschrieben werden, das keine Authentifizierung erfordert. S7

Die vorübergehende Beendigung von HTTP/2 auf einem separaten, aktualisierten Proxy und die Einschränkung von Backend-Quellen ist eine Bereitstellungsoption zur Reduzierung der Gefährdung; Ressourcenkontingente können nur die Folgen einer Ressourcenerschöpfung kontrollieren und UAF nicht patchen.

3.4 Oktober React / Next.js: zwei Artikel RCE und ein Artikel DoS

A. RCE in RSC / `use cache`-Funktionen, die typisierte Arrays zurückgeben

Veröffentlichungsdatum: 2026-10-14; Critical, CVSS 4.0 9.5. Offizielle Empfehlungskennungen:

React：GHSA-xqc2-xf4c-x3h3。
Next.js：GHSA-673q-mjm6-r5xr。S9 S10

Das Upstream-Problem React betrifft mehrere typisierte Arrays in Kombination mit vom Angreifer kontrollierbaren Werten in der RSC-Antwort. Die drei betroffenen react-server-dom-*-Paketversionen sind 19.0.0—19.0.8, 19.1.0—19.1.9, 19.2.0—19.2.8, 19.3.0; siehe Kapitel Abschnitt 2.1. Reine browserseitige React oder Anwendungen, die keine Frameworks/Plug-Ins verwenden, die RSC überhaupt unterstützen, fallen nicht in den Geltungsbereich dieses Artikels. S10

Next.js Downstream-Ankündigungslisten 16.0.0 – 16.4.0, überarbeitet in 16.4.1; Das Szenario besteht aus den Funktionen App Router, Cache Components und use cache, die mehrere typisierte Arrays zurückgeben. Es gibt keine offizielle, zuverlässige allgemeine Problemumgehung und Benutzer betroffener Versionen müssen rechtzeitig ein Upgrade durchführen. Es ist nicht angebracht, sich einfach auf die manuelle Suche nach „Diese Funktion scheint nicht zu existieren“ zu verlassen, um die Verarbeitung zu beenden. S9

Verweis: B. SVG Image Optimization RCE

CVE-2026-96889/GHSA-2464-fhr4-w9xw, 2026-10-14, Critical, CVSS 4.0 9.5. Das Problem tritt in der nativen Upstream-Bibliothek auf, die für die Bildoptimierung verwendet wird. Beamte wiesen darauf hin, dass im Szenario glibc Linux das Risiko RCE besteht. S11

Die offiziellen Versionsfelder sind:

>=10.0.0 <=15.5.27；
>16.0.0 <=16.4.0。

Der Beamte verwendet eine strikte Untergrenze von >16.0.0 für den 16.x-Zweig, aber diese Bereichsangabe reicht nicht aus, um zu beweisen, dass 16.0.0 sicher ist. Das eigentliche Upgrade-Ziel ist einheitlich 15.5.28 / 16.4.1. S11

Die offizielle vorübergehende Lösung besteht darin, sicherzustellen, dass Next tatsächlich scharfes ≥0.35.5 lädt. Sperrdateien, verschachtelte Abhängigkeiten und Bereitstellungsbilder enthalten möglicherweise noch alte Instanzen. Daher reicht es nicht aus, nur eine neue Version der sharp-Abhängigkeit auf der obersten Ebene hinzuzufügen. Der endgültige Abhängigkeitsbaum sollte überprüft und neu erstellt werden. S11

C. Server Actions CPU erschöpft

**GHSA-p3m5-59mp-jv5r, 2026-10-14, High, CVSS 4.0 8.2.**Next betrifft 13.0.0—15.5.27, 16.0.0 – 16.4.0, behebt 15.5.28 /16.4.1. Die Bedingungen sind App Router und mindestens ein Server Action; Böswillige Anfragen können CPU lange Zeit beschäftigen und nachfolgende Anfragen im selben Prozess blockieren. Anwendungen mit Pages Router oder ohne Server Actions sind hiervon nicht betroffen. S12

Es gibt keinen offiziellen Workaround, der das Upgrade ersetzen kann. Ratenlimits, Parallelitätslimits und Ressourcenkontingente können den Schaden reduzieren, können aber nicht als Schlussfolgerung für die Patch-Verifizierung herangezogen werden.

3.5 Früheres Next.js im selben Fenster Schwerwiegendes Problem

Die folgenden Punkte sollen verhindern, dass Bereitstellungen fehlen, die bei Versionen vor August und September immer noch hängen bleiben. Es wird nicht empfohlen, jetzt einfach zu den alten Fixschwellenwerten in der Tabelle zu wechseln.

Datum	Identifikator/Szenario	Erster Fix; aktuelle Aktion
2026-08-25	GHSA-2xp9-vwfh-vxw4: AVIF native Bildoptimierungsbibliothek RCE, Critical	15.5.24 / 16.3.3; jetzt 15.5.28 / 16.4.1 S13
2026-08-25	CVE-2026-75604: RCE, Critical, wenn Pages Router und App Router gleichzeitig auf Windows verwendet werden und Cache Components nicht aktiviert ist; Versionen `>=13.4.0 <15.5.24`, `>=16.0.0 <16.3.3`	15.5.24 / 16.3.3; Linux/macOS sind von diesem speziellen Windows-Problem S14 nicht betroffen
2026-09-22	GHSA-vcvr-r3jv-pc5j: Der Bildgenerierungspfad Node in `next/og` verarbeitet nicht vertrauenswürdige SVG, Critical; 16.2.0—16.3.5	16.3.6; Die Edge-Implementierung liegt außerhalb des Geltungsbereichs dieses Problems und 15.x ist kein betroffener Zweig für diesen RCE S15

4. Java-Ökosystem: Laufzeitvertrauen, Container und Frameworks werden separat behandelt

4.1 JDK: Regelmäßige CPU und CVE-2026-91403 sind zweistufige Updates

Die Java SE-Risikomatrix für Oracle CPU vom 20. Oktober listet 55 neue Sicherheitspatches auf, von denen 49 als über das Netzwerk ohne Authentifizierung ausnutzbar gekennzeichnet sind. Dies bedeutet nicht, dass es 55 Critical gibt, und es bedeutet auch nicht, dass es 49 direkt ausnutzbare RCE-Pfade für jeden Java-Webdienst gibt; Es muss in Verbindung mit den Komponenten, APIs, Benutzerinteraktionen und Bereitstellungsbedingungen in der Matrix verstanden werden. S16

Das CVE-2026-91403 (CVSS 3.1 9.1) des nächsten Tages befasst sich mit einer anderen Art von Risiko: einer Reihe von Zwischenrisiken CA im Zusammenhang mit dem eMudhra-Ereignis, dem nicht mehr vertraut wird. Sie betrifft die Peer-Authentifizierung TLS und die Vertraulichkeit/Integrität der Kommunikation und kann nicht als Sicherheitslücke hinsichtlich Speicherbeschädigung JVM beschrieben werden. S17

Im Oracle-Advisory wird die am 20. Oktober veröffentlichte Version als betroffen aufgeführt, sodass auch das Out-of-Band-Update vom 21. Oktober installiert werden muss. Die spezifische Version finden Sie im Abschnitt 2.2. GraalVM verfügt auch über entsprechende betroffene Produkte, und die korrigierte Version sollte seinem exklusiven Sicherheitsbulletin unterliegen. S17 S18

Vorübergehende offizielle Maßnahmen: Führen Sie zunächst eine Sicherung durch und entfernen Sie dann das angegebene Stammzertifikat aus jedem tatsächlich verwendeten Truststore:

emSign ECC Root CA - G3, Oracle-Alias emsigneccrootcag3 [jdk].
AAA Certificate Services, Oracle-Alias comodoaaaca [jdk]. S19

JDK 11 und höher, das offizielle Beispiel ist:

keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"

Verwenden Sie für diese Befehle keytool vom Ziel JDK und bestätigen Sie, dass sie auf dem tatsächlichen Trust Store der Anwendung ausgeführt werden. Java 8 verwendet den Pfad, der jre/lib/security/cacerts entspricht; Das Anpassen des Truststores muss separat erfolgen und andere Herausgeber können andere Aliase haben. Durch das Entfernen des Stammzertifikats wird der Umfang der Ablehnung erweitert und legitime Dienstzertifikatketten einem Regressionstest unterzogen. S19

Der Beamte bietet auch die Möglichkeit, die Sperrprüfung zu aktivieren, die Auswirkung hängt jedoch von der tatsächlichen TLS-Implementierung, der Erreichbarkeit des Sperrdienstes und der Fehlerstrategie ab. Priorisieren Sie bei allgemeinen Bereitstellungen die Installation vollständiger Herstelleraktualisierungen, um zu vermeiden, dass zwei JVM-Switches als Beweis dafür betrachtet werden, dass alle TLS-Bibliotheken repariert wurden.

4.2 Tomcat: Authentifizierungsumgehung und benutzerübergreifende Anforderungsisolierung

Die folgenden drei Artikel wurden am 2026-10-20 veröffentlicht; Der Eintrag der reparierten Version trägt das Datum Oktober 12. Der offizielle Grad von Apache ist Important. S21 S22 S23

CVE	Bestätigte betroffene Versionen	Notwendige Szenarien/Ergebnisse
CVE-2026-101296	9.0.0.M1—9.0.122；10.1.0-M1—10.1.60；11.0.0-M1—11.0.26	JNDIRealm Konfiguriert einen Nicht-GSSAPI-SASL-Authentifizierungsmechanismus, die Überprüfung der Anmeldeinformationen fehlt und es können auch falsche Passwörter passieren
CVE-2026-101356	9.0.118—9.0.122；10.1.55—10.1.60；11.0.22—11.0.26	Bei der asynchronen Servlet-Fehlerbehandlung von HTTP/2 werden Objekte falsch recycelt/wiederverwendet, was dazu führt, dass Anforderungen oder Antworten zwischen Benutzern gemischt werden
CVE-2026-103119	Bestätigen Sie nur 11.0.0-M25—11.0.26	Große nicht blockierende AJP-Schreibvorgänge können dazu führen, dass der Puffer nicht ausreichend gelesen wird und frühere Antwortdaten in späteren Anforderungen offengelegt werden.

Der entsprechende Fix ist 9.0.123 / 10.1.61 / 11.0.27; AJP wird laut Ankündigung nur als Tomcat 11 aufgeführt und kann nicht auf drei Zweige mit dem gleichen Problem erweitert werden. S21 S22 S23

Der JNDIRealm-Patch behebt eine Verifizierungslücke im eigentlichen Authentifizierungsprozess, bei der „die Anmeldeschnittstelle der Anwendung sieht normal aus“ nicht anstelle der Verifizierung verwendet werden kann. Realm sollten SASL-Mechanismen auf die tatsächliche Konfiguration des Dienstes überprüft werden, und Tests müssen bei falschen Passwörtern fehlschlagen. S24

Vorläufige Implementierungsvorschläge: Isolieren Sie den betroffenen Authentifizierungspfad. die HTTP/2-Verarbeitung von Tomcat aussetzen, wenn das Geschäft dies zulässt; schließen nutzlos AJP. Nur die Einschränkung des direkten Zugriffs auf den AJP-Port kann nicht beweisen, dass der über den legalen Front-Proxy eingehende Datenverkehr nicht beeinträchtigt wird. Nach dem offiziellen Update sollten asynchrone gleichzeitige Anfragen von zwei unabhängigen Benutzern getestet werden, um sicherzustellen, dass es keine Überschneidungen zwischen Identitäten und Antworten gibt.

Verweis: 4.3 Spring for GraphQL：CVE-2026-59285

Veröffentlichungsdatum: 2026-08-20; High. betroffen 2.0.0—2.0.4, repariert 2.0.5 (OSS) oder 2.0.4.1 (kommerzielle Unterstützung). S25

Dies stellt ein unsicheres Deserialisierungsrisiko bei Paging-Abfragen dar. Die offizielle Vorgabe lautet, dass gleichzeitig folgende Bedingungen erfüllt sein müssen:

Verwenden Sie Spring for GraphQL.
Deserialisieren Sie JSON mit Jackson 2.x.
Stellen Sie ein Verbindungs-Paging-Feld zur Außenwelt bereit.
Der Klassenpfad enthält bestimmte Klassen, die während der Instanziierung oder Deserialisierung unerwartete Logik ausführen können.

Eine böswillige GraphQL-Anfrage kann zu RCE führen, wenn die Bedingungen erfüllt sind. Es kann nicht auf „alle Java-Programme, die Jackson verwenden, ausgenutzt werden“ reduziert werden. S25

Warum 2.0.4 nicht ausreicht: Im Juni hatte CVE-2026-41699 Patch-Baselines wie 2.0.4 bereitgestellt, und im August wurde 2.0.4 in der Ankündigung eindeutig in den neuen Einflussbereich einbezogen. Daher muss das Reparaturprotokoll entsprechend späterer Ankündigungen aktualisiert werden und die Mindestversion des alten CVE kann nicht verwendet werden. S26

Wenn das Upgrade vorübergehend nicht verfügbar ist, können betroffene Paginierungsfelder, auf die nicht vertrauenswürdige Anrufer zugreifen können, gesperrt werden. Die Eingrenzung der deserialisierbaren Typen und Klassenpfade ist eine tiefgreifende Maßnahme. Regressionen sollten zulässige Cursor, paginierte Ergebnisse und Ablehnungen von Ausnahmeeingaben abdecken und die tatsächlichen Komponentenversionen innerhalb der endgültigen Anwendungs-JAR überprüfen.

4.4 Spring Security: CVE-2026-59270 und damit verbundene Authentifizierungsrisiken

CVE-2026-59270, 2026-08-20, Critical. eingebettet UnboundIdContainer registriert standardmäßig bekannte Administratoranmeldeinformationen und lauscht auf allen Netzwerkschnittstellen. Wenn die Komponente aktiviert und der Port erreichbar ist, kann ein Angreifer Verzeichnisdaten lesen oder ändern; Projekte, die im Allgemeinen Spring Security einführen, machen LDAP nicht automatisch verfügbar. S27

Betroffener Bereich:

Zweig	betroffen	Erster Fix-/Erfassungskanal
7.1	7.1.0	7.1.1 OSS; auch kommerziell 7.1.0.1
7.0	7.0.0—7.0.6	7.0.7 OSS; auch kommerziell 7.0.6.1
6.5 / 6.4	6.5.0—6.5.11；6.4.0—6.4.18	6.5.12/6.4.19, kommerziell
5.8 / 5.7	5.8.0—5.8.27；5.7.0—5.7.25	5.8.28/5.7.26, kommerziell

Quelle: S27. Fehlerbehebung bei der automatischen Konfiguration spring.ldap.embedded.* und dem direkten Instanziierungscode; Schließen Sie die Komponente, wenn sie nicht für die Produktion benötigt wird, und überprüfen Sie die tatsächliche Abhöradresse. Wenn das Unternehmen es wirklich benötigt, begrenzen Sie zunächst die Anrufquellen und schließen Sie dann das Komponenten-Upgrade ab.

**Zugehöriges Authentifizierungsproblem: CVE-2026-47841 (High).**WebAuthn Die Benutzerauthentifizierung ist auf REQUIRED eingestellt, und nachdem die HTTP-Sitzung durch verteilten Speicher serialisiert wurde, kann ein falscher Objektidentitätsvergleich die Authentifizierungsanforderung ungültig machen. Der Angriff setzt außerdem voraus, dass der Angreifer im Besitz des Benutzerauthentifizierungsgeräts ist, und nicht durch willkürliche Fernanmeldung ohne Gerät. Für die entsprechenden betroffenen Versionen von 7.1, 7.0, 6.5 und 6.4 stimmt die Patch-Baseline mit diesen Zweigen in der obigen Tabelle überein; Die Verifizierung sollte knotenübergreifende Sitzungen abdecken und dennoch eine PIN-/biometrische Verifizierung erfordern. S28

5. Python-Ökosystem: Interpreter, Standardbibliothek, Framework und Zertifikate

5.1 CVE-2026-19445: SSLContext UAF im SNI-Rückruf

Veröffentlichungsdatum: 2026-09-30; PSF Level: Critical. Im Python-Server TLS wechselt sni_callback die Verbindung zu einem anderen SSLContext. Wenn der ursprüngliche Kontext keine anderen überlebenden Referenzen aufweist, stürzt der nicht authentifizierte TLS-Client möglicherweise ab den Dienst oder rufen Sie einen Zeiger in einem freigegebenen Objekt auf. S29

Der Kern besteht darin, dass das Python-Objekt nicht mit dem zugrunde liegenden Rückruflebenszyklus TLS übereinstimmt. Der ursprüngliche Kontext wurde freigegeben und die darunter liegende Ebene enthält möglicherweise immer noch den für den Rückruf erforderlichen Status. Der native Patch des Interpreters muss verwendet werden, um den Referenzlebenszyklus zu reparieren. S47

Scope: Python-Code, der nur als TLS-Client fungiert, ist von diesem Element nicht betroffen; Der normale Modus des Listening-Sockets, der den ursprünglichen Kontext über einen längeren Zeitraum beibehält, fällt nicht in den in der Ankündigung beschriebenen spezifischen Fehlerpfad. Nachdem Nginx TLS beendet hat, übergibt es nur das lokale HTTP an Python, und Python verarbeitet SNI direkt selbst, was eine andere Angriffsfläche darstellt. S29

Entspricht der festen Version von 3.10—3.14, siehe Abschnitt 2.3.. Die offizielle Version von 3.15 wurde repariert und 3.15.1 kann tatsächlich ausgewählt werden. Nur die Aktualisierung der pip-Abhängigkeit kann die _ssl-Implementierung des Interpreters nicht ersetzen. S33 S35 S47

Offizielle vorübergehende Abhilfe: behält starke Verweise auf alle SSLContext bei, die den SNI-Rückruf bis zum Ende des Serverlebenszyklus festgelegt haben. Dies muss die tatsächlichen dynamischen Erstellungs- und Umschaltpfade abdecken; Der benutzerdefinierte OpenSSL 1.1.1-Build sollte auch die Neuverhandlungsbedingungen in Verbindung mit dem offiziellen Issue-Datensatz überprüfen und vollständigen Updates Vorrang einräumen. S29 S47

5.2 CVE-2026-19553: Das Hostnamen-Flag ist aktiviert, aber der Hostname fehlt beim Aufruf

Veröffentlichungsdatum: 2026-09-30; High. WennSSLContext.check_hostname=True wrap_bio() nicht in server_hostname übergeben wird, überspringt die ursprüngliche Implementierung möglicherweise stillschweigend die Überprüfung des Hostnamens. Eine erfolgreiche Überprüfung der Zertifikatskette bedeutet nicht, dass auch der Zieldomänenname abgeglichen wurde. S30

Die Sanierung erfordert beide Schritte:

Installieren Sie die im Abschnitt 2.3. aufgeführte Interpreter-Sicherheitsversion
Überprüfen Sie die Pfade wrap_bio() und asyncio.create_connection()/loop.start_tls(), übergeben Sie explizit den erwarteten und nicht leeren Hostnamen und lassen Sie die Zertifikatsüberprüfung aktiviert. S30

**Kompatibilitätsunterschiede, die nicht weggelassen werden können:**3.10, 3.11, 3.12 dienen der Kompatibilität. In einigen Fällen, in denen der Hostname fehlt, wird nur DeprecationWarning ausgegeben. 3.13 und später erhöhen ValueError. Der 3.12-Backport unterscheidet None auch deutlich von leeren Zeichenfolgen: Für None wird eine neue Warnung hinzugefügt, und für leere Zeichenfolgen wird weiterhin ein Fehler gemeldet. Daher können Benutzer mit geringer Verzweigung nicht davon ausgehen, dass die ursprünglich fehlende Überprüfung des Domänennamens einfach durch ein Upgrade automatisch wiederhergestellt wurde. S31 S33

Verwenden Sie in einer Testumgebung ein Zertifikat einer vertrauenswürdigen Kette mit einem nicht übereinstimmenden Hostnamen und bestätigen Sie, dass der TLS-Client der tatsächlichen Anwendung es ablehnt. Das bloße Lesen des booleschen Werts check_hostname stellt keine vollständige Akzeptanz dar.

5.3 CVE-2026-82049: Linkkombinationsumgehung im Tarfile-Filter

Veröffentlichungsdatum: 2026-09-14; High. In CPython 3.13 und früheren verwandten Implementierungen kann die Kombination von Hardlinks und symbolischen Links in nicht vertrauenswürdigem TAR den Extraktionsfilter data/tar umgehen, wodurch der Inhalt von Dateien außerhalb des Entpackverzeichnisses im Entpackbaum verfügbar gemacht oder deren Berechtigungen geändert werden und Änderungszeiten. S32

Zu den bestätigten Auswirkungen dieser Sicherheitslücke gehören die Offenlegung von Dateiinhalten und die Änderung von Metadaten. Diese Auswirkungen allein reichen nicht aus, um das willkürliche Überschreiben externer Dateiinhalte oder die bedingungslose Implementierung von RCE nachzuweisen.

Die entsprechenden Patch-Baselines von 3.10–3.13 finden Sie im Abschnitt 2.3.. Python. 3.14 wurde aufgrund von Verhaltensänderungen von os.link() seit 3.14.0b1 von diesem speziellen Problem ausgenommen. Daher gilt der betroffene Bereich des oben genannten Zweigs 3.10–3.13 nicht. S33

Vorübergehende und tiefgreifende Maßnahmen: setzt die automatische Extraktion nicht vertrauenswürdiger Archive aus; Verwenden Sie isolierte Arbeitsprozesse mit niedrigen Berechtigungen und neue exklusive Verzeichnisse, wenn Geschäfte verarbeitet werden müssen, verweigern Sie symbolische Links, Hardlinks und Geräteeinträge durch Unternehmen und begrenzen Sie die Anzahl der Dateien und Dekomprimierungsressourcen. Dies sind Bereitstellungsempfehlungen.

filter="data" eignet sich besser für allgemeine nicht vertrauenswürdige Archive als die vollständige Vertrauensstrategie, aber auch der Filter selbst in der alten Version weist diese Schwachstelle auf, und das Hinzufügen dieses Parameters allein kann das Update nicht ersetzen. Der Filter ist auch keine vollständige Dateisystem-Sandbox. S32 S45

5.4 Zusätzliches Risiko: CVE-2026-114583 (Medium) und Patch-Release-Status

PSF gab in 2026-10-22 bekannt, dass die Verarbeitung bestimmter Linknamen durch tarfile.tar_filter umgangen werden kann, sodass nachfolgende Mitglieder mit der Ebene Medium außerhalb des Entpackverzeichnisses schreiben können. Der offizielle Fix PR wurde an diesem Tag zusammengeführt; Bis zum 23. Oktober 2026 wurde keine offizielle Wartungsversion bestätigt, die diesen Commit enthält. S40

Deshalb:

Dieser Artikel wird separat als Medium aufgeführt.
Es kann nicht davon ausgegangen werden, dass die am 21. Oktober veröffentlichten Interpreterversionen diesen Fix enthalten.
Der Prozess, der immer noch filter="tar" verwendet, um nicht vertrauenswürdige Archive zu verarbeiten, sollte den Release-Backport verfolgen; Isolieren oder unterbrechen Sie diesen Verarbeitungspfad für kurze Zeit. Wenn Sie zu data wechseln und Links ablehnen, müssen Sie außerdem bestätigen, dass diese den Geschäftsanforderungen entsprechen und das Ändern des Filters nicht als bedingungslose Sandbox beschrieben werden kann.

5.5 GeoDjango: CVE-2026-15307 und nachfolgende Korrekturen im Oktober

2026-08-04, Django offiziell High. räumliche Abfrage übergibt implizit bestimmte Zeichenfolgen/Wörterbücher an GDALRaster, und der Treiber kann Dateien schreiben oder Netzwerkanforderungen initiieren; RCE kann gebildet werden, wenn bestimmte Pfade und nachfolgende Ausführungsbedingungen vorliegen. Mitarbeiter mit Berechtigungen zur Anzeige räumlicher Feldmodelle können auch über die Administrator-Änderungsliste auf diesen Pfad zugreifen. S38

Der erste Fix ist 5.2.17 / 6.0.8, der die von räumlichen Lookups akzeptierten Eingabetypen einschränkt. Diese Änderung kann sich auf das ursprüngliche Geschäft der Verwendung von Zeichenfolgen/Wörterbuch zum Ausdrücken von Rastern auswirken. Einfach nicht vertrauenswürdige Eingaben in GDALRaster einzuschließen, bedeutet nicht, sie zu überprüfen. S38

Am 6. Oktober wurde CVE-2026-87890 (Moderat) repariert: In Bytes ausgedrückte VRT kann auf externe Ressourcen verweisen und löst weiterhin Netzwerkanforderungen aus; Am selben Tag wurde auch der Schutz der verschachtelten Geometrie DoS von CVE-2026-15830 verstärkt. Die beiden letztgenannten können nicht aktualisiert werden, um das neue Hochrisiko-RCE zu beschreiben, geben jedoch an, dass die Bereitstellungsbasislinie 5.2.18 / 6.0.9 / 6.1.2 sein sollte. S39

Die Implementierung überprüft die beiden Einstiegspunkte API und Verwaltungsschnittstelle und schränkt nicht vertrauenswürdige räumliche Suche, Dateischreibberechtigungen und ausgehenden Zugriff ein. Führen Sie nach der Aktualisierung einen Regressionstest für gültige räumliche Abfragen durch und weisen Sie unzulässige Eingaben zurück. Gewöhnliche Django-Anwendungen, die GeoDjango nicht verwenden, sollten diese RCE-Schlussfolgerung nicht direkt anwenden.

5.6 certifi / pip: Die Vertrauenswürdigkeit des Zertifikats muss jede Kopie abdecken

GHSA-6q48-6c7w-9gw2, 2026-10-20, Critical, bekannt CVE nicht aufgeführt. Dies ist das Zertifikat-Misstrauens-Update, das durch den Zwischenfall eMudhra CA verursacht wurde. Es lässt sich nicht auf den Kryptografiemechanismus von HTTPS reduzieren oder darauf, dass alle Stammzertifikate geknackt wurden. S36

In der certifi-Beratung wurde 2026.10.18 ursprünglich als Patch aufgeführt; PSF empfahl später ausdrücklich 2026.10.19, um die Kompatibilität mit nicht betroffenen Stammzertifikaten zu wahren. Die operative Basislinie liegt bei .19. S36 S37

Zu unterscheiden ist:

Vertraue dem Materialstandort	Warum Sie separat prüfen müssen
Betriebssystem CA-Paket	Systemvertrauensmaterial für das Image oder den Host
certifi im Venv	CA bundle wird tatsächlich von Anwendungen oder Anfragen usw. verwendet.
pip eingebaut certifi	Ist eine andere Kopie als die extern installierte certifi
uv / Andere Verpackungswerkzeuge	Befolgen Sie die eigenen Updates des Tools und vertrauenswürdige Quellen
Angepasste CA-Dateien, gepackte Snapshots	Kann weiterhin standardmäßige vertrauenswürdige Quellen für Systeme oder Pakete überschreiben

Die obige Checkliste basiert auf verschiedenen Verpackungsorten. PSF erfordert die Aktualisierung zugehöriger Tools und vorhandener virtueller Umgebungen sowie die Neuerstellung des Images. Nur das Aktualisieren des Hosts CA oder die Neuinstallation des Interpreters kann nicht beweisen, dass alle Kopien aktualisiert wurden. S35 S37

Beim Upgrade vom alten sicheren Bootstrap pip stellt PSF die Befehle für das feste Rad und SHA-256 bereit, siehe Anhang S37. Deaktivieren Sie die TLS-Überprüfung nicht und fügen Sie --trusted-host nicht hinzu, um Zertifikatsprobleme zu umgehen.

6. Formeller Sanierungsprozess

Die folgenden Befehle gelten für bestätigte vertrauenswürdige Umgebungen. Bei der Ausführung sollten der vorhandene Paketmanager, die Sperrdatei und der Bereitstellungsprozess des Projekts kombiniert werden, um zu vermeiden, dass npm/pnpm/yarn oder pip/uv/Poetry gemischt werden, um widersprüchliche Sperrdateien zu generieren.

Behandeln Sie zuerst eine Ausnahme: Wenn Sie vermuten, dass die Umgebung das kompromittierte Paket in Abschnitt 9 ausgeführt hat, isolieren Sie es zuerst und überprüfen Sie die Festplatte, sperren Sie die Datei und den Image-Datensatz aus einer sauberen Umgebung. Führen Sie nicht zuerst den folgenden Befehl Python/pip aus. S41

6.1 Richten Sie ein Hauptbuch ein, das dem tatsächlichen Datenverkehr entsprechen kann

Jeder Dienst erfasst mindestens:

Externer Einstiegspunkt, Reverse-Proxy, direkter Verbindungspfad zum Ursprungsstandort und Hintergrundwarteschlange/geplante Aufgaben.
Der tatsächliche Startbefehl, das laufende Konto, der Binärpfad, der Prozess oder die Containeridentität.
Laufzeit-Vollversion, Herausgeber/Repository, Paket-Vollversion oder Image-Digest.
Framework- und transitive Abhängigkeiten, Sperrdateien, native Bibliotheken und Trust-Store-Pfade.
Entspricht dem Vorliegen der Schwachstellenbedingung, dem Patch-Ziel, dem Neustartumfang, der verantwortlichen Person und dem Überprüfungsergebnis.

Auch Entwicklungsmaschinen, CI-Runner, Build-Container und Hintergrundaufgaben sollten auf ihre Pfade zu nicht vertrauenswürdigen Inhalten überprüft werden; Aktualisieren Sie nicht nur den öffentlich zugänglichen Webcontainer.

6.2 Node.js: Bestimmen Sie zuerst die Laufzeit und aktualisieren Sie dann die Anwendungsabhängigkeiten

Überprüfen Sie die tatsächliche Serviceumgebung:

node -p 'JSON.stringify({execPath:process.execPath,node:process.version,openssl:process.versions.openssl,brotli:process.versions.brotli},null,2)'
npm ls next react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack sharp --all
npm audit --omit=dev

node -p sollte mit der tatsächlichen ausführbaren Datei des Dienstes oder in einem tatsächlichen Container ausgeführt werden; Es prüft, ob neu gestartete Prozesse vorliegen, und weist nicht selbst nach, dass der alte Worker ersetzt wurde. Node kann den Patch zum integrierten Brotli hinzufügen und dabei die ursprüngliche Bibliotheksversionszeichenfolge beibehalten. Verlassen Sie sich daher nicht ausschließlich auf process.versions.brotli, um festzustellen, ob es repariert wurde. Sie sollten es mit der Sicherheitsversion Node oder dem Backport-Beweis des Anbieters kombinieren. S2 S4

npm ls wird verwendet, um den tatsächlichen Abhängigkeitsbaum anzuzeigen. Fehlende Pakete oder Peer-Konflikte können ebenfalls zu Exit-Codes ungleich Null führen, daher sollten Sie die spezifische Ausgabe lesen. npm audit wird als Hilfe bei der Abhängigkeitsprüfung verwendet und kann die binäre und native Bibliotheksprüfung Node nicht ersetzen.

Verwenden Sie mise, um die Umgebung von Node 24 zu verwalten, die wie folgt aktualisiert werden kann:

mise use -g [email protected]
mise exec [email protected] -- node -p 'process.version + " " + process.execPath'

mise use -g konfiguriert die globale Version; Die lokale Konfiguration des Projekts muss noch separat überprüft werden. Wenn der Dienst den alten absoluten Pfad, das Container-Basisimage oder die Umgebung eines anderen Kontos korrigiert hat, muss die entsprechende Konfiguration aktualisiert und der Dienst neu gestartet werden. Der Befehl selbst ersetzt keinen alten laufenden Prozess. S43

Führen Sie im Next-Projekt den entsprechenden Befehl entsprechend dem ausgewählten Zweig aus. Für Next 15:

# Next 15 分支
npm install --save-exact [email protected]

Für Next 16:

# Next 16 分支
npm install --save-exact [email protected]

Überprüfen Sie die mit React/RSC kompatiblen Abhängigkeiten, sperren Sie Dateien und die endgültige Sharp-Instanz und erstellen Sie dann entsprechend dem Projektprozess. Verwenden Sie die aktualisierte Sperrdatei in CI für eine reproduzierbare Installation und überprüfen Sie die Version im laufenden Image nach der Erstellung. Verwenden Sie für diesen Notfall nicht die unkontrollierte automatische Reparatur über Hauptversionen hinweg als Standardlösung.

6.3 Java: Überprüfen Sie den Herausgeber, den tatsächlichen JVM und die eingebetteten Komponenten

Vorläufige Bestandsaufnahme:

java -XshowSettings:properties -version

java.home, java.runtime.version und Herausgeber in der Ausgabe sollten mit dem tatsächlich vom Dienst verwendeten JVM übereinstimmen. Für JVM mit Anhängeberechtigung kann jcmd oder JDK verwendet werden, um den Zielprozess und nicht nur die Anmeldeshell zu überprüfen.

Überprüfen Sie Abhängigkeiten in vertrauenswürdigen Projekten und wählen Sie basierend auf tatsächlichen Build-Tools aus:

./mvnw dependency:tree '-Dincludes=org.apache.tomcat.embed:*,org.springframework.security:*,org.springframework.graphql:*'

./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-security-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-graphql --configuration runtimeClasspath

Diese Build-Befehle können Plug-Ins ausführen und Abhängigkeiten online auflösen und werden nur auf vertrauenswürdigen Projekten ausgeführt. Überprüfen Sie das endgültige JAR/WAR oder das tatsächliche JAR im Image und ersetzen Sie das endgültige Artefakt nicht durch Build-Dateideklarationen. Spring Boot-Embedded Tomcat erfordert einen Neuaufbau der Anwendung; Durch die Aktualisierung einer separaten Tomcat-Installation im System wird die Kopie im Anwendungspaket nicht geändert.

Überprüfen Sie nach der Aktualisierung der Laufzeit den angepassten javax.net.ssl.trustStore, den von der Anwendung selbst geladenen KeyStore, die Jlink-Laufzeit, das GraalVM/native Image und andere Bereitstellungsformulare Stück für Stück. Anwendungen, die bereits über angepasste Vertrauensmaterialien verfügen, können die Prüfung nicht beenden, nur weil das Verzeichnis JDK neu wird.

6.4 Python: Interpreter-für-Interpreter- und virtuelle Umgebungsverarbeitung

Innerhalb des tatsächlichen Venv/Containers, der als vertrauenswürdig bestätigt wurde:

python - <<'PY'
import sys
import ssl
import importlib.metadata as metadata

print("executable:", sys.executable)
print("version:", sys.version)
print("openssl:", ssl.OPENSSL_VERSION)
print("verify_paths:", ssl.get_default_verify_paths())
for name in ("pip", "certifi", "Django", "urllib3", "Brotli", "litellm"):
    try:
        print(name + ":", metadata.version(name))
    except metadata.PackageNotFoundError:
        print(name + ": not installed")
PY

python -m pip --version
python -m pip check

Dieses Skript sammelt nur Informationen und führt keine Versionsqualifizierungsbestimmung durch. ssl.get_default_verify_paths() ist die Standardpfadinformation und kann nicht beweisen, dass alle Clients von Drittanbietern denselben Trust Store verwenden. Dies sollte anhand der Anwendungskonfiguration bestätigt werden.

Aktualisieren Sie nach Abschluss des vertrauenswürdigen pip-Boot-Upgrades des Anhangs S37 die Zertifikatsabhängigkeiten entsprechend den Projekteinschränkungen, zum Beispiel:

python -m pip install --upgrade 'certifi>=2026.10.19'

# 仅适用于当前就选择 Django 5.2 的项目
python -m pip install --upgrade 'Django>=5.2.18,<5.3'

python -m pip check

Gleichzeitig muss die Anforderungs-/Sperrdatei des Projekts aktualisiert werden, da sonst bei der nächsten Bereitstellung möglicherweise auf die alte Version zurückgegriffen wird. Wenn Sie uv, Poetry oder ein Unternehmenspaket-Repository verwenden, verwenden Sie deren vorhandene Sperr- und Veröffentlichungsprozesse. Ändern Sie Pakete nicht manuell nur innerhalb eines Produktionscontainers.

Der vorhandene pip-audit-Workflow des Projekts kann verwendet werden, um in einer vertrauenswürdigen Umgebung nach bekannten Abhängigkeitsschwachstellen zu suchen. Es handelt sich nicht um einen Schadcode-Scanner und deckt nicht alle Interpreter-, Systembibliotheks- und Trust Store-Risiken ab. S44

Es wird nicht empfohlen, das System zu erzwingen /usr/bin/python3 um auf eine neue kompilierte Version zu verweisen. Verwenden Sie Release-Sicherheitsupdates oder Projektisolationslaufzeiten, um zu vermeiden, dass Verwaltungstools, die vom System abhängen, beschädigt werden Python . Dies ist eine Implementierungsauswahl und keine zusätzliche Behebungsanforderung für diese Schwachstelle.

6.5 Erstellen Sie die laufende Instanz neu und ersetzen Sie sie

Es wird empfohlen, die folgenden Schritte als vollständige Änderung durchzuführen:

Besorgen Sie sich den Patch von der ursprünglichen vertrauenswürdigen Quelle und speichern Sie die Version/den Hash und die Abhängigkeitssperre.
Geben Sie Schlüsselfunktionen in einer produktionsnahen Umgebung zurück und bestätigen Sie, dass native Erweiterungen mit JVM/Framework kompatibel sind.
Aktualisieren Sie die Laufzeit, die Anwendungsabhängigkeiten und den tatsächlichen Trust Store. Aktualisieren Sie das Basis-Image und das System CA für den Container, verwenden Sie nicht nur die alte Ebene wieder.
Erstellen Sie Anwendungen und Images neu und ersetzen Sie Dienst-, Worker-, Warteschlangenkonsumenten- und geplante Aufgabeninstanzen fortlaufend.
Überprüfen Sie die Version und Konfiguration in der neuen laufenden Instanz erneut und stellen Sie sicher, dass alle alten Kopien beendet wurden.
Beobachten Sie Fehlerraten, Latenz, CPU/Speicher, TLS-Handshake-Fehler und Prozessabstürze.

Beim Rollback sollte der Beibehaltung sicherer Laufzeit- und Patch-Abhängigkeiten sowie dem Rollback der Anwendungskonfiguration oder geschäftlicher Änderungen Vorrang eingeräumt werden. Wenn Sie zu einem alten Produkt mit Schwachstellen zurückkehren müssen, sollten gleichzeitig die entsprechenden Zugangsbeschränkungen wiederhergestellt werden und der Verantwortliche sowie die Mindestwiederherstellungsdauer klar definiert werden.

7. Vorübergehende Schadensbegrenzung und Patch-Auswahl

7.1 Abdeckungsgrenze vorübergehender Maßnahmen

Im Folgenden finden Sie Umsetzungsvorschläge auf Basis der angekündigten Nutzungsbedingungen. Sofern der offizielle Plan nicht vermerkt ist, übernimmt der Anbieter keine Garantie dafür, dass alle Varianten vollständig blockiert werden können.

Risiko	Vorübergehende Maßnahmen, die ergriffen werden können	Der Teil, der auf dieser Grundlage nicht als abgeschlossen betrachtet werden kann
Brotli-Dekodierung	Stoppen Sie die Dekodierung nicht vertrauenswürdiger Eingaben. Überprüfen Sie die automatische Dekomprimierung für eingehende und ausgehende Daten	Eingehender WAF oder das Deaktivieren der Antwortkomprimierung deckt nicht alle Dekodierungseinträge S3 ab
Next.js typed arrays RCE	Sofort upgraden; Betroffene Dienste bei Bedarf vorübergehend isolieren	Es gibt keine offizielle zuverlässige universelle Problemumgehung S9
Next.js SVG RCE	Offizieller Plan: Stellen Sie sicher, dass die tatsächliche scharfe ≥0.35.5; Sperren Sie relevante Optimierungseinstiegspunkte, wenn das Geschäft dies zulässt	Deckt nicht andere Next/RSC-Probleme S11 ab
Tomcat Realm / HTTP/2 / AJP	Isolieren Sie den entsprechenden Pfad und schließen Sie nicht benötigte Anschlüsse	Benötigt wird weiterhin das entsprechende Zweigreparaturpaket S21 S22 S23
GraphQL Deserialisierung	Betroffene Verbindungsfelder aussetzen; Beschränken Sie nicht vertrauenswürdige Anrufer	Nur die Anforderungslängenbeschränkung kann das Typ-/Deserialisierungsproblem S25 nicht beheben
Spring embedded LDAP	Deaktivieren, wenn es nicht benötigt wird; Begrenzen Sie die Reichweite des echten Abhörports	Die Standardverwaltungsidentität und die Verzeichnisintegrität müssen noch überprüft werden S27
CPython SNI UAF	Offizieller Plan: Bewahren Sie die entsprechende starke Referenz SSLContext bis zum Ende des Dienstes auf	Alle Erstellungs-/Umschaltpfade müssen abgedeckt sein S29
Python Hostname überspringen	Offizielle Lösung: Übergeben Sie den erwarteten server_hostname korrekt	Das check_hostname-Flag kann nicht einfach überprüft oder die Warnung S30 S31 ignoriert werden
Unzuverlässiger Teer	Deaktivieren/Quarantäne-Extraktion, Ablehnen nicht notwendiger Links und Geräteeinträge	Weder Filter noch Ressourcenkontingente sind universelle Sandboxes S32 S40 S45
Zertifikatvertrauensereignis	Aktualisieren Sie das richtige CA-Material. Das Java-Vertrauen kann gemäß der offiziellen Schadensbegrenzung eingeschränkt werden	Das Deaktivieren der TLS-Überprüfung erhöht das Risiko S19 S37

7.2 Wählen Sie den Patch basierend auf der Bereitstellungsmethode aus

Versandart	Priorisieren Sie Reparaturmethoden	Beweise, die aufbewahrt werden sollten
Von der Verteilung verwaltete Laufzeit	Entsprechende Sicherheitsupdates des Herstellers	Vollständige Paketversion, Ankündigung, Repository-Quelle
Offizieller Binär-/Laufzeitmanager	Offizielle Sicherheitsveröffentlichung aus derselben Branche	Version, Quelle und Digest, tatsächlicher Ausführungspfad
Selbstkompiliertes Node / CPython	Die offizielle Quellversion des entsprechenden Zweigs oder das vollständige Patch-Set des Anbieters	Commit-Set, Build-Parameter, abhängige Bibliotheken und Regressionsergebnisse
Spring / Next / Django	Kompatibel mit brancheninternen Updates, der Neuerstellung von Abhängigkeitssperren und endgültigen Anwendungen	Endgültiger Abhängigkeitsbaum, aktuelle Version in JAR/Paket/Image
Benutzerdefinierter Trust Store	Offizieller Auszahlungsplan oder Anbieteraktualisierung, die die Auszahlung bestätigt	Tatsächlicher Nutzungspfad, Materialwechsel, TLS Erfolgs- und Ablehnungstests
Eine kompromittierte Umgebung	Nutzen Sie saubere und vertrauenswürdige Produkte und führen Sie eine separate Untersuchung des Vorfalls durch	Historischer Paket-/Image-Auszug, Installationsdatensatz, Anmeldedaten-Rotationsdatensatz

7.3 Schlüssel-Patch-Mechanismus und Überprüfungsschwerpunkt

Brotli: achtet darauf, ob die Grenzprüfung und die Fehlerrückgabe des nativen Decodierungsstatus abgeschlossen sind, bevor der Build aufgerufen wird. Nur das Ersetzen des JavaScript-Pakets kann den statisch in Node kompilierten Code nicht ändern. S4
Node DNS/TLS: konzentriert sich auf Eingabeablehnung, Adressnormalisierung, Unterscheidung zwischen IP SAN- und DNS-Identitäten sowie DNS-Rückruf/Versprechen. Der Parsing-Pfad und TLS Hostnamen-Übereinstimmungstest. S5 S6
Tomcat JNDIRealm: konzentriert sich darauf, ob der Authentifizierungsprozess die Anmeldeinformationen tatsächlich überprüft, und nicht nur auf das Abrufen eines Verzeichniskontexts. Priorisieren Sie die offizielle Version und behandeln Sie den Austausch einer einzelnen Quelldatei nicht als vollständigen Binärpatch. S24
CPython ssl: konzentriert sich auf den Referenzbesitz Python und den Lebenszyklus des zugrunde liegenden SSLContext; wrap_bio()-Backports weisen Unterschiede in der Zweigkompatibilität auf, und Sie müssen die tatsächliche Implementierung des verwendeten Zweigs lesen. S31 S47
Zertifikat-Misstrauen: Solche Updates erscheinen möglicherweise als vertrauenswürdiges Material oder verweigern Listenänderungen und nicht als offensichtliche API-Änderungen. Die gleiche Charge von Node enthält auch den Ablehnungsmechanismus des betroffenen Zwischenprodukts CA; Die jeweiligen Vertrauensquellen von Java und Python müssen noch separat überprüft werden. S19 S37 S46

Unabhängig Brotli Auch die Bindung sollte überprüft werden. Google Upstream veröffentlicht 1.0.10 / 1.1.1 / 1.2.1 am selben Tag zu beheben CVE-2026-111497 . Python Native Erweiterungen oder JNI-Artefakte, die dieselbe betroffene C-Implementierung einbetten, müssen unabhängig aktualisiert/neu erstellt werden; daraus kann nicht geschlossen werden, dass alles rein ist Java Decoder betroffen sind, kann auch nicht von einer Nachrüstung ausgegangen werden Node ersetzt automatisch Kopien in anderen Sprachen. S42

8. Überprüfung und Nachkontrollen

8.1 Mindestprüfliste für die Verifizierung

Artikel prüfen	Nachweis erforderlich
Laufzeit	Vollständige Version oder Anbieter-Backport-Beweise korrekt im realen Prozess/Container
Anwendungsabhängigkeiten	Next/RSC/sharp, Tomcat/Spring und Django/certifi in den endgültigen Bereitstellungsprodukten haben den entsprechenden Schwellenwert erreicht
Ersatzsortiment	Alle Worker-/JVM-/Containerkopien und Hintergrundaufgaben wurden durch neue ersetzt und die alten Instanzen wurden beendet.
TLS	Gültige Domänenzertifikate sind erfolgreich. nicht übereinstimmende Hostnamen und ungültige Ketten schlagen gemäß der Richtlinie fehl; Benutzerdefinierte Trust Stores sind enthalten
eMudhra Misstrauen	Die vom betroffenen Zwischenprodukt CA erstellte Zertifikatskette wurde während der tatsächlichen Laufzeit abgelehnt, oder es gibt Hinweise darauf, dass der Sicherheitsaufbau/die entsprechende Ablehnungsliste des jeweiligen Anbieters bereitgestellt wurde; Der Fall kann nicht auf Grundlage des allgemeinen TLS-Tests oder der Kurzversionsnummer Java 8 abgeschlossen werden.
Node Dekodierung und Bilder	Normale komprimierte Antwort-, Upload-, Bildoptimierungs- und RSC-Funktionen sind verfügbar; Es gilt die Richtlinie für nicht vertrauenswürdige Quellen
Java Authentifizierung und Isolierung	Falsches Passwort abgelehnt; Unabhängige gleichzeitige asynchrone Benutzeranforderungen ohne Identitäts-/Antwortmischung; LDAP hört wie erwartet zu
Python SNI / Archiv	Das normale Geschäft mit dem Multi-Domain-Namen TLS ist stabil; Die Archivierung lehnt Pfaddurchquerungen und unzulässige Links ab und Dateien außerhalb des Verzeichnisses werden nicht geändert
Daten und funktionale Regression	Paging, räumliche Abfrage, Berechtigungsprüfung und Hintergrundaufgaben haben die bestehenden Tests des Projekts bestanden
Ressourcen und Beobachtungen	Es gibt keinen abnormalen Anstieg der CPU-, Speicher-, Fehlerrate-, Latenz- und TLS-Fehler.
Rückverfolgbarkeit	Sparen Sie Upgrade-Zeit, Paket-/Image-Übersicht, Konfigurationsänderungen, Überprüfungsergebnisse und ungelöste Probleme

Hierbei handelt es sich um Empfehlungen zur Implementierungsakzeptanz und es ist nicht erforderlich, für jeden CVE ein Angriffsskript zu erstellen. Bei der Überprüfung, die Abstürze, Ressourcenerschöpfung und Archivüberschreitungen mit sich bringt, sollten vorgelagerte Regressionstests oder projektgesteuerte Testdaten in einer isolierten Umgebung verwendet werden.

8.2 Patching und Einbruchsuntersuchung sind unterschiedliche Aufgaben

Überprüfen Sie vorhandene Protokolle auf ungewöhnliche Decodierungsfehler, Worker-/JVM-Abstürze, verdächtige Dateischreibvorgänge, Verzeichnisdatenänderungen, Authentifizierungsausnahmen, ausgehende Anforderungen und Datensätze zur Anmeldeinformationsnutzung. Diese Anzeichen müssen im Kontext beurteilt werden: Ein Absturz oder OOM ist kein Beweis für eine erfolgreiche Ausnutzung; Das Fehlen von Warnungen beweist nicht, dass ein System nicht betroffen war.

Wenn unbefugte Änderungen, kompromittierte Anmeldeinformationen oder bestätigte böswillige Abhängigkeiten entdeckt werden, sollten Beweise gesichert, die relevanten Instanzen isoliert, betroffene Anmeldeinformationen aus einer vertrauenswürdigen Umgebung rotiert und das System neu aufgebaut werden. Der Patch widerruft keine vom Angreifer erhaltenen Token und stellt keine geänderten Daten wieder her.

9. Sicherheitsvorfall in der Lieferkette: LiteLLM 1.107.0-Kompromittierung

**Offizielles Bestätigungsdatum: 2026-10-21.**LiteLLM meldete, dass seine Release-Pipeline kompromittiert wurde. PyPIs litellm==1.107.0 und einige Docker/GHCR-Produkte aus derselben Zeit enthielten geheimen Diebstahl- und Fernsteuerungs-Schadcode, und die zugehörigen Produkte wurden zurückgezogen. S41

Um die Auswirkungen zu ermitteln, sollten Sie die historischen Installationsaufzeichnungen und den Image-Digest überprüfen. Etiketten wie latest, main-latest und main-stable weisen nun auf saubere Bilder hin, was nicht beweist, dass die zum Zeitpunkt des Vorfalls entnommenen Produkte sauber waren. Die damalige offizielle Empfehlung lautete, 1.106.2 vorübergehend anzupinnen; Diese Empfehlung basierte auf diesem Vorfall und andere Sicherheitsankündigungen müssen während der Bereitstellung noch überprüft werden. S41

Für Umgebungen, in denen verwandte Produkte installiert oder ausgeführt wurden:

Isolieren und bewahren Sie Installationsaufzeichnungen, Bilder und Protokolle auf und überprüfen Sie sie in einer sauberen Umgebung.
Python/pip nicht zuerst in einer verdächtigen Umgebung starten; Das bösartige .pth / sitecustomize.py kann nach dem Start erneut ausgeführt werden.
Hosts, Venvs/Container aus vertrauenswürdigen Quellen neu erstellen; Pakete können nicht einfach deinstalliert oder heruntergestuft werden.
Widerrufen/Rotieren von Cloud-Anmeldeinformationen, LLM-Anbieterschlüsseln, LiteLLM-Schlüsseln und Datenbankanmeldeinformationen basierend auf der tatsächlichen Zugänglichkeit und Überprüfung der abnormalen Nutzung. S41

Hierbei handelt es sich um einen bestätigten Vorfall in der Lieferkette, bei dessen Bewältigung die Ausführung bösartiger Codes, der Verlust von Anmeldeinformationen und Persistenzrisiken berücksichtigt werden müssen. Am 23. Oktober 2026 untersuchten die Beamten noch immer den ersten Einbruch.

Anhang: Zitierte Quellen und Links

Das folgende Datum der Quellenüberprüfung ist 2026-10-23, einschließlich der offiziellen Sicherheitsankündigung des Projekts, des offiziellen Code-Repositorys und der Anweisungen des Anbieters. Der Haupttext [Sx] entspricht diesem Anhang; Bei Aktualisierungen sollten Sie prüfen, ob der Lieferant Folgerevisionen freigegeben hat.

S1 – Node.js: Sicherheitshinweis vom 2026-10-21

Zweck: Vier Laufzeiten High, Auswirkungen auf Zweigstellen, Sicherheitsversion vom Oktober.
Verweis: Offizielles Sicherheitsbulletin

S2 — Node.js: Offizielle Freigabeanweisungen für drei Wartungslinien

Zweck: Überprüfen Sie 22.23.4, 24.22.1, 26.12.1 und die tatsächlich zusammengeführten Patches.
Verweis: Node.js 22.23.4
Verweis: Node.js 24.22.1
Verweis: Node.js 26.12.1

S3 – Vercel: Node.js Brotli RCE Sicherheitshinweis

Zweck: Eingehende/ausgehende Dekodierungsbedingungen, WAF-Abdeckungsgrenze, Node 20-Status.
Verweis: Node.js security advisory: Brotli decoder RCE

S4 – Node.js: Offizielle Patch-Einreichung von Brotli

Zweck: Implementierungsbasis für native Decodierungsprüfung und Fehlerausbreitung.
Verweis: Brotli Patch-Commit 49dff6f57a

S5 – Node.js: TLS Adressnormalisierungspatch

Zweck: Überprüfung der Zertifikatidentität von Nummern voller Breite und nicht standardmäßigen IP.
Verweis: IP normalization regression Patch
Verweis: lehnt das Patchen der nicht standardmäßigen IP-Adresse ab

S6 – Node.js: DNS NUL-Verifizierungspatch

Zweck: Eingabezurückweisung und Regressionsabdeckung.
Verweis: dns.resolve Eingabeverifizierungspatch

S7 – Node.js: Sicherheitshinweis vom 2026-07-29

Zweck: HTTP/2-Speicherauslastung, UAF- und Berechtigungsmodell-Schwachstellen.
Verweis: July 2026 Security Releases

S8 – Next.js: Sicherheitsupdate vom 2026-10-14

Zweck: Vereinheitlichung der Upgrade-Basislinie und der drei Hauptrisiken.
Verweis: Next.js Security Update for Upstream Vulnerabilities

Verweis: S9 — Next.js：typed arrays / use cache RCE

Zweck: GHSA-673q-mjm6-r5xr; wirkt sich auf Intervall, Zustand, Bewertung und Workaround-Status aus.
Verweis: Next.js Offizielles Sicherheitsbulletin

Verweis: S10 — React：React Server Components RCE

Zweck: GHSA-xqc2-xf4c-x3h3; betroffene und reparierte Versionen von drei RSC-Paketen.
Verweis: React Offizielles Sicherheitsbulletin

Verweis: S11 — Next.js：SVG Image Optimization RCE

Zweck: CVE-2026-96889 / GHSA-2464-fhr4-w9xw; glibc, scharfe und ursprüngliche Versionsgrenzen.
Verweis: SVG Offizielles Sicherheitsbulletin zur Bildoptimierung

Verweis: S12 — Next.js：Server Actions DoS

Zweck: GHSA-p3m5-59mp-jv5r; wirkt sich auf Bedingungen, Versionen und Bewertungen aus.
Verweis: Server Actions DoS Offizielles Sicherheitsbulletin

S13 — Next.js: AVIF Bildoptimierung RCE

Zweck: 2026-08-25, GHSA-2xp9-vwfh-vxw4.
Verweis: AVIF Offizielles Sicherheitsbulletin

Verweis: S14 — Next.js：Windows RCE

Zweck: 2026-08-25, CVE-2026-75604/GHSA-p293-qw3h-jr36.
Verweis: Windows RCE Offizielles Sicherheitsbulletin

Verweis: S15 — Next.js：next/og ImageResponse RCE

Zweck: 2026-09-22, GHSA-vcvr-r3jv-pc5j; Unterschied zwischen Node und Edge.
Verweis: ImageResponse Offizielles Sicherheitsbulletin
Verweis: Versionshinweise vom 22. September

Verweis: S16 — Oracle: October 2026 CPU

Zweck: Java SE Risikomatrix, Patch-Menge und anwendbare Bedingungen.
Verweis: Oracle Critical Patch Update – October 2026
Verweis: Oracle Java SE CPU Versionsliste

S17 – Oracle: CVE-2026-91403 Out-of-Band-Alarm

Zweck: 2026-10-21, Vertrauensrisiko des JSSE-Zertifikats, betroffene Produkte und CVSS 3.1 9.1.
Verweis: Oracle Security Alert

S18 – Oracle: JDK offizielle Version und Download

Zweck: Unterscheidung zwischen CPU am 20. Oktober und der Out-of-Band-Version am 21. Oktober; Unterscheiden Sie die Einschränkungen der Kurzversion von Java 8.
Verweis: JDK release list
Verweis: Oracle Java Download-Seite

S19 — Oracle: eMudhra vorübergehender Auszahlungsplan

Zweck: Aktualisiert am 2026-10-22; zwei Stammzertifikate, Keytool, benutzerdefinierter Truststore und Sperrprüfung.
Verweis: Distrusting eMudhra Intermediate Certificates in Oracle JDK

S20 – Eclipse Adoptium: Build-Datensatz veröffentlichen

Zweck: Temurin wird aufgrund des Zertifikatsvorfalls neu gepackt; Das Versionssuffix Oracle kann nicht mechanisch angewendet werden.
Verweis: Adoptium Release Scorecards

S21 – Apache Tomcat 9 Sicherheitshinweis

Zweck: 9-Zweig-genaues betroffenes Intervall mit 9.0.123-Fix.
Verweis: Tomcat 9 vulnerabilities

S22 – Apache Tomcat 10 Sicherheitshinweis

Zweck: 10.1 Zweig präzises Intervall und 10.1.61 Reparatur; 10.0 EOL.
Verweis: Tomcat 10 vulnerabilities

S23 – Apache Tomcat 11 Sicherheitshinweis

Zweck: Drei Elemente Important, 11.0.27, AJP, anwendbarer Umfang und Offenlegungs-/Veröffentlichungsdatum.
Verweis: Tomcat 11 vulnerabilities

S24 – Apache Tomcat: JNDIRealm Patch-Commit

Zweck: Formale Grundlage zur Behebung von Lücken in der Zertifizierungsprüfung.
Verweis: JNDIRealm Patch-Commit

Verweis: S25 — Spring：GraphQL CVE-2026-59285

Zweck: 2026-08-20, Erforderlich, 2.0.5 OSS / 2.0.4.1 Gewerbliche Reparatur.
Verweis: Spring for GraphQL Unsafe Deserialization

Verweis: S26 — Spring：GraphQL CVE-2026-41699

Zweck: Ein früherer Korrekturschwellenwert, nur um zu erklären, warum Sie nicht bei der alten Basislinie bleiben können.
Verweis: 6 Monat GraphQL Sicherheitsbulletin

Verweis: S27 — Spring Security：CVE-2026-59270

Zweck: Einbetten von UnboundID LDAP, bekannte Verwaltungsidentität und Unterscheidung von OSS/kommerzieller Version.
Verweis: Spring embedded LDAP Sicherheitsbulletin

Verweis: S28 — Spring Security：CVE-2026-47841

Zweck: WebAuthn Benutzerauthentifizierung, Sitzungsserialisierung und Angriffsprämisse.
Verweis: WebAuthn Sicherheitsbulletin

S29 – PSF: CVE-2026-19445 Unabhängige Sicherheitsempfehlung

Zweck: 2026-09-30, Critical, SNI Von SSLContext genannte Bedingungen und vorübergehende Maßnahmen.
Verweis: SSLContext UAF Offizielle Ankündigung

S30 – PSF: CVE-2026-19553 Unabhängige Sicherheitsempfehlung

Zweck: 2026-09-30, High, fehlender Hostname und explizite Parameterminderung.
Verweis: wrap_bio Offizielle Ankündigung der Überprüfung des Hostnamens

S31 – CPython: offizieller Wrap_bio-Patch und 3.12-Backport

Zweck: 3.10 – 3.12-Warnungskompatibilitätsrichtlinie, der Unterschied zwischen None und der leeren Zeichenfolge.
Verweis: Hauptpatch PR #158503
Verweis: 3.12 Hinterfüllung PR #158513
Verweis: 3.15 Hinterfüllung PR #158511

S32 – PSF: CVE-2026-82049 Unabhängige Sicherheitsempfehlung

Zweck: 2026-09-14, High, Linkkombination, Metadatenänderung und Offenlegung von Inhalten.
Verweis: tarfile-Link umgeht die offizielle Ankündigung

S33 – CPython: Offizielle Sicherheitsveröffentlichung Ende September/Anfang Oktober

Zweck: Mindestfixversion, Quellcode-Verteilungsmethode und 3.14-Ausnahme für tarfile-spezifische Probleme.
Verweis: Python Anweisungen zur branchenübergreifenden Sicherheitsfreigabe
Verweis: Python 3.11.17
Verweis: Python 3.12.15
Verweis: Python 3.13.16
Verweis: Python 3.14.8

S34 – CPython: 3.10 letzte sichere Version

Zweck: 3.10.22 und Ende des Upstream-Lebenszyklus.
Verweis: Python 3.10.22

S35 – CPython: Notfallwartungsversion 2026-10-21

Zweck: 3.13.17 / 3.14.9 / 3.15.1, integrierte pip- und certifi-Updates, bestehende Venv-Anforderungen.
Verweis: Python 3.13.17
Verweis: Python 3.14.9
Verweis: Python 3.15.1

S36 – certifi: Ankündigung des Misstrauens des Zertifikats emSign

Zweck: 2026-10-20, GHSA-6q48-6c7w-9gw2, Critical, kein bekannter CVE.
Verweis: certifi Offizielles Sicherheitsbulletin

S37 – PSF: Auswirkungen von eMudhra / emSign auf Python-Benutzer

Zweck: certifi .19-Empfehlung, pip/uv-Basislinie, vertrauenswürdiger Boot-Upgrade-Befehl mit SHA-256.
Verweis: PSF Offizielle Veranstaltungs- und Upgrade-Anweisungen

Der in den offiziellen Anweisungen von S37 bereitgestellte Boot-Upgrade-Befehl pip lautet wie folgt. Darf nur in Python-Umgebungen verwendet werden, die als vertrauenswürdig bestätigt wurden; Wenn in Abschnitt 9 ein Verdacht auf eine Vergiftung besteht, isolieren Sie zunächst und bauen Sie es gemäß dem Vorfallprozess wieder auf. Es korrigiert den Wheel-Inhalts-Hash und aktualisiert anschließend andere Abhängigkeiten entsprechend dem Projektprozess.

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

S38 – Django: 2026-08-04 sichere Veröffentlichung

Verwendung: CVE-2026-15307, GeoDjango Nutzungsbedingungen, anfängliche Korrekturen und Kompatibilitätsänderungen.
Verweis: Django 6.0.8 / 5.2.17

S39 – Django: 2026-10-06 sichere Veröffentlichung

Zweck: CVE-2026-87890, Geometrie DoS Nachträgliche Bewehrung mit der aktuell ausgewählten Grundlinie.
Verweis: Django 6.1.2 / 6.0.9 / 5.2.18

S40 – PSF / CPython: Neueste Randnotiz zu tar_filter

Zweck: 2026-10-22, CVE-2026-114583 (Medium); Die Fusion von PR bedeutet nicht, dass die offizielle Wartungsversion veröffentlicht wurde.
Verweis: PSF Unabhängige Ankündigung
Verweis: CPython Patch PR #160098

S41 – LiteLLM: Offizieller Bericht über Vorfälle in der Lieferkette, 21. Oktober

Zweck: 1.107.0 kontaminiertes Produkt, historische Zusammenfassung, Isolierungsrekonstruktion und Entsorgung von Berechtigungsnachweisen.
Verweis: Contained: LiteLLM v1.107.0 Compromised

S42 – Google Brotli: offizielle sichere Version

Zweck: Unabhängige Brotli 1.0.10 / 1.1.1 / 1.2.1- und sprachübergreifende eingebettete Kopienüberprüfungsbasis.
Verweis: Brotli releases

S43 – Mise: Verwenden Sie die offizielle Dokumentation des Befehls

Zweck: Angabe der Toolversion und Befehlssemantik der globalen Konfiguration.
Verweis: mise use

S44 – PyPA: pip – offizielles Audit-Projekt

Zweck: Python Der Zweck und die Leistungsgrenzen der Abhängigkeitsschwachstellenprüfung.
Verweis: pip-audit

S45 – Python: Tarfile-Extraktionsfilterdokument

Zweck: Datenstrategie, Standardverhaltensänderungen und Einschränkungen, die die Sandbox nicht ersetzen können.
Verweis: tarfile extraction filters

S46 – Node.js: Zwischen-Zurückweisungsmechanismus CA

Zweck: Diese eMudhra-bezogene Vertrauenskettenverarbeitung entspricht nicht der kryptografischen Ungültigmachung aller Stammzertifikate.
Verweis: Node.js PR #66871

S47 – CPython: SNI UAF technische Hinweise und Korrekturen

Zweck: Referenzlebenszyklus, spezielle Build-Bedingungen und Branch-Backtracking.
Verweis: offizielle Ausgabe Nr. 156293
Verweis: offizieller Patch PR #158504
Verweis: 3.15 Hinterfüllung PR #158514