CVE-2026-111849 in WpTravelly Plugin
Summary
by MITRE • 10/22/2026
Missing Authorization vulnerability in Magepeople inc. WpTravelly tour-booking-manager allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WpTravelly: from n/a through 2.3.5.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The identified security flaw represents a critical failure in access control mechanisms within the Magepeople Inc. WP Travelly plugin, specifically affecting versions ranging from initial releases up to version 2.3.5. This vulnerability is classified as an insecure direct object reference or broken access control issue, where the application fails to properly verify whether the authenticated user has sufficient privileges to perform specific actions on tour-booking resources. In a secure implementation, every request that modifies data or accesses sensitive information must be validated against the current user's role and permissions. However, in this instance, the software relies on client-side controls or lacks server-side validation entirely for certain administrative functions, allowing any authenticated user with even minimal privileges to escalate their rights effectively bypassing intended security boundaries.
From a technical perspective, the root cause lies in the absence of robust authorization checks when processing requests related to tour management and booking configurations. An attacker who has obtained valid credentials for a low-privilege account, such as a subscriber or contributor role within WordPress, can manipulate HTTP parameters to execute administrative tasks intended only for administrators. This typically involves modifying request payloads to target internal identifiers or function endpoints that do not verify the caller's identity against their assigned role in the database. The vulnerability exploits the assumption that if a user is logged into the system, they should have unrestricted access to all features associated with the plugin, which contradicts the principle of least privilege essential for secure software architecture.
The operational impact of this misconfiguration is severe, as it compromises the integrity and confidentiality of the tour booking data managed by the platform. An adversary can exploit this flaw to create, modify, or delete tours without authorization, potentially disrupting business operations and damaging customer trust. Furthermore, because WordPress plugins often have broad database access capabilities, an attacker could leverage these elevated privileges to inject malicious code, alter pricing structures arbitrarily, or exfiltrate sensitive customer information such as names, contact details, and payment history stored in the associated booking records. This level of unauthorized control effectively grants full administrative access to any authenticated user, turning a standard web application into a vehicle for data theft and service disruption.
This vulnerability aligns closely with CWE-269, which describes Improper Privilege Management, where software does not properly assign privileges or roles to actors based on their intended purpose. It also maps directly to the MITRE ATT&CK framework under T1078, specifically Valid Accounts, as it involves using legitimate credentials to gain unauthorized access to resources. Additionally, aspects of CWE-639, Authorization Bypass Through User-Controlled Key, may apply if the exploit relies on manipulating unique identifiers associated with tour objects or booking records. Understanding these classifications helps in contextualizing the severity and ensuring that remediation efforts address both the immediate code flaw and broader architectural weaknesses in how user roles are enforced across the application layer.
To mitigate this risk, it is imperative to upgrade WP Travelly to a version later than 2.3.5 where the vendor has presumably implemented proper server-side authorization checks for all administrative endpoints. Until an update is applied or if no patch exists, administrators should restrict access to the WordPress dashboard by limiting user roles and employing web application firewalls that can detect anomalous request patterns indicative of privilege escalation attempts. Regular security audits focusing on input validation and role-based access control logic are recommended to prevent similar issues in other plugins. Additionally, enforcing strong password policies and multi-factor authentication reduces the likelihood of credential compromise, thereby lowering the attack surface available for exploiting this authorization bypass mechanism.