Vulnerabilities & CVEs

A memory-corruption vulnerability in Google's Brotli decoder has a much wider reach than initially thought, extending well beyond the Node.js remote code execution issue that first brought it to attention. The flaw, tracked as CVE-2026-111497, allows specially crafted compressed data to write past the end of a buffer, corrupting the affected program's memory. Because the decoder is embedded in a broad range of software that unpacks Brotli-compressed data, the exposure is not limited to a single platform. Confirmed affected software includes: Bun Microsoft .NET The Python Brotli and brotlicffi packages Envoy proxies configured to decompress Brotli Any application or service that accepts untrusted Brotli-compressed input and relies on an unpatched decoder should be treated as potentially at risk. Administrators are advised to identify where Brotli decompression is exposed to external input and apply vendor updates as they become available. Source: The Hacker News Does your organization rely on any of the affected Brotli implementations, and how are you handling the patch?

Microsoft has pushed out emergency security updates for .NET to address a critical vulnerability that has been given the name Broccoli2Shell, and is also tracked as Node2Shell and HTTP2Shell. The flaw is rated critical and affects the Brotli decompression component within .NET. Microsoft is treating this seriously enough to release the patches outside of its normal update schedule, so administrators running affected .NET deployments should prioritize testing and deployment. At this time, the details available are limited to what Microsoft has published in its emergency advisory. The company has not disclosed the full technical specifics of the vulnerability, and no specific CVE identifier has been provided in the source reporting. That means defenders should rely on Microsoft's official guidance and patch information rather than assuming a particular CVE number. Given the critical rating and the emergency nature of the release, the practical takeaway is straightforward: Identify any systems, services, or applications that depend on .NET and the Brotli decompression path. Apply the emergency .NET updates as soon as possible. Monitor Microsoft's advisory channels for further technical details and any updates to the tracking information. Because the disclosure is still developing, expect additional details to emerge in the coming days. Source: Unknown Are any of your environments running .NET services that could be exposed to this Brotli flaw, and how are you handling the emergency patching window?

A critical vulnerability dubbed HTTP2Shell has been identified in Brotli, the C decoder library bundled with Node.js. The flaw could allow attackers to corrupt memory and gain access to sensitive data, prompting emergency patches from maintainers. Because the issue affects the decoding library that ships with Node.js, applications and services that process Brotli-compressed input may be exposed. Memory corruption issues of this kind can potentially be leveraged beyond a simple crash, making prompt patching important for anything relying on the affected library. At this stage, the available details center on the memory corruption impact and the emergency patch response. Administrators running Node.js or other software that embeds Brotli should treat this as high priority and apply vendor updates as soon as they are available. Review your Node.js and Brotli dependencies for affected versions Apply the emergency patches released by maintainers promptly Monitor vendor advisories for further technical details and updated guidance Given the severity, don't wait for a full exploit breakdown before patching. Source: Unknown Are your Node.js services already patched, or are you still assessing exposure?

Two critical vulnerabilities have been disclosed in Wasmtime, a WebAssembly runtime that can be embedded into other software. According to the project's maintainers, both flaws could allow a malicious WebAssembly module to break out of the sandbox that is meant to contain it. Exploitation requires the attacker to get a vulnerable Wasmtime build to compile a module they control — the flaws are not remotely triggerable on their own. One of the two issues impacts only ARM64 systems, so exposure depends heavily on the underlying architecture in use. Fixed versions of Wasmtime have been released, and operators running the runtime — directly or as a dependency inside another application — should upgrade to the patched release as soon as possible. Mitigation guidance: Identify any software in your environment that bundles or embeds Wasmtime. Upgrade to the fixed release published by the maintainers. Pay particular attention to ARM64 deployments, which are affected by one of the two flaws. Avoid compiling or running untrusted WebAssembly modules on unpatched builds. Source: The Hacker News Does your organization embed Wasmtime in any production software, and have you already patched it?

PHP has pushed out emergency updates addressing two critical vulnerabilities in the PHP language itself that could allow an unauthenticated attacker to execute code on a web server. The fixes are available in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, and according to the PHP team, only applying the update provides full protection for a server. The two flaws, collectively tracked as PHP2Shell, reside in the PHP runtime rather than in any application layer. This means a site can be exposed even when its own code is not at fault, since the weakness exists beneath whatever application is running on top of the interpreter. Key points for defenders: The vulnerabilities are unauthenticated, requiring no account or credentials to exploit. Because the flaws sit in the runtime, patching the application code or hardening the site will not remediate them. The affected update branches are 8.5.x, 8.4.x, 8.3.x, and 8.2.x, with fixes landing in the point releases listed above. The PHP team's guidance is clear: updating is the only complete protection. If your organization runs PHP in any capacity, treat this as urgent and verify which version your servers and containers are running before the weekend. Source: [email protected] (The Hacker News) Has your team already confirmed which PHP versions are running across your environments, or are you still mapping affected hosts?

GitLab has released fixes for a critical vulnerability that allows an attacker to execute code on a self-managed server without authentication. The flaw carries a CVSS score of 10.0 and affects every version of the software going back to 7.0, which was released in 2014 — meaning roughly twelve years of releases are impacted. The October 21 patch is significant even for administrators who updated nine days earlier. The October 12 update only covered versions 19.2 and later, and the newly fixed versions sit one patch above it, so anyone who applied that earlier release remains exposed. Key points for defenders: The vulnerability enables unauthenticated remote code execution on self-managed GitLab instances. All versions from 7.0 onward are affected. Fixes were published on October 21. The earlier October 12 update addressed only 19.2 and later and does not cover older branches. Administrators should move to the latest patched release rather than relying on the earlier update. Given the breadth of affected releases and the lack of authentication required, self-managed GitLab operators should treat this as urgent and verify their current version against the latest fixed release. Source: The Hacker News Has your organization already applied the October 21 patch, or are you still running a release from before 19.2?

Amazon's Threat Intelligence team has reported that an exploitation attempt targeting the newly disclosed PHP2Shell vulnerabilities was detected as early as October 17, 2026, against its MadPot honeypot service. This predates the public disclosure of the flaws and indicates possible prior knowledge or opportunism before patches became widely available. The attempt originated from an IP address tied to a commercial anonymization network, suggesting the actor sought to obscure their origin. Following the release of patches, the PHP2Shell flaws have now come under broad exploitation in the wild, making timely patching and monitoring especially important for exposed systems. At this time, the article does not provide specific affected version details, indicators of compromise, or mitigation guidance beyond applying the available patches and watching for exploitation activity. Administrators running PHP-based services should prioritize patching and review logs for suspicious requests. Source: The Hacker News Has your organization applied the PHP2Shell patches yet, and have you observed any exploitation attempts in your logs?

Threat actors are actively exploiting the PHP2Shell vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, with global scanning activity observed and signs that attackers are leveraging agentic artificial intelligence platforms during post-exploitation. In one notable incident, attackers targeted a government entity in Europe. Within two hours of the initial exploitation, they had successfully accessed password hashes and multi-factor authentication data, according to reporting on the campaign. The use of AI-assisted tooling in the post-exploitation phase marks a concerning shift, as it appears to accelerate the speed at which attackers move from initial access to credential theft. Key points from the reporting: Exploitation centers on the PHP2Shell vulnerabilities, CVE-2026-109618 and CVE-2026-109619 A European government entity was compromised, with password hashes and MFA-related data accessed within two hours of exploitation Global scanning for vulnerable systems is underway Threat actors have been observed using agentic AI platforms for post-exploitation activity Organizations running affected PHP-based systems should prioritize patching and review authentication logs for signs of compromise, particularly unusual access to credential stores or MFA configurations. Source: [email protected] (The Hacker News) Has your organization scanned for exposure to these PHP2Shell vulnerabilities yet, and if so, what did you find?

A researcher has disclosed that Tailscale SSH can be abused to escalate from a single compromised device to root on other reachable servers. The attack hinges on two preconditions: Tailscale SSH configured to permit port forwarding, and an attacker who already controls one device that the network's access rules allow to connect to the target. The flaws remain unpatched at the time of reporting, so the exposure is a configuration and trust-boundary issue as much as a software one. Any environment relying on Tailscale SSH for administrative access should review whether port forwarding is enabled and how broadly its access rules permit device-to-device connections. Port forwarding through Tailscale SSH is a prerequisite for the attack The attacker must already control a device that access rules permit to reach the target No patch is currently available, per the report Until a fix ships, tightening access rules and disabling unnecessary port forwarding limits the blast radius of a single compromised endpoint. Source: The Hacker News Does your organization rely on Tailscale SSH for server access, and have you reviewed your port forwarding settings in light of this?

Researchers at FoxIO have disclosed vulnerabilities in QPACK, the header compression mechanism used by HTTP/3, and released working proof-of-concept code. According to the firm, a remote attacker who has not logged in can crash many HTTP/3 web servers with a single connection. The attack works by sending a small batch of compressed HTTP headers that expands in memory to a much larger set. This forces the server to consume thousands of times more memory than the data it received — with amplification reaching up to 4,000-fold — which is enough to exhaust resources on a default server configuration and take it down. Key points: QPACK header compression in HTTP/3 is affected. No authentication is required; a single connection is sufficient to trigger the crash. The technique relies on memory amplification from compressed headers expanding far beyond their on-wire size. Working proof-of-concept code has been published by FoxIO. The disclosure did not include specific CVE identifiers in the available reporting, so affected organizations should track advisories from their HTTP/3 server vendors for patches and mitigations. Source: The Hacker News Is your organization running HTTP/3 in production, and have you applied vendor mitigations yet?

Node.js has pushed security updates for all three of its supported release lines — 22.x, 24.x, and 26.x — addressing a total of 10 flaws. The standout issue is a vulnerability in the Brotli decompression code bundled with Node.js, which the project states could enable remote code execution, potentially letting an attacker run arbitrary code on an affected system. Each supported release line has a single fixed version available, so administrators should confirm they are running the corrected build for their branch and treat the Brotli issue as the priority item when planning patching. 22.x — apply the latest fixed release for this line 24.x — apply the latest fixed release for this line 26.x — apply the latest fixed release for this line The remaining nine fixes in the same batch should be reviewed alongside the Brotli patch, as they ship together in the October 21 updates. Given that the flaw lives in decompression code, any service that processes Brotli-compressed input from untrusted sources deserves immediate attention. Source: The Hacker News Are you running any of the affected release lines in production, and have you scheduled the upgrade yet?

A vulnerability in the OpenCode AI coding agent allowed a malicious or hijacked MCP server to execute code on a developer's Windows or WSL machine at sign-in time. OpenCode connects to MCP (Model Context Protocol) servers to extend its capabilities with external tools, and any code executed through this path would run with the developer's own access privileges. Anomaly, the company behind OpenCode, addressed the issue in version 1.18.33, released in September. Key points: The flaw could be triggered when a developer signed in to OpenCode. Exploitation required a malicious or compromised MCP server. Code execution occurred on Windows and WSL systems with the developer's permissions. The fix shipped in OpenCode 1.18.33. Developers using OpenCode should upgrade to 1.18.33 or later and review the MCP servers configured in their environments. Source: The Hacker News Have you audited which MCP servers your team's OpenCode installs are connected to?

Linux servers running KSMBD, the SMB server built directly into the kernel, are currently exposed to two remote code execution flaws that Trend Micro's Zero Day Initiative has rated 9.0 on the CVSS scale. The details were disclosed on public mailing lists, and as of now no fix has landed in the mainline kernel. The two issues are tracked as ZDI-CAN-33774 and ZDI-CAN-33549. The first is the more dangerous of the pair, since it can be triggered before any network authentication takes place. The second requires the SMB Direct transport along with an RDMA-capable network to be exploited. Key points for defenders: Both flaws affect KSMBD, so any Linux server with the in-kernel SMB server enabled should be reviewed. ZDI-CAN-33774 is pre-authentication, meaning exposure does not depend on valid credentials. ZDI-CAN-33549 is narrower in scope, requiring SMB Direct and RDMA-capable networking. No mainline kernel fix is available at the time of disclosure. Given that the flaws were reported publicly before patches were merged, administrators running KSMBD should treat this as urgent: consider disabling or restricting the service where it isn't strictly needed, and monitor kernel updates closely for fixes. Source: [email protected] (The Hacker News) Is your organization running KSMBD in production, and if so, are you disabling it or waiting for kernel patches?

AI agents using the x402 SDKs to pay for API calls could be tricked into signing away their entire balance of a supported token if a malicious API requested it, according to security firm V12 on October 22. The root cause was the SDKs' default client, which applied no spending limit until releases on August 18 introduced one. Exposure was limited to agents that automatically signed payments and whose applications did not otherwise constrain what they would approve. The default client in older x402 SDK releases enforced no spending cap. A spending limit was added in releases dated August 18. Agents affected are those that sign payments automatically without app-level restrictions. Developers running x402-based agents should confirm they are on a release from August 18 or later, and should verify that their applications enforce their own limits on what payment requests an agent will sign rather than relying solely on SDK defaults. Source: The Hacker News Does your organization run x402-based agents, and have you confirmed which SDK release they are using?

A newly identified UEFI bootkit dubbed BlackX was used in an espionage campaign in early 2026, leveraging the older Baton Drop vulnerability to bypass Secure Boot. Once Secure Boot protections were circumvented, the bootkit loaded a malicious driver specifically built to interfere with security solutions from Kaspersky and Avast. The key points from the report: BlackX is a UEFI bootkit deployed in an espionage operation. It exploits the Baton Drop flaw to bypass Secure Boot. The payload includes a malicious driver designed to interfere with security products from Kaspersky and Avast. Since the bootkit targets the boot chain before the operating system loads, traditional protections can be undermined early in startup, making detection and remediation more difficult for defenders. Source: Unknown Has your organization reviewed Secure Boot and boot-chain integrity protections against bootkit threats like this?

Researchers at Imperva have demonstrated a working proof of concept that chains crafted Brotli data to remote code execution on a standard, unmodified Node.js build. Dubbed Node2Shell, the exploit ran attacker-supplied code on the official Node.js 24.22.0 image for Linux arm64, without a debugger or any custom build, by feeding malicious input to the bundled Brotli decoder. The flaw is tracked as CVE-2026-111497. Key points from the disclosure: The target was the official Node.js 24.22.0 Linux arm64 image, not a debug or custom build. The attack vector is crafted Brotli data processed by the decoder shipped with Node.js. Successful exploitation results in remote code execution under the application's context. Node.js has disclosed the vulnerability; the researchers' demonstration shows the issue is practically exploitable rather than theoretical. Because the bundled Brotli decoder is reachable wherever applications decompress untrusted Brotli content, teams running affected Node.js versions should review their exposure and apply the vendor's fix as soon as possible. Until patched builds are deployed, avoid passing untrusted Brotli data to the decoder and treat any service that does so as potentially at risk. Source: [email protected] (The Hacker News) Does your organization process untrusted Brotli data in Node.js services, and if so, how are you handling the patch?

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added two critical vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, following reports that both are being actively exploited in the wild. The affected products are Collabora Online Built-in CODE Server and Arista VeloCloud Orchestrator (VCO). The first flaw, tracked as CVE-2026-110447, carries a CVSS score of 9.2, placing it in the critical severity range. The article excerpt does not provide further technical detail on the vulnerability's root cause beyond its operating context. The second vulnerability affects Arista VeloCloud Orchestrator (VCO), though the source material does not disclose a specific identifier or CVSS score for this issue. Key points for defenders: Both vulnerabilities are rated critical and have been observed exploited in real-world attacks. CISA's KEV addition signals that federal remediation timelines now apply, and private organizations should treat the flaws as urgent. Affected products: Collabora Online Built-in CODE Server and Arista VeloCloud Orchestrator (VCO). Organizations running either product should prioritize patching and check their exposure immediately. As always, review the official KEV entry for the authoritative list of affected versions and required actions. Source: The Hacker News Does your organization run Collabora Online or Arista VeloCloud Orchestrator, and how are you handling remediation?

Ruby has shipped new releases to address memory corruption issues in Onigmo, the regular expression engine bundled with the language. The fixes arrive in Ruby 4.0.9, 3.4.12, and 3.3.13, and cover three bugs that sit at the root of four critical GitLab vulnerabilities patched over the past month. According to GitLab's investigation, a specially crafted regex pattern could corrupt memory during the compilation process in Ruby. Because that corruption occurs while the pattern is being compiled, it carries the potential for code execution on affected GitLab servers. Key points: Affected component: Onigmo regex engine in Ruby Fixed Ruby versions: 4.0.9, 3.4.12, 3.3.13 Root cause: memory corruption triggered by crafted patterns during regex compilation Downstream impact: four critical RCE flaws in GitLab, already patched No CVE identifiers were disclosed in the source report If you run Ruby in production or maintain GitLab instances, upgrading to one of the fixed Ruby releases is the sensible first step, and confirming your GitLab deployment includes the relevant patches should follow. Source: The Hacker News Has your organization already applied the Ruby updates, or are you still validating them against your GitLab environment?

Diplomatic organizations across Central Asia have been targeted by a sophisticated new UEFI bootkit tracked as BlackX, according to a technical report from Kaspersky. The campaign singled out diplomatic entities in Tajikistan, Uzbekistan, and Turkmenistan in early 2026, and the activity is suspected to be orchestrated by the China-linked state-sponsored group known as APT41. The bootkit's most notable capability is its ability to bypass Secure Boot on patched Windows systems that are missing the relevant revocations. In practice, this means fully updated machines can still be at risk if the necessary revocation updates were never applied, allowing BlackX to load before the operating system and operate beneath the visibility of typical security tooling. Key points from the report: Targeted sector: diplomatic organizations in Central Asia Targeted countries: Tajikistan, Uzbekistan, and Turkmenistan Timeframe: early 2026 Malware type: UEFI bootkit named BlackX Notable behavior: bypasses Secure Boot on patched Windows systems lacking revocations Suspected actor: APT41, a China-linked state-sponsored group Because BlackX operates at the firmware and boot level, detection and removal are considerably harder than with conventional malware. Organizations should prioritize applying all outstanding revocation updates rather than relying solely on patch level, and should treat boot integrity monitoring as part of their defensive posture. Source: [email protected] (The Hacker News) Has your organization verified that Secure Boot revocation updates are actually deployed across your Windows fleet, or is patch compliance being assumed?

HPE has released security updates addressing 72 vulnerabilities in ArubaOS, the operating system powering its Aruba networking gear. Among the fixes are eight maximum-severity flaws that could allow authentication bypass and remote code execution. The most critical issues fall into two categories: authentication bypass vulnerabilities that could let attackers sidestep login controls, and RCE flaws that could enable arbitrary code execution on affected systems. Given the maximum severity rating, these should be treated as high-priority patching targets for anyone running ArubaOS in their environment. Administrators running ArubaOS should review HPE's advisory and apply the available updates as soon as possible. As always, prioritize internet-facing and edge devices first, and check whether any of the addressed flaws impact hardware models or software branches currently deployed in your network. Source: BleepingComputer Are any of your ArubaOS devices exposed to these flaws, and have you scheduled the patch yet?