CVE-2019-5591 is a default configuration vulnerability in Fortinet FortiOS. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2021, which means attackers have used it in real attacks. Organisations running the affected product should apply the vendor fix or mitigation as a priority.
What this vulnerability means in practice
A default configuration flaw means the product can ship or be deployed with settings that are too permissive, exposed, or otherwise unsafe for real-world use. For a network security platform like FortiOS, that is dangerous because the configuration itself can become the access path, not just the software code.
That makes exposure assessment more than a patch check. Organisations need to know whether the vulnerable FortiOS instances exist in internet-facing locations, whether the default state was ever changed, and whether the device is acting as a trusted boundary for users, VPN access, or management traffic.
Why default configurations are dangerous
Default settings are risky because they are usually designed for convenience and first-time usability, not hardened operation. In security appliances, a weak default can amplify impact by exposing administrative surfaces, reducing segmentation, or making it easier for an attacker to turn a perimeter device into a foothold.
This is one reason CISA KEV inclusion matters: it signals that the weakness has been used in real attacks, so the issue is not theoretical. For authoritative version and patch details, readers should check the CVE Program record and the NIST National Vulnerability Database entry rather than relying on secondary summaries.
How organisations should assess exposure
Exposure review should start with asset inventory, because you cannot remediate what you have not located. The next question is whether the affected FortiOS systems are reachable from the internet, used for remote access, or embedded in a path that would let an attacker pivot deeper into the environment.
Vendor advisories and device administration records are important here because default configuration issues are often influenced by local deployment choices, not only by the base product. A device that appears “patched” may still remain risky if the unsafe configuration was never replaced or validated after deployment.
Remediation and verification after exposure
Priority should go to the vendor fix or mitigation identified for the exact product and deployment pattern. When immediate change is not possible, compensate by reducing exposure, tightening access paths, and removing any unnecessary management reachability until the hardened state is confirmed.
After remediation, verify more than software versioning. Review whether the configuration was actually corrected, whether remote management or exposed services were reduced, and whether there are signs that the appliance was already used as an entry point or persistence layer before the fix was applied.
Risk and Threat Considerations
Default configuration weaknesses are attractive to attackers because they can be exploited at scale, often before defenders notice that the appliance is exposed. On perimeter equipment, the practical danger is that a seemingly ordinary configuration choice becomes a path to control, interception, or lateral movement.
Failure mechanism: The attacker abuses the unsafe default state to gain an initial foothold, bypass expected hardening, or operate through a trusted security boundary that defenders assume is already protected.
Impact: Compromise of a FortiOS device can expose administrative access, traffic handling, and downstream systems that depend on it for segmentation or remote connectivity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Asset Inventory | Asset inventory is essential to locating exposed FortiOS instances affected by the vulnerability. |
| PR.AA-01 — Identity Management, Authentication, and Access Control | Default configuration flaws often hinge on exposed management and access paths that must be hardened. | |
| DE.CM-01 — Networks and Network Services Are Monitored to Find Potentially Adverse Events | Monitoring is needed to detect abuse of an exposed security appliance and signs of compromise. | |
| Recommendation — Inventory all FortiOS assets so you can scope exposure and prioritise remediation. Tighten access controls on FortiOS management paths and remove unsafe default access. Monitor FortiOS activity for signs of exploitation or unexpected administrative use. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Default configuration vulnerabilities are directly addressed by secure configuration controls. |
| Recommendation — Harden FortiOS configurations and eliminate unsafe defaults across deployed appliances. | ||
Practitioner Guidance
What to watch for: Treat default configurations as a live security condition, not a one-time deployment detail. If a security appliance is internet-facing, supports remote access, or anchors trust for other systems, its configuration state should be validated as carefully as its patch status.
Practitioner takeaway: For KEV-listed default configuration issues, the safest assumption is that configuration state matters as much as code state, and both must be verified before the device is treated as secure.
Related resources from NHI Mgmt Group
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