Vulnerability Briefing 9 November 2026

TL;DR — 9 November 2026 (2026-11-09)

SonicWall: CISA added the SonicOS SSLVPN authentication-bypass issue to KEV on 6 November. Prioritize exposed affected VPNs. Official CISA catalog

OpenSSH on musl: The 5 November fix now has direct sensor-exploitation evidence from 7 November. Match the actual authentication configuration before deciding applicability. OpenSSH release GreyNoise observations

Linux TCP: This is an October disclosure with fresh November appliance fixes. Verify installation and required restarts; planned mitigations are not completed patches. Sophos update

This edition reviews developments since 5 November, including the weekend and early-9-November sensor update, with primary sources opened on 9 November during the Johannesburg research window. Older disclosure dates remain visible where the new information is remediation or exploitation evidence. It is a selected, evidence-led briefing, not an exhaustive census of every vulnerability.

Overall overview

Three different decisions matter this Monday. A remote-access control can fail despite a dashboard showing MFA enabled; an SSH alert can be urgent only for a particular libc and authentication setup; and a kernel fix can exist upstream while an appliance or distribution still needs a separate update. Use the detailed prerequisite and vendor tables to turn a generic alert into an asset-specific action.

Our priority order follows observed exploitation, reachable exposure and operational consequence. CVSS describes technical severity under its stated assumptions. EPSS is a separate daily forecast and does not incorporate your asset inventory, compensating controls or business impact. A low forecast is not an all-clear when exploitation is already known. FIRST methodology FIRST interpretation FAQ

At-a-glance priorities

The detailed sections provide the source, score vector, version matrix and limitations behind each row. The index opens those sections; email readers follow the link to the corresponding website section.

CVE-2026-19868 SonicOS SSLVPN SAML and MFA enforcement bypass

Overview

Detailed assessment and verification

What changed: CISA added this vulnerability on 6 November. Its official feed, refreshed here on 9 November, contains one addition dated 5 November or later: this SonicOS issue. The retrieved catalog version is 2026.11.06, with 1,769 entries; that is the observed snapshot, not a claim that no vulnerability was exploited elsewhere over the weekend. CISA catalog snapshot

The important operational distinction is between having credentials and satisfying the intended authentication policy. SonicWall describes an alternate authentication path that can bypass SAML and its MFA requirements. An inventory that records only “MFA enabled” is therefore insufficient to establish that this exposure is closed. Check the actual SSLVPN authentication methods and the affected running build. The score and vector are attributed to CISA ADP because the vendor CNA container does not supply a CVSS score. Technical record

The vendor notice covers a batch of vulnerabilities and displays an overall 8.8 score; it should not be assigned to this CVE. Its Gen 7 matrix distinguishes the 7.3.4-7013 build available from 20 October from 7.3.4-7015 dated 5 November. The Gen 8 row names 8.2.3-8015 but retains planned-release wording. Treat that as a build to verify with the vendor, not evidence that a particular appliance has received it. Vendor notice, updated 6 November

Operational assessment: Make one change record for firmware remediation and another for exposure review. Confirm the model, generation, exact firmware, SSLVPN reachability and configured identity paths. Capture configuration and recovery information before an upgrade, then verify that required users can authenticate through the intended path. If the upgrade cannot be completed promptly, record the owner, temporary access restrictions and a short review deadline rather than silently accepting the exception.

Verification and uncertainty: A new firmware string does not prove the appliance was never accessed through the vulnerable path. Review authentication and administrative activity for the exposure period and escalate anomalies through the incident-response process. This briefing does not establish victim counts, a specific ransomware campaign or public proof-of-concept availability. No exploit was run against any device.

The 0.621% EPSS snapshot is an estimated population-level exploitation signal for the next 30 days, not the probability that your VPN is compromised. Known exploitation, reachable exposure and the value of the protected network justify urgency independently of that low-looking percentage. FIRST score dated 8 November FIRST methodology.

CVE-2026-123158 OpenSSH on musl: password authentication bypass

Overview

Alpine fixed package matrix

Alpine fixed packages, 5 November 2026

Detailed assessment and verification

What changed: Portable OpenSSH 10.6p2 was released on 5 November with a workaround for a password-authentication failure affecting certain musl Linux configurations. Upstream places the underlying cause outside sshd while addressing the exploitable path in sshd. This is a new release and a newly published CVE, rather than a relabelled item from the previous briefing. OpenSSH release note CNA metadata

An OpenSSH version alert is the start of triage, not the complete exposure test. Red Hat says its builds are not affected because they use glibc and PAM. That product-specific conclusion should not be transferred to a separate musl container or appliance simply because it runs beside a Red Hat host. Red Hat applicability

Observed activity: GreyNoise reports successful exploitation against an instrumented vulnerable gridpoint on 7 November, with shell-command execution as its success criterion. The 9 November 00:10 UTC snapshot displays 16 confirmed post-exploitation activity chains. Those chains, its separate intrusion summaries and broad port-22 scan volumes are different measurements; none provides a defensible global victim count. GreyNoise also reports public exploit availability, but no exploit was downloaded or executed for this briefing. Dated primary sensor report

Remediation detail: Deploy the branch-specific package below and restart sshd. Before temporarily disabling password logins, verify key access and retain recovery. Alpine advisory

Operational assessment: Prioritize services that are reachable outside their intended trust boundary, then document the accounts and privilege paths that make a successful login consequential. Coordinate the daemon restart with the owner of the management path. A secure baseline should be checked against effective configuration rather than the mere presence of a configuration snippet; conflicting per-user or per-group rules can otherwise make an inventory misleading.

Post-change verification: Record the running package and restarted daemon. Treat suspicious authentication or privilege changes as incident-response leads; patch completion cannot prove that earlier compromise is absent. Alpine advisory

Uncertainty: This review did not inspect your assets and does not enumerate every distribution or embedded product. The exact Alpine branches are retained to make backport verification concrete; other vendors require their own support statements. FIRST’s 1.014% dated forecast should not delay an applicable fix where successful sensor exploitation has already been observed. FIRST dated score

CVE-2026-98432 Linux IPv4 TCP use-after-free: fresh appliance fixes

Overview

Upstream Linux fixed release thresholds

Linux CNA branch matrix; unlisted older branches have no fixed release declared here. Vendor backports can differ.

Detailed assessment and verification

What changed: This CVE was published on 15 October. The fresh developments are Sophos remediation on 5–6 November, Arista’s 6 November advisory revision and Ubuntu’s 7 November tracker update. Those developments justify a follow-up without presenting an older kernel defect as a new Monday discovery. CNA dates Sophos update Arista revision Ubuntu tracker

The defect involves a use-after-free in IPv4 TCP handling. Red Hat describes unauthenticated remote memory corruption, crashes and possible code execution, while noting the timing and heap-control difficulties of reliable execution. A lab configuration demonstrates one route to impact; it does not define every potentially affected production configuration. In particular, an inventory rule that marks all MPTCP-disabled systems unaffected would overstate the evidence. Current Red Hat analysis

Sophos: Confirm the applicable Firewall release, hotfix receipt and restart. For SD-RED 20/60, the separate 3.0.012 pattern is available through SFOS 20.0 MR3 or later and 21.0 MR1 or later; installation on the connected device triggers its reboot. Legacy end-of-life RED models do not receive that fix. A management console downloading the pattern does not establish that every connected device has installed it. Firewall advisory SD-RED deployment notice

Arista: The checked advisory identifies NDR through 5.4.11 under its known MPTCP-configuration assessment. It describes a planned online-appliance mitigation and directs air-gapped operators to support, while listing no fixed release or hotfix. Do not convert that plan into proof of completed rollout. The 6 November revision adds on-premises CloudVision Portal to the unaffected list and updates EOS/NetVisor mitigations; those product-specific statements are not a universal claim that vulnerable IPv4 code is absent. Arista revision 1.2

Distribution backports: Debian records first-fixed source packages including linux 6.1.190-1 for bookworm, 6.12.113-1 for trixie, 7.2.10-1 for unstable and linux-6.12 6.12.113-1~deb12u1 for bookworm. The currently offered security package can be newer than the first-fixed version. Check the actual package stream and running kernel rather than comparing only a major/minor version. Debian tracker

Ubuntu’s main linux source-package row lists 26.10 fixed at 7.3.0-10.10, while several LTS rows remain work in progress in the 7 November update. This is a sampled main-package status, not a complete inventory of cloud, HWE, OEM or realtime variants. A proposed or work-in-progress build is not a released fix. Use the row for the installed flavour and release. Ubuntu status and qualifications

Operational assessment: Join the external-service inventory to the host or appliance that owns each listening socket. Sequence updates around recovery capacity and record where a temporary vendor mitigation is used instead of a fix. Broad packet filtering can affect legitimate protocols; it needs product-specific review and should not be declared equivalent to a complete patch without supporting vendor evidence.

Verification and uncertainty: Capture the exact running kernel or appliance build after the restart and close the change only when that evidence matches the applicable fixed status. Keep crash reports and anomalous activity for incident review. The vendor statements above do not establish that every environment was unexploited, and this briefing did not test any deployment or observe vendor rollout completion. FIRST’s 0.760% probability is a dated forecast, not a reason to defer an exposed critical kernel update. FIRST dated score

Remediation and verification checklist

1. Establish applicability. Record the owner, exposed service, exact product or package, running build and relevant configuration. Keep unsupported or unconfirmed assets visible as exceptions.

2. Choose the correct fix. Follow the vendor’s branch or appliance matrix. An upstream version threshold does not replace backport evidence, and a planned release is not a verified available download.

3. Protect recovery. Check access, backups and a rollback or recovery path before changing remote-management components. Coordinate restarts with the service owner.

4. Prove the running state. Retain installed-package or firmware evidence after restart and verify the intended authentication and service behavior. Record what was actually checked.

5. Separate patching from incident response. Where exploitation is known or suspicious activity exists, preserve relevant records and assess possible prior access. Do not close an incident solely because the fix installed.

6. Track remaining exposure. Assign an accountable owner and review time to each temporary mitigation or unavailable fix. Recheck the vendor advisory before the next change window.

Methodology, scoring and uncertainty

Research used current vendor notices, official CVE/CNA records, the complete retrieved CISA KEV feed, FIRST and GreyNoise’s own sensor reporting. The CISA analysis filters the current catalog by addition date from 5 November; it is not a historical diff of every edited catalog field. A checked page can describe an older event, so disclosure, update and observation dates are kept separate.

Every EPSS value here is the FIRST snapshot dated 8 November 2026, retrieved during the 9 November research window. Probabilities and percentile ranks are shown separately. EPSS estimates exploitation activity over the next 30 days; it is not a probability that a particular organization is compromised. Its ranking complements exposure and impact review, and does not override observed exploitation. FIRST EPSS Interpretation and limitations

Source limitations are explicit: the CISA website returned 403, so its official public repository supplied the catalog; SonicWall’s PSIRT application did not expose a readable advisory body, so its CNA and support notice supplied the verified facts. Some vendor pages have no usable revision timestamp; those are current checked snapshots rather than newly dated announcements. Firmware availability, your deployed state and completion of vendor-side mitigation rollouts were not independently observed.

The briefing does not assert a universal absence of attacks, a global victim count, complete distribution coverage or guaranteed mitigation effectiveness. Sensor sessions, public proof-of-concept availability, laboratory demonstrations and confirmed production incidents are different evidence categories. No intrusive scan or exploit execution was performed. Recheck the linked vendor guidance when acting because the sources and package status can change after this research cutoff.