CVE-2026-100501 in Flame
Summary
by MITRE • 09/26/2026
Flame through 2.4.0 contains an improper restriction of excessive authentication attempts vulnerability in the POST /api/auth login endpoint that allows unauthenticated attackers to brute-force the admin password. Attackers can submit unlimited password guesses without rate limiting, attempt counters, lockouts, or delays to gain full administrator access and modify application configuration.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Flame versions prior to 2.4.0 represents a critical failure in authentication security controls, specifically categorized under CWE-307 as Improper Restriction of Excessive Authentication Attempts. This flaw resides within the POST /api/auth login endpoint, which serves as the primary gateway for user identity verification and session establishment. The core technical deficiency is the absence of any mechanism to limit or throttle the number of authentication requests originating from a single source IP address or user account over a defined time window. In secure systems, this control is typically implemented through rate limiting algorithms, exponential backoff strategies, account lockout policies after a threshold of failed attempts, or CAPTCHA challenges designed to distinguish human users from automated scripts. The lack of these safeguards means that the authentication endpoint processes login requests with no regard for volume or frequency, effectively removing any temporal barrier between successive password guesses.
From an operational perspective, this architectural oversight allows unauthenticated attackers to execute brute-force attacks against administrative accounts with near-zero friction and high probability of success. By leveraging automated tools such as Hydra, Burp Suite, or custom Python scripts, adversaries can submit thousands or even millions of credential combinations per minute without triggering any defensive responses from the application server. The absence of attempt counters means that the system does not track how many times a specific username has been used in failed login attempts, while the lack of lockouts ensures that accounts remain active and accessible regardless of prior failures. Similarly, the missing delays or rate limits prevent the degradation of service performance that might otherwise alert administrators to an ongoing attack or slow down automated guessing tools enough to render them impractical for real-time exploitation.
The impact of this vulnerability is severe, as it directly compromises the confidentiality, integrity, and availability of the application by facilitating unauthorized administrative access. Once an attacker successfully guesses a valid administrator password through brute force, they gain full control over the system configuration. This level of access allows for extensive modifications to application settings, potentially including the creation of new privileged accounts, alteration of security policies, exfiltration of sensitive data stored within the database, or installation of persistent backdoors such as web shells. The ability to modify application configuration further exacerbates the risk, enabling attackers to disable logging mechanisms, weaken other security controls, or redirect traffic for malicious purposes. This scenario aligns with MITRE ATT&CK techniques T1110 (Brute Force) and potentially T1078 (Valid Accounts), illustrating how a single misconfiguration can lead to complete system compromise.
To mitigate this vulnerability, immediate remediation steps must focus on implementing robust authentication hardening measures at both the application layer and infrastructure level. Developers should integrate rate limiting middleware that restricts the number of login attempts per IP address or user identity within a specific timeframe, such as capping requests at five to ten attempts per minute before introducing delays or temporary blocks. Implementing account lockout policies is also essential, where an account is temporarily disabled after a set number of consecutive failed logins, requiring administrative intervention or time-based unlocking to restore access. Additionally, deploying multi-factor authentication adds a critical second layer of defense that renders brute-forcing passwords alone insufficient for gaining entry. On the infrastructure side, Web Application Firewalls can be configured to detect and block abnormal traffic patterns associated with automated login attempts, providing an additional shield against distributed brute-force campaigns until the application code is patched in version 2.4.0 or later.