CVE-2026-90510 Overview
CVE-2026-90510 affects dromara orion-visor versions up to 2.5.7. The vulnerability resides in the HostKeyServiceImpl.encryptKey function within orion-visor-modules/orion-visor-module-asset/orion-visor-module-asset-service/src/main/java/org/dromara/visor/module/asset/service/impl/HostKeyServiceImpl.java. The flaw stems from a hard-coded cryptographic key [CWE-320] used to protect stored SSH private keys and host passwords. Any attacker with access to the encrypted material and knowledge of the shared key can decrypt sensitive credentials. The exploit has been disclosed publicly, and the project maintainers had not responded to the initial issue report at the time of disclosure.
Critical Impact
A hard-coded Advanced Encryption Standard (AES) key allows attackers to decrypt SSH private keys and host passwords stored by orion-visor, enabling lateral movement across managed hosts.
Affected Products
- dromara orion-visor versions up to and including 2.5.7
- orion-visor-module-asset-service component
- HostKeyServiceImpl class
Discovery Timeline
- 2026-09-13 - CVE-2026-90510 published to the National Vulnerability Database (NVD)
- 2026-09-14 - Last updated in the NVD database
Technical Details for CVE-2026-90510
Vulnerability Analysis
Orion-visor is a host and asset management platform that stores SSH credentials and host passwords for the systems it manages. The HostKeyServiceImpl.encryptKey function encrypts these secrets before persisting them. Because the encryption key is embedded directly in source code, it is identical across every deployment of the affected versions. Anyone who reads the public repository obtains the key and can decrypt exported ciphertext without brute forcing.
The practical result is that credential confidentiality collapses to the confidentiality of the ciphertext store alone. An attacker who reads database rows, backups, or configuration exports can recover cleartext SSH private keys and host passwords. Those credentials then enable authenticated access to every host managed by the orion-visor instance.
Root Cause
The root cause is a Use of Hard-coded Cryptographic Key weakness [CWE-320]. The encryptKey routine references a compile-time constant rather than deriving a per-installation key from a secure source such as a key management service, environment secret, or user-supplied passphrase.
Attack Vector
Exploitation is remote and requires no authentication to the affected component when the attacker already possesses the encrypted data. Typical attack paths include compromise of database backups, exposure of configuration exports, insider access to stored ciphertext, or chaining with a separate read primitive against the orion-visor data store. The attacker recovers the hard-coded key from the open source repository and decrypts credentials offline.
No synthetic exploitation code is included here. Refer to the CVE-321 Hardcoded AES Key Analysis for the disclosed technical write-up.
Stop Remote Code Execution Before It Runs
Singularity™ Endpoint detects and blocks exploit attempts at machine speed, including zero-days and novel attack techniques.
Stop Exploit AttemptsDetection Methods for CVE-2026-90510
Indicators of Compromise
- Unexpected read access, exports, or dumps against orion-visor database tables that store host key or password ciphertext.
- SSH logins to managed hosts from source addresses or times inconsistent with normal orion-visor operator activity.
- Unauthorized access to orion-visor backup archives or configuration files stored outside the application server.
Detection Strategies
- Inventory orion-visor deployments and confirm versions against 2.5.7 or earlier using package manifests or the running application banner.
- Audit source control, container images, and deployed JAR files for the hard-coded key referenced in the GitHub Issue #171 Discussion.
- Correlate authentication logs on managed hosts with orion-visor session records to identify SSH sessions that did not originate from a legitimate orion-visor task.
Monitoring Recommendations
- Enable database query auditing on the orion-visor schema and alert on bulk reads of host credential tables.
- Monitor filesystem and object storage access to orion-visor backup locations for anomalous download activity.
- Track new SSH key fingerprints or password changes across managed hosts to detect attacker-added persistence following credential decryption.
How to Mitigate CVE-2026-90510
Immediate Actions Required
- Treat every SSH private key and host password managed by an affected orion-visor instance as compromised and rotate them.
- Restrict network access to the orion-visor application and its underlying database to trusted administrative networks only.
- Secure and audit all existing backups of the orion-visor database, and re-encrypt or destroy backups that contain the vulnerable ciphertext.
Patch Information
No vendor patch is referenced in the enriched CVE data. The project was informed through an issue report but had not responded at the time of disclosure. Track the GitHub Orion Visor Repository and the VulDB CVE-2026-90510 Entry for updated release information.
Workarounds
- Rotate all stored SSH keys and host passwords, and re-import them only after a fixed release replaces the hard-coded key with a per-installation secret.
- Place orion-visor behind strict network segmentation and enforce multi-factor authentication for administrative access.
- If continued use is required before a patch, store the orion-visor database on encrypted volumes with restricted operating system access to limit ciphertext exposure.
# Example: restrict network access to orion-visor with iptables
iptables -A INPUT -p tcp --dport 9338 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 9338 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
