Node.js, BIND and Java in one week: the October 2026 security releases from the server side
Last updated:

Security releases rarely line up this neatly. In one week ISC patched BIND 9, Oracle shipped its quarterly Critical Patch Update and then an emergency Java alert, Node.js published ten fixes, and browsers blocked eight intermediate certificate authorities after their private keys turned out to be weak. Each one is manageable on its own. Together they touch DNS, the TLS trust chain and two of the most common application runtimes on a server, so it is worth handling them as one piece of work.
TL;DR
- ISC fixed four high-severity BIND 9 bugs on 21 October 2026; the fixed releases are 9.20.30 and 9.21.27, and 9.18 gets no GSS-TSIG fix.
- Eight eMudhra intermediate CAs were blocked after a key compromise; browsers acted from 17 October, Node.js and Java on 21 October.
- Node.js 22.23.4, 24.22.1 and 26.12.1 updated their bundled CA list; Java needs both the October CPU and Security Alert CVE-2026-91403.
- The OS bundle, each JDK’s
cacertsand Node.js’s built-in roots are separate stores and are updated separately. - Check whether
namedactually runs before planning an emergency BIND upgrade.
The week at a glance
ISC sent early notification of the BIND issues to its customers on 14 October. On 17 October a researcher reported to Mozilla that eight eMudhra intermediate CA keys were compromised; Chrome blocked them the same day, Apple followed on the 19th and Microsoft on the 20th. Oracle released its October Critical Patch Update on 20 October. On 21 October ISC published the BIND advisories, Node.js shipped 22.23.4, 24.22.1 and 26.12.1, Oracle issued Security Alert CVE-2026-91403 for Java, and eMudhra published its explanation of the weak keys.
BIND 9: four high-severity fixes
| CVE | Issue | Score | Who is exposed |
|---|---|---|---|
| CVE-2026-94300 | Concurrent GSS-TSIG messages corrupt memory; abort or potential remote code execution | 8.1 | Servers that accept GSS-TSIG, typically dynamic updates integrated with Active Directory or Kerberos |
| CVE-2026-19630 | Crafted inbound messages cause disproportionate CPU and memory use | 7.5 | Resolvers |
| CVE-2026-97313 | Certain RPZ configurations and query patterns trigger an assertion failure | High | Recursive servers using RPZ |
| CVE-2026-96888 | Redirect zone with strict QNAME minimization can abort | High | Resolvers with that configuration |
Affected ranges for the two scored issues are 9.11.0 to 9.18.50, 9.20.0 to 9.20.29 and 9.21.0 to 9.21.26. The fixed releases are 9.20.30 and 9.21.27, and ISC lists no workaround for the GSS-TSIG bug. The 9.18 branch is end of life, so moving to 9.20 is the upstream path. ISC said it was not aware of active exploitation.
Enterprise distributions ship older BIND versions with their own backports, so the upstream version number is not the test. Check your vendor’s errata for these CVE numbers and the package changelog.
Node.js and Java: the trust chain moved too
The Node.js release fixed ten CVEs, four of them high, and updated the bundled c-ares, OpenSSL, Undici and CA certificate store. The CA change removes the compromised eMudhra intermediates, which matters because Node.js uses its own bundled roots by default rather than the operating system’s.
Java has the same property. Oracle’s October Critical Patch Update contained 55 Java SE fixes, 49 of them remotely exploitable without authentication. A day later Oracle issued Security Alert CVE-2026-91403, rated 9.1, for the JSSE component, which could continue to accept certificates from the compromised eMudhra intermediates. Reports list builds shipped in the October update itself among those affected, so a server that installed the quarterly update on 20 October still needs the alert fix.
Check a BIND version against the advisories:
How do you tell what role a BIND server plays?
The BIND advisories split by role, so the first question for each server is what it does. named-checkconf -p prints the effective configuration: a recursion yes; with an allow-recursion list means the server resolves names for clients, zone statements of type primary or secondary mean it is authoritative, and many servers do both. GSS-TSIG shows up as a tkey-gssapi-keytab or tkey-gssapi-credential option, usually next to an update-policy that grants Kerberos principals the right to update records.
A resolver with an open allow-recursion is the worst case for CVE-2026-19630, because anyone who can send it a query can drive the resource exhaustion. Restricting recursion to your own networks does not fix the bug, but it shrinks the set of people who can reach it until the upgrade is done.
How do you check each trust store for the eMudhra intermediates?
Each store answers a different command. The operating system bundle can be listed with trust list | grep -i emsign on Red Hat-family systems. A JDK’s own store is read with keytool -list -cacerts, filtered the same way. Node.js keeps its roots inside the binary, so the quickest check is that the runtime is at 22.23.4, 24.22.1 or 26.12.1, the builds whose bundled store was updated.
Two cautions. A root entry named emSign in a list is not the same thing as a compromised intermediate, because the blocked certificates were intermediates and several projects handled them by distrusting or removing them rather than by shipping a new root list, so read your vendor’s notice before deleting anything by hand. And a service only picks up a changed store when it restarts.
A field note from a cPanel server
On one of our cPanel servers the bind package is installed, at a Red Hat backport build of 9.11.36, yet the server is not exposed to these BIND bugs: cPanel is configured to use PowerDNS and named is not running. The package is there for its tools. The lesson is to check the service, not the package list, before you schedule an emergency upgrade, and to keep the package updated anyway so it never becomes the exposed one.
How do the three releases fit together?
It is tempting to handle each vendor’s release as its own ticket. In practice they share one dependency, the TLS trust chain, and one constraint, restarts. BIND is separate on the DNS side, but a resolver that is upgraded and restarted in the same window as Java and Node.js services saves a second round of change approvals and a second night of watching dashboards.
The order we use is DNS first, because every other service depends on name resolution and a broken resolver hides every later problem; then the operating system trust bundle; then the runtimes, each followed by a restart of the services that use it; and last a check of the certificates the servers themselves present. Each step has its own verification, and the next one starts only when the previous one is clean.
How do you update Java without breaking applications?
Java is the runtime most often pinned to an exact build, either by a vendor that certifies one release or by an application packaged with its own JRE. That makes inventory the hard part. Look for every java binary on the host, including copies under application directories, and note which ones are managed by the operating system and which ones arrive inside a product.
For the managed copies, apply the October update and the CVE-2026-91403 fix, restart the services, and watch their logs for TLS handshake errors in the first hour, since a trust-store change shows up there first. For bundled copies, ask the vendor for a build that includes the alert fix rather than replacing the runtime underneath the product, which can void its support. Record the vendor’s answer and the date, so the exception has an owner and an end.
What to do on your servers
- Find every named.
systemctl is-active namedandnamed -von each host, and note whether it is authoritative, a resolver or both, and whether it accepts GSS-TSIG. - Upgrade BIND. Move to 9.20.30 or 9.21.27, or your distribution’s fixed package, and restart
named. Prioritize resolvers and any server that accepts GSS-TSIG dynamic updates. - Retire 9.18 and older. They will not receive the GSS-TSIG fix from ISC.
- Update every trust store. The operating system bundle (
ca-certificates), each installed JDK’scacertsand Node.js’s bundled roots are separate. Updating one does not update the others. - Inventory Java. List every JDK and JRE on the host, including copies bundled with applications, and apply both the October update and the CVE-2026-91403 alert fix.
- Update Node.js. 22.23.4, 24.22.1 or 26.12.1, including the copies used by panels, build tools and process managers.
- Restart the services. Java and Node.js processes keep their old runtime and trust store in memory until they restart.
- Check your own certificates. If any certificate you serve chains to an eMudhra intermediate, have it reissued by another CA before clients stop trusting it.
Earlier in the same month PHP shipped its emergency PHP2Shell release, covered in the PHP2Shell patch-day runbook; the kernel side of server hardening is in five kernel settings for a shared Linux server.
The short version
The week’s releases looked like three unrelated tickets and turned out to be one piece of work about trust and restarts. Handle DNS first, then the trust bundles, then the runtimes, each with its own verification, and finish by checking the certificates your own servers present. Most of the effort is inventory: knowing which servers run named, which JDKs exist where, and which processes still hold an old runtime in memory. That inventory is also what makes the next week like this one shorter.
FAQ: Node.js, BIND and Java security releases, October 2026
Which BIND servers are affected by CVE-2026-94300 in October 2026?
Servers running BIND 9.11.0 to 9.18.50, 9.20.0 to 9.20.29 or 9.21.0 to 9.21.26 that accept GSS-TSIG messages, typically for Kerberos or Active Directory dynamic updates. ISC lists no workaround, so the fix is 9.20.30, 9.21.27 or a patched vendor package.
Will BIND 9.18 receive the October 2026 GSS-TSIG fix from ISC?
No. The 9.18 branch is end of life and is not getting the GSS-TSIG fix upstream. Move to 9.20, or use a distribution that backports the fix into its own BIND package and says so in its errata.
BIND resolver vs authoritative server: which faces more risk from the October 2026 fixes?
Resolvers carry more of it. CVE-2026-19630 and the RPZ and redirect-zone crashes concern recursive servers, while CVE-2026-94300 depends on GSS-TSIG rather than role. A server that does both should be upgraded first.
Is a server exposed if the bind package is installed but named is not running?
Not to these network bugs, because nothing is listening. Check with systemctl is-active named. Keep the package updated anyway, since a later configuration change could start the service on an old build.
What happened to the eMudhra intermediate certificates in October 2026?
A researcher reported on 17 October that the private keys of eight eMudhra intermediate CAs were compromised. eMudhra said a key-generation flaw had produced weak keys. Browsers blocked the intermediates between 17 and 20 October, and Node.js and Java followed with updates.
Java October CPU vs Security Alert CVE-2026-91403: do servers need both?
Yes. The Critical Patch Update of 20 October carried 55 Java SE fixes, and the alert of 21 October addressed the eMudhra trust issue in JSSE. Reports list builds from the October update among those affected, so install the build the alert names.
Does Node.js use the operating system certificate store on a Linux server?
Not by default. Node.js trusts a CA list compiled into the binary unless it is started with --use-system-ca or given extra certificates, so updating ca-certificates alone does not change what a Node.js service trusts.
Which Node.js versions contain the October 2026 security fixes?
Node.js 22.23.4, 24.22.1 and 26.12.1, released on 21 October 2026. They fix ten CVEs, four of them high, and update the bundled c-ares, OpenSSL, Undici and CA store. Node.js 20 and older receive none of them.
Do you need to reissue a website certificate issued under an eMudhra intermediate?
Yes, if it chains to one of the affected intermediates. Clients that have already blocked them will reject the certificate, so replace it with one from another CA before more clients update and visitors start seeing errors.
After updating ca-certificates or a JDK, do running services pick up the new trust store?
No. Java and Node.js processes load their trust store at start-up and keep it until they restart, and many long-running daemons behave the same way. Restart them after the update, or the old trust decisions stay in effect.
Sources
- CVE-2026-94300 and CVE-2026-19630, ISC Knowledge Base
- CVE-2026-97313, ISC Knowledge Base
- October 2026 security releases, nodejs.org
- Oracle October 2026 Critical Patch Update, Tenable
- Google and Mozilla revoke eMudhra intermediates, CSO Online