CVE-2024-13994 is a critical (CVSS 9.8) missing authorization flaw in Nagios XI versions before 2024R1.1.2. When the Allow Insecure Logins option is enabled, any user can create valid login credentials for other users. Upgrade to 2024R1.1.2 or later, and turn the option off if you do not need it.
What's affected
Nagios XI versions prior to 2024R1.1.2 are affected, according to the NVD record and the VulnCheck advisory. The flaw only applies when the Allow Insecure Logins option is enabled.
The fixed release is 2024R1.1.2. The Nagios changelog entry for 2024R1.1.2, dated April 23, 2024, lists a security fix for an issue where any user could modify an insecure login ticket.
The VulnCheck advisory credits the report to Kevin De Frene.
How to check if you're exposed
Nagios XI shows its version in the web interface after login, and on a default Linux install the version file can be read from the shell:
grep full /usr/local/nagiosxi/var/xiversion
If the output shows a release older than the fixed version above, treat the server as affected. If the path differs on your install, use the version shown in the Nagios XI web interface or follow the steps in the vendor changelog.
Next, check whether the option is on. Look in the Nagios XI administration settings for the Allow Insecure Logins setting. If you cannot find it, search the Nagios XI documentation for the setting name and follow the steps there.
What to do now
- Upgrade Nagios XI to 2024R1.1.2 or later. Newer releases carry later security fixes as well.
- Turn off Allow Insecure Logins unless a documented use case needs it.
- Review the user list for accounts you do not recognise, and check when each was created.
- Reset passwords for administrator accounts if any unexplained account or login appears.
- Keep the Nagios XI web interface off the public internet and limit it to management networks.
Why it matters
The class is CWE-862, missing authorization. The software lets a caller perform an action without checking that the caller is allowed to. Here the action is creating working credentials for someone else, so an ordinary user can become an administrator or take over any account.
Monitoring servers are rich targets. They hold network maps, credentials for checks and often have a path to many internal hosts. The scope depends on which account the attacker creates, and the NVD text says the result ranges from unauthorised account creation to full compromise of the web interface.
Quick check
Does this affect me if Allow Insecure Logins is off?
The advisory ties the flaw to that option being enabled. Upgrade anyway, because the same release train fixes other security issues.
Is this exploited in the wild?
The record's KEV flag is false, and the sources fetched for this post do not report exploitation.
Sources
Last reviewed: 19 October 2026.
