CVE-2019-6693 is an use of hard-coded credentials vulnerability in Fortinet FortiOS. CISA added it to the Known Exploited Vulnerabilities catalogue on 25 June 2025, which means attackers have used it in real attacks. Organisations running the affected product should apply the vendor fix or mitigation as a priority.
Why hard-coded credentials are dangerous in FortiOS
Hard-coded credentials are dangerous because they embed an authentication secret directly into the product rather than managing it as a changeable, revocable secret. Once discovered, the same credential can be reused at scale, and a device that still trusts it may be exposed long after the original disclosure path is closed.
In network appliances, that pattern is especially risky because the credential can sit inside an operational control plane that administrators assume is protected by normal login boundaries. When the secret is fixed in code, the security of the product depends on obscurity, which is fragile under reverse engineering, firmware extraction, or reuse across deployments.
How organisations should assess exposure
Exposure starts with knowing whether FortiOS is deployed anywhere in the environment, including branch devices, perimeter gateways, lab systems, and forgotten appliances. Organisations should verify inventory, check whether the product is internet reachable, and compare deployed versions against the vendor advisory and the official vulnerability record rather than relying on assumptions about fleet standardisation.
For any appliance that is externally exposed, the practical question is not only whether it is installed, but whether it is reachable on management interfaces or other attackable services. Internet-facing security appliances deserve faster triage because exploitation often happens before normal maintenance windows, especially when a flaw is already in the CISA KEV catalogue.
Remediation and compensating controls
The primary response is to apply the vendor fix or mitigation as soon as possible, because hard-coded credentials are not a configuration preference that can be safely tuned away. If patching must wait, reduce exposure by restricting management access, segmenting the device, and removing any unnecessary paths that would let an attacker reach the vulnerable function.
Where appliances support emergency containment, treat credential rotation, administrative access review, and temporary control tightening as part of the response, not as optional hygiene. Guidance on rotating and revoking exposed secrets is still useful even when the flaw is inside a product, and the Secret Sprawl Challenge captures why hard-coded material becomes difficult to govern once it is embedded in systems.
Detection and post-exploitation review
Because exploitation can be silent, defenders should review logs for abnormal authentication attempts, unexpected admin sessions, configuration changes, and lateral movement from the appliance into adjacent systems. If the vulnerable device was exposed to the internet or used in a sensitive management role, assume the credential may have been discovered and used outside normal operational patterns.
After patching, review whether any accounts, tokens, API keys, certificates, or adjacent administrative credentials were touched by the same compromise path. The key issue is not only whether the appliance is now fixed, but whether the attacker used it as an entry point into other trust relationships that still need to be reset or monitored.
Risk and Threat Considerations
Hard-coded credentials create a durable abuse path because one recovered secret can bypass the normal authentication boundary for every affected deployment. That makes the vulnerability attractive for opportunistic scanning, repeat exploitation, and follow-on access to privileged management functions.
Failure mechanism: Attackers extract or reuse the embedded credential, authenticate successfully, and then pivot from device access into broader network or management compromise.
Impact: Exposure can include administrative takeover, configuration tampering, service disruption, and a downstream trust break that affects other systems managed through the appliance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Hard-coded credentials are embedded secrets that can be recovered and reused. |
| NHI-07 — Long-Lived Secrets | Fixed credentials create durable access that resists normal revocation and rotation. | |
| Recommendation — Scan firmware and configs for embedded secrets, then remove and rotate any exposed credentials. Replace fixed secrets with short-lived credentials and enforce rotation and revocation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Managing credentials lifecycle is central when a product uses hard-coded authentication material. |
| IA-9 — Service Authentication | Appliance and service-side authentication material falls under non-user authenticator controls. | |
| Recommendation — Enforce credential issuance, rotation, revocation, and storage controls for all authenticators. Use service authenticator controls to prevent embedded secrets from enabling unauthorized access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and credential governance is directly implicated when embedded credentials can be reused. |
| Recommendation — Inventory and control privileged accounts, then remove or replace any embedded credentials. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Hard-coded credentials fit the credential exposure pattern attackers exploit for access. |
| Recommendation — Hunt for exposed credentials and remove weak secret storage paths from the environment. | ||
| OWASP ASVS | V6 — Authentication | The flaw is an authentication design failure in how credentials are handled by the product. |
| Recommendation — Verify authentication design avoids embedded secrets and supports secure credential lifecycle management. | ||
Practitioner Guidance
What to watch for: Treat any hard-coded credential finding as a governance failure, not just a patching issue. The product owner should confirm whether the secret can be removed, rotated, or contained operationally, and should verify whether similar patterns exist in other appliances or embedded tools.
Practitioner takeaway: If a security appliance relies on an embedded secret, assume compromise potential persists until the device is updated and the surrounding access paths are reviewed.
Related resources from NHI Mgmt Group
- CVE-2020-8657 (EyesOfNetwork Use of Hard-Coded Credentials)
- CVE-2026-22769 (Dell RecoverPoint for Virtual Machines (RP4VMs) Use of Hard-coded Credentials)
- What happens when DevOps teams use hard-coded or long-lived credentials instead of just-in-time access?
- CVE-2026-20316 (Cisco Secure Firewall Management Center Use of Hard-coded Password)
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org