10 min readIdentity and access
On 6 November 2026, CISA added CVE-2026-19868 to its Known Exploited Vulnerabilities catalog, based on evidence of active exploitation. The flaw affects the SSLVPN component of SonicWall SonicOS. CISA classifies it as “Use of Single-factor Authentication”. On a remote access gateway, that classification describes a weakness in the very control that multi-factor authentication is meant to provide.
In the same week, OpenSSH shipped emergency fixes for “SSHole” (CVE-2026-123158, CVSS 8.1). On some Linux systems, this flaw lets accounts accept any password between 257 and 1,024 characters. CERT-FR published an alert on it on 5 November and updated it on 6 November.
The two flaws differ in product, mechanism and exploitation status. They share one feature that should concern any management body: in both cases, the authentication control appeared to be in place. A configuration review would have found MFA enabled on the VPN. It would have found password authentication governed by policy on the SSH server. Neither review would have shown that the control could fail. This matters to CISOs, CIOs, risk and compliance leaders, and board members of regulated organizations. Remote access gateways and administrative SSH paths are among the most sensitive entry points of any information system. Under NIS2 Article 20, the management bodies of essential and important entities must approve and oversee the measures that protect them.
Most organizations report authentication maturity as a set of declarations. MFA is enabled for remote access. SSO is enforced through an identity provider. Password policies are set on servers. These statements end up in audit reports, risk registers and board dashboards. They are usually accurate as descriptions of configuration.
This week’s flaws show the gap between configuration and behaviour. A gateway that is meant to require several factors but carries a weakness classified as single-factor authentication does not reliably enforce MFA. A password check that accepts any string within a given length range does not check passwords. The configuration still says the right thing. The system does something else.
Executive takeaway: “MFA enabled” and “SSH password policy set” describe what the organization intended. They do not prove what the system does when someone tries to log in. Boards should treat them as claims to be tested, not as evidence.
This is an identity governance problem more than a patching problem. Patching closes these two specific flaws. It does not change how the organization knows whether its authentication works, and that question will come up again with the next flaw.
CISA’s alert gives the essentials. CVE-2026-19868 is a SonicOS SSLVPN vulnerability classified as use of single-factor authentication. It was added to the KEV catalog because of evidence of active exploitation. CISA notes that this type of flaw is a frequent attack vector for malicious cyber actors.
The classification is what matters for governance. Many organizations report MFA on all remote access. For them, an exploited weakness of this type on the VPN is exactly the scenario their dashboards say cannot happen. The detailed conditions belong in the vendor’s advisory. The gateway owner should read that advisory against the organization’s own configuration rather than rely on summaries.
Two points deserve emphasis. First, a single-factor login still requires the attacker to hold a factor, typically a credential. That should not reassure anyone. Credential theft and reuse are common, and MFA exists precisely because passwords leak. Second, no source available to us attributes the exploitation to a named actor, and this article does not do so.
Under Binding Operational Directive 26-04, US federal civilian agencies must prioritise fast remediation of KEV vulnerabilities on publicly exposed assets that give total control after exploitation. CISA encourages all organizations to adopt risk-based vulnerability management and to prioritise KEV entries. The directive does not bind European entities. The prioritisation logic still applies to them.
SecurityWeek reports that SSHole affects sshd on Linux distributions that use musl libc with PAM disabled. On those systems, some accounts accept any password between 257 and 1,024 characters. The cause is described as a “misinterpretation of whether a string is intended to be a password hash”. OpenSSH developer Damien Miller says the flaw is not in sshd itself but can be exploited through sshd. Fixes are available in OpenSSH 10.6p2.
CERT-FR published alert CERTFR-2026-ALE-015, which is marked as an ongoing alert. Its 6 November update gives the CVE identifier and notes that Alpine has published a security bulletin. CERT-FR also stresses that any patch installation or configuration change must be handled with care.
No source we reviewed confirms exploitation of SSHole, and none reports affected organizations in France. The flaw matters because of its nature, not because of observed attacks. It sits in the most basic authentication step on a server, and a standard configuration review would not reveal it.
Key point: One flaw is confirmed as exploited. The other is not. Both show that an authentication control can be configured correctly and still fail, so configuration evidence alone cannot support a claim of effective authentication.
Authentication rarely fails in the place where policy is defined. It fails at the joins:
Remote access gateways often support several login methods and factors side by side. The control only holds if the strongest requirement cannot be sidestepped through a weaker neighbour. CVE-2026-19868 shows what is at stake when that assumption fails: a gateway expected to enforce more than one factor, carrying an exploited weakness classified as single-factor authentication. In the SSHole case, a password check depends on how a lower-level component interprets data. That dependency becomes visible only on specific platform combinations, here musl libc without PAM.
Neither failure is visible in a policy document, a configuration export or a compliance questionnaire. Each becomes visible only when someone tries to authenticate in a way the control should refuse, and observes whether it does.
Security implication: Every internet-facing authentication path should be tested negatively, not only positively. It is not enough to confirm that a legitimate user with MFA can log in. The organization must also confirm that a user with only one factor, or with credentials for another login method, cannot.
Most access-control audits are built on design and configuration evidence. Auditors sample settings, review policies, check that MFA is “on” for a population of users, and confirm that a patch management process exists. This approach is efficient and necessary. It is weak at detecting controls that are configured correctly but behave incorrectly.
Three habits make the gap wider.
The SSHole case adds a platform dimension. Container images and lightweight Linux builds can use different system libraries from mainstream server distributions. An organization may not know where musl libc runs, or where PAM is disabled. Those choices were made at build time by teams outside the security function.
According to Security Affairs, NIS2 Article 20 requires the management bodies of essential and important entities to approve cybersecurity risk-management measures and to oversee their implementation. Those bodies can be held liable for infringements, subject to national law. The obligation is now live across most of the EU. In July, four member states were referred to the Court of Justice for failing to notify full transposition.
The article draws on an access-management report published by Passwork, a vendor in the field. It should be read as a commercial source. In that report, regulators from two national cybersecurity authorities and independent security leaders describe a shift: boards now ask for proof that controls work, where they once accepted a summary of the policy.
That shift fits this week’s flaws closely. Consider a board that approves “MFA on all remote access” and then receives a dashboard confirming that MFA is enabled. It has approved a policy. It has not overseen its implementation in the sense that matters. Oversight means asking how the organization knows the control works, who checked it, when, and with what result.
Decision point: Management bodies should decide which evidence they will accept for authentication controls on internet-facing and administrative paths. Configuration attestations alone should no longer be sufficient for those paths. Test results, named owners and dated remediation decisions should be required.
This does not mean board members must understand identity federation protocols or libc behaviour. It means they must insist on a chain of accountability. Each critical authentication path has an owner. That owner can show recent evidence that the path refuses what it should refuse. When a flaw such as CVE-2026-19868 appears, there is a defined deadline and a recorded decision on any residual risk.
Inventory every internet-facing authentication path. The CISO, working with network and IAM teams, should list each gateway, portal and administrative interface exposed to the internet. The list should include every login method enabled on each one, including fallback and legacy methods.
Name one owner per path. Each path should have a single accountable owner, named in the risk register. That owner answers for whether authentication on the path works, not only for whether it is configured.
Set patch deadlines tied to exploitation status. The CISO should define remediation deadlines and get them approved. Deadlines should be shorter for vulnerabilities listed as exploited, such as KEV entries, on exposed authentication components. CVE-2026-19868 should be handled under the shortest deadline, following the vendor’s advisory.
Test negatively, on a schedule. Security testing teams or approved third parties should regularly try to authenticate with a single factor and through alternative login methods. They should record each result as evidence for the path owner.
Map where platform assumptions hide. Infrastructure and platform teams should identify systems running sshd on musl libc with PAM disabled. They should upgrade them to OpenSSH 10.6p2 or a vendor-patched build, and handle changes with the care CERT-FR recommends. They should then confirm that the patched version is the one actually running.
Record residual risk explicitly. When a patch cannot be applied immediately, the path owner should document the compensating measure, the accepted residual risk and its expiry date. The decision should be signed at the appropriate management level.
Change what the board receives. The CISO should replace “MFA enabled” indicators with evidence-based ones:
These two flaws will be patched, and attention will move on. The underlying question will remain. Most organizations still describe their authentication posture in terms of what is enabled rather than what has been shown to work. That shortcut was tolerable when access-control oversight was a technical matter. It is harder to defend now that NIS2 places approval and oversight with management bodies and allows them to be held liable.
The adjustment does not require new technology. It requires a change of standard:
In practice, that means fewer reassuring dashboard figures and more uncomfortable questions answered with evidence. That trade is consistent with a simple principle: never trust, always verify, and that includes verifying your own controls.
Practical takeaway: For every internet-facing and administrative authentication path, require three things:
Until those exist, “MFA enabled” is a statement of intent, and the board should treat it that way.
The implementation
Implements the designed security (migrate, deploy, integrate) through to go-live, and proves that it works.
Explore Trusted IntegrationProof: French public financial institution
Programme management and integration of a public financial institution's public key infrastructure migration: certificates of 140 applications migrated with no service interruption, on schedule.
140 applications whose certificates were migrated with no service interruption
Persistent Windows device identifiers are becoming a critical cyber governance issue, reshaping how organizations manage identity, compliance, tracking, and risk across modern enterprise environments.
FortiBleed highlights how firewalls and VPN gateways have become critical identity risk targets, exposing why security teams must rethink access, trust, and device hardening.
A surge of 24 billion exposed credentials is forcing executives to rethink identity security, governance, and the growing business risks tied to compromised access.
Tell us about your context: an expert will get back to you.
or write directly to trust@blooo.io
Your e-mail is sent from your own mail client: blooo.io stores nothing. We only use your details to reply to you. Privacy policy.