CVE-2026-67276: RouterOS SSH RSA key-identity mismatch permits authentication with a forged key sharing an authorized modulus

CVE-2026-67276 is an SSH RSA public-key authentication bypass in MikroTik RouterOS. Current-run production-path testing demonstrated that RouterOS CHR 7.23.3 accepts an attacker-offered RSA key whose modulus equals an authorized key but whose exponent is changed from 65537 to 1. Because signature validation uses the offered exponent, a client can construct a valid PKCS#1 v1.5 encoded signature without the authorized private key. In two fresh 7.23.3 QEMU states, the forged SSH authentication opened a command channel and returned RouterOS-originated /system resource print output. The same input was rejected before command-channel creation in two fresh RouterOS CHR 7.23.4 states.

• Component: MikroTik RouterOS SSH server, RSA public-key user authentication.
• Confirmed affected target: RouterOS CHR 7.23.3.
• Vendor-fixed negative control: RouterOS CHR 7.23.4.
• Risk: Critical authentication/authorization bypass over the network. An attacker who knows a target username and that account's authorized RSA public modulus can authenticate without the corresponding private key and execute RouterOS commands at that account's existing policy level.
• Scope boundary: The controlled user belonged to RouterOS's read group. No privilege escalation and no other MikroTrick CVE was attempted or claimed.

Impact Parity

• Disclosed/claimed maximum impact: Authorization/authentication bypass (authz_bypass) with an SSH command channel at the targeted user's existing privileges.
• Reproduced impact from this run: The forged public-key request authenticated as the controlled cveuser account and executed /system resource print through a real SSH command channel in two independent vulnerable states; 7.23.4 rejected the same request twice.
• Parity: full.
• Not demonstrated: Privilege escalation, administrative-policy acquisition, compromise of another account, or any issue other than CVE-2026-67276. These are not required by the submitted claim.

Root Cause

An RSA public key is the ordered pair (n, e): modulus n and public exponent e. RouterOS 7.23.3's SSH authorized-key matching accepts an offered key based on RSA key type and modulus while omitting the exponent. Signature verification subsequently uses the complete attacker-offered key, including the attacker-selected exponent.

The reproduction provisions a normal 2048-bit RSA authorized key with exponent e=65537, deletes its private half, and retains only the public key in the attacker's directory. The forged client offers the same modulus with e=1. For RSA verification, exponent one makes signature^e mod n equal to the signature representative itself. The attacker therefore supplies the computable EMSA-PKCS1-v1_5 encoding of the SSH user-authentication data as the signature. RouterOS 7.23.3 incorrectly associates the offered key with the authorized identity and validates this forged signature; RouterOS 7.23.4 rejects both rsa-sha2-256 and ssh-rsa attempts, showing that the vendor-fixed target no longer permits this exponent substitution.

RouterOS CHR is a proprietary vendor image, so there is no public source fix commit to link. The vendor bulletin identifies 7.23.4 as containing the fix: https://mikrotik.com/supportsec/september-2026-vulnerability/. CERT Polska's technical description is at https://cert.pl/en/posts/2026/09/mikrotik-routeros-cve/.

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh from any directory. PRUVA_ROOT may identify the bundle root explicitly.
2. The script verifies pinned SHA-256 values for official RouterOS CHR 7.23.3 and 7.23.4 archives, installs QEMU only if absent, pins the forged-client source to commit 3281202c8ade8e31acf007da0c71057da83f2335, and pins Paramiko 5.0.0 and cryptography 50.0.1.
3. It creates one ordinary RSA setup key, records exponent 65537 and a hash of its modulus, provisions a fresh controlled read-group user and public key through factory/setup authentication, deletes the private key, and verifies that no private-key file remains.
4. It boots two clean copies of unmodified CHR 7.23.3 and sends the exponent-one forged request through each VM's real TCP SSH listener. Each attempt must authenticate, open an exec channel, and return target-originated version 7.23.3 output.
5. It boots two clean copies of unmodified CHR 7.23.4 and sends the identical attack. Both algorithms must be rejected before any command channel opens.
6. It writes bundle/repro/runtime_manifest.json only after all QEMU processes are stopped and hashes every finalized proof artifact. Exit status 0 means the complete vulnerable/fixed matrix passed; exit status 1 means the issue was not reproduced as required.

Evidence

• Runtime manifest: bundle/repro/runtime_manifest.json
  • entrypoint_kind="tcp_peer"
  • service_started=true, healthcheck_passed=true, target_path_reached=true
  • Vulnerable archive target digest: 646764fb0a53e9b5a056cb9cf7420eb1629031096c7268c99fb9216c07f8e98c
  • Fixed archive digest (manifest note and identity log): 0d32a8da0950dee71e751281c39063f2bebee4b542291aedecc9dbfbe5d60c9d
• Target identity: bundle/repro/target_identity.log
  • Raw image SHA-256: 7.23.3 c21bf7d9e21fd8e0595875ddc06bd00e6e414a78b092bdaa245b0fe81f82614d; 7.23.4 e5c35c04210438db6825341fa6477c68dfe7ae91443f358cd6e5be45e0201d6b.
  • QEMU 10.2.1 binary SHA-256: 0cd4112a8f0cb891eb7c10e8df38c9dfeec8c7389bb22db6aa425f0d6fe733dc.
• Vulnerable attempts:
  • bundle/repro/vulnerable_attempt_1_attack.log (manifest hash 4b89ba5e2f4abb1eebd4551ba3c0e8306e1a387b6ed266fec3eae76392355e7a)
  • bundle/repro/vulnerable_attempt_2_attack.log (manifest hash 769070041fabcb731c68e8b12259750a789c58ff9ae1a13bb8772793d9883fe3)
  • Both state AUTHORIZED_PRIVATE_KEY_PRESENT=false, AUTHORIZED_ORIGINAL_EXPONENT=65537, ATTACKER_OFFERED_EXPONENT=1, AUTHENTICATED as 'cveuser', and include target-originated version: 7.23.3 (stable) and platform: MikroTik output.
• Fixed negative controls:
  • bundle/repro/fixed_attempt_1_attack.log (manifest hash 0d6adc714f103587070ef2592e9ca4a193439a673679de10e94469d870216d9a)
  • bundle/repro/fixed_attempt_2_attack.log (manifest hash 774b847e3250beb0d5e50f23eba24bedf029d6abf67871dd493ec8e77091810a)
  • Both report authentication rejection for rsa-sha2-256 and ssh-rsa, then ATTACK_RESULT=rejected_before_command_channel.
• Setup/TCP evidence: bundle/repro/*_setup.log records the fresh role/version/endpoint, TCP_LISTENER_REACHED=true, controlled account creation, imported RSA-2048 key, fingerprint, and SETUP_PHASE_COMPLETE=true.
• Summary: bundle/repro/proof_summary.log records the four-attempt matrix and explicitly limits the observed impact to authz_bypass.
• Diagnostics: bundle/logs/reproduction_steps.log contains build/download/runtime diagnostics but is intentionally not manifest-bound while active.

Key vulnerable excerpt:

AUTHORIZED_PRIVATE_KEY_PRESENT=false
AUTHORIZED_ORIGINAL_EXPONENT=65537
ATTACKER_OFFERED_EXPONENT=1
[+] AUTHENTICATED as 'cveuser' via forged e=1 key (rsa-sha2-256)
--- post-auth command output ---
version: 7.23.3 (stable)
platform: MikroTik
ATTACK_RESULT=accepted_command_channel_opened

Key fixed-control excerpt:

TARGET_VERSION=7.23.4
[-] rsa-sha2-256: authentication rejected (Authentication failed.)
[-] ssh-rsa: authentication rejected (Authentication failed.)
ATTACK_RESULT=rejected_before_command_channel

Recommendations / Next Steps

• Upgrade affected 7.x long-term systems to RouterOS 7.23.4 or a later vendor-fixed release. Follow MikroTik's current channel-specific upgrade guidance for other release trains.
• Compare canonical complete RSA public-key identities during authorization, including both modulus and exponent, rather than treating the modulus alone as the identity.
• Bind signature verification to the exact authorized key that matched, not to unchecked attributes from the client-offered key.
• Add regression tests with equal moduli and unequal exponents, including canonical and non-canonical SSH mpint encodings, and require rejection before SSH_MSG_USERAUTH_SUCCESS or channel creation.
• Until systems are upgraded, restrict RouterOS SSH management access to trusted management networks and review authorized keys and authentication logs.

Additional Notes

• Idempotency: The finalized reproduction script completed successfully twice consecutively. Each invocation created two new vulnerable and two new fixed VM disk copies and independently reproduced the same result matrix.
• Real boundary: This is a production-path test of the unmodified vendor CHR images. Attacker data crossed a localhost host-forwarded TCP socket into RouterOS's real SSH server; the vulnerable parser/authentication path was not invoked directly.
• Setup separation: Factory password handling, user creation, and key import occur only in per-target setup logs. The attacker invocation receives only the controlled username and authorized public-key file; it does not receive any setup password. The authorized private key is removed before the first attacker request.
• Sanitizers/mocks: No sanitizer, mocked service, reimplemented RouterOS authentication function, or host-only marker was used. The primary oracle is RouterOS SSH authentication plus RouterOS-originated command output, paired with fixed-version rejection.