CVE-2026-111388 in Frappe
Summary
by MITRE • 10/16/2026
Frappe Framework before 15.120.0 and 16.x before 16.33.0 does not enforce the per-user restrict_ip allowlist for non-session authentication methods, including API key, OAuth, and header-based authentication. Attackers holding valid credentials of these types can authenticate from IP addresses outside the allowlist, defeating the configured network-based access restrictions.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/16/2026
The Frappe Framework, a popular open-source full-stack web framework used to build business applications such as ERPNext, contains a significant security flaw in its authentication subsystem prior to versions 15.120.0 and 16.33.0. This vulnerability stems from an incomplete implementation of access control mechanisms specifically regarding IP-based restrictions. While the framework provides a feature allowing administrators to define per-user allowlists for source Internet Protocol addresses, this restriction is not uniformly applied across all authentication methods. The flaw lies in the fact that while session-based logins correctly enforce these network-based policies, other programmatic and API-driven authentication vectors bypass them entirely. This inconsistency creates a critical gap where security controls configured at one layer are effectively nullified by another, undermining the principle of defense in depth.
The technical root cause involves how different authentication handlers process user credentials against the stored IP allowlist configuration. When users authenticate using standard web sessions, typically via username and password through a browser interface, the framework correctly validates the source IP address against the configured restrictions. However, for non-session authentication methods such as API key validation, OAuth token usage, or header-based custom authentications, this validation step is omitted. Consequently, any attacker possessing valid credentials obtained from these alternative vectors can initiate requests and access protected resources regardless of their actual network location. This behavior indicates a failure in the central authorization logic to consistently apply security policies across all entry points into the application system.
From an operational impact perspective, this vulnerability severely compromises the effectiveness of network-based segmentation strategies intended to limit exposure to sensitive data or administrative functions. Organizations often rely on IP allowlisting as a primary control for restricting access to critical business applications from untrusted networks or public internet spaces. By allowing authentication from any IP address when using API keys or OAuth tokens, attackers who have compromised these credentials can operate freely without being blocked by firewall rules or network security groups designed to mitigate such threats. This is particularly dangerous in scenarios where API keys are stored in client-side code, mobile applications, or third-party integrations that may be accessed from various uncontrolled environments, thereby exposing the backend systems to unauthorized access and potential data exfiltration.
This vulnerability aligns with CWE-284, Improper Access Control, as it represents a failure to enforce intended restrictions on user actions based on their identity and context. Furthermore, in the context of the MITRE ATT&CK framework, this flaw facilitates Initial Access techniques where adversaries leverage valid credentials obtained through phishing or malware to gain entry into systems without triggering network-based alerts associated with anomalous source IPs. The ability to bypass IP restrictions using alternative authentication methods allows attackers to maintain persistence and move laterally within a network environment under the guise of legitimate activity, as their requests appear technically compliant with application-level security policies despite originating from unauthorized locations.
To mitigate this risk, organizations running affected versions of Frappe must upgrade immediately to version 15.120.0 or 16.33.0 and later, where the authentication logic has been corrected to enforce IP allowlists consistently across all supported methods including API keys, OAuth, and header-based authentications. Until an upgrade is feasible, administrators should implement compensating controls such as strict network-level firewall rules that restrict access to the Frappe application servers from only known trusted subnets, effectively enforcing the intended restriction at the infrastructure layer rather than relying solely on the application framework. Additionally, reviewing API key usage and ensuring they are not embedded in publicly accessible client-side code can reduce the attack surface available for exploitation of this specific flaw.