Cybersecurity Patch Alert: GitLab CVSS 10.0, Node.js Brotli RCE, Arista VeloCloud Zero-Day and More
Several serious security fixes have arrived within 48 hours, giving system administrators, developers and network engineers a busy patching schedule.
The latest disclosures include a maximum-severity GitLab vulnerability, a Node.js remote code execution flaw involving Brotli decompression, an actively exploited Arista VeloCloud Orchestrator zero-day, HTTP/3 QPACK vulnerabilities and two publicly reported Linux kernel SMB server issues.
Some of these flaws can have serious consequences if left unaddressed. Others require administrators to take defensive measures while waiting for a fix.
The most important point is that patching earlier in the month does not automatically mean a system is secure today. New vulnerabilities can affect previously patched installations, and some security updates only cover specific software branches.
Here is what administrators need to know about each issue and the steps they should take.
1. GitLab CVE-2026-110264 Receives a Maximum CVSS Score
GitLab released fixes on October 21, 2026, for CVE-2026-110264, a vulnerability rated CVSS 10.0, the maximum score on the scale.
The flaw involves an integer overflow when compiling a specially crafted regular expression. Under certain conditions, an unauthenticated user could execute code on the server.
GitLab had not publicly explained those conditions in the supplied reporting, making it important for administrators to follow the vendor’s security advisory rather than speculate about the exact exploitation requirements.
The vulnerability affects self-managed installations across versions going back to 7.0, released in 2014. GitLab.com customers were told they did not need to take action for this issue because the hosted service was managed by GitLab.
There is an additional complication for administrators who already patched earlier in October.
The October 12 update covered versions 19.2 and later, while the newly fixed versions sit one patch level above those releases. As a result, an installation patched nine days earlier could still be vulnerable.
GitLab reported no attacks at the time of the supplied reporting, and the flaw was not listed in CISA’s Known Exploited Vulnerabilities catalogue as of October 22.
What GitLab administrators should do
- Check whether the installation is self-managed or hosted on GitLab.com.
- Identify the exact version running in production.
- Apply the appropriate fixed release from GitLab’s official security guidance.
- Verify that the upgrade completed successfully.
- Review security advisories for any additional requirements specific to the installed version.
Do not assume that an earlier security update covers a newly disclosed vulnerability simply because the system was recently patched.
2. Node.js Updates Fix 10 Security Flaws
Node.js published security releases on October 21 for three supported release lines:
- Node.js 22.23.4
- Node.js 24.22.1
- Node.js 26.12.1
The updates address 10 security flaws. The most serious involves the bundled Brotli decompressor and could allow remote code execution.
According to the supplied reporting, the issue may affect applications that call the zlib module directly or use fetch() on a Brotli-compressed response.
Brotli is a compression technology used to reduce the size of data transferred over networks. Software must decompress that data correctly and safely. A vulnerability in the decompression process can create security risks when an application handles affected input.
Node.js 20 and earlier were identified as end-of-life versions that would not receive the new fix.
What Node.js developers should do
Update applications to an appropriate supported Node.js release containing the security fixes.
Check the runtime used by production services, containers, continuous integration systems and deployment environments. Updating Node.js on a developer’s workstation does not automatically update a separately deployed production application.
If a service uses an end-of-life version, plan a move to a supported release instead of waiting for a patch that will not arrive.
3. Arista VeloCloud Orchestrator Zero-Day Is Being Exploited
Arista warned on October 22 that attackers were exploiting a zero-day vulnerability in VeloCloud Orchestrator.
The flaw, CVE-2026-114625, has a CVSS score of 9.9.
According to the supplied reporting, anyone who can log in, including someone using a read-only customer account, could gain operator privileges.
This is especially concerning because the initial account does not necessarily need to have administrative permissions. A vulnerability that allows privilege escalation can turn a low-privilege account into a route towards more powerful access.
Fixes were available in the following versions:
- VCO 5.2.3.18
- VCO 6.1.3.10
- VCO 6.4.2.12
Hosted and dedicated orchestrators had already been patched, according to the reporting.
Administrators should note that builds containing fixes for earlier July and September vulnerabilities are older than the fixes for this new zero-day. A system that was updated to address those earlier flaws may therefore remain exposed.
What VeloCloud administrators should do
Check the exact VeloCloud Orchestrator version and apply the appropriate security update.
Do not rely on the presence of earlier security fixes as proof that the new zero-day has been addressed. Where the service is managed by a provider, confirm that the specific environment has been patched.
Because exploitation was already reported, prioritise this issue and follow the vendor’s security guidance.
4. QPACK Vulnerabilities Threaten HTTP/3 Servers
Network engineers should also review the QPACK vulnerabilities disclosed by FoxIO.
The reported flaws can allow a single connection from an unauthenticated attacker to crash multiple HTTP/3 servers because small compressed headers can expand dramatically in memory, by as much as 4,000 times.
The issue highlights the importance of how servers process compressed data. If a small amount of incoming data causes a disproportionately large memory allocation, an attacker may be able to exhaust available resources and interrupt service.
FoxIO found the same class of bug in seven of the 10 stacks it tested.
Fixes were available for quic-go, Cloudflare quiche, lsquic and Wireshark, while Bun, the h3 Rust library and aioquic were still unpatched at the time of disclosure.
What HTTP/3 operators should do
Identify which HTTP/3 implementations are used in production and determine whether they are affected by the disclosed flaws.
Apply available fixes and monitor vendor advisories for components that had not yet been patched.
Where a fix is unavailable, follow the relevant project’s mitigation guidance and consider restricting exposure to vulnerable services until a suitable update can be deployed.
5. Linux KSMBD Faces Two Publicly Reported RCE Vulnerabilities
Linux servers exposing the kernel SMB server, known as KSMBD, also face two publicly reported remote code execution vulnerabilities rated CVSS 9.0.
One of the reported vulnerabilities requires no authentication on port 445.
SMB is commonly associated with file and resource sharing. A remotely exploitable flaw in a server handling SMB connections can create a serious risk when the service is accessible to untrusted networks.
The supplied reporting said no mainline fix was available at the time.
What Linux administrators should do
Until a suitable kernel patch becomes available, restrict access to port 445 so that only necessary, trusted systems can reach it.
Review firewall rules, network segmentation and whether the KSMBD service needs to be exposed at all. Avoid making SMB services publicly accessible unless there is a clear and properly secured requirement.
Monitor the relevant Linux kernel and distribution security advisories for fixes, and apply the appropriate update when it becomes available.
Cybersecurity Patching Checklist for This Week
Administrators managing several of these products should prioritise work according to active exploitation, potential impact and exposure.
- Arista VeloCloud Orchestrator: Prioritise the reported zero-day because exploitation was already underway.
- GitLab self-managed installations: Confirm the installed version and apply the newly available fix, even if the system was patched earlier in October.
- Node.js applications: Update supported runtimes and plan migration away from end-of-life releases.
- HTTP/3 services: Identify affected QPACK implementations, install available fixes and monitor unpatched projects.
- Linux KSMBD: Restrict port 445 exposure while awaiting a suitable fix, especially where unauthenticated access is possible.
This ordering is a practical starting point, not a substitute for assessing your own environment. An exposed service or a vulnerable component supporting a critical business application may require immediate attention.
Why Regular Patch Management Matters
These disclosures show why cybersecurity teams need to track the exact versions of software running across their environments.
A recent patch may not address a newly disclosed vulnerability. A hosted service may be updated by its provider, while a self-managed installation requires action from its own administrator. An end-of-life runtime may no longer receive fixes at all.
A strong vulnerability management process should therefore include asset inventory, version tracking, security advisory monitoring, risk-based prioritisation and verification after deployment.
