Node.js, Java and Python: recent vulnerabilities and remediation guide

Sources checked as of October 23, 2026 (UTC) Coverage period: July 25-October 23, 2026, focusing on new announcements and subsequent patches from September to October. Audience: engineers and security responders who maintain Node.js, Java, Python services, containers, build pipelines and development environments.

This article summarizes recent important security risks in Node.js, Java, and Python runtimes, standard libraries, and common server frameworks and dependencies, and provides impact scope, fixed versions, temporary mitigation measures, patch selection, and verification methods.

Assess impact against component versions, enabled features and accessible entry points. Vulnerability facts come from official advisories; dates refer to public disclosure unless an earlier patch release is explicitly noted. We do not infer unconfirmed exploit conditions, CVSS scores or exploitation in the wild. Deployment advice is identified as implementation guidance.

TL;DR: remediation priorities

Update the runtime that actually hosts the service first. Update the corresponding Node.js branch to at least 22.23.4 / 24.22.1 / 26.12.1. Services using Node 24 can upgrade to 24.22.1 within the same major version or a later version that contains the same fixes. S1 S2
Update Node application dependencies separately. For Next.js, use 15.5.28 / 16.4.1 as the upgrade baseline; when using React Server Components independently, check the actual installed react-server-dom-* package. Only updating the Node binary does not cover these framework vulnerabilities. S8 S9 S10 S11 S12
Java: cover both rounds of updates. Install a vendor build covering both the October 20 CPU and the October 21 CVE-2026-91403 emergency certificate-trust fix. See section 2.2 for Oracle JDK 11-27 out-of-band versions; verify other distributions against their own security packages and full build numbers. Update the corresponding Tomcat branch to 9.0.123 / 10.1.61 / 11.0.27. S16 S17 S18 S20 S21 S22 S23
Python: update the interpreter, application packages and certificate packages separately. See section 2.3 for interpreter baselines; certifi recommends ≥2026.10.19, pip ≥26.2.2, when using uv ≥0.13.4. Every existing venv needs to be checked. For wrap_bio() related codes, correct and non-empty server_hostname must also be passed in. S29 S30 S31 S33 S35 S36 S37
If an immediate upgrade is impossible, reduce exposure at the relevant entry points. Prioritize stopping untrusted Brotli decoding, affected image/paging/archiving processing, and isolating problematic LDAP or authentication entries; keeping TLS certificates and hostnames verified. Inbound WAF cannot cover outbound paths such as applications pulling malicious compressed responses. S3 S11 S25 S27 S30 S32
Rebuild, replace old processes, and verify through real service paths. Save the lock file and image digest, rebuild the application and image, roll out replacements for all workers/JVM/containers; check the actual process, dependency tree, trust store and business regression tests. A newer command-line version alone does not establish that remediation is complete.
If LiteLLM 1.107.0 was installed or run, follow incident-response procedures. The project confirmed the release compromise on October 21. Isolate affected environments, investigate from a clean environment, rebuild and rotate exposed credentials. Do not start Python/pip in a suspicious environment for checking first. See Section 9 for details. S41

1. Vulnerability Overview and risk assessment

1.1 Prioritize remediation by actual exposure

The deployment priorities below are implementation guidance. Severity labels follow each vendor, including Apache’s Important rating. CVSS 3.1 and 4.0 are different scoring systems; do not rank issues across them by score alone.

Ecosystem / layer	Key issues	Official grade or verified score	Priority deployment
Node.js native dependency	CVE-2026-111497: Brotli is written out of bounds, and there is a risk of RCE	Node：High	Decode Brotli data S1 S3 in the external request body or external response
Node.js TLS / DNS	CVE-2026-105482, 105483, 106069: Parsing and identity verification are inconsistent	High	URL crawl, proxy, Webhook, dynamic target address S1 S5 S6
Node.js HTTP/2	CVE-2026-56846, 56848: Memory exhausted and UAF	High	Node directly handles untrusted HTTP/2 traffic S7
React / Next.js	RSC / `use cache` typed arrays RCE	Critical；CVSS 4.0 9.5	Server RSC, related cache components and data path S9 S10
Next.js Image optimization	CVE-2026-96889: SVG Image processing RCE	Critical；CVSS 4.0 9.5	Instances on glibc Linux that can handle untrusted images S11
Next.js Server Actions	Specially crafted request causes CPU to be exhausted	High；CVSS 4.0 8.2	App Router and at least one Server Action S12
Java TLS Trust	CVE-2026-91403: Continue to trust the affected intermediate CA	CVSS 3.1 9.1	TLS/API Scenario S17 using affected trust chain
Tomcat	JNDIRealm authentication bypass, HTTP/2 cross-request mix-ups, AJP response leakage	Important	Corresponding to Realm / Connector / async Servlet path S21 S22 S23
Spring for GraphQL	CVE-2026-59285: Paging deserialization RCE	High	Jackson 2 + Connection Paging + Exploitable Classpath S25
Spring Security	CVE-2026-59270: Embedded LDAP known management identity exposed	Critical	Embedded LDAP is enabled and the listening port is accessible to the attacker S27
CPython `ssl`	CVE-2026-19445: SNI switching context results in UAF	Critical	Python terminates TLS by itself, and meets the context life cycle condition S29
CPython `ssl`	CVE-2026-19553: Skip verification when hostname is missing	High	`wrap_bio()` / Related asyncio call missing expected hostname S30
CPython `tarfile`	CVE-2026-82049: Hard link and symbolic link combination bypass	High	Automatically extract untrusted tar archive S32
Django / GeoDjango	CVE-2026-15307: Spatial query write file, SSRF, under the condition RCE	High	Spatial queries or related administration interfaces accepting untrusted input S38
Python certificate dependency	certifi: emSign related certificate distrust	Critical; GHSA, none known CVE	TLS client and package management tool S36 S37 still using affected CA bundle

Abbreviations: RCE stands for remote code execution, UAF stands for use-after-free, and SSRF stands for server-side request forgery. The direct permissions of RCE are usually the permissions of the process hosting the application and cannot automatically be equivalent to the root permissions.

Recommended sequence: first handles RCE, which is externally reachable and meets the conditions, authentication bypass, cross-user data leakage and certificate authentication issues; at the same time, schedule updates for the public-facing DoS entry point. No need to run attack payloads in production to prove exploitability. Dependencies exist, code paths are reachable, and attack conditions are met. These are three issues that need to be checked separately.

1.2 Three easily confused boundaries

Upgrade runtimes and dependencies separately. Security updates for Node, JDK, CPython does not automatically repair standalone installations of Next.js, Spring, Django, certifi or native extensions.
The remediation threshold is separate from the current deployment baseline. The first patch for a vulnerability in August is not guaranteed to cover new issues from September to October; Section 2 uses verified subsequent updates as the implementation target.
Distinguish a vulnerability from an actual supply-chain compromise. For common vulnerabilities, patches eliminate future attack paths; when malicious packages have been run, the impact of credentials and persistence needs to be investigated. Section 9’s LiteLLM is the officially confirmed event. S41

Whether there are confirmed exploitation in the wild should be based on official disclosures. The vendor did not mention the exploitation activities and cannot prove that there is no attack; remediation should be performed based on the actual attack surface.

2. Quick check of fixed version and deployment baseline

2.1 Node.js、React、Next.js

component/branch	Recommended version baseline	Instructions for use
Node.js 22.x	22.23.4	Security release S1 S2 on October 21st
Node.js 24.x	24.22.1	Applies to the 24.x branch; 24.22.0 does not contain the October 21 security patch S1 S2
Node.js 26.x	26.12.1	Security release in the same batch S1 S2
Node.js 20 and earlier upstream branches	Migrate to a supported branch	Node 20 does not accept this upstream fix; the vendor extended support must be verified separately S3
Next.js 15.x	15.5.28	Updated on October 14 S8
Next.js 16.x	16.4.1	Same as above S8
Standalone RSC 19.0 / 19.1 / 19.2 / 19.3 branch	19.0.9 / 19.1.10 / 19.2.9 / 19.3.1	Check the three `react-server-dom-*` packages separately; not just look at the top layer `react` S10
Next actually loaded `sharp`	≥0.35.5	Official temporary fix conditions for the SVG vulnerability; does not replace other Next.js patches S11

Node officially lists the affected maintenance branches for the October vulnerability, but does not provide the initially introduced patch version item by item, so the precise starting version of each vulnerability cannot be determined based on the maintenance branch range alone. When deploying, give priority to using the above version of the same branch or a subsequent version confirmed to contain the same fixes.

2.2 Java: October CPU plus out-of-band certificate update

This table applies to Oracle JDK. The second column covers only the October 20 CPU; the third includes the October 21 out-of-band release. The CPU versions alone do not cover all Java risks discussed here. S16 S17 S18

branch	October 20 CPU	Oracle released out of band on October 21
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	The public release table still shows 8u511; the specific security build and trust chain repair must be checked, and cannot be determined based on the short version number alone

**Java 8 needs to be checked against the full build information:**Oracle The alert lists 8u511 as an affected version, and the release list lists subsequent updates with the same short name. The patch status cannot be distinguished based on the “8u511” short version number alone. You should confirm the specific security build and trust chain fixes. S17 S18

Temurin, Corretto, Zulu, Microsoft Build of OpenJDK, release version OpenJDK, etc., check according to their respective announcements and complete package/build numbers. For example, the official release record of Adoptium states that the relevant build is repackaged to add the eMudhra fix; the same name of the upstream version does not mean that the package content is the same. The .0.2 suffix rules for Oracle cannot be mechanically applied to other publishers. S20

Java application components	Recommended version baseline	Remarks
Tomcat 9 / 10.1 / 11	9.0.123 / 10.1.61 / 11.0.27	Check branch by branch; Tomcat 10.0 has stopped maintenance S21 S22 S23
Spring for GraphQL 2.0.x	2.0.5（OSS）	Commercial support is also 2.0.4.1 S25
Spring Security 7.1 / 7.0	7.1.1 / 7.0.7（OSS）	Corresponds to the minimum fix version announced in August; you need to check the subsequent security bulletin S27 S28 before deployment
Spring Security 6.5 / 6.4 / 5.8 / 5.7	6.5.12 / 6.4.19 / 5.8.28 / 5.7.26	The announcement is listed as a commercial support fix; migration is evaluated when there is no corresponding support, and it cannot be assumed that Maven Central is available for free S27

Spring upgrades should respect the project’s Spring Boot BOM, Java minimum version and compatibility lines. Do not directly force all Spring modules to the same number just to get a patch.

2.3 CPython, Django and certificate dependencies

The second column of the table below focuses on the TLS issue disclosed in September; the branch differences for tarfile are shown in section 5.3. The October 21 releases also updated bundled certificate tooling, so the last column includes those later deployment baselines. S29 S30 S33 S35

CPython branch	September security batch minimum version	Recommended deployment baseline
3.10	3.10.22	Last release from upstream, EOL; arrange migration or verify release extension support S34
3.11	3.11.17	3.11.17, and update pip/certifi in each environment individually
3.12	3.12.15	3.12.15, and update pip/certifi in each environment individually
3.13	3.13.16	3.13.17
3.14	3.14.8	3.14.9
3.15	The final 3.15.0 release includes both TLS fixes S31 S47	3.15.1

The upstream security versions of 3.11 and 3.12 may only be released in source code; when using the operating system package, check the vendor’s backport advisory and the complete package version, and there is no requirement to forcibly replace the system Python with a self-compiled version. S33 S34

independent dependency	Recommended version baseline	Description
Django 5.2 / 6.0 / 6.1	5.2.18 / 6.0.9 / 6.1.2	Incorporate subsequent correction S38 S39 on October 6
certifi	≥2026.10.19	GHSA initial patch is .18; PSF recommends .19 to preserve compatibility for unaffected certificates S36 S37
pip	≥26.2.2	The built-in copy of certifi needs to be updated separately S35 S37
uv (if used)	≥0.13.4	Update S37 according to actual installation method

These baselines cover the listed fixes. Another medium-severity issue in tar_filter was disclosed on October 22. As of October 23, 2026, an official maintenance version containing this fix has not yet been confirmed; therefore, 3.13.17 / 3.14.9 / 3.15.1 cannot be considered to have covered all tarfile issues. See Section 5.4. S40

2.4 Verifying distribution backports

Implementation principles applicable to Ubuntu, Debian, RHEL and other software packages:

Record the operating system version, repository source, full package version, and vendor security bulletin number.
Confirm that the advisory covers the specific CVE and identifies a fixed package for the relevant distribution release.
Compare the binaries/libraries loaded by the actual running process, not just the upstream short version.
When there is no evidence of a vendor patch, leave it “to be confirmed” and don’t take it as the only conclusion that the version number looks old or new.

There are differences in the apt/RPM package versions and backport strategies of different distributions. The security bulletin and complete package version of each distribution should prevail.

3. Node.js / JavaScript ecosystem: Analysis of Causes and remediation

3.1 CVE-2026-111497: Brotli native decoder out-of-bounds write

Disclosure: 2026-10-21; Node official grade: High. Affected builds of Node 22.x, 24.x, 26.x require patch section 2.1 to be installed. Node The announcement does not list a numerical CVSS score. S1

The problem occurs in the native decoding logic when handling the malformed Brotli compressed stream, which can lead to out-of-bounds writes. The official description of Vercel confirms that the research demonstration involves process memory leaks and command execution. Whether an attacker can reach the decoder depends on whether the application or dependency actually decodes the data it controls. S3

Both directions need to be checked at the same time:

inbound: The framework or middleware automatically decompresses the Brotli request body submitted by the user.
**outbound:**HTTP Clients, image grabbers, etc. access attacker-controllable sources and automatically decompress the returned content.

Disabling Brotli compression of responses sent to browsers does not remove a decoding entry point. Inbound WAF protection also does not cover applications fetching and decoding external responses. S3

**Patch direction:**Node Move the Brotli upstream fix into the native dependency, and supplement illegal decoding status checking and error propagation. When maintaining a self-compiled version, you should use the official security release or the complete patch of the matching branch. You cannot just change the version statement of a JavaScript package. S4

Interim implementation suggestions: stop unnecessary untrusted Brotli decoding; check the automatic decompression behavior of the middleware and HTTP client; if the business must accept this format, complete the processing in the patched environment as soon as possible. Adjusting Accept-Encoding is merely an act of negotiation and should not stand alone as evidence that a malicious response has been blocked.

3.2 TLS / DNS three High: The verification object is inconsistent with the actual target

All three were disclosed on October 21, with the official upgrade threshold set out in Section 2.1. S1

Identifier	Issue confirmed	Affected branches
CVE-2026-105482	`dns.resolve` Truncation of names containing NUL	22.x / 24.x / 26.x
CVE-2026-105483	IP in full-width numeric form causes certificate hostname verification to be bypassed	24.x / 26.x
CVE-2026-106069	Hostname that can be loosely interpreted as IP results in TLS verification bypass	22.x / 24.x / 26.x

DNS The essence of the problem is that the string checked by the upper layer is different from the name actually parsed by the lower layer. The official patch rejects NUL at the parsing entry and adds regression coverage. S6

TLS Two items involve name normalization, consistency of IP interpretation and certificate matching. Patch so that non-standard IP input is rejected or handled correctly to avoid confusing the actual IP endpoint with the certificate domain identity. S5

Actual troubleshooting suggestions for : gives priority to checking the code of the receiving user URL, dynamic proxy target or Webhook address; unified standardization and allow list judgment, rejects NUL/control characters, confirms legal IPv4, IPv6 and internationalized domain names still work. Whether SSRF can be further formed requires the application of link evidence, which cannot be directly deduced from the name CVE.

Do not use NODE_TLS_REJECT_UNAUTHORIZED=0 or rejectUnauthorized: false to eliminate post-upgrade checksum errors. The address, certificate and business configuration should be corrected.

3.3 July HTTP/2 High-risk and permission model issues

The following issues disclosed in July still need to be included in the investigation. It is recommended to directly use the October security version baseline in Section 2.1 when deploying. S7

CVE	Causes and effects	First fixed version
CVE-2026-56846	The retained HTTP/2 header block is not properly included in the `maxSessionMemory` budget and can exhaust memory; Impact 22.x / 24.x	22.23.2 / 24.18.1
CVE-2026-56848	HTTP/2 re-enters the sending path during packet collection, causing a heap UAF; impact 22.x / 24.x / 26.x	22.23.2 / 24.18.1 / 26.5.1
CVE-2026-58043	`--permission` The path prefix boundary match is too wide, and files outside the allowed list may be accessed.	Same as the three maintenance lines above

All three are officially High. The first two items give priority to checking whether HTTP/2 is processed by Node itself; the third item only has corresponding meaning when using the permission model and relying on this boundary. Permission model items cannot all be described as network RCE that does not require authentication. S7

Temporarily terminating HTTP/2 on a separate, updated proxy and limiting backend sources is a deployment option to reduce exposure; resource quotas can only control the consequences of resource exhaustion and cannot patch UAF.

3.4 October React / Next.js: two items RCE and one item DoS

A. RCE in RSC / `use cache` functions returning typed arrays

Public date: 2026-10-14; Critical, CVSS 4.0 9.5. Official advisory identifiers:

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

The React upstream issue involves multiple typed arrays combined with attacker-controllable values in the RSC response. The three affected react-server-dom-* package versions are 19.0.0—19.0.8, 19.1.0—19.1.9, 19.2.0—19.2.8, 19.3.0; see chapter Section 2.1. Pure browser-side React, or applications that do not use frameworks/plug-ins that support RSC at all, do not fall within the scope of this item. S10

Next.js downstream announcement lists 16.0.0—16.4.0, revised in 16.4.1; the scenario is App Router, Cache Components, and use cache functions that return multiple typed arrays. There is no official reliable general workaround, and users of affected versions are required to upgrade in time. It is not appropriate to just rely on manual searches for “this function does not seem to exist” to end the processing. S9

B. SVG Image Optimization RCE

CVE-2026-96889/GHSA-2464-fhr4-w9xw, 2026-10-14, Critical, CVSS 4.0 9.5. The problem occurs in the upstream native library used for image optimization. Officials pointed out that the RCE risk exists in the glibc Linux scenario. S11

The official version fields are:

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

The official uses a strict lower bound of >16.0.0 for the 16.x branch, but this range statement is not enough to prove that 16.0.0 is safe. The actual upgrade target is uniformly 15.5.28 / 16.4.1. S11

The official temporary solution is to ensure that Next actually loads sharp ≥0.35.5. Lock files, nested dependencies, and deployment images may still hold old instances, so just adding a new version of the sharp dependency at the top level is not enough, the final dependency tree should be checked and rebuilt. S11

C. Server Actions CPU exhausted

**GHSA-p3m5-59mp-jv5r, 2026-10-14, High, CVSS 4.0 8.2.**Next affects 13.0.0—15.5.27, 16.0.0—16.4.0, fixes 15.5.28 /16.4.1. The conditions are App Router and at least one Server Action; malicious requests can keep CPU occupied for a long time, blocking subsequent requests in the same process. Applications with Pages Router or without Server Actions are not affected by this. S12

There is no official workaround that can replace the upgrade. Rate limits, concurrency limits and resource quotas can reduce damage, but cannot be used as a conclusion for patch verification.

3.5 Earlier Next.js in the same window Serious problem

The following items are intended to avoid missing deployments that are still stuck on pre-August-September versions; it is not recommended to just move up to the old fix thresholds in the table now.

Date	Identifier / scenario	First fix; current action
2026-08-25	GHSA-2xp9-vwfh-vxw4: AVIF image optimization native library RCE, Critical	15.5.24 / 16.3.3; now 15.5.28 / 16.4.1 S13
2026-08-25	CVE-2026-75604: RCE, Critical when Pages Router and App Router are used simultaneously on Windows, and Cache Components is not enabled; versions `>=13.4.0 <15.5.24`, `>=16.0.0 <16.3.3`	15.5.24 / 16.3.3; Linux/macOS are not affected by this specific Windows issue S14
2026-09-22	GHSA-vcvr-r3jv-pc5j: the Node image-generation path in `next/og` processes untrusted SVG, Critical; 16.2.0—16.3.5	16.3.6; the Edge implementation is outside this issue’s scope, and 15.x is not an affected branch for this RCE S15

4. Java ecosystem: Runtime trust, containers and frameworks are handled separately

4.1 JDK: Regular CPU and CVE-2026-91403 are two-tier updates

The Java SE risk matrix for Oracle CPU on October 20 lists 55 new security patches, 49 of which are marked as exploitable over the network without authentication. This does not mean that there are 55 Critical, nor does it mean that there are 49 directly exploitable RCE paths for each Java web service; it must be understood in conjunction with the components, APIs, user interactions and deployment conditions in the matrix. S16

The next day’s CVE-2026-91403 (CVSS 3.1 9.1) deals with another type of risk: a set of intermediate CA related to the eMudhra event that is no longer trusted. It affects TLS peer authentication and communication confidentiality/integrity and cannot be described as a JVM memory corruption vulnerability. S17

The Oracle advisory lists the version released on October 20th as affected, so the out-of-band update on October 21st also needs to be installed. See section 2.2 for the specific version. GraalVM also has corresponding affected products, and the fixed version should be subject to its exclusive security bulletin. S17 S18

Temporary official measures: Back up first, and then remove the specified root certificate from each actually used truststore:

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

JDK 11 and later, the official example is:

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

Use keytool from the target JDK for these commands and confirm that they are operating on the actual trust store of the application. Java 8 uses the path corresponding to jre/lib/security/cacerts; customizing the truststore must be handled separately, and other publishers may have different aliases. Removing the root certificate will expand the scope of rejection, and regression-test legitimate service certificate chains. S19

The official also provides the option to enable revocation checking, but the effect depends on the actual TLS implementation, revocation service reachability and failure strategy. For general deployments, prioritize installing full vendor updates to avoid treating two JVM switches as evidence that all TLS libraries have been fixed.

4.2 Tomcat: Authentication bypass and cross-user request isolation

The following three items were published on 2026-10-20; the repaired version entry is dated October 12. The official grade of Apache is Important. S21 S22 S23

CVE	Confirmed affected versions	Necessary scenarios/results
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 Configures non-GSSAPI SASL authentication mechanism, credential verification is missing, and incorrect passwords may also pass
CVE-2026-101356	9.0.118—9.0.122；10.1.55—10.1.60；11.0.22—11.0.26	HTTP/2’s asynchronous Servlet error handling incorrectly recycles/reuses objects, causing requests or responses being mixed between users
CVE-2026-103119	Only confirm 11.0.0-M25—11.0.26	Large AJP non-blocking writes can cause a buffer under-read, exposing previous response data in later requests.

The corresponding fix is 9.0.123 / 10.1.61 / 11.0.27; AJP is only listed as Tomcat 11 according to the announcement, and cannot be expanded to three branches with the same problem. S21 S22 S23

The JNDIRealm patch fixes a verification gap in the actual authentication process, where “the application login interface looks normal” cannot be used instead of verification. Realm, SASL mechanisms should be checked for the actual configuration of the service, and tests must fail for incorrect passwords. S24

Interim implementation suggestions: isolate the affected authentication path; suspend HTTP/2 processing of Tomcat when business permits; close useless AJP. Only restricting direct access to the AJP port cannot prove that traffic entering through the legal front proxy will not be affected. After the official update, asynchronous concurrent requests from two independent users should be tested to confirm that there is no cross-talk between identities and responses.

4.3 Spring for GraphQL：CVE-2026-59285

Public date: 2026-08-20; High. affected 2.0.0—2.0.4, repaired 2.0.5 (OSS) or 2.0.4.1 (commercial support). S25

This is an unsafe deserialization risk in paging queries. The official requirement is that the following conditions must be met at the same time:

Use Spring for GraphQL.
Deserialize JSON using Jackson 2.x.
Provide Connection paging field to the outside world.
The classpath contains specific classes that can perform unexpected logic during instantiation or deserialization.

A malicious GraphQL request may cause RCE when the conditions are met. It cannot be reduced to “all Java programs using Jackson can be exploited”. S25

Why 2.0.4 is insufficient: In June, CVE-2026-41699 had given patch baselines such as 2.0.4, and in August the announcement clearly included 2.0.4 into the new scope of influence. Therefore, the repair record must be updated according to subsequent announcements, and the minimum version of the old CVE cannot be used. S26

When upgrade is temporarily unavailable, affected pagination fields accessible to untrusted callers can be suspended; narrowing down the deserializable types and class paths is an in-depth measure. Regressions should cover legal cursors, paginated results, and exception input rejections, and check the actual component versions within the final application JAR.

CVE-2026-59270, 2026-08-20, Critical. embedded UnboundIdContainer registers known administrator credentials by default and listens on all network interfaces. When the component is enabled and the port is reachable, an attacker can read or modify directory data; projects that generally introduce Spring Security will not automatically expose LDAP. S27

Affected area:

branch	affected	First fix/acquisition channel
7.1	7.1.0	7.1.1 OSS; also commercial 7.1.0.1
7.0	7.0.0—7.0.6	7.0.7 OSS; also commercial 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, commercial
5.8 / 5.7	5.8.0—5.8.27；5.7.0—5.7.25	5.8.28/5.7.26, commercial

Source: S27. Troubleshoot the spring.ldap.embedded.* automatic configuration and direct instantiation code; close the component when it is not needed for production, and check the actual listening address. When the business really needs it, first limit the calling sources and then complete the component upgrade.

**Related authentication issue: CVE-2026-47841 (High).**WebAuthn User authentication is set to REQUIRED, and after the HTTP session is serialized by distributed storage, incorrect object identity comparison may invalidate the authentication requirement. The attack also requires the attacker to have possession of the user authenticator device, not arbitrary remote login without a device. For the corresponding affected versions of 7.1, 7.0, 6.5, and 6.4, the patch baseline is consistent with these branches in the above table; verification should cover cross-node sessions and still require PIN/biometric verification. S28

5. Python ecosystem: interpreter, standard library, framework and certificates

5.1 CVE-2026-19445: SSLContext UAF in SNI callback

Publication date: 2026-09-30; PSF Level: Critical. In Python server TLS, sni_callback switches the connection to another SSLContext, and when the original context has no other surviving references, the unauthenticated TLS client may crash the service or call a pointer in a released object. S29

The core is that the Python object is inconsistent with the underlying TLS callback life cycle. The original context has been released, and the underlying layer may still hold the state required for the callback; the interpreter native patch needs to be used to fix the reference life cycle. S47

Scope: Python code that only acts as a TLS client is not affected by this item; the normal mode of the listening socket holding the original context for a long time does not fall into the specific failure path described in the announcement. After Nginx terminates TLS, it only hands over the local HTTP to Python, and Python directly handles SNI by itself, which is a different attack surface. S29

Corresponding to 3.10—3.14 fixed version, see section 2.3. The official version of 3.15 has been repaired, and 3.15.1 can actually be selected. Only updating the pip dependency cannot replace the interpreter’s _ssl implementation. S33 S35 S47

Official temporary mitigation: keeps strong references to all SSLContext that have set the SNI callback until the end of the server life cycle. This needs to cover the actual dynamic creation and switching paths; the custom OpenSSL 1.1.1 build should also check the renegotiation conditions in conjunction with the official issue record and give priority to complete updates. S29 S47

5.2 CVE-2026-19553: The hostname flag is turned on, but the hostname is missing when calling

Public date: 2026-09-30; High. WhenSSLContext.check_hostname=True, if wrap_bio() is not passed in server_hostname, the original implementation may silently skip hostname verification. Successful certificate chain verification does not mean that the target domain name has also been matched. S30

Remediation requires both steps:

Install the interpreter security release listed in section 2.3.
Check the wrap_bio(), related asyncio.create_connection() / loop.start_tls() paths, explicitly pass in the expected and non-empty hostname, and keep certificate verification turned on. S30

**Compatibility differences that cannot be omitted:**3.10, 3.11, 3.12 are for compatibility, only DeprecationWarning is issued for some cases where hostname is missing; 3.13 and later raise ValueError. 3.12 backport also clearly distinguishes None from empty strings: a new warning is added for None, and an error is still reported for empty strings. Therefore, low-branch users cannot assume that the originally missing domain name verification has been automatically restored simply by upgrading. S31 S33

In a test environment, use a trusted-chain certificate with a mismatched hostname and confirm that the actual application TLS client rejects it. Merely reading the check_hostname Boolean value does not constitute complete acceptance.

5.3 CVE-2026-82049: Link combination bypass in tarfile filter

Public date: 2026-09-14; High. In CPython 3.13 and earlier related implementations, the combination of hard links and symbolic links in untrusted tar can bypass the data / tar extraction filter, exposing the contents of files outside the unpacking directory in the unpacking tree, or modifying their permissions and modification times. S32

Confirmed impacts of this vulnerability include file content exposure and metadata modification; these impacts alone are not sufficient to demonstrate arbitrary overwriting of external file content or unconditional implementation of RCE.

For the corresponding patch baselines of 3.10—3.13, see Section 2.3. Python 3.14 has been exempted from this specific issue due to os.link() behavior changes since 3.14.0b1, so the affected scope of the 3.10—3.13 branch above does not apply. S33

Temporary and in-depth measures: suspend automatic extraction of untrusted archives; use isolated low-privilege worker processes and new exclusive directories when business must be processed, deny symbolic links, hard links and device entries by business, and limit the number of files and decompression resources. These are deployment recommendations.

filter="data" is more suitable for general untrusted archives than the full trust strategy, but the filter itself on the old version also has this vulnerability, and adding this parameter alone cannot replace the update. The filter is also not a full file system sandbox. S32 S45

5.4 Supplementary risk: CVE-2026-114583 (Medium) and patch release status

PSF disclosed in 2026-10-22 that tarfile.tar_filter’s processing of specific link names can be bypassed, allowing subsequent members to write outside the unpacking directory, with a level of Medium. Official fix PR was merged that day; as of October 23, 2026, no official maintenance release containing this commit has been confirmed. S40

Therefore:

This item is listed separately as Medium.
Interpreter versions released on October 21st cannot be considered to have included this fix.
The process that still uses filter="tar" to handle untrusted archives should track release backport; isolate or suspend this processing path for a short period of time. When switching to data and rejecting links, you must also confirm that it meets business requirements, and changing the filter cannot be described as an unconditional sandbox.

5.5 GeoDjango: CVE-2026-15307 and subsequent fixes in October

2026-08-04, Django official High. spatial query implicitly passes certain strings/dictionaries to GDALRaster, and the driver may write files or initiate network requests; RCE may be formed when there are specific paths and subsequent execution conditions. Staff with spatial field model viewing permissions may also access this path through the admin changelist. S38

The initial fix is 5.2.17 / 6.0.8, which restricts the input types accepted by spatial lookups. This change may affect the original business of using string/dictionary to express raster; simply wrapping untrusted input into GDALRaster does not mean verifying it. S38

On October 6, CVE-2026-87890 (Moderate) was repaired: VRT expressed in bytes can reference external resources and still triggers network requests; on the same day, the nested geometry DoS protection of CVE-2026-15830 was also strengthened. The latter two cannot be upgraded to describe the new high-risk RCE, but indicate that the deployment baseline should be 5.2.18 / 6.0.9 / 6.1.2. S39

The implementation checks the two entry points of API and administration interface, restricts untrusted spatial lookup, file write permissions and outbound access; after updating, regression-test valid spatial queries and rejection of prohibited input. Ordinary Django applications that do not use GeoDjango should not directly apply this RCE conclusion.

5.6 certifi / pip: Certificate trust must cover every copy

GHSA-6q48-6c7w-9gw2, 2026-10-20, Critical, known CVE not listed. This is the certificate distrust update caused by the eMudhra intermediate CA incident. It cannot be summarized as the cryptography mechanism of HTTPS or that all root certificates have been cracked. S36

The certifi advisory originally listed 2026.10.18 as a patch; PSF later explicitly recommended 2026.10.19 to preserve compatibility with unaffected root certificates. The operating baseline is .19. S36 S37

Need to distinguish:

Trust material location	Why you need to check separately
Operating system CA package	System trust material for the image or host
certifi in venv	CA bundle actually used by applications or Requests etc.
pip built-in certifi	Is a different copy than the externally installed certifi
uv / Other packaging tools	Follow the tool’s own updates and trusted sources
Customized CA files, packaged snapshots	May continue to override default trusted sources for systems or packages

The above is a checklist based on different packaging locations. PSF requires updating related tools, existing virtual environments and rebuilding the image; only updating the host CA or reinstalling the interpreter cannot prove that all copies have been refreshed. S35 S37

When upgrading from the old pip secure bootstrap, PSF provides the commands for fixed wheel and SHA-256, see appendix S37. Do not turn off TLS verification or add --trusted-host to bypass certificate issues.

6. Formal remediation process

The following commands are for confirmed trusted environments. When executing, the existing package manager, lock file and deployment process of the project should be combined to avoid mixing npm/pnpm/yarn or pip/uv/Poetry to generate conflicting lock files.

Handle an exception first: If you suspect that the environment has run the compromised package in Section 9, isolate it first and check the disk, lock file and image record from a clean environment; do not run the following Python/pip command first. S41

6.1 Establish a ledger that can correspond to real traffic

Each service records at least:

External entry point, reverse proxy, direct connection path to the origin site, and background queue/scheduled tasks.
The actual startup command, running account, binary path, process or container identity.
Runtime full version, publisher/repository, package full version, or image digest.
Framework and transitive dependencies, lock files, native libraries, and trust store paths.
Corresponding to whether the vulnerability condition exists, patch target, restart scope, responsible person and verification result.

Development machines, CI runners, build containers, and background tasks should also be checked according to their paths to untrusted content; don’t just update the public-facing web container.

6.2 Node.js: Determine the runtime first, then update application dependencies

Check in actual service environment:

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 should be executed using the service’s actual executable or within an actual container; it checks for newly launched processes and does not itself prove that the old worker has been replaced. Node can add the patch to the built-in Brotli while retaining the original library version string. Therefore, do not rely solely on process.versions.brotli to determine whether it has been repaired. You should combine it with the Node security version or the vendor’s backport evidence. S2 S4

npm ls is used to see the actual dependency tree; missing packages or peer conflicts may also produce non-zero exit codes, so you should read the specific output. npm audit is used as a dependency checking aid and cannot replace Node binary and native library checking.

Use mise to manage the environment of Node 24, which can be updated as follows:

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

mise use -g configures the global version; the project’s local configuration still needs to be checked separately. If the service has fixed the old absolute path, container base image, or environment of a different account, the corresponding configuration must be updated and the service must be restarted. The command itself does not replace an old running process. S43

In the Next project, execute the corresponding command according to the selected branch. For Next 15:

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

For Next 16:

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

Check the React/RSC compatible dependencies, lock files and final sharp instance, and then build according to the project process. Use the updated lock file in CI for reproducible installation, and check the version in the running image after building. Do not use uncontrolled automatic repair across major versions as the default solution for this emergency.

6.3 Java: Verify publisher, actual JVM and embedded components

Preliminary inventory:

java -XshowSettings:properties -version

The java.home, java.runtime.version and publisher in the output should be aligned with the JVM actually used by the service. For JVM with attach permission, jcmd of JDK can be used to check the target process, not just the login shell.

Check dependencies in trusted projects and select based on actual build tools:

./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

These build commands may execute plug-ins and resolve dependencies online, and only run on trusted projects. Check the final JAR/WAR or the actual JAR in the image and do not substitute build file declarations for the final artifact. Spring Boot embedded Tomcat requires rebuilding the application; updating a separate Tomcat installation in the system will not modify the copy in the application package.

After the runtime is updated, check the customized javax.net.ssl.trustStore, application-self-loaded KeyStore, jlink runtime, GraalVM/native image and other delivery forms item by item. Applications that already have customized trust materials cannot end the check just because the JDK directory becomes new.

6.4 Python: Interpreter-by-interpreter and virtual environment processing

Within the actual venv/container confirmed to be trusted:

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

This script only collects information and does not perform version qualification determination. ssl.get_default_verify_paths() is the default path information and cannot prove that all third-party clients use the same trust store; it should be confirmed based on the application configuration.

After completing the trusted pip boot upgrade of appendix S37, update the certificate dependencies according to project constraints, for example:

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

The project’s requirements/lock file needs to be updated at the same time, otherwise the next deployment may revert to the old version. When using uv, Poetry, or an enterprise package repository, use their existing locking and publishing processes; do not manually modify packages just within a production container.

The project’s existing pip-audit workflow can be used to check for known dependency vulnerabilities in a trusted environment; it is not a malicious code scanner and does not cover all interpreter, system library and trust store risks. S44

It is not recommended to force the system /usr/bin/python3 to point to a new compiled version. Use release security updates or project isolation runtimes to avoid breaking management tools that rely on system Python. This is an implementation choice and is not an additional fix requirement for this vulnerability.

6.5 Rebuild and replace the running instance

It is recommended that the following steps be taken as a complete change:

Obtain the patch from the original trusted source and save the version/hash and dependency lock.
Return key functions in a near-production environment and confirm that native extensions are compatible with JVM/framework.
Update the runtime, application dependencies and actual trust store; refresh the base image and system CA for the container, do not just reuse the old layer.
Rebuild applications and images, and replace service, worker, queue consumer, and scheduled task instances on a rolling basis.
Recheck the version and configuration in the new running instance and confirm that all old copies have exited.
Observe error rates, latency, CPU/memory, TLS handshake failures, and process crashes.

Rollback should give priority to retaining safe runtime and patch dependencies, and rolling back application configuration or business changes. If you have to return to an old product with vulnerabilities, the corresponding entry restrictions should be restored simultaneously, and the responsible person and the minimum recovery period should be clearly defined.

7. Temporary Mitigation and Patch Selection

7.1 Coverage boundary of temporary measures

The following are implementation suggestions based on the announced utilization conditions. Unless the official plan is noted, the vendor does not guarantee that all variants can be completely blocked.

risk	Temporary measures that can be taken	The part that cannot be deemed completed based on this
Brotli decoding	Stop untrusted input decoding; check inbound and outbound automatic decompression	Inbound WAF or turning off response compression does not cover all decoding entries S3
Next.js typed arrays RCE	Upgrade immediately; temporarily isolate affected services if necessary	There is no official reliable universal workaround S9
Next.js SVG RCE	Official plan: Ensure the actual sharp ≥0.35.5; suspend relevant optimization entry points when business permits	Does not cover other Next/RSC issues S11
Tomcat Realm / HTTP/2 / AJP	Isolate the corresponding path and close unnecessary connectors	Still need the corresponding branch repair package S21 S22 S23
GraphQL Deserialization	Suspend affected Connection fields; restrict untrusted callers	Only request length limit cannot fix type/deserialization problem S25
Spring embedded LDAP	Disable when not needed; limit the reach of the real listening port	Default administrative identity and directory integrity still need to be checked S27
CPython SNI UAF	Official plan: Keep the relevant SSLContext strong reference until the end of the service	All create/switch paths must be covered S29
Python hostname skip	Official solution: Pass expected server_hostname correctly	Cannot just check check_hostname flag or ignore warning S30 S31
Untrustworthy tar	Disable/quarantine extraction, reject non-essential links and device entries	Neither filters nor resource quotas are universal sandboxes S32 S40 S45
Certificate trust event	Update the correct CA material; Java trust can be restricted according to the official mitigation	Disabling TLS verification increases risk S19 S37

7.2 Select patch based on delivery method

Delivery method	Prioritize repair methods	Evidence that should be retained
Distribution-managed runtime	Manufacturer’s corresponding security updates	Full package version, announcement, repository source
Official Binary/Runtime Manager	Official security release from the same branch	Version, source and digest, actual execution path
Self-compiled Node / CPython	The matching branch’s official source release or the vendor’s complete patch set	Commit set, build parameters, dependent libraries and regression results
Spring / Next / Django	Compatible with in-branch updates, rebuilding dependency locks and final applications	Final dependency tree, actual version in JAR/package/image
Custom trust store	Official withdrawal plan or vendor update confirming the withdrawal	Actual usage path, material change, TLS success and rejection tests
A compromised environment	Rebuild from clean and trustworthy products and conduct separate incident investigation	Historical package/image digest, installation record, credential rotation record

7.3 Key patch mechanism and review focus

Brotli: pays attention to whether the boundary check and error return of the native decoding status are complete before entering the build; only replacing the JavaScript package cannot change the code statically compiled into Node. S4
Node DNS/TLS: focuses on input rejection, address normalization, distinction between IP SAN and DNS identities, and DNS callback/Promise The parsing path and TLS hostname match test. S5 S6
Tomcat JNDIRealm: focuses on whether the authentication process actually verifies the credentials, rather than just obtaining a directory context; prioritizing the official version and not treating a single source file replacement as a complete binary patch. S24
CPython ssl: focuses on Python reference ownership and the life cycle of the underlying SSLContext; wrap_bio() backports while having branch compatibility differences, and you must read the actual implementation of the branch used. S31 S47
Certificate distrust: Such updates may appear as trusted material or deny list changes rather than obvious API changes. The same batch of Node also includes the rejection mechanism of the affected intermediate CA; the respective trust sources of Java and Python still need to be verified separately. S19 S37 S46

**Independent Brotli binding should also be checked.**Google upstream released 1.0.10 / 1.1.1 / 1.2.1 on the same day to fix CVE-2026-111497. Python native extensions or JNI artifacts that embed the same affected C implementation need to be independently updated/rebuilt; it cannot be inferred that all pure Java decoders are affected, nor can it be assumed that upgrading Node automatically replaces copies in other languages. S42

8. Verification and follow-up checks

8.1 Minimum verification checklist

Check items	Evidence required
runtime	Full version or vendor backport evidence correct in real process/container
application dependencies	Next/RSC/sharp, Tomcat/Spring, and Django/certifi in the final deployment products have reached the corresponding threshold
Replacement range	All worker/JVM/container copies and background tasks have been replaced with new ones, and the old instances have exited.
TLS	Valid domain certificates succeed; mismatched hostnames and invalid chains fail according to policy; custom trust stores are included
eMudhra distrust	The certificate chain built by the affected intermediate CA was rejected during actual runtime, or there is evidence that the specific vendor’s security build/corresponding rejection list has been deployed; the case cannot be closed based on the general TLS test or the Java 8 short version number.
Node decoding and images	Normal compressed response, upload, image optimization and RSC functions are available; untrusted source policy is in effect
Java Authentication and Isolation	Wrong password rejected; independent user concurrent asynchronous requests without identity/response mixing; LDAP listening as expected
Python SNI / Archive	Normal multi-domain name TLS business is stable; archiving rejects path traversal and disallowed links, and files outside the directory are not modified
Data and functional regression	Paging, spatial query, permission check and background tasks passed the existing tests of the project
Resources and Observations	There is no abnormal increase in CPU, memory, error rate, latency and TLS errors.
Traceability	Save upgrade time, package/image digest, configuration changes, verification results and unresolved items

These are implementation acceptance recommendations and do not require an attack script to be produced for each CVE. Verification involving crashes, resource exhaustion, and archive out-of-bounds should use upstream regression testing or project controlled test data in an isolated environment.

8.2 Patching and intrusion investigation are different tasks

Check existing logs for unusual decoding errors, worker/JVM crashes, suspicious file writes, directory data changes, authentication exceptions, outbound requests, and credential usage records. These signs need to be judged in context: a crash or OOM is not proof of successful exploitation; the absence of alerts does not prove that a system was unaffected.

When unauthorized modifications, compromised credentials, or confirmed malicious dependencies are discovered, evidence should be preserved, the relevant instances isolated, affected credentials rotated from a trusted environment, and the system rebuilt. The patch will not revoke tokens that have been obtained by the attacker or restore data that has been modified.

9. Supply chain security incident: LiteLLM 1.107.0 compromise

**Official confirmation date: 2026-10-21.**LiteLLM reported that its release pipeline was compromised. PyPI’s litellm==1.107.0 and some Docker/GHCR products of the same period contained secret stealing and remote control malicious code, and the related products have been withdrawn. S41

To determine the impact, you should check the historical installation records and image digest; labels such as latest, main-latest, and main-stable now point to clean images, which does not prove that the products pulled at the time of the incident were clean. The official recommendation at that time was to temporarily pin 1.106.2; this recommendation was based on this incident, and other security announcements still need to be checked during deployment. S41

For environments where related products have been installed or run:

Isolate and preserve installation records, images, and logs, and inspect them from a clean environment.
Do not start Python/pip in a suspicious environment first; malicious .pth / sitecustomize.py may be executed again after startup.
Rebuild hosts, venvs/containers from trusted sources; cannot just uninstall or downgrade packages.
Revoke/rotate cloud credentials, LLM provider keys, LiteLLM keys and database credentials based on actual accessibility and review abnormal usage. S41

This is a confirmed supply chain incident and requires consideration of malicious code execution, credential leakage, and persistence risks when dealing with it. As of October 23, 2026, officials were still investigating the initial intrusion.

Appendix: Cited sources and links

The following source verification date is 2026-10-23, including the project’s official security announcement, official code repository and vendor’s instructions. The main text [Sx] corresponds to this appendix; when performing updates, you should check whether the supplier has released subsequent revisions.

S1 — Node.js: 2026-10-21 Security Notice

Purpose: Four runtimes High, affecting branches, October security release.
Link: Official Security Bulletin

S2 — Node.js: Official release instructions for three maintenance lines

Purpose: Check 22.23.4, 24.22.1, 26.12.1 and the actual merged patches.
Link: Node.js 22.23.4
Link: Node.js 24.22.1
Link: Node.js 26.12.1

S3 — Vercel: Node.js Brotli RCE security advisory

Purpose: Inbound/outbound decoding conditions, WAF coverage boundary, Node 20 status.
Link: Node.js security advisory: Brotli decoder RCE

S4 — Node.js: Brotli official patch submission

Purpose: Implementation basis for native decoding checking and error propagation.
Link: Brotli Patch commit 49dff6f57a

S5 — Node.js: TLS address normalization patch

Purpose: Certificate identity verification of full-width numbers and non-standard IP.
Link: IP normalization regression Patch
Link: rejects the patching of non-standard IP address

S6 — Node.js: DNS NUL verification patch

Purpose: Input rejection and regression coverage.
Link: dns.resolve Input verification patch

S7 — Node.js: 2026-07-29 Security Notice

Purpose: HTTP/2 memory exhaustion, UAF and permission model vulnerabilities.
Link: July 2026 Security Releases

S8 — Next.js: 2026-10-14 security update

Purpose: Unify upgrade baseline and three key risks.
Link: Next.js Security Update for Upstream Vulnerabilities

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

Purpose: GHSA-673q-mjm6-r5xr; affects interval, condition, score and workaround status.
Link: Next.js Official Security Bulletin

S10 — React：React Server Components RCE

Purpose: GHSA-xqc2-xf4c-x3h3; affected and fixed versions of three RSC packages.
Link: React Official Security Bulletin

S11 — Next.js：SVG Image Optimization RCE

Purpose: CVE-2026-96889 / GHSA-2464-fhr4-w9xw; glibc, sharp and original version boundaries.
Link: SVG Image Optimization Official Security Bulletin

S12 — Next.js：Server Actions DoS

Purpose: GHSA-p3m5-59mp-jv5r; affects conditions, versions and ratings.
Link: Server Actions DoS Official Security Bulletin

S13 — Next.js: AVIF Image optimization RCE

Purpose: 2026-08-25, GHSA-2xp9-vwfh-vxw4.
Link: AVIF Official Security Bulletin

S14 — Next.js：Windows RCE

Purpose: 2026-08-25, CVE-2026-75604/GHSA-p293-qw3h-jr36.
Link: Windows RCE Official Security Bulletin

S15 — Next.js：next/og ImageResponse RCE

Purpose: 2026-09-22, GHSA-vcvr-r3jv-pc5j; Difference between Node and Edge.
Link: ImageResponse Official Security Bulletin
Link: September 22 release notes

S16 — Oracle: October 2026 CPU

Purpose: Java SE risk matrix, patch quantity and applicable conditions.
Link: Oracle Critical Patch Update – October 2026
Link: Oracle Java SE CPU Version list

S17 — Oracle: CVE-2026-91403 out-of-band alarm

Purpose: 2026-10-21, JSSE certificate trust risk, affected products and CVSS 3.1 9.1.
Link: Oracle Security Alert

S18 — Oracle: JDK official version and download

Purpose: Distinguish between CPU on October 20th and the out-of-band version on October 21st; distinguish limitations of the short version of Java 8.
Link: JDK release list
Link: Oracle Java Download page

S19 — Oracle: eMudhra temporary withdrawal plan

Purpose: Updated 2026-10-22; two root certificates, keytool, custom truststore, and revocation checking.
Link: Distrusting eMudhra Intermediate Certificates in Oracle JDK

S20 — Eclipse Adoptium: Release build record

Purpose: Temurin is repackaged due to the certificate incident; the Oracle version suffix cannot be mechanically applied.
Link: Adoptium Release Scorecards

S21 — Apache Tomcat 9 Security Notice

Purpose: 9-branch exact affected interval with 9.0.123 fix.
Link: Tomcat 9 vulnerabilities

S22 — Apache Tomcat 10 Security Notice

Purpose: 10.1 branch precise interval and 10.1.61 repair; 10.0 EOL.
Link: Tomcat 10 vulnerabilities

S23 — Apache Tomcat 11 Security Notice

Purpose: Three items Important, 11.0.27, AJP applicable scope and disclosure/release date.
Link: Tomcat 11 vulnerabilities

S24 — Apache Tomcat: JNDIRealm patch commit

Purpose: Formal basis for repairing certification verification gaps.
Link: JNDIRealm Patch commit

S25 — Spring：GraphQL CVE-2026-59285

Purpose: 2026-08-20, Required, 2.0.5 OSS / 2.0.4.1 Commercial Repair.
Link: Spring for GraphQL Unsafe Deserialization

S26 — Spring：GraphQL CVE-2026-41699

Purpose: An earlier fix threshold, just to explain why you can’t stay at the old baseline.
Link: 6 Month GraphQL Security Bulletin

S27 — Spring Security：CVE-2026-59270

Purpose: Embed UnboundID LDAP, known management identity and distinguish OSS/commercial version.
Link: Spring embedded LDAP Security Bulletin

S28 — Spring Security：CVE-2026-47841

Purpose: WebAuthn user authentication, session serialization and attack premise.
Link: WebAuthn Security Bulletin

S29 — PSF: CVE-2026-19445 Independent Security Advisory

Purpose: 2026-09-30, Critical, SNI Conditions and temporary measures cited by SSLContext.
Link: SSLContext UAF Official announcement

S30 — PSF: CVE-2026-19553 Independent Security Advisory

Purpose: 2026-09-30, High, missing hostname and explicit parameter mitigation.
Link: wrap_bio Official announcement of hostname verification

S31 — CPython: wrap_bio official patch and 3.12 backport

Purpose: 3.10—3.12 warning compatibility policy, the difference between None and the empty string.
Link: Main Patch PR #158503
Link: 3.12 Backfill PR #158513
Link: 3.15 Backfill PR #158511

S32 — PSF: CVE-2026-82049 Independent Security Advisory

Purpose: 2026-09-14, High, link combination, metadata modification and content exposure.
Link: tarfile link bypasses the official announcement

S33 — CPython: Official security release at the end of September/early October

Purpose: Minimum fix version, source code distribution method and 3.14 exemption for tarfile specific issues.
Link: Python Cross-branch security release instructions
Link: Python 3.11.17
Link: Python 3.12.15
Link: Python 3.13.16
Link: Python 3.14.8

S34 — CPython: 3.10 last safe release

Purpose: 3.10.22 and end of upstream life cycle.
Link: Python 3.10.22

S35 — CPython: 2026-10-21 emergency maintenance version

Purpose: 3.13.17 / 3.14.9 / 3.15.1, built-in pip and certifi updates, existing venv requirements.
Link: Python 3.13.17
Link: Python 3.14.9
Link: Python 3.15.1

S36 — certifi: emSign certificate distrust announcement

Purpose: 2026-10-20, GHSA-6q48-6c7w-9gw2, Critical, no known CVE.
Link: certifi Official Security Bulletin

S37 — PSF: Impact of eMudhra / emSign on Python users

Purpose: certifi .19 recommendation, pip/uv baseline, trusted boot upgrade command with SHA-256.
Link: PSF Official event and upgrade instructions

The pip boot upgrade command provided by the official instructions cited by S37 is as follows. Only be used in Python environments that have been confirmed to be trustworthy; if there is suspicion of poisoning in Section 9, first isolate and rebuild according to the incident process. It fixes the wheel content hash and subsequently updates other dependencies according to the project process.

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 safe release

Usage: CVE-2026-15307, GeoDjango Exploitation conditions, initial fixes and compatibility changes.
Link: Django 6.0.8 / 5.2.17

S39 — Django: 2026-10-06 safe release

Purpose: CVE-2026-87890, geometry DoS subsequent reinforcement with the currently selected baseline.
Link: Django 6.1.2 / 6.0.9 / 5.2.18

S40 — PSF / CPython: Latest tar_filter side note

Purpose: 2026-10-22, CVE-2026-114583 (Medium); PR merger does not mean that the official maintenance version has been released.
Link: PSF Independent Announcement
Link: CPython Patch PR #160098

S41 — LiteLLM: Official Supply Chain Incident Report, October 21

Purpose: 1.107.0 contaminated product, historical digest, isolation reconstruction and credential disposal.
Link: Contained: LiteLLM v1.107.0 Compromised

S42 — Google Brotli: official secure version

Purpose: Independent Brotli 1.0.10 / 1.1.1 / 1.2.1 and cross-language embedded copy verification basis.
Link: Brotli releases

S43 — mise: use command official documentation

Purpose: Specify tool version and command semantics of global configuration.
Link: mise use

S44 — PyPA: pip-audit official project

Purpose: Python The purpose and capability boundaries of dependency vulnerability auditing.
Link: pip-audit

S45 — Python: tarfile extraction filter document

Purpose: data strategy, default behavior changes, and restrictions that cannot replace the sandbox.
Link: tarfile extraction filters

S46 — Node.js: Intermediate CA rejection mechanism

Purpose: This eMudhra related trust chain processing is not equivalent to the cryptographic invalidation of all root certificates.
Link: Node.js PR #66871

S47 — CPython: SNI UAF technical notes and fixes

Purpose: reference life cycle, special build conditions and branch backtracking.
Link: official issue #156293
Link: official patch PR #158504
Link: 3.15 Backfill PR #158514