A hard-coded cryptographic key in dromara orion-visor allows for the unauthorized decryption of sensitive credentials, leading to a potential full compromise of managed infrastructure.

This vulnerability is caused by the use of a hard-coded AES encryption key (uQeacXV8b3isvKLK) within the application configuration, which is used to protect SSH private keys and host passwords; the issue is exploitable by any attacker who can access the database, regardless of authentication level.

The exposure of SSH private keys and host passwords provides attackers with direct, unrestricted access to all hosts managed by the orion-visor bastion, effectively bypassing all authentication, session recording, and auditing controls. Given the high CVSS score of 8.3, this represents a critical risk to organizational security, as it facilitates lateral movement and total infrastructure takeover.

Immediate Action: Ensure that the SECRET_KEY environment variable is explicitly set to a unique, strong, and randomly generated value during deployment to override the vulnerable default.

Proactive Monitoring: Review database access logs for unusual queries targeting the host_key table or attempts to export credential data.

Compensating Controls: Restrict network access to the database hosting the orion-visor data and ensure that database backups are stored in encrypted, access-controlled environments.

Public Exploit Available: Yes — a published proof-of-concept exists in the referenced research write-up.

Organizations utilizing dromara orion-visor must treat this vulnerability with extreme urgency. Because the default key is publicly known and identical across all deployments, any instance that has not had the SECRET_KEY environment variable manually overridden is currently insecure. Immediate action should be taken to rotate all stored credentials and update the configuration to use a secure, unique key.