CVE-2026-129153 in SurveyKing
Summary
by MITRE • 11/13/2026
SurveyKing 1.12.0 through 1.13.2 contains an authorization bypass in the linked survey feature that fails to verify the referenced linkSurveyId belongs to the caller's own project. Authenticated attackers can point a linked option at another user's survey so that loadLinkResult and updateLinkSurveyAnswer read, rewrite, or create responses in that survey.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/13/2026
The vulnerability identified in SurveyKing versions 1.12.0 through 1.13.2 represents a critical failure in access control mechanisms within the application's linked survey functionality. This flaw allows authenticated users to bypass intended authorization checks, leading to unauthorized access and manipulation of data belonging to other users. The core issue lies in the server-side logic that handles requests related to linking surveys together. When an authenticated user attempts to link one survey to another by specifying a target survey identifier, the application fails to validate whether the specified linkedSurveyId actually belongs to a project owned or authorized for access by the requesting user. This lack of object-level authorization verification creates a direct path for attackers to interact with resources they should not be able to reach.
From a technical perspective, this vulnerability is classified as an Insecure Direct Object Reference (IDOR), which corresponds to CWE-639 in the Common Weakness Enumeration standard. The flaw occurs because the application relies solely on user-supplied input for the linkedSurveyId parameter without cross-referencing it against the current session's permissions or ownership records. Consequently, if an attacker knows or can guess a valid survey ID belonging to another user, they can manipulate this identifier in their requests. This allows them to exploit two specific endpoints: loadLinkResult and updateLinkSurveyAnswer. The former endpoint is responsible for retrieving data from the linked survey, while the latter is used to submit answers or modify responses within that survey.
The operational impact of this vulnerability is severe due to its potential for both information disclosure and data integrity compromise. By exploiting the read capability through loadLinkResult, an attacker can extract sensitive response data collected in other users' surveys. This constitutes a significant privacy breach, potentially exposing personally identifiable information or confidential business insights depending on the nature of the surveys hosted on the platform. Furthermore, the write capabilities exposed via updateLinkSurveyAnswer allow attackers to inject false responses, alter existing answers, or create new entries within another user's survey. This undermines the integrity and reliability of the data collected by SurveyKing users, potentially leading to skewed analytics, fraudulent results in competitions or polls, and a general loss of trust in the platform's security posture.
This vulnerability aligns with several tactics defined in the MITRE ATT&CK framework. The initial exploitation phase corresponds to Initial Access, where an authenticated attacker leverages existing credentials to gain entry into the system. Once inside, the unauthorized interaction with other users' resources falls under Lateral Movement or Collection, as the attacker moves laterally across different data objects within the application environment. Specifically, the ability to read and write arbitrary survey responses maps to Data Exfiltration and Data Manipulation techniques. The lack of proper authorization checks means that once an account is compromised or created by a malicious actor, they can immediately escalate their impact beyond their own workspace without needing additional privilege escalation exploits.
To mitigate this vulnerability, developers must implement strict object-level access control checks on all endpoints involved in the linked survey feature. Specifically, both loadLinkResult and updateLinkSurveyAnswer should verify that the referenced linkedSurveyId is associated with a project owned by or explicitly shared with the authenticated user making the request. This validation should occur server-side before any database queries are executed to ensure that users cannot access resources outside their authorized scope. Additionally, implementing robust input validation and using opaque identifiers rather than sequential integers can reduce the risk of IDOR attacks based on identifier guessing. Regular security audits focusing on authorization logic and automated testing for broken object level permissions are essential to prevent similar flaws in future updates.