CVE-2026-45274 in Talebook
Summary
by MITRE • 08/19/2026
MyBooks is anebook management web server also known as Talebook. In 3.41.2 and earlier, the SignUp.post handler for POST /api/user/sign_up in webserver/handlers/user.py does not enforce the ALLOW_REGISTER configuration flag, even though the frontend hides registration controls when the flag is false. An unauthenticated remote attacker can call the endpoint directly and create a valid account on an instance whose administrator disabled public registration. The process_auth_header function in webserver/handlers/base.py also does not verify the account's active flag, so the newly created and unactivated account can authenticate immediately and access user-level API functionality. The bypass defeats the intended account-creation policy and can supply the low-privilege account required by related authorization vulnerabilities. This issue is fixed in version 3.42.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in MyBooks, also known as Talebook, represents a critical failure in access control mechanisms within versions up to 3.41.2. The application serves as an ebook management web server and relies on configuration flags to manage user registration policies. Specifically, the ALLOW_REGISTER flag is intended by administrators to disable public self-registration when desired. However, the backend implementation fails to enforce this policy at the API level. While the frontend interface correctly hides the sign-up controls based on this setting, creating a false sense of security for users and administrators who rely solely on UI visibility, the underlying RESTful endpoint POST /api/user/sign_up remains accessible without checking the ALLOW_REGISTER configuration variable. This architectural disconnect between presentation logic and business logic allows an unauthenticated remote attacker to bypass administrative restrictions by directly invoking the API endpoint with valid registration parameters.
The technical flaw extends beyond mere account creation due to a secondary deficiency in the authentication handling process. The function responsible for processing authorization headers, located in webserver/handlers/base.py, fails to verify the active status of user accounts during the login validation phase. Typically, systems that disable public registration require manual activation by an administrator before new users can access resources. In this vulnerable implementation, a newly created account is considered valid and authenticated immediately upon creation, regardless of its inactive state in the database. This allows the attacker to not only create an unauthorized account but also to log in instantly using those credentials. The combination of these two flaws effectively nullifies the intended security boundary established by disabling public registration, granting immediate low-privilege access to the application's user-level API functionality.
From a threat modeling perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-601 URL Redirection to Untrusted Destination if combined with other flaws, though primarily it is an authorization bypass. In terms of MITRE ATT&CK mapping, the initial exploitation step corresponds to T1136 Create Account, where adversaries create accounts for persistence or lateral movement. The subsequent authentication without proper validation relates to T1078 Valid Accounts. Although the resulting account has low privileges initially, this vulnerability is particularly dangerous because it can serve as a foothold for related authorization vulnerabilities within the application. By obtaining any valid user-level API access, an attacker may exploit additional flaws that rely on having at least one authenticated session, potentially escalating to higher privilege levels or accessing sensitive ebook data and management features intended only for verified users.
The operational impact of this vulnerability is significant as it undermines the integrity of administrative policies regarding user onboarding. Administrators who disable public registration do so to prevent spam, maintain control over community membership, or comply with regulatory requirements restricting open access. The ability for any remote actor to bypass these controls means that the system's trust model is compromised. Attackers can populate the database with malicious accounts which may be used for further reconnaissance, abuse of resources such as storage and processing power, or as a stepping stone for more severe exploits like privilege escalation if other vulnerabilities exist in user-level endpoints. The lack of immediate notification to administrators about unauthorized account creation exacerbates the risk, allowing attackers time to establish persistence before detection.
To mitigate this vulnerability, organizations running MyBooks versions 3.41.2 and earlier must upgrade immediately to version 3.42.0 or later where these issues have been resolved. The fix ensures that the SignUp.post handler strictly enforces the ALLOW_REGISTER configuration flag on the server side, preventing account creation when public registration is disabled regardless of frontend visibility. Additionally, the authentication logic has been corrected to check the active status of accounts during the login process, ensuring that newly created but unactivated accounts cannot authenticate until manually approved by an administrator. For environments where upgrading is not immediately feasible, temporary mitigations include implementing a Web Application Firewall rule to block direct access to /api/user/sign_up when public registration should be disabled, and configuring network-level controls to restrict API endpoint exposure if possible. Regular auditing of user creation logs can also help detect any unauthorized accounts created during the window of vulnerability.