SonicWall and OpenSSH both shipped authentication fixes last week. On affected SonicWall firewalls, a user with credentials for another authentication method may bypass SAML-enforced MFA. On certain musl-based SSH servers, an account with no password can accept an overlong one. CISA lists the SonicWall flaw as exploited; SANS saw attempts against the SSH flaw in its honeypots by November 8. The two cases are unrelated.

TL;DR

  • CISA added SonicWall CVE-2026-19868 to its Known Exploited Vulnerabilities (KEV) catalog on November 6. Inventory exposed Gen7 and Gen8 SonicOS SSL-VPN devices, install the fixed firmware, and review VPN and identity logs.
  • CVE-2026-123158 affects OpenSSH on musl Linux when PAM is not used, password authentication is enabled, an account has a * password field, and another account has a $5$ or $6$ hash. Update the distribution package and restart sshd.
  • SANS observed SSH exploit attempts. Its November 8 report did not establish successful compromise of real targets.

Where the authentication checks fail

The SonicWall flaw affects authentication at the network edge. The SSH flaw comes from the interaction of OpenSSH’s fallback salt with musl’s error value and the * marker for an account without a usable password. Exposure depends on the firmware and authentication settings in the first case, and on a specific mix of SSH settings and account fields in the second.

Start with internet-facing VPNs and SSH services. Patch affected builds, then examine successful logins and subsequent activity. The update prevents future use of the flaw, while logs may show whether anyone used it earlier.

SonicWall SSL-VPN: another credential route can bypass SAML MFA

SonicWall’s November 6 advisory, SNWLID-2026-0014, covers seven SonicOS flaws. CISA lists one of them, CVE-2026-19868, as exploited. SonicWall’s CVE record says a user with valid credentials for an alternate authentication method may bypass SAML controls, including SAML-enforced MFA. The attacker still needs those alternate credentials.

Think of an organization that requires a SAML login with MFA for VPN access, but also has a second credential method configured. The expected decision is “complete SAML and MFA before opening the VPN.” The vulnerable behavior described by SonicWall lets someone holding valid credentials for the other method reach the VPN without completing that SAML check. The weakness is in enforcement across authentication methods, not in the mathematics of MFA.

SonicWall has published the impact and affected versions, but no source-code diff for this proprietary component. We cannot point to a specific faulty if statement or claim to know exactly how its firmware fix works internally. Operationally, the fix is the vendor’s patched SonicOS build, followed by a login test that confirms the required SAML/MFA path for your configuration.

The vendor identifies affected Gen7 systems at 7.3.3-7015 and older and Gen8 systems at 8.2.2-8015 and older. SonicWall’s advisory lists fixed firmware 7.3.4-7013 or later for Gen7 and 8.2.3-8015 or later for Gen8. Confirm the appliance model and supported upgrade path before scheduling the change. CISA set a November 20 deadline for covered US federal agencies.

Inventory each SSL-VPN deployment’s authentication sources, SAML enforcement, firmware, and public reachability. After upgrading, verify the running firmware and test that representative user groups must pass the intended SAML/MFA checks. An external vulnerability scan cannot verify that policy on its own.

Review the period before the fix in SonicWall SSL-VPN and identity-provider logs. Correlate successful VPN sessions with SAML and MFA events, then check unfamiliar source networks and what those sessions reached internally. A session with no matching identity event warrants investigation; logging gaps and legitimate alternate methods can produce the same symptom.

SSHole: a passwordless account can accept a password

CVE-2026-123158 was disclosed on November 5. On a musl-based Linux system with OpenSSH built or run without PAM, sshd may borrow the salt of another account when checking an account whose shadow password field is *. If the supplied password exceeds 256 bytes, musl’s crypt() returns * as an error value. The comparison can then match the account’s stored * and allow a login.

Here is the failure in concrete values. A key-only account has * in its password field, which normally means no password should work. A different account supplies the salt OpenSSH needs for a consistent timing check. An attacker enters a password longer than 256 bytes. On musl, crypt() rejects that input by returning *. The old OpenSSH check compared the two strings and saw a match:

Value in the password checkVulnerable result
Stored field for the target account*
Result from musl crypt() for the overlong input*
Old OpenSSH decisionEqual strings → accept

The OpenSSH fix commit shows the missing guard in auth-passwd.c. This excerpt shows the decision before and after the patch; the commit also contains memory-cleanup changes.

return encrypted_password != NULL &&
    strcmp(encrypted_password, pw_password) == 0;
ret = encrypted_password != NULL &&
    strlen(pw_password) >= MIN_PASSWORD_HASH_LEN &&
    strcmp(encrypted_password, pw_password) == 0;

pw_password is the account’s stored password field. The old code accepted any non-null computed value that matched it, including musl’s one-character error value *. The added length check requires the stored field to be at least four characters before a match can authenticate. That excludes * even when crypt() returns the same character.

The guard does not remove key-based access to an account whose field is *. It prevents that marker from being treated as a valid password hash. The urgent operational step is still to install the fixed package and restart sshd, because the old daemon keeps running after a package upgrade.

The full exposure requires PasswordAuthentication yes, an SSH-reachable account with a * field, and at least one other local account with a $5$ or $6$ password hash. Alpine’s standard openssh-server package is built without PAM. Its tiny-cloud images can ship an alpine account with * and passwordless doas; adding an account with a suitable hash can open a path to root. The described configuration excludes glibc systems, Alpine’s PAM-enabled package with UsePAM yes, and hosts with PasswordAuthentication no. An Alpine container with no running sshd has no SSH service to attack.

OpenSSH released 10.6p2 as a workaround, and Alpine backported the fix. For supported Alpine branches, the fixed openssh packages are 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23, and 10.0_p1-r11 on 3.22. Alpine also published fixes for older branches. Compare the installed package against Alpine’s branch table, not just the upstream version printed by sshd.

SANS Internet Storm Center reported long-password SSH attempts in its honeypots. It identified the first attempt consistent with this exploit on November 5. Its November 8 report has limited password capture and does not establish how many real systems, if any, were compromised.

What You Can Do Today

  1. List public SonicOS SSL-VPN devices and musl-based hosts running sshd. Record their versions, authentication settings, and owners.

  2. Upgrade SonicOS using the Gen7 or Gen8 image specified by SNWLID-2026-0014. Verify the running build after reboot and test SAML-enforced MFA. Preserve VPN and identity logs before they roll over.

  3. On Alpine, run apk upgrade -U -a, then rc-service sshd restart. Compare the installed package with Alpine’s fixed-version table and confirm the daemon restarted. If the update must wait, disable password authentication, check the effective setting including Match blocks, and keep a working key-based session open while testing. Install the package fix afterward.

  4. On affected Alpine hosts, search /var/log/messages or the journal for Accepted password for an account whose password field is *. Correlate a match with doas use, new accounts, and changes to authorized_keys. For SonicWall, compare VPN successes with identity-provider events and internal access. Preserve evidence and assess credential rotation if compromise is suspected.

  5. Record the running SonicOS build or restarted sshd, the tested authentication settings, and the log period reviewed. Record gaps in log coverage.

Sources