CVE-2026-97685 in LimeSurvey
Summary
by MITRE • 09/29/2026
An authenticated LimeSurvey Community Edition 7.3.0 user allowed to create surveys can use their own survey as an authorized context while supplying question or answer identifiers belonging to another user's survey. The REST survey-patching endpoint checks the attacker's permission against the survey ID in the request URL, but the vulnerable persistence operations resolve the target object independently by its global qid or aid and never verify that it belongs to that authorized survey.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability described represents a classic instance of an insecure direct object reference combined with insufficient authorization checks within the LimeSurvey Community Edition version 7.3.0 application logic. This flaw specifically affects authenticated users who possess the permission to create surveys, allowing them to manipulate the REST API endpoint responsible for patching survey configurations. The core technical deficiency lies in a mismatch between how access control is enforced and how data persistence operations resolve target objects. When an attacker initiates a request to modify a survey via the REST api/v2/survey/{surveyid} endpoint, the application correctly validates that the authenticated user has permission to edit the specific survey identified by the ID provided in the URL path. This initial check creates a false sense of security for both the developer and the system administrator, as it appears that proper authorization boundaries are being respected at the entry point of the request handling process.
However, the vulnerability emerges during the subsequent persistence phase where the application attempts to save changes to question or answer identifiers within the survey structure. Instead of verifying that these specific identifiers belong to the authorized survey context established by the URL parameter, the backend logic resolves the target database records independently using their global unique identifiers for questions (qid) and answers (aid). This architectural oversight means that if an attacker can guess or enumerate qid or aid values belonging to another user's private survey, they can supply these external identifiers in the request body. The system will then apply the patching operations directly to those foreign records without performing any cross-reference check against the authorized survey ID from the URL. This effectively bypasses the intended isolation between different users' data sets, as the authorization logic is decoupled from the actual data modification logic.
From an operational impact perspective, this vulnerability allows for unauthorized modification of other users' surveys and their constituent questions or answers. An attacker with basic authenticated access can alter survey structures, potentially changing question types, default values, validation rules, or answer options belonging to victims. This compromises the integrity of sensitive survey data that may contain personal information or proprietary research findings depending on the organization's use case. Furthermore, if certain question types allow for complex logic or integration points, this manipulation could lead to broader security implications such as cross-site scripting through injected malicious content in question text fields or answer options, although the primary impact here is unauthorized data modification and integrity violation. The ability to modify another user's survey configuration undermines trust in the platform's multi-tenancy model and can disrupt ongoing surveys if critical structural changes are applied inadvertently or maliciously by an attacker seeking to cause denial of service through logical disruption.
This flaw aligns with CWE-284, which describes Improper Access Control where a security-critical resource is not accessed by authorized users, specifically manifesting here as insecure direct object references leading to privilege escalation in the context of data modification. It also relates to CWE-601, URL Redirection to Untrusted Destination, although more accurately it fits CWE-862, Missing Authorization, because the authorization check exists but is applied incorrectly relative to the actual resource being modified. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1530 Data from Information Repositories, as the attacker accesses and modifies data stored in a repository outside their authorized scope, and potentially T1498 Network Denial of Service if the modifications disrupt survey functionality for other users. The attack vector is remote with low complexity provided that the target qid or aid values are discoverable, which may be possible through enumeration attacks or information leakage from public surveys or API responses.
To mitigate this vulnerability, developers must enforce strict ownership verification at every stage of data manipulation within the application logic. Specifically, when processing PATCH requests for survey components such as questions and answers, the backend service should not only validate that the user has permission to edit the survey ID found in the URL but also explicitly verify that the qid or aid being modified belongs exclusively to that specific survey ID. This can be achieved by querying the database with a condition that ensures both the identifier matches and the parent survey relationship is valid before executing any write operations. Additionally, implementing comprehensive logging for such cross-context modifications would assist in detecting potential exploitation attempts during incident response activities. Upgrading to a patched version of LimeSurvey where this logic error has been corrected is the primary remediation strategy, ensuring that all persistence layers respect the contextual boundaries established by the initial authorization checks.