How SSH Servers Get Tricked Into Skipping Authentication

SSH is the protocol most administrators trust without a second thought. It encrypts the session, it authenticates with keys, and it has decades of scrutiny behind it. So when a vendor ships an "SSH authentication bypassAuthentication Bypass📖A security vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. that allows an attacker to circumvent the login verification process and gain unauthorized access to a system without providing valid credentials.," it is worth understanding what actually broke, because the failure is almost never in the cryptography. It is in the state machine and the plumbing around it. The MikroTik RouterOS flaws disclosed in September 2026, which attackers chained into full device takeover, are a clean set of examples. This article explains the three ways an SSH server gets tricked into skipping authentication: doing things in the wrong order, verifying a signature incompletely, and mishandling the data that surrounds a login.

The rule that everything depends on

The SSH protocol is layered. A transport layer sets up encryptionEncryption🛡️The process of converting data into a coded format that can only be read with the correct decryption key. and host-key verification. On top of it, the client asks to start a service by name. Two services matterMatter🏠A new universal smart home standard backed by Apple, Google, and Amazon for cross-platform compatibility. here: `ssh-userauth`, which proves who you are, and `ssh-connection`, which opens the channels you use to run commands, forward ports and move files. The entire security model rests on ordering. The connection service must not start until authentication has succeeded. RFC 4252, the SSH authentication protocol, is explicit that the server starts the requested service only after it has sent the success message for authentication.

If a server ever reaches the connection phase without having completed authentication, no amount of strong cryptography helps. The attacker is already inside the part of the protocol that runs commands. Every authentication-bypass bug is, at bottom, a way to reach that phase early.

Failure one: skipping authentication with a rekey

SSH allows either side to renegotiate the session keys at any time, a feature called key re-exchange, or rekey. It exists so long-lived sessions can refresh their encryption without disconnecting. RFC 4253 says either party may start a rekey by sending a key-exchange-init message, and that both sides must keep handling in-flight traffic while it happens. Rekey is a normal, expected event.

The problem is that rekey cuts across the neat layering. It is a transport-level operation, but it can be requested at a moment when the state machine is tracking something else, such as whether the user has authenticated yet. If the code that resumes after a rekey assumes authentication has been dealt with, an attacker can request a rekey before authenticating and land in a state where the server is willing to open a session channel. That is the shape of CVE-2026-67279 in RouterOS: after a client-requested rekey the server entered the connection protocol even though user authentication was never attempted, letting an unauthenticated client open a channel and touch the device's file namespace. The bug is not in the key exchange itself. It is in an assumption about what must have already happened by the time the key exchange finishes.

Failure two: verifying only part of a signature

Public-key authentication feels bulletproof: the client signs a challenge with a private key, the server checks the signature against the stored public key, and only the holder of the private key can produce a valid signature. RFC 4252 requires the server to check that the supplied key is acceptable and that the signature is correct. The catch is in the word "correct," which is doing a lot of work.

An RSA public key is two numbers: a modulus and an exponent. A correct check compares both against the authorized key and then validates the signature math against them. RouterOS compared the key type and the modulus but omitted the exponent. Because the exponent is a free parameter the attacker controls, they could present a key with the same authorized modulus but a trivial exponent of one, for which forging a valid-looking signature is easy. The server saw a matching modulus, accepted the forged signature, and opened a command channel as the target user. This is CVE-2026-67276, and it is a partial-comparison bug: verifying most of a credential is the same as verifying none of it, because an attacker only needs the part you skipped.

A close cousin appears in the same disclosure on the TLS side. CVE-2026-67278 exists because RouterOS accepted malformed PKCS#1 v1.5 signatures and trusted a root certificate with exponent three, so an attacker could forge a trusted intermediate and impersonate TLS servers. Same root cause, different protocol: a signature check that stops short of checking everything.

Failure three: trusting the shape of a username

The third failure is the least glamorous and the most common in the wild. Authentication data is not just a password or a key; it is a bundle of strings, including the username, that the server passes down into other code. If any of that code treats a string as more than opaque data, an attacker can smuggle meaning into it.

RouterOS mishandled usernames that began with a prohibited character. A username starting with a dash looks, to a program that builds command arguments, like a command-line option rather than a name. By crafting a username, an attacker could reach into the login helper and overwrite the internal policy mask that decides what a session is allowed to do, escalating to full administrative rights. That is CVE-2026-86060, an argument-injection bug, and it is why the RouterOS attack logs show a login attempt for the literal user `-2`. Combined with the auth-bypass flaw, it took attackers from an unauthenticated connection to complete control, the chain CERT Polska named MikroTrick in the September 2026 disclosure that put these bugs under active exploitation.

Where this leaves defenders

Notice what none of these three failures required: breaking encryption, guessing a password, or stealing a key. They abused ordering, incomplete verification, and unsanitized input, the same three categories that produce authentication bypasses across web frameworks, VPN appliances and identity providers. You cannot audit your vendors' state machines, but you can make the exposure that these bugs need expensive to reach. An SSH port open to the whole internet is the precondition for every attack above; behind a firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. or a VPN, the same bug is a patchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program. item instead of a breach. That is the practical takeaway that our companion guide on how to lock down MikroTik RouterOS management access turns into concrete settings, and it is why the MikroTik advisory led with "get SSH off the internet" before it led with "patch." When the next SSH bypass ships, and one always does, the devices that survive it will be the ones an attacker could not reach in the first place.