orion-visor CVE-2026-90510

The hard-coded AES key is embedded in orion-visor's publicly available open-source source code, so key material is known to any attacker who reads the GitHub repository - no special access to the running application is needed to recover the key itself. Actual credential decryption further requires obtaining the encrypted ciphertext from orion-visor's data store; this is the primary limiting factor, as it demands a separate read vector such as database access via SQL injection, an exposed or leaked backup, a misconfigured storage endpoint, or an authenticated application feature that surfaces encrypted values. No special orion-visor configuration is required - the vulnerability is present in all standard deployments up to 2.5.7 by design. Exploitation is constrained by the attacker's ability to reach the backing data store and is not a direct unauthenticated remote code execution against the application network interface.

The CVSS 4.0 score of 6.9 with PR:N appears overstated on the attack-vector axis - directly exploiting the decryption capability still requires obtaining ciphertext from the application's data store, which typically implies some form of secondary access (database read, backup exposure, or an authenticated application export). However, the confidentiality impact is severely underweighted: SSH private keys are not ordinary secrets; possession of them grants shell access to every server managed by that orion-visor instance, cascading the breach far beyond the application itself. Even a mid-sized municipal IT team in sanok relying on orion-visor to centrally manage a server fleet should treat this as urgent because the lateral-movement radius is bounded only by the scope of the managed infrastructure. Compounding urgency: the project is open-source, the hard-coded key is trivially extracted without any tooling, and a public proof-of-concept has already been disclosed. No CISA KEV listing exists and no patch is available, creating a window of indefinite exposure with no vendor-provided resolution in sight.

An attacker clones the public orion-visor GitHub repository and extracts the hard-coded AES key from HostKeyServiceImpl.java in under a minute. After gaining read access to the orion-visor database - through a separate SQL injection, an exposed backup archive, or a misconfigured cloud storage bucket - the attacker runs the published proof-of-concept to decrypt all stored SSH private keys and host passwords in bulk, then uses those credentials to authenticate directly to every server the orion-visor instance manages.