CVE-2023-45249 is an insecure default password vulnerability in Acronis Cyber Infrastructure (ACI). CISA added it to the Known Exploited Vulnerabilities catalogue on 29 July 2024, which means attackers have used it in real attacks. Acronis Cyber Infrastructure (ACI) allows an unauthenticated user to execute commands remotely due to the use of default passwords.
What this vulnerability means for ACI
Insecure default password are dangerous because they turn first access into an assumption rather than a control. In a product like Acronis Cyber Infrastructure, that can mean a remote attacker does not need prior authentication to reach administrative functionality, which collapses the normal trust boundary around the platform.
The practical issue is not just that a password exists, but that the same password may be present across multiple deployments if it is never changed during installation or onboarding. That creates a repeatable entry path for opportunistic scanning, scripted exploitation, and follow-on abuse once an exposed instance is found.
How organisations should assess exposure
Exposure review starts with asset inventory, because teams need to know where ACI is deployed, who owns it, and whether it is reachable from the internet or other untrusted networks. A system may be vulnerable even if it sits behind a firewall when management interfaces, support portals, or adjacent services are exposed more broadly than intended.
Vendor advisory review matters because the authoritative version and remediation details belong with the product vendor and the CISA Known Exploited Vulnerabilities Catalog, not in a glossary entry. For CVE records and canonical vulnerability metadata, the CVE Program and the NIST National Vulnerability Database are the right places to verify identifiers, descriptions, and related references.
Remediation and compensating controls
The primary fix is to remove the default password condition entirely, then confirm that every installation uses unique, non-default credentials. Where immediate remediation is not possible, organisations should restrict management access to trusted administrative networks, remove unnecessary exposure paths, and treat any publicly reachable instance as high priority until it is confirmed secure.
Hardened deployment practice matters here because a default credential flaw is often a lifecycle failure, not only a software defect. A deployment that depends on human memory or informal handoff to change initial credentials is fragile, especially when multiple operators, support teams, or automation paths touch the same environment.
Detection and post-compromise review
Because exploitation can begin with unauthenticated command execution, defenders should review authentication logs, administrative actions, command history, and any configuration changes made after the exposure window. If the platform was reachable during the vulnerable period, assume an attacker may have used the access path to plant persistence, modify accounts, or stage later movement.
Post-incident review should also include identity and secret hygiene. Where command execution or admin-level access occurred, rotate any credentials, API keys, tokens, certificates, or service account material that could have been exposed through the affected system or adjacent management plane, and check for unexpected changes in trust relationships or scheduled tasks.
Risk and Threat Considerations
Default-password weaknesses are attractive to attackers because they are cheap to scan for, easy to automate, and often present on appliances or infrastructure products that sit near sensitive data and administrative control planes. Once one of these systems is reachable, the compromise can become a launch point for broader intrusion, data theft, or operational disruption.
Failure mechanism: The attacker uses the known default credential to gain access without needing a password guess, phishing step, or prior foothold, then executes commands through the exposed interface.
Impact: The resulting access can enable configuration tampering, credential theft, persistence, lateral movement, and in some environments service disruption or data exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Default passwords are an authenticator lifecycle failure. |
| AC-2 — Account Management | Administrative access created by default passwords depends on account governance. | |
| CM-6 — Configuration Settings | Default passwords are a deployment configuration weakness on exposed infrastructure. | |
| Recommendation — Replace default credentials and manage authenticator changes, rotation, and revocation consistently. Review privileged accounts and remove any shared or default access paths from production systems. Enforce secure configuration baselines that forbid shipped defaults on externally reachable systems. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and credential governance directly addresses default-password exposure. |
| CIS-12 — Network Infrastructure Management | Exposure depends on whether the vulnerable management surface is reachable. | |
| Recommendation — Inventory administrative accounts and eliminate default or shared credentials from deployed systems. Restrict management-plane exposure and allow access only from approved administrative paths. | ||
Practitioner Guidance
Why practitioners should care: This is not a theoretical hardening issue, it is an exploitable initial-access condition. For internet-facing or operationally sensitive infrastructure, a single unchanged default password can outweigh many other control investments because it bypasses normal authentication entirely.
What to watch for: Treat any system that shipped with a shared or well-known default credential as needing explicit verification, not assumed remediation. If you cannot prove that the password was changed and the service is no longer exposed, you should treat the instance as still at risk.
Related resources from NHI Mgmt Group
- How should teams govern a self-hosted password vault in cloud infrastructure?
- What breaks when cyber and physical access are governed separately in critical infrastructure?
- Who should own remediation when a CVE affects identity infrastructure?
- Who is accountable when cyber incident reporting timelines tighten for critical infrastructure and federal programmes?