Enterprise Managed IT Solutions logo Enterprise Managed IT SolutionsBusiness IT support across the GTHA. 905-602-9899

ADVISORIES

Security issues that need timely attention.

Plain-language alerts on active threats, affected systems and the practical steps businesses should take next.

CURRENT ALERTS

Act on the risk, not the noise.

Review these notices with your IT provider, confirm whether your systems are exposed and follow the vendor's current guidance before making changes.

SECURITY ALERT · NOV 12, 2026

N-able N-central zero-days hit MSPs — disable the Legacy API now

N-able N-central — the remote monitoring and management platform MSPs use to run client systems — has two new zero-days with public exploits, published November 12. 4EverAble2Shell gives an unauthenticated attacker root on an on-premises server where the Legacy API is turned on — and it works even on Hotfix 2 (2026.4.1.26), released November 10. Researchers report at least 21 production servers compromised and mining cryptocurrency. There is no patch for the new chain yet: make sure the Legacy API is disabled. Hosted N-central is not affected.

Read advisory

N-central is the remote monitoring and management (RMM) platform managed service providers use to monitor and manage client computers and networks. On November 12, researcher Sean Bales published two new exploit chains, 4EverAble2Shell and Agent2Shell, and says he tested both against N-central Appliance 2026.4.1.26 Hotfix 2 — the emergency update N-able released November 10 for the earlier Able2Shell disclosure of more than 30 flaws. 4EverAble2Shell chains an Apache Axis flaw (CVE-2026-90436, rated 9.8) with a separate N-central privilege escalation that has no CVE yet (tracked by Previdian as VULN-2026-0009) to run commands as root on the server. Agent2Shell is claimed to give SYSTEM privileges on Windows machines through the N-central agent.

Exploitation is already being reported, with one honest conflict in the sources. Previdian saw probing against its N-central honeypot from about 08:30 UTC on November 12, within hours of the public exploit release, followed by attempts to run the full chain. Huntback reports at least 21 production N-central servers compromised with XMRig cryptocurrency miners — 19 of them on Hotfix 2 — confirmed through the attackers' mining-pool data at 12:50 UTC. N-able's own November 12 advisory said it had seen no signs of compromise using the new flaws; the independent researcher evidence (probing, confirmed miners, pool data) is the stronger signal, so treat the 21 as reported by researchers, not vendor-confirmed.

Affected and fixed

On-premises N-central 2026.4, including 2026.4.1.26 (Hotfix 2), with the Legacy API enabled and exposed to the internet. The Legacy API is off by default and N-able does not recommend it — only servers where someone turned it on are in scope for this chain. Hosted N-central is not affected, and N-able says it has already applied protections there. There is no fix for the new chain yet: N-able is restricting some N-central features and integrations while it develops further fixes, and has disabled the Intune integration as a precaution.

What to do

  1. Confirm the Legacy API is disabled on every on-premises N-central server. If an integration you rely on needs it, that integration has to wait — this chain only works with it on.
  2. Hunt for the miner, don't just check the setting. Look for suspicious requests to /dms/services/ServerUI (especially referencing jline.internal.TerminalLineSettings), unexpected XMRig processes, an xvd.service systemd service, or files under /tmp/.xvd or /var/tmp/.xvd.
  3. Treat any hit as a full compromise of the server — the chain gives root, and a compromised RMM server can reach every managed client.
  4. Keep Agents and Probes updated under the Hotfix 2 guidance and watch for N-able's follow-up fix for the new chain.
SECURITY ALERT · NOV 11, 2026

Chrome flaw exploited in the wild — update and relaunch to close it

Google's November 9, 2026 Chrome update fixes CVE-2026-125350 (High, 8.8), a use-after-free flaw in Chrome's XML handling that Google says has an exploit in the wild: a crafted web page can run code inside Chrome's renderer sandbox. CISA added it to its exploited list November 10, 2026 (federal due date November 24). Fix: Chrome Stable 157.0.8103.50/.51 (Windows/Mac), 157.0.8103.50 (Linux/Android), or Extended Stable 156.0.8078.96 — then relaunch the browser.

Read advisory

Google released the Chrome Stable update on November 9, 2026, fixing nine security flaws — but only one is confirmed exploited, and it is in the browser itself. CVE-2026-125350 is a use-after-free vulnerability in Chrome's XML component (the libxslt code Chrome uses for XSLT transformations): visiting a crafted web page can run code inside Chrome's renderer sandbox. Google's release note states plainly that it is aware an exploit for CVE-2026-125350 exists in the wild. The flaw was reported by an anonymous researcher on November 6, and patched three days later. It is the eighth Chrome zero-day exploited in the wild in 2026. Google has not said who is exploiting it, who was targeted, or whether attackers pair it with a second flaw to escape the sandbox — a sandbox escape has not been confirmed.

Affected and fixed

Google Chrome Stable below 157.0.8103.50 (Windows, Mac, Linux, Android); Chrome Extended Stable below 156.0.8078.96 (Windows, Mac). Fixed: Stable 157.0.8103.50/.51 (Windows/Mac), 157.0.8103.50 (Linux/Android); Extended Stable 156.0.8078.96. Early Stable Chrome 158 needs 158.0.8127.30 or later. Other Chromium-based browsers (Microsoft Edge, Brave, Opera, Vivaldi) share the engine — apply each vendor's own update when it lands; no ChromeOS Stable release carrying the fix had appeared as of November 10.

What to do

  1. Update Chrome to 157.0.8103.50 or later (Extended Stable: 156.0.8078.96) — Help > About Google Chrome — then relaunch. The update does nothing until the browser restarts.
  2. Check other Chromium browsers on the same machines (Edge, Brave, Opera) for their updates.
  3. For managed fleets, push the update and consider a forced-relaunch policy — a downloaded-but-not-relaunched browser is still vulnerable.
SECURITY ALERT · NOV 11, 2026

Outlook flaw exploited in the wild — opening a crafted message can leak your Windows login hash

Microsoft's November 10, 2026 Patch Tuesday fixes CVE-2026-124194 (6.5, Moderate), an Outlook spoofing flaw Microsoft marks as exploited: opening a crafted message file makes Outlook connect to an attacker-controlled server without its usual external-content warning, disclosing the user's NTLMv2 hash. CISA added it to its exploited list November 10, 2026 (federal due date November 24). Fix is the November 10 Office update: Office LTSC 2021 16.0.14334.21048, Office LTSC 2024 16.0.17932.21140, Microsoft 365 Apps November 10 security update for the deployed channel.

Read advisory

Microsoft's November 2026 security release, published November 10, fixes 1,259 flaws — but only one is confirmed exploited, and it is in Outlook. CVE-2026-124194 is a user-interface flaw (Outlook fails to warn before an unsafe action): an unauthenticated attacker sends a specially crafted message file and persuades the target to open it. Outlook then connects to a network location the attacker controls without displaying the usual external-content warning, disclosing authentication information such as an NTLMv2 hash that can be used to impersonate the user. The Preview Pane is not an attack vector — the message file must be opened. Microsoft has not attributed the exploitation to any threat actor or published technical details of how it is being exploited in the wild. A public proof-of-concept repository appeared on GitHub on November 11, described by its author as untested.

The same November Office update also fixes three Critical Outlook remote-code-execution flaws (CVE-2026-110043, CVE-2026-110068 and CVE-2026-111309, each scored 8.8), among 20 Outlook vulnerabilities in the release. The Outlook fix ships only in the Office update — the Windows cumulative update does not fix it.

Affected and fixed

Microsoft 365 Apps for Enterprise, Office LTSC 2021 and Office LTSC 2024 (32-bit and 64-bit). Fixed: Office LTSC 2021 build 16.0.14334.21048; Office LTSC 2024 build 16.0.17932.21140; Microsoft 365 Apps — install the November 10, 2026 security update for the deployed update channel. Office 2019 is not on Microsoft's affected-product list for this flaw.

What to do

  1. Deploy the November 10 Office update first — before the rest of Patch Tuesday. Check LTSC builds (2021: 16.0.14334.21048; 2024: 16.0.17932.21140) and confirm Microsoft 365 Apps is on its November 10 build for its channel.
  2. Warn users not to open message files (.msg) from unexpected senders, even if they look like ordinary email — the Preview Pane is safe, opening the file is the trigger.
  3. Treat any exposed hash as a credential compromise: force a password reset for affected users and review sign-ins, since a captured NTLMv2 hash can be used to authenticate as the user elsewhere.
SECURITY ALERT · NOV 10, 2026

Fortinet publishes details of October hardening release — eight critical flaws, worst is unauthenticated code execution

Fortinet published the advisories for its October 22 hardening release on Nov 10, 2026: eight critical flaws (9.0–9.8) across FortiOS, FortiManager, FortiAnalyzer and FortiSASE. Worst is CVE-2026-126170 (9.8), unauthenticated code execution on FortiManager/Analyzer via the JSON API. Six of the eight need no login. Fixes are the Oct 22 builds (FortiOS 7.2.14 / 7.4.13 / 7.6.8 / 8.0.2; FortiManager/Analyzer 7.2.13 / 7.4.12 / 7.6.8 / 8.0.2) with two exceptions: on the 8.0 branch CVE-2026-126170 needs the still-upcoming 8.0.3 — disable the JSON API (set rpc-permit none) until then; the HA flaw's 7.6.8 fix is also listed as upcoming — apply Fortinet's virtual patch meanwhile. Fortinet reports no exploitation yet; none of the eight is in CISA's exploited list, but several carry proof-of-concept or functional exploit code in Fortinet's scoring.

Read advisory

Fortinet published the advisories for its October 22 hardening release on November 10, 2026 — eight critical flaws (9.0–9.8) across FortiOS, FortiManager, FortiAnalyzer and FortiSASE. The patches shipped October 22; the details were withheld until now, which means attackers now have public descriptions of exactly what was fixed. The worst, CVE-2026-126170 (9.8, FG-IR-26-219), is a JSON injection flaw in the JSON-RPC API shared by FortiManager and FortiAnalyzer: when the JSON API is enabled (it is disabled by default), a crafted request lets an unauthenticated attacker run code or commands on the systems that manage whole fleets of FortiGates.

The other management flaws: CVE-2026-126262 (9.3, FG-IR-26-276), unauthenticated SQL injection through OFTP (TCP 514) on FortiAnalyzer and FortiManager with FortiAnalyzer features enabled; CVE-2026-126260 (9.0, FG-IR-26-274), a pre-authentication server-side request forgery in the same OFTP service; and CVE-2026-126261 (9.0, FG-IR-26-275), an authorization weakness in the FortiManager FGFM service (TCP 541) that triggers before the registration password is checked. On FortiOS and FortiSASE: CVE-2026-126254 (9.6), a numeric truncation flaw in the BGP daemon that needs traffic from a configured iBGP neighbour; CVE-2026-126253 (9.3, FG-IR-26-267), an OSPF authentication bypass letting an unauthenticated attacker broadcast forged Link State Advertisements; CVE-2026-126229 (9.1, FG-IR-26-244), an authenticated administrator reaching virtual domains beyond their permissions; and CVE-2026-126259 (9.0), a high-availability flaw letting an unauthenticated attacker run commands as super admin — but only where FGSP with standalone-config-sync, or autoscale, is configured.

Fortinet reports no known exploitation of any of the eight at publication, and none is in CISA's exploited-vulnerabilities catalog. But several carry proof-of-concept or functional exploit code in Fortinet's scoring, and the details are now public — so this is a patch-now batch, not a watch-and-wait one.

Affected and fixed

FortiOS 7.2.0–7.2.13, 7.4.0–7.4.12, 7.6.0–7.6.7 and 8.0.0–8.0.1. Fixed: 7.2.14 / 7.4.13 / 7.6.8 / 8.0.2. FortiManager and FortiAnalyzer 7.2, 7.4, 7.6 and 8.0 branches. Fixed: 7.2.13 / 7.4.12 / 7.6.8 / 8.0.2. Two exceptions: CVE-2026-126170 on the 8.0 branch needs the still-upcoming 8.0.3 (7.4 and 7.2 are not affected by that flaw) — disable the JSON API until then; and the HA flaw's 7.6.8 fix is also listed as upcoming — apply Fortinet's virtual patch FG-VD-61445.0day meanwhile. Fixed builds vary by flaw, so match each CVE to its own advisory rather than assuming one build covers all eight.

What to do

  1. Confirm your FortiOS, FortiManager and FortiAnalyzer builds — the October 22 builds or newer (FortiOS 7.2.14 / 7.4.13 / 7.6.8 / 8.0.2; FortiManager/Analyzer 7.2.13 / 7.4.12 / 7.6.8 / 8.0.2).
  2. On the 8.0 branch, disable the JSON API until 8.0.3 ships (config system admin profile, set rpc-permit none); for the HA flaw, apply Fortinet's virtual patch FG-VD-61445.0day meanwhile.
  3. Keep OFTP (TCP 514) and FGFM (TCP 541) off the internet — restricting the browser login page does not protect these services.
  4. Check logs for unexpected administrator or API activity — updating does not remove a foothold.
SECURITY ALERT · NOV 10, 2026

GPUStack flaw gives attackers admin on AI servers — update to 2.2.0

A critical improper-authentication flaw (CVE-2026-102895, 9.8) in GPUStack, the open-source GPU cluster manager for AI model serving, lets a remote attacker gain unauthenticated administrator access. All versions before 2.2.0 are affected; the fix is 2.2.0. Exploitation has been observed in the wild against a 2.1.1 deployment, and CISA added the flaw to its exploited list on Nov 9, 2026.

Read advisory

GPUStack manages GPU clusters and serves AI models. Before 2.2.0, its get_current_user function treated any request appearing to come from the loopback address as the built-in administrator when force_auth_localhost was false, which was the default — so a remote attacker could spoof the request source and walk in as admin. The vendor advisory says the flaw was observed exploited in the wild against a 2.1.1 deployment, where attackers created custom inference backends that opened reverse shells on worker hosts. An attacker with admin access can change users and models, create persistent administrator API keys, disclose worker and cloud-provider secrets, and run code through POST /v2/inference-backends/from-yaml.

Affected and fixed

GPUStack before 2.2.0. Fixed: 2.2.0 (2.2.2 also fixes a sibling SAML flaw, CVE-2026-102894).

What to do

  1. Update GPUStack to 2.2.0 or later.
  2. Check logs for administrator API keys, users, models or inference backends you don't recognize — updating does not remove a foothold.
  3. Until patched, do not expose the GPUStack management interface to the internet.
SECURITY ALERT · NOV 10, 2026

FreeSWITCH flaw lets one SIP message run commands — update to 1.11.3

A critical code-injection flaw (CVE-2026-116779, 9.8) in SignalWire FreeSWITCH lets a crafted inbound SIP MESSAGE run FreeSWITCH API commands, including operating-system commands. All releases before 1.11.3 are affected; the fix is 1.11.3. SignalWire says exploitation has been observed in the wild, and CISA added the flaw to its exploited list on Nov 9, 2026.

Read advisory

FreeSWITCH is an open-source telephony platform used in call centres, hosted PBX services, carrier SIP gateways and conferencing products. Its SIP handling splits the To user of an inbound SIP MESSAGE on '+' and allows a message addressed to sip:api+system ... to invoke the internal API directly. That means a single unauthenticated message can run system commands on the server, as well as disclose configuration and credentials and take arbitrary call control. The flaw affects SIP profiles that accept inbound MESSAGE, which is the default setting. The fix shipped quietly in FreeSWITCH 1.11.3 on Aug 28, 2026; SignalWire published its advisory on Oct 28 saying exploitation had been observed.

Affected and fixed

FreeSWITCH before 1.11.3 (whole 1.10 branch and 1.11.0–1.11.2). Fixed: 1.11.3.

What to do

  1. Update FreeSWITCH to 1.11.3 or later and restart.
  2. Until patched, set enable-chat=false on every SIP profile that does not need inbound SIP chat. Message authentication alone does not close this path.
  3. Check logs for unexpected API or system commands and for SIP MESSAGE traffic from unfamiliar sources — updating does not remove a foothold.
SECURITY ALERT · NOV 10, 2026

IBM Aspera Faspex flaw hands users full admin — update to 5.0.19 PL1

A critical authorization-bypass flaw (CVE-2026-123218, 9.8) in IBM Aspera Faspex 5 lets a user craft a specific message to bypass authorization checks and gain full administrative privileges. Faspex 5.0.0 through 5.0.19 are affected; the fix is 5.0.19 PL1. IBM lists no workaround, and CISA added the flaw to its exploited list on Nov 9, 2026, two days after IBM's bulletin.

Read advisory

Aspera Faspex is IBM's high-speed managed file-exchange platform. Its bulletin, published Nov 7, 2026, says an authorized user can craft a specific message — about 80 characters long — to bypass user authorization and gain full administrative privileges on the Faspex server. IBM rates the flaw CVSS 9.8. One honest wrinkle: IBM's prose describes an authenticated user, while its CVSS vector records no privileges required — the guidance here follows IBM's prose, and either way the fix is the same. There is no workaround: IBM's bulletin lists none, so upgrading is the only remediation. For container deployments, IBM asks operators to validate that the faspex-core container image is 5.0.19 (build 1ce4b13, Fix Pack 1).

Affected and fixed

IBM Aspera Faspex 5.0.0–5.0.19. Fixed: 5.0.19 PL1.

What to do

  1. Upgrade Faspex to 5.0.19 PL1 and confirm the faspex-core container image reads 5.0.19 (1ce4b13, Fix Pack 1).
  2. Audit administrator accounts and recent admin actions for changes you don't recognize — updating does not remove a foothold.
  3. Review who holds Faspex user accounts, especially external and guest accounts, since the flaw needs a user account to start from.
SECURITY ALERT · NOV 9, 2026

WatchGuard AuthPoint Gateway flaws let attackers disrupt logins — update to 7.6.0

Four flaws in WatchGuard AuthPoint Gateway, three rated critical (9.1–9.2), let an attacker disrupt authentication, delete the directory-sync configuration, replay requests for unauthorized admin actions, intercept directory logins, and forge login results. All versions before 7.6.0 are affected; the fix is AuthPoint Gateway 7.6.0. WatchGuard reports no known exploitation in the wild.

Read advisory

AuthPoint Gateway is the on-premises piece that connects WatchGuard's AuthPoint multi-factor authentication to a company's own directory — Active Directory, LDAP, RADIUS or ADFS. WatchGuard published all four flaws on November 4, 2026. The worst, CVE-2026-121639 (9.2), needs no login: an attacker with network access to the gateway can disrupt authentication services and delete the local directory synchronization configuration on gateways using LDAP or Active Directory. CVE-2026-121640 (9.1) lets an attacker who has observed a legitimate request between gateway components replay it and perform unauthorized administrative actions. CVE-2026-121638 (9.1) is a certificate-validation flaw letting an on-path attacker intercept and modify traffic between the gateway and RADIUS, LDAP or ADFS providers. CVE-2026-121637 (8.9) lets a network attacker with a valid header signature forge authentication results and transaction identifiers in LDAP callback requests.

Affected and fixed

AuthPoint Authentication Gateway 1.0 and later, before 7.6.0. Fixed: 7.6.0.

What to do

  1. Update AuthPoint Gateway to 7.6.0 and confirm the installed version afterward.
  2. Until then, restrict network access to the gateway host to trusted networks only.
  3. Check AuthPoint logs for unexpected authentication disruptions, directory-sync deletions, or admin actions you don't recognize — updating does not remove a foothold.
SECURITY ALERT · NOV 8, 2026

Fortinet FortiSIEM flaw: unauthenticated code execution, public exploit out — update to 7.5.1

A critical path-traversal flaw in Fortinet FortiSIEM (CVE-2026-106173, 9.4) lets an unauthenticated attacker write files anywhere on the appliance and turn that into code execution, through the phQueryMaster gRPC service on TCP port 27918. Fortinet fixed it in FortiSIEM 7.5.1. A public proof of concept has been out since October 20, and Canada's Cyber Centre says open-source reporting indicates it is being exploited in the wild — Fortinet itself says it is not aware of exploitation, and it is not in CISA's exploited list.

Read advisory

Fortinet published advisory FG-IR-26-180 on October 13, 2026. The flaw is an improper pathname restriction (CWE-22) in the phQueryMaster gRPC service, which accepts connections on TCP port 27918 without requiring a client certificate. An unauthenticated attacker can steer a file write outside the intended folder and reach code execution. Horizon3.ai published a technical deep-dive and a working proof of concept on October 20.

Affected and fixed

Fortinet's advisory lists FortiSIEM 7.5.0 as affected, fixed in 7.5.1 or later; FortiSIEM 7.6 and FortiSIEM Cloud are not affected. The CVE record also lists 7.0.0 through 7.4.2 and recommends moving to 7.6.0 or above — until Fortinet explains the difference, treat those branches as exposed and move to 7.6.0+.

What to do

  1. Upgrade FortiSIEM 7.5.0 to 7.5.1 or later (older branches: move to 7.6.0 or later) and verify the build after upgrading.
  2. Until then, restrict access to TCP port 27918 to internal FortiSIEM nodes only — that blocks the attack path without removing the flaw.
  3. Hunt if you were on 7.5.0 with port 27918 reachable: compare file timestamps on scheduled scripts and look for unexpected files, since the attack writes files to the appliance.
SECURITY ALERT · NOV 7, 2026

Barracuda email gateway flaw lets attackers in with no login — update ESG to 9.4.0.030

Two Barracuda Email Security Gateway flaws chain into remote code execution as root with no login: CVE-2026-116606 (9.3) is an authorization bypass in the admin interface, and CVE-2026-111560 (8.6) is a command injection in the timezone setting. Barracuda patched both on November 2, and researchers at watchTowr demonstrated the full chain on November 5. The fix is ESG firmware 9.4.0.030 or later. Update, Nov 10: Barracuda now says attackers have exploited this chain against a small number of organisations, and CISA added both flaws to its exploited-vulnerabilities catalog on Nov 10 (federal agencies have until Nov 13 to patch). The chain needs only network reach to the admin interface, so an exposed admin page is the whole ballgame.

Read advisory

Barracuda's Email Security Gateway (ESG) is the email-filtering appliance that sits at the edge of an office network. Two flaws in it, disclosed November 2, 2026, chain together: CVE-2026-116606 (CVSS 4.0 9.3) is an authorization bypass — a failed password change returns a role object instead of stopping the request, leaving a backup-restore function open to someone who has not logged in. An attacker restores a crafted backup whose timezone value the appliance later runs as a shell command with root privileges — that is CVE-2026-111560 (CVSS 4.0 8.6), an OS command injection in the timezone setting. Barracuda guards backups with a checksum, but the secret used to compute it is built into the code, so the checksum can be forged. watchTowr Labs demonstrated the full chain and showed a file written to the appliance as root.

The chain needs network access to the appliance's administrative web interface — no credentials. That is the precondition that decides the risk: an admin page reachable only from trusted networks is far less exposed than one facing the internet. The command-injection flaw on its own also exists in five other Barracuda products, but there it still needs an administrator account, so only the ESG is pre-auth. Update, Nov 10: Barracuda says it has identified exploitation affecting a small number of organisations, and CISA added both flaws to its Known Exploited Vulnerabilities catalog on Nov 10, with a Nov 13 deadline for federal agencies (forensic triage required). watchTowr has published a detection tool but no exploit. This gateway was hit before — in 2023 attackers exploited a different ESG flaw (CVE-2023-2868) as a zero-day — which is why a confirmed-exploited pre-auth root chain on the same box deserves a fast patch.

Affected and fixed

Email Security Gateway before 9.4.0.030. Fixed: 9.4.0.030 or later (patches BNSF-40425 for 9.4.017 and later, BNSF-40430 for older builds). The command-injection flaw also affects five other Barracuda products — check Barracuda's advisory for their fixed builds.

What to do

  1. Update the ESG to 9.4.0.030 or later and confirm the installed version afterward.
  2. Restrict the admin interface to trusted networks. If the admin page is reachable from the internet, that is the exposure — limit it now, even before patching.
  3. Turn automatic patching back on if it was switched off — Barracuda's own advice.
  4. Check for compromise: review admin-interface logs for backup restores or password-change attempts from unfamiliar addresses, and look for unexpected files, users, or configuration changes — updating does not remove a foothold.
SECURITY ALERT · NOV 6, 2026

SonicWall SSLVPN flaw lets attackers skip SAML and MFA — update SonicOS now

SonicWall published advisory SNWLID-2026-0014 on November 6 for CVE-2026-19868: an attacker with valid credentials for another login method can bypass SAML authentication on the SonicOS SSLVPN service — including SAML-enforced multi-factor authentication. It only affects SSLVPN where SAML is enabled for logins. CISA added it to its exploited-vulnerabilities catalog the same day, after SonicWall investigated a report of exploitation in the wild. The fix is SonicOS 7.3.4-7013 or newer on Gen7 firewalls, and 8.2.3-8015 or newer on Gen8. If you can't upgrade yet, SonicWall's workaround — added Nov 9 — is to disable or delete any active LDAP, RADIUS and TACACS+ authentication servers on the firewall.

Read advisory

SonicWall SonicOS firewalls (Gen7 and Gen8) run an SSLVPN service that many offices use for remote access. When SAML is enabled for SSLVPN logins, that SAML step — and any multi-factor authentication enforced through it — is supposed to be mandatory. CVE-2026-19868 (CWE-308, use of single-factor authentication) breaks that: a user holding valid credentials for an alternate authentication method on the same firewall can skip the SAML step entirely and log in to SSLVPN without it.

SonicWall's advisory, SNWLID-2026-0014, published November 6, 2026, says its PSIRT investigated a report indicating potential exploitation and urges customers to upgrade immediately. CISA added the flaw to its Known Exploited Vulnerabilities catalog the same day, with a November 20 federal remediation deadline (federal agencies only), and lists exploitation as active. Canada's Centre for Cyber Security (alert AV26-1133, November 6) repeats that the flaw is being exploited. No threat actor, victim, or scale has been published, and ransomware use is listed as unknown.

Affected and fixed

Gen7 firewalls (TZ, NSa, NSsp, NSv) on SonicOS 7.3.3-7015 and earlier. Fixed: 7.3.4-7013 or newer. Gen8 firewalls (TZ, NSa, NSv) on SonicOS 8.2.2-8015 and earlier. Fixed: 8.2.3-8015 or newer. Only SSLVPN with SAML enabled for logins is affected — firewalls without SAML on SSLVPN are not in scope for this flaw. SonicWall's advisory (revised Nov 9) gives a workaround if upgrading isn't possible yet: disable or delete any active LDAP, RADIUS and TACACS+ authentication servers on the firewall (Device → Users → Settings → Authentication).

Same update, more flaws

SNWLID-2026-0014 fixes six other SonicOS flaws in the same builds, including two management-interface flaws rated 8.8 (CVE-2026-107154 and CVE-2026-107155) and a pre-authentication SSL-VPN denial-of-service flaw rated 7.5 (CVE-2026-82308). None of those is confirmed exploited — but the same upgrade closes them, so there is no reason to wait for a separate patch.

What to do

  1. Upgrade SonicOS to the fixed build for your generation — 7.3.4-7013+ (Gen7) or 8.2.3-8015+ (Gen8) — and confirm the installed version afterward.
  2. Check whether SAML is enabled for SSLVPN logins. If it is, review SSLVPN sign-in logs for logins that used an alternate authentication method where SAML was expected.
  3. Treat any such login as a possible compromise and review what that account reached — the bypass defeats MFA, so a valid credential alone was enough to get in.
  4. If you can't upgrade yet and SAML is in use, apply SonicWall's workaround — disable or delete any active LDAP, RADIUS and TACACS+ authentication servers on the firewall — and keep a working admin path so you don't lock yourself out.
SECURITY ALERT · NOV 6, 2026

Patched Zyxel GS1900 switches still open to attack — install the Patch 3 firmware now

Zyxel published a November 3 advisory for CVE-2026-107441 (rated 8.8 by Zyxel; researchers rate it 9.8): an out-of-bounds write in the GS1900 web-management CGI lets a network-adjacent attacker with no login run operating-system commands. The June Patch 2 firmware fixed a different flaw (CVE-2026-7273) — researchers proved the exploit still works on every Patch 2 build. Ten GS1900 models are affected; the fix is the model-specific 2.90 Patch 3 build. Open-source reporting indicates exploitation in the wild (Canadian Cyber Centre, November 4); Zyxel's own advisory does not confirm it. One campaign compromised 996 switches, and 564 of them still had factory-default credentials.

Read advisory

Zyxel's GS1900 switches are small-business network switches, and this flaw sits in the CGI program behind their web-management interface. CVE-2026-107441 is an out-of-bounds write: a crafted HTTP request from anywhere on the local network can write beyond the intended memory and run commands on the switch's operating system — no login, no user interaction. The June fix (Patch 2, for CVE-2026-7273) addressed a different bug in the same program: a missing counter check. This one is a missing size check, and the exploit recovered in the wild relies on it, so Patch 2 never stopped it.

Affected and fixed

Ten GS1900 models, on firmware 2.90 Patch 2 or earlier. Fixed: the model-specific 2.90 Patch 3 build — a firmware file for another model is not interchangeable.

  • GS1900-8: 2.90(AAHH.3)C0
  • GS1900-8HP: 2.90(AAHI.3)C0
  • GS1900-10HP: 2.90(AAZI.3)C0
  • GS1900-16: 2.90(AAHJ.3)C0
  • GS1900-24: 2.90(AAHL.3)C0
  • GS1900-24E: 2.90(AAHK.3)C0
  • GS1900-24EP: 2.90(ABTO.3)C0
  • GS1900-24HPv2: 2.90(ABTP.3)C0
  • GS1900-48: 2.90(AAHN.3)C0
  • GS1900-48HPv2: 2.90(ABTQ.3)C0

Products not listed in Zyxel's table are described as unaffected. Zyxel's advisory lists no workaround.

What to do

  1. Install the Patch 3 firmware for your exact model from Zyxel, and note the exact firmware number before and after — don't trust a vague "up to date" flag. A .2 build is not sufficient for this flaw.
  2. Hunt for compromise, don't just patch. Updating does not remove access an attacker may already have. Check for unfamiliar configuration changes and review logs; GreyNoise found 564 of the 996 compromised switches still had factory-default credentials — change those now if they were never changed.
  3. Keep the management interface off untrusted networks and restrict it to trusted hosts until every switch is patched.
SECURITY ALERT · NOV 6, 2026

OpenSSH password bypass on Alpine Linux and other musl systems — update to 10.6p2

OpenSSH released 10.6p2 on November 5 with a critical workaround for a password-authentication bypass in sshd on Linux systems using musl libc with PAM disabled (CVE-2026-123158, rated 8.1). A password longer than 256 bytes can match the placeholder stored for key-only accounts, logging an attacker in without the key. Affects Alpine Linux (patched packages shipped the same day) and other musl-based systems such as OpenWrt, Buildroot, and Yocto. Debian, Ubuntu, and RHEL (glibc) and any sshd using PAM are not affected. Exploitation is now confirmed on a honeypot: Previdian reported the first attempt less than nine hours after disclosure and confirmed root access on an Alpine honeypot. No production compromises have been reported. CISA added CVE-2026-123158 to its Known Exploited Vulnerabilities catalog on November 9, 2026, with a November 12 federal deadline (federal agencies only).

Read advisory

OpenSSH 10.6p2, released November 5, 2026, contains what OpenSSH calls a critical security workaround for a password-authentication bypass in sshd (CVE-2026-123158, CVSS 8.1). It affects Linux systems built with the musl C library and with PAM support disabled — most notably Alpine Linux, plus OpenWrt, Buildroot, and Yocto devices. The root cause sits in musl's password handling, but it is exploitable through sshd, and the OpenSSH fix blocks it there.

The mechanism, in plain terms: musl's crypt function returns "*" for passwords longer than 256 bytes, and "*" is also the placeholder stored for accounts that have no password at all — key-only accounts. So a login attempt with a 257-to-1,024-byte password against a key-only account matches, and sshd lets the attacker in without the key.

Affected and not affected

Affected: Alpine Linux 3.16–3.24 and edge (patched packages shipped November 5), and other musl-based systems running sshd without PAM. Not affected: glibc-based Linux (Debian, Ubuntu, RHEL and their derivatives) and any sshd built with PAM support, regardless of distribution.

The fix

Update to OpenSSH 10.6p2, or install your vendor's patched package (Alpine's shipped November 5). Interim mitigation if you cannot update yet: set PasswordAuthentication no in sshd_config, or disable SSH access entirely until patched.

What to do

  1. Update sshd to 10.6p2 or the vendor patched package on every affected system, and confirm the installed version afterward.
  2. Audit key-only accounts on affected systems — those are the accounts this bypass targets.
  3. Review authentication logs for unusual login attempts, including very long password submissions.
  4. Don't expose sshd unnecessarily. If SSH must face the network, restrict it to trusted hosts and require key authentication plus PAM where possible.
  5. Check logs for 'Accepted password for' entries involving accounts that should not accept password logins (Alpine's own advice: look in /var/log/messages, review doas use and recently created users, files and authorized keys). If you cannot rule out a login, treat the machine as compromised.
SECURITY ALERT · NOV 6, 2026

A 10/10 flaw in Siemens IoT2050 gateways is now being exploited — update Industrial OS now

A maximum-severity flaw (CVE-2026-58115, rated 10.0) in the Node-RED interface on Siemens SIMATIC IoT2050 Advanced industrial gateways lets an attacker with no login create malicious flows and run code with full privileges. Siemens patched it in August (Industrial OS V4.3.4.1) — but on October 30, attackers started exploiting unpatched devices, dropping Linux bots and persistent webshells. Not in CISA's exploited-vulnerabilities catalog yet. The same danger applies to any standalone Node-RED running without a login.

Read advisory

CVE-2026-58115 is a missing-authentication flaw (CWE-306) in the Node-RED HTTP interface bundled with Siemens SIMATIC IoT2050 Advanced gateways (model 6ES7647-0BA00-1YA2) running Industrial OS. The editor and admin API ship without authentication, and Node-RED's programming nodes can run shell commands — so reaching the HTTP interface is equivalent to code execution with full privileges. Siemens disclosed it in advisory SSA-834709 on August 11, 2026; CISA republished it as ICSA-26-237-03 on August 25.

Exploitation began October 30, 2026: VulnCheck's honeypot network caught an attacker wiring an inject node to an exec node that downloaded and ran a Linux bot binary, with staged downloaders and persistent flow-based webshells also observed. Sixteen attempts from the same source address were logged by November 1. The activity is opportunistic mass scanning of internet-reachable interfaces — and it is not limited to Siemens: any standalone Node-RED installation running without adminAuth is equally exposed.

Affected and fixed

SIMATIC IoT2050 Advanced devices running Industrial OS with Node-RED installed, on all versions before V4.3.4.1. Fixed: Industrial OS V4.3.4.1 or later.

What to do

  1. Update to Industrial OS V4.3.4.1 or later. That is the only complete fix.
  2. If Node-RED is not needed, uninstall it. If it is needed, enable adminAuth, enable HTTPS, and protect HTTP nodes and the dashboard.
  3. Take the Node-RED editor off the internet. Restrict it to trusted networks or a VPN.
  4. Audit flows for anything unfamiliar — unexpected exec nodes and HTTP-in endpoints — and check /dev/shm and /tmp for suspicious files.
SECURITY ALERT · NOV 6, 2026

Plex2Shell: four flaws chain into unauthenticated code execution — update Plex Media Server now

Four flaws in Plex Media Server — nicknamed Plex2Shell — chain together into unauthenticated remote code execution: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656. None is critical on its own (rated 5.3 to 8.6), but together they let an attacker with no login run code as the Plex process. CISA added all four to its exploited-vulnerabilities catalog on October 20, after attacks began the day after exploit code went public. The fix has existed since August: Plex Media Server 1.43.3.10861 or later.

Read advisory

Plex2Shell is a chain of four Plex Media Server flaws, reported to Plex by researcher Zach Main on July 27, 2026, with a public write-up and proof-of-concept published October 16. Each flaw on its own is moderate: CVE-2026-96652 (5.3) is a server-side request forgery in the player timeline endpoint — any X-Plex-Token value is accepted without checking it is real; CVE-2026-96654 (6.9) exposes internal agent functions over the loopback interface; CVE-2026-96655 (5.3) discloses the server owner's admin token; and CVE-2026-96656 (8.6) allows arbitrary file writes to the Codecs directory. Chained in sequence, they give an unauthenticated attacker code execution as the Plex process.

Attacks began October 17, one day after the proof-of-concept was published, first hitting honeypots to install a cryptominer, with proxy software also reported on compromised machines. CISA added all four to its Known Exploited Vulnerabilities catalog on October 20, with federal deadlines of October 23 and November 3. Plex's own guidance is blunt: if your server is older than the fixed build and reachable from the internet, assume it may be compromised.

Affected and fixed

All Plex Media Server versions before 1.43.3.10861. Fixed: 1.43.3.10861 or later (a newer build, 1.43.5.11029, became generally available October 20). Check the full build number — an earlier 1.43.3 build, 1.43.3.10828, is still vulnerable. Plex Desktop 1.115.0 is the patched desktop release. Home servers often don't auto-update, so check yours.

What to do

  1. Update Plex Media Server to 1.43.3.10861 or later today, especially if the server faces the internet — and confirm the installed version in Settings afterward.
  2. If the server was below the fixed build and internet-facing, hunt for compromise: unfamiliar libraries, unknown processes, miners, or proxy software — updating does not remove a foothold.
  3. Don't expose the server unnecessarily. Review port forwarding and relay settings; a media server does not need to be reachable by the whole internet.
SECURITY ALERT · NOV 6, 2026

Attackers are abusing a signed Siemens program to run malware — update Software Center to 4.0.9.8

Attackers in the Romulus ClickFix campaign are abusing a genuine, validly signed copy of Siemens Software Center to run their own code — no breach of Siemens was needed. The flaw (CVE-2026-110936, rated 8.4) is a DLL side-loading bug: the program loads helper files from its own folder without checking they are Siemens files. Siemens confirmed active exploitation on October 19, and CISA added it to its exploited-vulnerabilities catalog on October 20. Fixed in Software Center 4.0.9.8 — but updating alone does not stop this campaign's method, so the check matters as much as the patch.

Read advisory

Siemens Software Center is the Windows application Siemens customers use to download, install, activate, and update purchased Siemens software. CVE-2026-110936 is an uncontrolled search path flaw (CWE-427): the application loads helper DLLs from its own folder without verifying they are Siemens files. Attackers place a crafted DLL — named archive.dll in the observed campaign — beside a genuine, signed copy of the program, and their code runs inside a trusted application. The Siemens program itself is untouched, so checks based on file fingerprints miss it. Siemens disclosed the flaw in advisory SSA-580366 on October 15 (fix added October 17), reported by Jose Oregon of Huntress Labs, and confirmed active exploitation on October 19 in the Romulus multi-platform ClickFix campaign. CISA added it to its Known Exploited Vulnerabilities catalog on October 20, with a November 3 federal deadline.

Affected and fixed

All Siemens Software Center versions before 4.0.9.8. The version the attackers abused was 3.5.8.7. Fixed: 4.0.9.8 or later. Installed copies update automatically — but only when the application is next started, so a host that downloaded the fix and never reopened the program may still be running vulnerable code.

Why the patch alone isn't enough

The 4.0.9.8 fix protects installed copies, but it does not stop the campaign's method: an older, still validly signed 3.5.8.7 binary delivered alongside a malicious DLL still works. That is why the hunt below is part of the fix, not an optional extra.

What to do

  1. Update every copy of Siemens Software Center to 4.0.9.8 or later — and actually open the application on each machine so the automatic update applies.
  2. Hunt using Siemens' published indicators — detect on folders and behavior, not file hashes: look for unexpected DLLs beside the Siemens binary and review the network indicators Siemens published.
  3. Block execution from user-writable paths and use version-aware allow-listing for the Siemens binary on engineering workstations.
SECURITY ALERT · NOV 6, 2026

The update button itself was the attack: WordPress core flaw exploited during upgrades — confirm 7.1.4

A flaw in WordPress core (CVE-2026-119977) lets an unauthenticated attacker run code on a site during the few seconds a core update unpacks — the update itself is the attack window. WordPress fixed it on October 28 in 7.1.4, with backports to every branch back to 4.7, and CISA added it to its exploited-vulnerabilities catalog on November 3 after confirmed exploitation. Wordfence logged more than 18,500 attack requests in the first 21 hours after disclosure. The scoring is split honestly: Wordfence rates it 8.1 High; WordPress's own advisory rates it Low.

Read advisory

During a full-package WordPress core upgrade, the new files are unpacked into a predictable, web-accessible folder under wp-content/upgrade/ — including the installer file setup-config.php, which can run without your site's settings. An unauthenticated attacker who hits the few-second window while the update unpacks can restart the installation, point the site at their own database, and run code on the server. The flaw is a time-of-check time-of-use race (CWE-367), reported by Umut Bayram of Picus Security. New research from Xint (November 4) traces the flaw back to WordPress 2.7 and warns the old updater can expose the same window even while installing the 7.1.4 fix itself.

CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on November 3, with a November 6 federal deadline (federal agencies only). Wordfence deployed a blocking rule about three hours after the October 28 release and saw its first match nine minutes later — more than 18,500 requests targeting the staged installer paths in the first 21 hours, and over 12,600 attempts per day still being blocked as of November 4. No confirmed successful compromise has been publicly reported, and no public proof-of-concept exists as of November 4 — but attackers are polling sites in a loop, waiting for an update to start.

Affected and fixed

WordPress 4.7.0 through 7.1.3. Fixed: 7.1.4, plus branch backports (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18, down to 4.7.39). WordPress 4.6 and older receive no fix. WordPress 7.1.4 randomizes the staging directory, adds an index guard, and prevents unsafe promotion of staged configuration data.

What to do

  1. Confirm the version in Dashboard > Updates — 7.1.4, or your branch's patched release. The best option is still to move to 7.1.4.
  2. Close the door, then update. Before running any core update, have your host block web access to the wp-content/upgrade folder — since the attack targets the update itself, that order matters.
  3. Check logs from October 28 forward for probing of the upgrade folder. A site that only updated after October 28 deserves a closer look.
SECURITY ALERT · OCT 30, 2026

WatchGuard Firebox batch: seven critical flaws, several with pre-login code execution — update Fireware now

WatchGuard disclosed a batch of Fireware OS security advisories on October 27, headlined by seven critical flaws rated 9.1 to 9.5 — including pre-login code execution in the SIP proxy and the Active Directory authentication service, and a 9.5 WireGuard configuration flaw. Fixed releases are Fireware OS 2026.4, 12.12.4, and 12.5.22 for T15/T35 models. WatchGuard reports no known exploitation of any of them — but several are pre-authentication, so this is a patch-now batch, not a watch-and-wait one.

Read advisory

WatchGuard published the batch on October 27, 2026. Seven flaws are rated critical (CVSS v4.0 9.1–9.5); the same release also fixes high- and medium-severity issues, plus a Mobile VPN with SSL client flaw (CVE-2026-115495, fixed in client 2026.4). Read the preconditions carefully: not every flaw hits every Firebox — several need a specific feature enabled or a specific attacker position, which is exactly why the list below names the trigger for each one.

The seven critical flaws

  • CVE-2026-103594 (9.5) — WireGuard configuration, stack buffer overflow. A remote attacker with man-in-the-middle, TLS-decrypted access between the Firebox and WatchGuard Cloud can tamper with a FireCloud Gateway configuration payload, causing denial of service or potentially executing code. Only Fireboxes configured as a FireCloud Gateway are affected. Fixed in 2026.4 / 12.12.4 (the 12.5 branch is not listed as affected).
  • CVE-2026-112709 and CVE-2026-112710 (9.2 each) — Active Directory authentication service, heap buffer overflows. Triggered by a crafted response from, or interception of traffic to, the configured Active Directory server — pre-authentication remote code execution. Fixed in 2026.4 / 12.12.4 / 12.5.22 (T15/T35).
  • CVE-2026-93857 (9.2) — SIP proxy, stack buffer overflow. A remote, unauthenticated attacker can execute code by sending a crafted request through a policy that uses the SIP proxy. Requires a SIP proxy configured on the Firebox. Fixed in 2026.4 / 12.12.4 / 12.5.22 (T15/T35).
  • CVE-2026-93865 (9.2) — FireCluster sync daemon, missing authentication. A remote, unauthenticated attacker can invoke privileged system-level administrative actions against the FireCluster management IP when clustering is enabled. Fixed in 2026.4 / 12.12.4 / 12.5.22 (T15/T35).
  • CVE-2026-93866 (9.2) — Access Portal, integer overflow. A remote, unauthenticated attacker can trigger a heap out-of-bounds write through the Access Portal's WebSocket handling while the Access Portal is enabled. Fixed in 2026.4 / 12.12.4 / 12.5.22 (T15/T35).
  • CVE-2026-103593 (9.1) — Logging service, stack buffer overflow. A network-adjacent attacker who can impersonate or intercept traffic to the configured log server and present a crafted certificate can execute code as root. Fixed in 2026.4 / 12.12.4 / 12.5.22 (T15/T35).

Affected and fixed

Most of the batch affects Fireware OS 2025.1 up to 2026.4, and 12.0 up to 12.12.4 (12.0 up to 12.5.22 on the 12.5.x branch for T15/T35). The WireGuard flaw is narrower: 2026.2 up to 2026.4, and 12.12 up to 12.12.4. Fixed releases: 2026.4, 12.12.4, and 12.5.22 for T15/T35 models. Match each appliance to its own branch — there is no single version that fits every Firebox. Also update the Mobile VPN with SSL client for Windows to 2026.4.

What to do

  1. Back up each Firebox configuration, then upgrade to its branch's fixed build and verify the build after upgrading.
  2. Turn off what you do not use. Disable the SIP proxy and the Access Portal where they are not needed — both remove a pre-authentication attack path outright.
  3. Keep management interfaces off the internet and limit them to trusted hosts, and keep FireCluster links on their own isolated connection.
  4. WatchGuard reports no known exploitation of any of these flaws, and none is in CISA's exploited-vulnerabilities catalog — but pre-authentication code execution on the firewall itself is the kind of flaw that does not stay unexploited for long.
SECURITY ALERT · OCT 25, 2026

WatchGuard Firebox flaw: a malicious VPN server could take root on a connecting Firebox

A critical code-injection flaw in Fireware OS (CVE-2026-86131, rated 9.2/10) lets an attacker who controls the VPN server a Firebox connects to as a BOVPN-over-TLS client run commands as root on that Firebox. Read the scope carefully: this is not every Firebox, and it is not a direct attack on an internet-facing firewall — the Firebox must connect to an attacker-controlled server. No exploitation has been observed.

Read advisory

WatchGuard disclosed CVE-2026-86131 on September 29: a code-injection flaw (CWE-94) in how Fireware OS handles BOVPN-over-TLS client configurations. BOVPN over TLS is the feature that lets Fireboxes build site-to-site VPN tunnels over TCP port 443. If the Firebox connects as a client to a VPN server under an attacker's control, the attacker can inject commands that run as root on the connecting appliance — full control of the firewall itself, not just a user account behind it. No user interaction and no login to the firewall are required on the attacker's side; the precondition is control of the server.

Affected and fixed

Fireware OS 2026.3 to before 2026.3.2; 2025.0 to before 2026.2.3; 12.0 to before 12.12.3; on T15/T35 devices, 12.0 to before 12.5.21. Fixed releases: 2026.3.2, 2026.2.3, 12.12.3, and 12.5.21 for T15/T35. Match each appliance to its own branch — there is no single version that fits every Firebox. The same September 29 release also fixes 13 high-severity and 1 medium-severity flaws, so the upgrade covers more than this one bug.

What to do

  1. Check whether any Firebox connects as a BOVPN-over-TLS client — especially tunnels to third-party or partner networks. Fireboxes that do not use BOVPN over TLS in client mode are not exposed to this flaw.
  2. Upgrade exposed appliances to their branch's fixed build and verify the build after upgrading.
  3. Treat VPN servers as trusted infrastructure. A tunnel to a server you do not control deserves the same scrutiny as any other privileged connection.
SECURITY ALERT · OCT 25, 2026

Two critical PHP flaws let attackers run code with no login — update your web servers now

The PHP project disclosed two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619, each rated 9.2/10) that let an attacker run code on a web server without any login or account. The PHP team has a demonstrated exploit for the common Apache mod_php setup, where a single unauthenticated web request triggers the attack before your website's own code even runs. Update October 27: CISA added both flaws to its Known Exploited Vulnerabilities catalog on October 26 after confirmed exploitation — patch first, then hunt for compromise, not just the patch.

Read advisory

If your business runs a website on PHP — and most WordPress sites do — the emergency PHP release of October 21 deserves your attention today. The first flaw corrupts PHP's memory handling so a request can hijack the server process; the second lets stale data from one request poison the next one handled by the same worker.

Affected and fixed

Every PHP installation serving web requests — PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed — on any version older than the fixed releases. Fixed: PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. If your server gets PHP from a Linux distribution or LTS vendor, install their patched package — they received the fixes in advance. There are no complete workarounds; the PHP team is explicit that updating is the only safe choice.

What to do

  1. Check your PHP version. Run php -v on each web server, or check your host's control panel. Anything older than the four fixed releases needs attention.
  2. Update to the fixed release for your version line, restart the web workers, and confirm the running version afterward.
  3. Mind the old versions. PHP 8.1 and earlier no longer receive security updates from the PHP project — those servers need a vendor backport or an upgrade. PHP 8.2 reaches end of life December 31, 2026, so plan that move now.
  4. Start with what's internet-facing. Public websites first; internal-only apps can follow in the same window.

One related note from October 23: PHP published an informational advisory for a separate session-upload flaw (CVE-2026-115560) with narrow exposure only — the mitigation is session.upload_progress.enabled=0, the same setting already recommended for CVE-2026-109619, so servers that applied it are already covered.

SECURITY ALERT · OCT 25, 2026

The backdoor didn't break in — it used a stolen key: the UpdraftCentral breach, explained

This one isn't a vulnerability in a plugin. Over the weekend of October 17–18, attackers breached teamupdraft.com — the company behind UpdraftPlus, the backup plugin on more than 4 million WordPress sites — and accessed its customer database, including the connection keys for UpdraftCentral, the dashboard used to manage many WordPress sites at once. Since October 18–19, those stolen keys have been used to issue commands to connected sites and install backdoor plugins: 99 distinct backdoor plugin names have been counted. No password was guessed and no code flaw was needed — the sites trusted the keys, so the commands looked legitimate.

Read advisory

Who is exposed: sites running UpdraftPlus that were connected to UpdraftCentral with a key from before the evening of October 18. TeamUpdraft's own estimate is that under 10% of its 4M+ installs hold such a key — roughly 400,000 sites in the potential blast radius. That is an exposure estimate, not a victim count; how many sites were actually backdoored isn't public. The UpdraftPlus plugin itself was not compromised, and backups in customers' own storage were not accessed.

What to do — all of it, not just the first step

  1. Update UpdraftPlus to 1.26.13 (free) or 2.26.13 (Premium). These builds revoke UpdraftCentral connections made before the breach window. Don't stop at 1.26.12 — its key revocation was buggy.
  2. Delete the UpdraftCentral connection key by hand on every site — in the site's own dashboard: Settings > UpdraftPlus Backups > Advanced Tools > UpdraftCentral. TeamUpdraft is explicit that this manual step is required.
  3. Check every connected site for unknown plugins and administrator accounts. Updating revokes keys; it does not remove a backdoor that has already been planted. If you find one, clean it out and restore from a backup taken before October 17.
  4. Change your teamupdraft.com password and reset its 2FA. If a site was accessed through UpdraftCentral, also re-authorise its remote storage and change the storage access keys.

The bigger lesson: remote-management keys are skeleton keys. Any tool that can run commands on your sites — backup dashboards, management consoles, agency tooling — deserves the same suspicion as an admin password, because in an attacker's hands it is one.

SECURITY ALERT · OCT 17, 2026

The "medium" Fortinet flaw that put a rootkit in firewall memory

Fortinet rates CVE-2025-61624 a medium 6.0 — but CISA added it to the exploited-vulnerabilities catalog on October 16 after attackers chained it into a full firewall takeover, deploying a memory-only implant that leaves no file on disk. And some older FortiGate branches have no fix at all: migration is the only option.

Read advisory

Fortinet disclosed in April (advisory FG-IR-26-122) a path-traversal flaw in the command-line interpreter of FortiOS, FortiPAM, FortiProxy, and FortiSwitchManager (CVE-2025-61624, CVSS 6.0 Medium). An attacker holding an administrator profile with read-write permissions could write or delete arbitrary files on the device through crafted arguments to existing commands. On October 16, CISA added it to its Known Exploited Vulnerabilities catalog with an October 19 federal remediation deadline — because attackers are not just theorizing about this one.

How it was used

Palo Alto Networks' Unit 42 reports the flaw was chained into a full firewall takeover at a telecom managed service provider. The intrusion (tracked as CL-STA-0954 / UNC5820) began with the FortiManager FortiJump flaw (CVE-2024-47575), which exposed configurations, credentials, and trust material for more than 500 managed FortiGates. From there the attackers used this CLI flaw — abusing FortiOS's system.auto-script feature to escape the restricted admin shell — to reach root and deploy PEERSTITCH, a memory-resident ARM64 implant that hooks the miglogd and iked daemons to bypass security checks on tagged VPN sessions. PEERSTITCH leaves no file on disk, opens no ports, and makes no outbound connections of its own; the attackers also cleared crash logs and deleted their rogue admin accounts and auto-scripts afterward. A separate SSH reverse-shell channel via Apache mod_md was observed in the same campaign.

The fix

Per Fortinet's own advisory: FortiOS 7.6.5+ or 7.4.10+ (7.6.0–7.6.4 and 7.4.0–7.4.9 affected); FortiPAM 1.7.1+ (1.8 not affected); FortiProxy 7.4.12+ or 7.6.5+; FortiSwitchManager 7.2.8+ or 7.0.7+. Older branches — FortiOS 7.2 / 7.0 / 6.4, FortiPAM 1.0–1.6, FortiProxy 7.2 / 7.0 — have no fixed build on their branch: the only remediation is migrating to a fixed release. A virtual patch (FG-VD-59270.0day, in FMWP db update 25.120) is available as interim cover.

What to do

  1. Confirm exact firmware versions on every FortiGate, FortiPAM, FortiProxy, and FortiSwitchManager you run, and map each to the branch table above.
  2. Upgrade — or plan the migration. Devices on branches with no fixed build (FortiOS 7.2 / 7.0 / 6.4 and the others listed) need a migration plan, not a patch window.
  3. Audit administrator profiles and system.auto-script entries for anything unknown, and rotate admin credentials and API keys.
  4. Restrict management interfaces to dedicated management networks, remove unused admin profiles, and enforce phishing-resistant MFA.
  5. Hunt by configuration and logs, not file scans. The implant is memory-resident — file scans will not find it.
SECURITY ALERT · OCT 15, 2026

Cisco email gateway zero-day under active attack — root access from a single email

A flaw in Cisco's Secure Email Gateway (CVE-2026-76519, rated 9.8/10) lets an attacker with no login write arbitrary files and run commands as root — the entire attack is one email with a crafted attachment. Cisco confirms active exploitation, and CISA has added the flaw to its Known Exploited Vulnerabilities catalog.

Read advisory

Cisco disclosed an actively exploited zero-day in its Secure Email Gateway on October 14 (CVE-2026-76519, rated 9.8/10): a relative path traversal in the Advanced Malware Protection feature lets an attacker with no login and no user interaction write arbitrary files and run commands as root on the appliance — the entire attack is one email with a crafted attachment. Cisco's PSIRT confirms it is aware of active exploitation this month, and CISA has added the flaw to its Known Exploited Vulnerabilities catalog.

Who is exposed

Only gateways meeting both conditions are vulnerable: the File Reputation service is enabled and assigned to a mail policy, and Content Scanner Tools is older than 25.3.0.5525. Check exposure with the contentscannerstatus CLI command and the "Enable File Reputation" checkbox under Mail Policies > Incoming/Outgoing Mail Policies > Advanced Malware Protection. Cisco confirms Secure Email and Web Manager is not vulnerable. There are no workarounds.

The fix

Update Content Scanner Tools to 25.3.0.5525 or later (no restart needed), or move to fixed AsyncOS builds — SEG 15.5.5-014 or 16.5.0-780 (older 16.x releases: migrate to 16.5.0-780).

What to do

  1. Check both exposure conditions on every Secure Email Gateway you run.
  2. Hunt for compromise before patching. Cisco published indicators of compromise and warns attackers erase evidence after getting root — cross-check firewall and network logs for suspicious transfers.
  3. Apply the fix — Content Scanner Tools 25.3.0.5525+ or a fixed AsyncOS build.
  4. If a virtual appliance shows signs of compromise, rebuild it with fresh credentials rather than just upgrading, which destroys forensic data.

Cisco has already applied mitigations to its cloud email service and contacted affected cloud customers directly. Context worth knowing: this is the second SEG zero-day in about a month — CVE-2026-76461, patched in mid-September, was the same flavor of malicious-email-to-root attack, and January's CVE-2025-20393 (10.0) was also exploited in the wild. Attackers are hunting email gateways right now; if you run one, assume it is being probed.

SECURITY ALERT · OCT 15, 2026

Palo Alto firewall zero-day under active attack — root on your firewall, patch now

Palo Alto Networks disclosed a PAN-OS zero-day (CVE-2026-0322, rated 8.6/10) on October 14 and confirmed attackers are already exploiting it in the wild. It takes login credentials for the web management interface — but root on the firewall itself is about as bad as it gets.

Read advisory

On October 14, Palo Alto Networks disclosed a zero-day flaw in PAN-OS, the software running its firewalls (CVE-2026-0322, rated 8.6/10) — and confirmed attackers are already exploiting it in the wild. CISA added it to its Known Exploited Vulnerabilities catalog the same day, giving federal agencies until October 17 to fix it.

The flaw is a code-injection vulnerability (CWE-94) in the firewall's web management interface. An attacker who already has login credentials and network access to the interface can execute arbitrary commands as root on the firewall. No special configuration is needed for a device to be vulnerable, and Palo Alto assigned its highest provider-urgency rating. Honest framing: this is not a no-login attack — it requires credentials. But the risk is highest wherever the management interface is reachable from the internet, and because the target is the firewall itself, root compromise there is about as bad as it gets.

Affected

PA-Series and VM-Series firewalls, plus Panorama (virtual and M-Series) appliances. Cloud NGFW and Prisma Access are not affected.

Fixed releases

Per Palo Alto's advisory: PAN-OS 12.2.4+; 12.1 — 12.1.4-h12 / 12.1.7-h8 / 12.1.10-h2; 11.2 — 11.2.4-h22 / 11.2.7-h21 / 11.2.10-h15 / 11.2.13-h3 / 11.2.16; 11.1 — 11.1.4-h37 / 11.1.6-h39 / 11.1.7-h11 / 11.1.10-h35 / 11.1.13-h15 / 11.1.16-h3; 10.2 — 10.2.7-h38 / 10.2.10-h41 / 10.2.13-h26 / 10.2.16-h11 / 10.2.18-h12. Older unsupported releases must move to a supported fixed version. There are no known workarounds.

What to do

  1. Upgrade to a fixed release. There is no workaround — patching is the fix. (Limited Threat Prevention coverage exists via Threat IDs 510046/510047, but Palo Alto says to upgrade rather than rely on it.)
  2. Restrict the management interface to trusted internal IPs — a single jump box sharply reduces exposure.
  3. Check your logs for any contact with the three IP addresses Palo Alto links to the observed exploit attempts: 66.42.72.14, 208.83.239.114, 149.248.47.234.

Note: this is a different flaw from the GlobalProtect VPN issue (CVE-2026-0257) — different bug, different fix.

SECURITY ALERT · OCT 15, 2026

Exploited Windows zero-day bypasses your download warnings — install October updates now

Microsoft's October 13 Patch Tuesday fixed an actively exploited Windows zero-day (CVE-2026-96951, rated 8.8/10) that bypasses Mark of the Web — the protection that flags files downloaded from the internet and warns you before they run. Exploitation began before the fix existed.

Read advisory

Microsoft's October 13 Patch Tuesday fixed an actively exploited Windows zero-day — CVE-2026-96951 (CVSS 8.8/10) — a command-injection flaw in Windows Shell that lets an attacker bypass Mark of the Web (MOTW), the protection that flags files downloaded from the internet and warns before they run. Microsoft confirms exploitation began before the fix existed, and CISA added the flaw to its Known Exploited Vulnerabilities catalog the same day, with a federal-agency deadline of October 16.

A MOTW bypass is a prized capability for attackers: it neutralizes one of the most effective built-in user protections, so malicious files can open without the warnings that usually prompt a second thought. The attack still requires user action — a crafted file or link the victim is tricked into opening — so this isn't silent drive-by compromise; it's the layer of warnings disappearing on machines behind on updates.

What to do

  1. Install the October 2026 Windows cumulative update and restart. There is no separate patch — the fix is this month's cumulative update.
  2. Treat this month's updates as priority, not routine — exploitation is confirmed in the wild.
  3. Remind staff to be suspicious of unexpected files and links — on an unpatched machine, the usual download warnings may not appear.
SECURITY ALERT · OCT 10, 2026

Seven governments name a state-backed hacking campaign — the weapon is your unpatched old software

On October 8, seven governments — including Canada — jointly warned that Chinese state-linked hackers known as Flax Typhoon are actively breaking into organizations worldwide. In the same move, the FBI seized seven internet domains used to run the attackers' tools, and CISA added five exploited flaws to its Known Exploited Vulnerabilities catalog with an October 11 remediation deadline for federal agencies.

Read advisory

On October 8, seven governments — including Canada — jointly warned that Chinese state-linked hackers known as Flax Typhoon are actively breaking into organizations worldwide. In the same move, the FBI seized seven internet domains used to run the attackers' tools, and CISA added five exploited flaws to its Known Exploited Vulnerabilities catalog with an October 11 remediation deadline for federal agencies.

Here's the twist: none of the five flaws are new. They date from 2015 to 2023 — a 10.0-rated ProFTPD flaw (CVE-2015-3306), a 9.8 ONLYOFFICE Docs flaw (CVE-2021-3199), an Apache Struts command-injection flaw (CVE-2016-3081), a BIND denial-of-service flaw (CVE-2015-5477), and a Strapi information-disclosure flaw (CVE-2023-22894).

The campaign's power comes from automation: botnets scanning the internet for systems that were never patched, password spraying against Microsoft Exchange servers, VPN software planted for persistent access, and stolen emails and credentials exfiltrated to attacker servers. Three more flaws in the same campaign were already on CISA's exploited list — Shellshock, an old Pulse Secure VPN flaw, and an old GitLab flaw.

What to do

  1. Hunt for forgotten systems — the risk isn't your maintained servers, it's the FTP server someone set up years ago, the self-hosted document tool, the legacy web app nobody owns. Inventory anything running ProFTPD, self-hosted ONLYOFFICE Docs, Apache Struts, BIND, or Strapi, and bring it current or take it offline.
  2. Check the indicators — the joint advisory includes attacker IP addresses, domains, and malware signatures; review your logs for matches, especially on internet-facing systems.
  3. Turn on multi-factor authentication everywhere, starting with email — password spraying against Exchange is part of this campaign's standard playbook; MFA is the cheapest effective defense.
  4. Treat the October 11 date as a signal, not an obligation — it applies to US federal agencies, but CISA only sets deadlines that short when exploitation is active and ongoing.
SECURITY ALERT · OCT 9, 2026

Fourth NetScaler patch in a week: 9.5-rated SAML flaw can mean remote code execution

Citrix has released patches for a critical vulnerability in NetScaler ADC and NetScaler Gateway. The memory-overflow flaw could let an attacker run code on the appliance or knock it offline where SAML authentication is configured.

Read advisory

Citrix has released patches for a critical vulnerability (CVE-2026-107406, rated 9.5/10) in NetScaler ADC and NetScaler Gateway. A memory-overflow flaw could let an attacker run code on the appliance or knock it offline — but only where the appliance is configured for SAML authentication, as an identity provider or a service provider.

The facts

CVE-2026-107406 was patched on October 8–9. It affects NetScaler ADC and NetScaler Gateway configured as a SAML IdP (identity provider) or SAML SP (service provider) — the authentication setup common in remote-access and single-sign-on deployments.

Affected ranges include 14.1-73.37 through 14.1-73.41 and 13.1-64.23 through 13.1-64.28 (IdP configurations), with broader ranges for SAML configurations generally. Fixed releases: 14.1-73.46+, 13.1-64.29+ (and matching FIPS builds).

Citrix reports no known exploitation of this flaw so far — so this is patch-before-it-burns, not an active incident.

Context

This is the fourth NetScaler bulletin in a week. The three earlier flaws (CVE-2026-88771, CVE-2026-88772, CVE-2026-88779) are all under active attack, and Secure Private Access Hybrid deployments using NetScaler are affected by this one too.

What to do

  1. Check your SAML configuration. Review your NetScaler configuration for SAML IdP or SP entries; the exposure depends on that, not just the version number.
  2. Patch to the fixed builds. Upgrade affected appliances to 14.1-73.46+ or 13.1-64.29+, verifying the build against Citrix's current bulletin.
  3. Don't assume last week's patch covered this. If you patched for the earlier SAML zero-day, you need this update too.
SECURITY ALERT · OCT 9, 2026 · UPDATED OCT 18

9.8-rated MikroTik router flaw needs one request, no login — patch and hide your management interface

A critical RouterOS flaw lets an unauthenticated attacker run code as root on a MikroTik router with a single crafted HTTP request to its web management interface. No login and no user interaction are required.

Read advisory

Small-business networks love MikroTik routers — affordable, capable, everywhere. That popularity is also why a critical new flaw in RouterOS deserves attention: CVE-2026-84411, rated 9.8/10, lets an unauthenticated attacker run code as root on the router with a single crafted HTTP request to its web management interface. No login, no user interaction.

The facts

CVE-2026-84411, rated 9.8/10 (Critical), was disclosed September 29 in CISA advisory ICSA-26-272-06. The bug is an integer underflow in the web management service's HTTP handling — it triggers before any authentication check, so the request that crashes it never needs a username.

RouterOS before 7.24 is affected — including RouterOS v6 — on any device where the web management interface is reachable. Per MikroTik's own bulletin for this flaw, the fix ships in 7.24 or later on the v7 stable line; the v7 long-term and v6 long-term fixes are still pending, so those branches have no in-line fix yet.

No confirmed exploitation yet — CISA reports no known public exploitation and no confirmed public proof-of-concept. This is a patch-before-it-burns advisory, not an active incident. Researchers note the fixed release saw very slow adoption in its first week — a large vulnerable footprint still sits exposed.

Added context

CERT Polska reports attackers have been actively exploiting other MikroTik flaws ('MikroTrick') since early September, so these routers are squarely on attackers' radar right now.

What to do

  1. Update RouterOS. The only fixed line right now is v7 stable: 7.24 or later. On the v7 long-term branch or any 6.x there is no fixed release on your branch yet — plan a move to the v7 stable line (a major upgrade from 6.x; plan configuration migration), or keep the web interface unreachable from untrusted networks until MikroTik ships the long-term fixes.
  2. Check for compromise markers. Review the log and audit users, scripts, and scheduled tasks for anything unfamiliar — regardless of patch status.
  3. Hide the web management interface. Do not expose router management to the internet; restrict it to trusted networks or a VPN. This applies regardless of patch status.
  4. Inventory your routers. Branch offices, home offices, and third-party-installed gear are easy to miss.
SECURITY ALERT · OCT 9, 2026 · UPDATED OCT 12

Backup servers under attack: critical AhsayCBS flaw actively exploited — emergency hotfix now available

AhsayCBS, a backup server product used by IT service providers, carries a critical flaw that lets an unauthenticated attacker run operating-system commands on the server — with full SYSTEM privileges. Since October 7, threat actors have been exploiting it in the wild, and the vendor's 10.3.4 patch did not fully fix it. An emergency hotfix (v10.3.4.45) is now available.

Read advisory

AhsayCBS, a backup server product used by IT service providers, carries a critical flaw that lets an unauthenticated attacker run operating-system commands on the server — with full SYSTEM privileges. Since October 7, threat actors have been exploiting it in the wild, and the vendor's 10.3.4 patch did not fully fix it — an emergency hotfix (v10.3.4.45) is now available to Ahsay partners running v10.

The facts

CVE-2026-105134 (rated 10.0/10 under CVSS 3.1) allows unauthenticated command injection through the Replication Receiver component. Attackers chain it with CVE-2026-105133, a medium-severity authentication bypass (7.3/10 under CVSS 3.1) in the API's password-check function — no login required either way. The flaws were disclosed October 3–4, and public exploit code is circulating.

Update (October 12): a fix is now available — but 10.3.4.0 doesn't count. Ahsay confirmed on October 10 that v10.3.4.0 did not fully address either flaw and issued an emergency hotfix, v10.3.4.45, for affected v10 partners (downloaded from Ahsay's partner portal; reboot required after installing). Verify the build after installing.

Huntress has observed real-world exploitation against at least five organizations since October 7: attackers drop JSP web shells, deploy XMRig cryptocurrency miners disguised as Microsoft Edge processes, and install persistence — including a Windows service (MicrosoftEdgeUpdateSvc) and the WinRing0x64 kernel driver used to boost mining. Managed service providers are the primary targets.

What to do

  1. Check for compromise first — a hotfix won't remove a foothold. Review for JSP web shells in the application directory, unexpected Windows services, Edge-named processes launched under cbssvcX64.exe, and unusual PowerShell or certutil activity.
  2. If compromised, rebuild. A hotfix does not evict web shells or persistence. Restore from a clean backup and validate backup integrity before you need it.
  3. Apply the emergency hotfix. Ahsay partners running v10 should install hotfix v10.3.4.45 from the Ahsay partner portal (login required) and reboot the server afterward. Verify the build after installing.
  4. Keep the console off the internet until patched. Until the hotfix is in, restrict the AhsayCBS management interface to trusted IPs or a VPN.
SECURITY ALERT · OCT 8, 2026 · UPDATED OCT 22

Critical GitLab flaws: 10/10 file-read bug under active attack

A maximum-severity flaw in self-managed GitLab lets an unauthenticated attacker read arbitrary files — including credentials and source code — from the server.

Read advisory

A maximum-severity flaw in self-managed GitLab (CVE-2026-85706, CVSS 10.0) lets an unauthenticated attacker read arbitrary files — including credentials and source code — from the server through the repository commits API. Active exploitation began within a day of the September 10 patch, and CISA confirmed real-world attacks on September 11. Any self-hosted GitLab instance still on an affected build is now over a month behind: patch to 19.3.6, 19.4.3, or 19.5.1 or newer. Those builds also cover October’s unauthenticated RCE (CVE-2026-97229) and a second maximum-severity flaw patched out-of-band on October 21 — CVE-2026-110264 (10.0), an unauthenticated remote-code-execution bug in the regex engine bundled with GitLab; no exploitation of it has been reported so far. Update October 30: CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalog on October 29 after confirmed exploitation — patch first, then hunt for compromise, not just the patch. Note the floor moved: 19.3.5 fixed the earlier flaws but is itself vulnerable to CVE-2026-110264, so don’t stop there. (19.1.8 and 19.2.6 fix this file-read flaw, but the 19.1 line lost security support on September 17 and 19.2 on October 15.) Then hunt API logs for traversal probing, and rotate every credential the GitLab process could have exposed. GitLab.com and GitLab Dedicated customers are unaffected. Related: CVE-2026-90970 (9.9/10) in the self-hosted GitLab AI Gateway lets authenticated Duo Agent Platform users run commands on the gateway — update the AI Gateway to 19.2.4 / 19.3.2 / 19.4.1 and rotate AI provider API keys.

SECURITY ALERT · OCT 7, 2026 · UPDATED OCT 17

SonicWall SMA1000 gets a 10/10 pre-auth flaw — and September's patch doesn't cover it

SonicWall released hotfixes Tuesday for four SMA1000 flaws, led by CVE-2026-102255 — a no-login flaw in the remote-access portal that lets an unauthenticated attacker make the appliance act on their behalf. Any appliance on September's hotfix needs patching again.

Read advisory

CVE-2026-102255 is a pre-authentication server-side request forgery (SSRF) in the WorkPlace interface of SonicWall SMA1000 appliances, rated 10.0 out of 10. The interface's "unintended alternate access path" lets a remote attacker with no credentials and no user interaction send crafted requests through the appliance — directing it to issue requests on their behalf and reach internal functionality, effectively performing unauthorized operations through a box that guards your network edge. Three companion flaws are included in the same release: CVE-2026-102256 (7.8, OS command injection in the Appliance Management Console), CVE-2026-102257 (7.2, Zip Slip file overwrite in the console), and CVE-2026-102258 (5.5, stored XSS) — but all three require an administrator login, so the urgency belongs to the pre-auth flaw. SonicWall initially stated there was no evidence of exploitation — but update October 17: researchers now report active exploitation in the wild. Honeypots logged 135+ attempts from two US IP addresses on October 9-10, and one report describes web shells and stolen admin credentials on compromised boxes. (SonicWall itself hasn't confirmed exploitation, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog yet.) Treat unpatched appliances as a potential active compromise: hunt for indicators of compromise, don't just patch. SMA1000 flaws were exploited as zero-days in July 2026 and again in September, and Shadowserver counts more than 400 internet-exposed appliances.

The September patch doesn't cover this

The affected versions are exactly the ones SonicWall named as fixes for September's exploited flaws: 12.4.3-03526 and older, and 12.5.0-02952 and older (models 6210, 7210, and 8200v). The new fixed releases are 12.4.3-03670 and higher, and 12.5.0-03082 and higher. If your appliance was patched last month, it needs patching again. SSL-VPN running on SonicWall firewalls and the SMA 100 Series are not affected. There is no workaround; the hotfix installs from the MySonicWall portal and the appliance restarts when installation finishes.

Why this one is serious

SMA1000 appliances are remote-access gateways — the front door for remote workers into company networks and applications. A flaw that needs no login on an internet-facing box at that position is the worst kind of exposure, and threat actors have made this product line a favorite: July's zero-days were linked to ransomware gangs. Patching fast and reducing internet exposure are both worth doing.

What to do now

  1. Find every SMA1000. Inventory models 6210, 7210, and 8200v and compare platform-hotfix versions against the fixed releases above — even if you patched in September.
  2. Apply the hotfix. Upgrade to 12.4.3-03670+ or 12.5.0-03082+ and plan for the restart; schedule it outside working hours for production gateways.
  3. Reduce exposure. Ask whether your appliance needs to face the internet directly, or whether access can be narrowed — IP allow-lists, a management subnet, or fronting it through a stricter perimeter.

How we help

We inventory your SonicWall remote-access deployments, schedule the hotfix with a maintenance window that respects the restart, and review whether your gateways' internet exposure can be reduced. If you're unsure whether your business is affected, contact us and we'll work through it with you.

SECURITY ALERT · OCT 6, 2026

Critical Dell System Update flaw — unauthenticated remote code execution as root on PowerEdge servers

Dell patched a 9.6-rated path-traversal flaw in System Update that could let a remote attacker without credentials run code as root on PowerEdge servers. No attacks reported yet — but the details are public, so patch now.

Read advisory

CVE-2026-86360 is a path-traversal vulnerability in Dell System Update (DSU), the command-line deployment tool enterprise IT teams use to push BIOS, firmware, and software updates onto PowerEdge servers. It is rated 9.6 out of 10. Dell says "an unauthenticated attacker with remote access could potentially exploit this vulnerability," which can be leveraged to execute arbitrary code with root privileges — complete compromise of the application and the underlying operating system. The CVSS vector indicates some user action may be required, so this is not a simple wormable case — but a privileged, widely deployed management tool with a public remote-root flaw is exactly the kind of thing attackers study.

Five flaws in one release

Dell's advisory DSA-2026-324 (published October 1, 2026) fixes five vulnerabilities in System Update versions before 2.3.0.0. Alongside the critical path-traversal bug: CVE-2026-63697 (7.6), an improper certificate-validation flaw enabling remote code execution; CVE-2026-71168 (7.3), a second path-traversal flaw enabling remote code execution; and CVE-2026-86361 and CVE-2026-86362 (both 8.2), privilege-escalation flaws letting a low-privileged local user raise their rights. Upgrading to 2.3.0.0 or later resolves all five. There is no workaround. Dell has not reported active exploitation and no public proof-of-concept has surfaced; none of the five CVEs are in CISA's Known Exploited Vulnerabilities catalog.

Why this one is serious

System Update runs with root-level privileges by design, and most shops deploy the same DSU build across their entire server fleet — so a single vulnerable version can leave a whole data center exposed. Attackers favor trusted management components precisely because compromising one yields privileged access everywhere it manages.

What to do now

  1. Find every DSU install. Inventory PowerEdge hosts on Windows Server, Linux, ESXi, and Azure Stack HCI — including standalone boxes outside central management — and flag anything older than 2.3.0.0. Dell's download record shows the fixed build dates to July 2026, so servers updated in your normal cycle may already be covered.
  2. Upgrade to 2.3.0.0 or later. Take the package from Dell and verify the checksums before deploying; "or later" is the instruction to follow, not 2.3.0.0 exactly.
  3. Shrink exposure in the meantime. Limit which systems and users can reach DSU components, and which catalogs or repositories they can use, until every host is patched. Treat any server you can't patch quickly as a candidate for extra monitoring.

How we help

We inventory your Dell server fleet, plan the System Update upgrade with a scheduled maintenance window, and review exposure while patches roll out. If you're unsure whether your business is affected, contact us and we'll work through it with you.

SECURITY ALERT · OCT 7, 2026

Actively exploited Atlassian flaw hits eight self-hosted products — patch your Jira and Confluence now

If your business runs Jira, Confluence, or Bitbucket on your own servers, a critical vulnerability in Atlassian's self-hosted software is now being exploited in the wild, just hours after a public exploit was released.

Read advisory

CVE-2026-21589 is rated 9.3 out of 10 and affects self-hosted installations of eight Atlassian products: Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Fisheye and Crucible.

An attacker needs no login and no user interaction to read files inside the application's web directory. In Jira setups tied to Atlassian Crowd for identity management, researchers demonstrated that the file access could escalate to full administrator privileges. Attack attempts were detected on the internet within two hours of the public exploit release, and the pace is expected to increase. Atlassian Cloud customers are unaffected because Atlassian has already patched the cloud service.

What to do now

  1. Patch immediately. Atlassian published fixed releases for each affected product. Apply the update for your version line and verify the exact fixed version against Atlassian's current bulletin before making changes.
  2. Limit exposure. If your Atlassian server is reachable from the internet, restrict that access while the update is planned and deployed.
  3. Block known attacker IP addresses. Add 38.60.157.86, 146.70.187.234 and 159.26.119.225 to appropriate deny lists, while recognizing that blocking these addresses does not replace patching.
  4. Check for compromise. Atlassian cannot determine whether any given server was already compromised, so review logs for unexpected access rather than treating the patch as the end of the response.

How we help

We can identify exposed Atlassian servers, apply the correct updates, harden internet-facing services and review systems for signs of compromise. If your business runs Atlassian software, contact us and we'll assess your exposure.

SECURITY ALERT · OCT 7, 2026

Zammad zero-days under attack: session hijack to root in seconds — patching alone may not be enough

CISA added two actively exploited Zammad helpdesk flaws to its exploited-vulnerabilities catalog, and the federal deadline (October 5) has now passed. The chain runs from a hijacked session to remote code execution to root — and CISA is asking for forensic review, not just an upgrade.

Read advisory

CVE-2026-102489 and CVE-2026-102490 are a session-fixation vulnerability and an improper-privilege-management vulnerability in Zammad, the open-source helpdesk and ticketing platform. Chained together, an attacker hijacks a session to execute code as the Zammad service account, then escalates to root on the host — full control of the server. Researchers at DIVD, the Dutch vulnerability-disclosure organization whose own Zammad system was breached through these flaws, rate the chained path at 9.4 out of 10. CISA added both to its Known Exploited Vulnerabilities catalog on October 2, 2026, with a federal remediation deadline of October 5, 2026 — now passed, so any still-unpatched system is overdue.

Patching isn't the whole job this time

CISA is explicitly calling for forensic triage rather than patch-and-move-on. That language is the agency's way of saying it expects some exposed systems are already compromised: exploitation evidence goes back to at least September 21. If your Zammad system was reachable during that window, the upgrade should be paired with a compromise check — session logs, unexpected administrative or root-level activity, and indicators of session hijacking.

What versions are affected

The remote code-execution flaw is practically exploitable on Zammad 6.3.0 through 6.5.4, per researchers; Zammad's own advisory states exploitation is only possible on 6.5 and earlier and that 7.0 and later are not affected in practice. Critically, 6.5 and older are end-of-life and no longer receive security updates — so for those systems the fix is an emergency migration to 7.x (current stable 7.2.0 includes the hardened code), not a patch. Check the exact installed build against Zammad's current advisory before acting.

What to do now

  1. Find your Zammad systems. Ticketing systems are easy to forget about — inventory every Zammad instance, including ones run by individual departments.
  2. Migrate off 6.5 and older now. They are end-of-life with no security updates; move to 7.x as an emergency change, not a routine window.
  3. Check for compromise, don't just upgrade. Review for session-hijacking indicators and unexpected root-level activity dating back to mid-September before declaring a system clean.

How we help

We inventory your Zammad deployments, migrate end-of-life 6.5-and-older systems to 7.x with a planned emergency window, and pair the move with a forensic review of the exposure window — because this is one where the update alone isn't the answer. If you're unsure whether your business runs Zammad, contact us and we'll work through it with you.

SECURITY ALERT · OCT 7, 2026

Critical Veeam Backup RCE: patch before recovery systems become a target

CVE-2025-64393 lets a low-privileged Backup Viewer run code on the Veeam Backup Server. No active exploitation has been reported, but vulnerable version 12 systems should be updated before attackers put the flaw to use.

Read advisory

Veeam has fixed a critical remote-code-execution vulnerability in Veeam Backup & Replication 12. CVE-2025-64393 is rated 9.4 out of 10 under CVSS 4.0 and is caused by unsafe handling of data received through the Mount Service.

An attacker needs an authenticated account with the low-privileged Backup Viewer role, so this is not an unauthenticated internet attack. That requirement does not make the flaw routine: if an attacker gains that account through stolen credentials or another foothold, the vulnerability can turn limited access into code execution on the backup server.

Why backup infrastructure deserves priority

Backup servers hold the recovery data businesses depend on after ransomware, system failure or human error. Control of that infrastructure can give an intruder a chance to disrupt recovery, alter backup operations or move deeper into the environment. Veeam has not reported active exploitation, and no confirmed public proof of concept was reported when the issue was disclosed, making this a patch-before-it-burns priority rather than an active incident.

Affected and fixed builds

Veeam Backup & Replication build 12.3.2.4854 and earlier version 12 builds are affected. The fix is included in version 12.3.2 P4 (build 12.3.2.4934); version 13 is not affected. Confirm the current supported upgrade path and release guidance before making changes.

What to do now

  1. Confirm every build. Inventory Veeam Backup & Replication servers and record the exact version and build running on each one.
  2. Apply the fixed release. Upgrade affected version 12 systems to 12.3.2 P4 or a later supported release, then verify that backup jobs, repositories and restore testing still operate as expected.
  3. Review Backup Viewer access. Remove accounts that do not need the role, protect the remaining identities with strong authentication controls and investigate unfamiliar role assignments or sign-ins.
  4. Keep backup systems isolated. Limit administrative and service access to trusted management paths, and monitor the backup server for unexpected processes, configuration changes or recovery-point activity.

How we help

We can identify affected Veeam servers, confirm their builds, plan the update and validate backup and restore operations after patching. Review the published vulnerability summary and Veeam's current release guidance before upgrading. If you're unsure whether your business is affected, contact us and we'll work through it with you.

SECURITY ALERT · OCT 6, 2026

Cisco SD-WAN Manager zero-day: no-login admin access under active attack

A critical authentication bypass can give a remote attacker administrator access to the SD-WAN Manager API. Cisco has confirmed active exploitation, and there is no complete workaround — affected systems need a fixed release.

Read advisory

Cisco Catalyst SD-WAN Manager, formerly vManage, has a critical authentication bypass that should be treated as an emergency. CVE-2026-76504 is rated 9.8 out of 10. A remote attacker who can reach the management interface can send a crafted HTTP request, bypass authentication and access the API with administrator privileges — no username, password or user interaction required.

This is especially serious because SD-WAN Manager is the central management plane for network policies, configurations and branch connectivity. Cisco says the vulnerability affects the product regardless of system configuration and confirmed that it was being actively exploited in September. CISA added it to the Known Exploited Vulnerabilities catalog on September 30, with a federal remediation deadline of October 3.

There is no complete workaround

Cisco has released a Live Protect shield as temporary partial protection, and recommends restricting on-premises management access to known, trusted hosts behind a filtering device. Neither measure replaces the software upgrade. Cisco-managed SD-WAN Cloud was fixed in release 20.15.605 and requires no customer upgrade action.

What to do now

  1. Identify every deployment. Confirm the release running on each Cisco Catalyst SD-WAN Manager and whether its management interface is reachable from the internet or another untrusted network.
  2. Upgrade to a fixed release. The first fixed builds are 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1 and 26.2.1. Releases earlier than 20.9 must migrate to a supported fixed release.
  3. Restrict access while upgrading. Allow only known administrative hosts to reach the management interface and keep control components behind an appropriate firewall. Treat this as risk reduction, not remediation.
  4. Check for signs of exploitation. Review serviceproxy-access.log and vmanage-server.log for unexpected requests to encoded variants of j_security_check, unfamiliar source addresses and activity involving accounts whose names begin with viptela-reserved-. Cisco recommends collecting an admin-tech bundle and opening a TAC case if compromise is suspected.

How we help

We can inventory affected SD-WAN Manager systems, plan the correct upgrade path, restrict management exposure and review the published indicators for signs of attack. Refer to Cisco's security advisory for the latest fixed-release and investigation guidance. If you're unsure whether your business is affected, contact us and we'll work through it with you.

SECURITY ALERT · OCT 5, 2026

NetScaler zero-day #3: SAML flaw under attack — last week's patch isn't enough

Citrix disclosed another actively exploited NetScaler vulnerability on October 4. The catch: the fixes from the previous patch round don't cover it, so affected appliances need updating again — CISA's deadline is Wednesday.

Read advisory

CVE-2026-88779 is a memory-overflow flaw in the SAML authentication handler of Citrix NetScaler ADC and NetScaler Gateway, rated 8.7 out of 10. An unauthenticated attacker can send a crafted SAML request that crashes the appliance's authentication service, cutting off VPN, single sign-on and remote access. Citrix has confirmed targeted attacks; Norway's National Security Authority has reported indications the flaw could allow remote code execution, a scope Citrix has not confirmed. CISA added it to its Known Exploited Vulnerabilities catalog on October 4, with a federal remediation deadline of October 7, 2026.

Only SAML configurations are exposed

The flaw applies where the appliance is configured as a SAML service provider or identity provider. Appliances without SAML authentication configured are not exposed to this flaw (though the earlier NetScaler flaws are a separate matter).

Patch again — the new build numbers

The fixed releases are NetScaler ADC and Gateway 14.1-73.41 and later, 13.1-64.28 and later, plus FIPS equivalents. Critically, the builds from last week's emergency patch round do not include this fix — an appliance patched for the earlier flaws is still vulnerable to this one. Citrix has also released interim deny-list signatures that can be deployed through the NetScaler Global Deny List feature while an upgrade is planned.

What to do now

  1. Check SAML configuration. Review NetScaler configurations for SAML authentication actions or identity-provider profiles; only those deployments are exposed.
  2. Upgrade to the fixed builds. Move to 14.1-73.41 or 13.1-64.28 (FIPS equivalents where applicable), and apply the interim deny-list signatures if the upgrade can't happen immediately.
  3. Look for signs of attack. Researchers and administrators have reported appliance crashes and reboots, and attacks have been observed against honeypots — review appliance logs and uptime history for unexpected outages during the exposure window.

How we help

We inventory your NetScaler deployments, check which are configured for SAML, apply the fixed builds with a planned maintenance window, and review logs for signs of compromise. If you're unsure whether your business is affected, contact us and we'll work through it with you.

SECURITY ALERT · OCT 5, 2026

Out-of-band Exchange update: any user account could read other mailboxes

Microsoft pushed an emergency “September 2026 V2” update for Exchange Server because of a flaw that lets an ordinary authenticated user read other users’ email and attachments.

Read advisory

Microsoft released an out-of-band security update for Exchange Server on October 2, 2026—eleven days before the regular October Patch Tuesday—because of a high-severity authorization flaw it decided could not wait.

CVE-2026-96940 is rated 8.8 out of 10. A weak authorization check in Exchange Server lets an authenticated attacker with ordinary privileges read the mailboxes and attachments of other users in the same organization, with no user interaction and over the network. There is no access across organization boundaries. Microsoft’s Exchange Team says it is not aware of active exploitation, but considers exploitation “more likely” and notes that flaws of this type have been exploited in the past.

Even patched servers need the update again

The fix shipped as a reissue of the September update, labelled “September 2026 V2.” If a server received the original September patch, it still needs the V2 version. Microsoft’s Exchange Team recommends installing the security update on all Exchange servers—and on any server or workstation running the Exchange Management Tools, so the tools stay compatible.

What to do now

  1. Confirm your build. The fix applies to Exchange Server Subscription Edition RTM (KB5129955), Exchange 2019 CU15 (KB5129956) and CU14 (KB5129957), and Exchange 2016 CU23 (KB5129958). Identify every on-premises Exchange server and record its current build.
  2. Install the V2 update. Apply it even if the September patch is already in place, then restart and run Microsoft’s Exchange Server Health Checker to confirm nothing is missing.
  3. Plan the 2016/2019 exit. This fix requires enrolment in the Extended Security Update Period 2 program, which expires at the end of October 2026. After that there is no patch path for Exchange 2016 or 2019—affected organizations should move to Exchange Server Subscription Edition or Exchange Online.

How we help

We can inventory your on-premises Exchange servers, apply the update with a planned restart, and put you on a supported path for 2016 and 2019. If you are unsure whether your business is affected, contact us and we’ll work through it with you.

SECURITY ALERT · OCT 5, 2026

Citrix NetScaler flaws under active attack: patching alone is not enough

Two critical vulnerabilities can let an unauthenticated attacker run commands on affected appliances—and persistence may survive an upgrade.

Read advisory

Organizations using Citrix NetScaler ADC or NetScaler Gateway should treat two newly disclosed vulnerabilities as an incident-response priority, not a routine maintenance item.

CVE-2026-88771 and CVE-2026-88772 are both rated 9.5 out of 10 and are being actively exploited. An attacker does not need a username or password to run commands on a vulnerable appliance. Because NetScaler systems often sit at the edge of the network in front of remote access and business applications, a successful compromise can provide a valuable foothold.

Why an upgrade may not be enough

Evidence of exploitation predates the available fixes, and attackers have installed web shells that can remain after the vulnerable software is upgraded. Patching closes the entry point, but it does not prove the appliance was clean before the update or remove persistence that is already present.

What to do now

  1. Confirm exposure. Identify any NetScaler ADC or Gateway appliances, especially systems reachable from the internet, and record their current builds.
  2. Use Citrix's current guidance. Review bulletin CTX697096, confirm the affected and fixed build numbers, and upgrade without delay.
  3. Hunt for compromise. Review the indicators in Citrix's bulletin and investigate appliance activity back to early September. Look for unexpected files, web shells, commands, accounts and outbound connections.
  4. Respond to findings. If there are signs of compromise, isolate the appliance, preserve evidence and follow a full incident-response process. Rebuilding from a known-good image may be safer than trusting an in-place upgrade.

How we help

We can help identify exposed appliances, coordinate the correct upgrade path and review systems for signs of compromise. If you are unsure whether your business is affected, contact us and we’ll work through it with you.

SECURITY ALERT · OCT 4, 2026

FortiMail zero-day under active attack: what small businesses need to know

If your business runs a Fortinet FortiMail email gateway, this critical vulnerability needs attention now.

Read article

If your business runs a Fortinet FortiMail email gateway, read this today—not next week.

On October 1, Fortinet disclosed a critical flaw in FortiMail (CVE-2026-104286, severity 9.8 out of 10) and confirmed it was already being exploited in the wild. Attackers need no username or password: a crafted web request is enough to write files anywhere on the appliance and take it over. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities catalog, with a federal remediation deadline of October 4.

Who’s affected

The affected releases are FortiMail 8.0.0–8.0.1, 7.6.0–7.6.6, 7.4.0–7.4.8 and 7.2.0–7.2.9. Fortinet lists upgrades to 8.0.2 or later, 7.6.7 or later, and 7.4.9 or later; deployments on 7.2 should move to the 7.4 branch or later. Verify the current upgrade path and instructions in Fortinet advisory FG-IR-26-175 before making changes.

What to do right now

  1. Apply Fortinet’s workarounds immediately. Disable the affected Identity-Based Encryption (IBE) feature and make sure the management interface isn’t reachable from the internet.
  2. Don’t assume you’re safe just because you patched. Patching closes the hole, but it doesn’t remove an attacker who already got in. Check for signs of compromise: unfamiliar accounts, modified binaries, tampered web configurations or unexpected outbound connections.
  3. Watch for the published indicators. Fortinet has shared suspicious IP addresses and file hashes with the advisory.

The bigger pattern: attackers are coming in through the front door

Separately, Microsoft’s security team recently reported phishing campaigns that trick employees into installing legitimate remote-access tools—MSP360, then ScreenConnect—disguised as meeting invites or software updates. There was no malware to detect, just trusted IT software in the wrong hands. The fix there isn’t a patch; it’s awareness and good endpoint control.

How we help

This is exactly what proactive IT management is for: monitoring threat alerts like this one, checking your systems before attackers do and applying protections the same day—not when something breaks. If you’re not sure whether your business is exposed, contact us and we’ll take a look.

Concerned that one of these issues affects your business?