CVE-2026-111682 in EFAK
Summary
by MITRE • 10/16/2026
EFAK 5.0.0 through 5.1.0 contains a missing authorization vulnerability that allows authenticated low-privilege users to read LLM provider API keys through the /api/model-config REST API. Attackers with any ROLE_USER account can query /api/model-config/page or /api/model-config/{id} to retrieve unmasked keys, enabling provider account access and incurred costs.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in EFAK versions 5.0.0 through 5.1.0 represents a critical failure in access control mechanisms within the application's REST API layer. Specifically, this is an instance of broken object level authorization or insecure direct object reference where the server fails to verify that the authenticated user has sufficient privileges to request sensitive configuration data. While the system correctly enforces authentication requiring users to possess at least a ROLE_USER account, it neglects to enforce proper authorization checks for specific endpoints responsible for managing Large Language Model provider configurations. This architectural flaw allows any authenticated user with minimal permissions to bypass intended security boundaries and access resources that should be restricted to administrative roles or higher-privilege accounts.
The technical core of this vulnerability lies in the handling of requests directed at the /api/model-config REST API, particularly when querying for specific model configuration identifiers via endpoints such as /api/model-config/page or /api/model-config/{id}. Under normal security expectations, these endpoints should validate that the requesting user holds an administrative role before returning data. However, due to the missing authorization logic, the server processes these requests without verifying privilege levels and proceeds to serialize and return the full configuration payload. This payload includes unmasked API keys for various LLM providers such as OpenAI, Anthropic, or other integrated services. The absence of masking or redaction in the response further exacerbates the severity, as it provides attackers with plaintext credentials that can be immediately utilized without additional obfuscation bypass techniques.
The operational impact of this vulnerability is severe and multifaceted. By obtaining valid API keys for LLM providers, an attacker gains unauthorized access to external AI services associated with those accounts. This leads directly to financial liability, as the attacker can consume computational resources billed to the victim organization's account. Beyond direct monetary loss, there are significant risks related to data privacy and intellectual property theft if the compromised provider accounts have access to sensitive datasets or proprietary models. Furthermore, an attacker could potentially use these credentials to perform malicious actions under the guise of legitimate users, such as generating harmful content, conducting prompt injection attacks against other systems connected via those APIs, or exfiltrating training data that was processed through the compromised service endpoints.
This vulnerability aligns with CWE-269, which describes Improper Privilege Control, and more specifically CWE-862, Missing Authorization, where a user is able to access resources they are not authorized for. In terms of offensive security frameworks, this behavior maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as the attacker leverages legitimate credentials but exploits a lack of privilege separation to achieve unauthorized outcomes. It also relates to T1530, Data from Cloud Storage Object, if the API keys are used to access stored data within the provider's ecosystem. The exploitation path is straightforward and does not require complex payload construction or side-channel analysis, making it highly exploitable by automated tools or low-skilled adversaries who have obtained valid user credentials through phishing or credential stuffing attacks.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. For the affected versions 5.0.0 through 5.1.0, applying the vendor-provided patch is the primary recommendation to restore proper authorization checks on the model configuration endpoints. In environments where patching is not immediately feasible, network-level controls such as Web Application Firewalls can be configured to restrict access to /api/model-config paths exclusively from administrative IP ranges or internal service accounts with elevated privileges. Additionally, implementing strict role-based access control validation at the API gateway level ensures that requests lacking appropriate authorization headers are rejected before reaching the application logic.
Long-term remediation should involve a comprehensive review of all REST endpoints to ensure consistent enforcement of authorization policies across the entire application surface area. Developers must adopt a principle of least privilege by default, ensuring that sensitive data such as API keys is never returned in standard responses unless explicitly required and only for authorized roles. Implementing automated security testing within the CI/CD pipeline can help detect similar missing authorization flaws early in development. Regular penetration testing focusing on horizontal and vertical privilege escalation scenarios will further strengthen the application's resilience against access control bypasses, ensuring that authenticated users cannot escalate their privileges to access administrative functions or sensitive configuration data.