CVE-2026-100418 in Flame
Summary
by MITRE • 09/26/2026
Flame through 2.4.0 contains an information exposure vulnerability in the unauthenticated GET /api/config endpoint that returns the entire configuration object without field redaction. Attackers can retrieve the stored weather API key and internal operational settings by sending a single unauthenticated request to consume provider quota or access sensitive configuration data.
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 Flame application, specifically versions up through 2.4.0, suffers from a critical information exposure vulnerability within its RESTful API architecture. This flaw is located in the GET /api/config endpoint, which is designed to retrieve system configuration parameters for client-side rendering or administrative purposes. The core technical deficiency lies in the absence of proper access control mechanisms and data sanitization routines on this specific interface. Instead of filtering sensitive fields such as cryptographic keys, database credentials, or internal operational settings before serialization, the server returns the raw, unredacted configuration object to any requester that reaches the endpoint. This represents a classic case of insecure direct object references combined with insufficient authorization checks, allowing unauthorized actors to harvest critical infrastructure details simply by issuing an HTTP GET request without providing valid authentication tokens or session cookies.
From a technical perspective, this vulnerability aligns closely with CWE-200: Information Exposure and CWE-798: Use of Hard-coded Credentials if the API keys are statically defined in the configuration file rather than dynamically injected at runtime. The lack of field-level redaction means that every property within the JSON response payload is exposed to potential attackers. This includes not only external service credentials like weather API keys but also internal endpoints, debug flags, and potentially database connection strings or third-party integration secrets. By exploiting this misconfiguration, an attacker can perform reconnaissance with minimal effort, gaining a comprehensive map of the application's backend dependencies and security posture without needing to bypass any authentication layers first.
The operational impact of this vulnerability is significant due to its direct link to resource abuse and potential downstream compromise. The exposure of weather API keys allows malicious actors to consume the organization's allocated quota for these external services, leading to financial loss through overage charges or service denial when legitimate users require access during peak times. Furthermore, the disclosure of internal operational settings can facilitate more sophisticated attacks by revealing version numbers, feature flags that might be disabled in production but enabled elsewhere, or other configuration nuances that aid in crafting targeted exploits against known vulnerabilities associated with those specific software versions and dependencies. This level of information leakage effectively lowers the barrier for entry for subsequent attack phases such as credential stuffing, social engineering, or direct exploitation of related services if the exposed keys have broader permissions than intended.
To mitigate this vulnerability, immediate remediation steps must focus on enforcing strict access controls and implementing data sanitization protocols. The GET /api/config endpoint should be restricted to authenticated users with specific administrative roles only, ensuring that standard end-users cannot retrieve sensitive backend configurations. Additionally, developers must implement a robust serialization layer that explicitly excludes or masks sensitive fields such as API keys, passwords, tokens, and internal secrets before the configuration object is returned in the HTTP response body. It is also advisable to conduct a thorough audit of all other API endpoints for similar information disclosure flaws, ensuring that no other unauthenticated routes expose privileged data. Regular security testing using automated vulnerability scanners and manual penetration tests should be integrated into the development lifecycle to prevent such misconfigurations from reaching production environments in the future.