phpMyFAQ 3.2.10 - Unintended File Download Triggered by Embedded Frames

phpMyFAQ 3.2.10 — Unintended File Download Triggered by Embedded Frames (CVE-2024-55889)

This article examines a security issue discovered in phpMyFAQ v3.2.10 (CVE-2024-55889) where an authenticated, privileged user can craft FAQ content that causes a victim’s browser to automatically download a previously uploaded attachment when the FAQ page or the FAQ edit screen is rendered. The vulnerability affects the FAQ record editor’s handling of saved HTML content and the way attachments are served, allowing embedded frames to cause unintended downloads without explicit user interaction in some browsers.

Quick reference

Item	Value
Product	phpMyFAQ
Version	3.2.10
CVE	CVE-2024-55889
Advisory	https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-m3r7-8gw7-qwvc
Disclosure	https://geochen.medium.com/cve-2024-55889-03572ae6c35c

Summary of the issue

phpMyFAQ allowed privileged users to edit FAQ body content using an editor that saved raw HTML. If an attacker embedded a frame-like element in that content that referenced an attachment-serving URL (an attachment the attacker previously uploaded), some browsers would automatically fetch and save that attachment on page render. This results in an unintended file download on a visitor’s machine without explicit consent or interaction, creating a vector for delivering malicious files to users.

Why this is dangerous

• Automatic download: Depending on browser behavior and response headers, the attachment can be downloaded automatically on page load or edit-screen render, increasing the risk of inadvertent malware delivery.
• Privilege abuse: The attack requires only a user with privileges to upload an attachment and edit a FAQ entry — roles that may exist for many legitimate users.
• Low visibility: The embedded HTML can be stored in a FAQ and therefore served to many users repeatedly.

Technical root cause

The vulnerability rests on two interacting issues:

• Unsanitized or insufficiently filtered HTML saved in FAQ records. The editor permitted embedding elements that can cause the browser to request secondary resources (e.g., frame/iframe).
• Attachment endpoint behavior combined with response headers. The attachment-serving endpoint could serve files in a way that made browsers treat them as downloadable resources (or download them automatically), and the endpoint could be fetched from within the page context without requiring additional confirmation or explicit user action in some browsers.

High-level proof-of-concept (concept only)

At a conceptual level, an attacker with the ability to upload attachments and save HTML into a FAQ body can create content that references the attachment URL such that a normal page render causes the browser to request the attachment. The request to that attachment endpoint will cause the browser to receive the file. Whether the browser saves the file automatically or shows a prompt depends on the browser and response headers.

Important safety note: Do not attempt to reproduce this against systems you do not own or operate. Use isolated test environments for security research and follow responsible disclosure policies.

Detecting exploitation and indicators

• Unexpected file downloads correlated with viewing or editing FAQ entries.
• FAQ body content containing embedded tags that request internal endpoints (for example any tag that triggers a GET request to the /attachment or equivalent endpoint).
• Webserver logs showing anonymous/curated requests to attachment endpoints originating from pages that reference FAQ pages (referrer headers may help).
• Audit the FAQ edit history for modifications by accounts that should not be adding embedded resource references.

Immediate mitigations (pre-patch)

• Limit who can upload attachments or edit FAQ content. Restrict privileges to trusted users until a patch is applied.
• Temporarily disable HTML source editing or strip risky tags server-side before saving (see remediation code below).
• Require authentication/authorization to access attachments. Ensure attachments are not publicly accessible without a valid session/permission check.
• Harden HTTP headers: set X-Content-Type-Options: nosniff, X-Frame-Options or Content-Security-Policy frame-ancestors to restrict framing, and a strict Content-Security-Policy to limit where resources can be loaded from.

Patches and long-term fixes

The upstream advisory provides the recommended fix and the maintainers have released an updated version that addresses the problem by sanitizing stored HTML and tightening attachment handling. The most complete remediation is to upgrade to the patched phpMyFAQ version that contains the fix. If you cannot upgrade immediately, apply the mitigations below.

Recommended secure coding and configuration mitigations

Below are defensive changes that should be implemented in the application to eliminate or mitigate the vulnerability:

• Sanitize stored HTML: allow only an explicit, minimal whitelist of safe tags and attributes. Disallow iframe, object, embed, and other tags that can trigger fetches or file retrievals.
• Authenticate and authorize attachment access: ensure the attachment-serving endpoint enforces the same permission model as the UI. Do not serve sensitive attachments to unauthenticated users.
• Set safe response headers: use X-Content-Type-Options: nosniff and Content-Type matching the file. Prefer inline delivery only for safe, displayable types; otherwise require explicit user action for downloads.
• Enforce CSP for FAQ pages: use frame-ancestors and default-src rules to restrict resource loading from untrusted origins.

Example: Server-side HTML sanitization using HTML Purifier (PHP)

// Example: sanitize user-supplied HTML with HTML Purifier
require_once '/path/to/HTMLPurifier.auto.php';
$config = HTMLPurifier_Config::createDefault();

// Allow only a small, controlled set of tags and attributes
$config->set('HTML.Allowed', 'p,b,i,strong,em,ul,ol,li,a[href|title|rel],br,code,pre');
$config->set('Attr.AllowedFrameTargets', array('_blank')); // if you must allow links that open in new tab

$purifier = new HTMLPurifier($config);
$clean_html = $purifier->purify($dirty_html);

// Now store $clean_html in the database instead of raw input

Explanation: This code uses the HTML Purifier library to remove any tags and attributes not explicitly allowed. The configuration whitelists safe inline and formatting tags while excluding iframe, object, embed, script and other tags able to trigger resource fetches. Storing only the cleaned HTML prevents attackers from embedding frame-based references to attachments.

Example: Enforce attachment access control and safe delivery (PHP)

// Pseudo-code for secure attachment delivery
session_start();

// Verify user is authenticated and authorized
if (!isset($_SESSION['user']) || !user_can_view_attachment($_SESSION['user'], $attachment_id)) {
    http_response_code(403);
    exit;
}

$file_path = get_attachment_path($attachment_id);
if (!is_readable($file_path)) {
    http_response_code(404);
    exit;
}

// Determine MIME type safely
$mime = mime_content_type($file_path);
$basename = basename($file_path);

// Set security headers
header('X-Content-Type-Options: nosniff');
header('Content-Type: ' . $mime);

// Prefer inline for web-displayable files; otherwise require explicit download flow
$web_displayable = in_array($mime, ['image/png','image/jpeg','text/plain','text/html']);
if ($web_displayable) {
    header('Content-Disposition: inline; filename="' . $basename . '"');
} else {
    // Force a controlled download endpoint that requires an additional click/token
    header('Content-Disposition: attachment; filename="' . $basename . '"');
}

readfile($file_path);

Explanation: This pattern enforces authentication and fine-grained authorization before sending a file. It also sets X-Content-Type-Options: nosniff to prevent MIME-sniffing attacks and chooses Content-Disposition based on whether the file type is safe to render inline. For non-displayable or risky files, require a distinct download action so that passive embedding (e.g., via frame) is less effective.

Operational recommendations

• Upgrade: apply the vendor’s patch or upgrade to the fixed release as soon as possible.
• Review privileges: audit users who can upload attachments and edit FAQ content. Reduce the number of users with those rights.
• Audit content: scan existing FAQ bodies for disallowed tags or internal URLs that reference attachments or internal endpoints.
• Logging and monitoring: add logging around attachment access and content edits, and alert if attachments are served without an authenticated session or if many downloads are initiated from a single FAQ view.

Detection signatures for blue teams

• Search stored FAQ bodies for "<iframe", "<object", "<embed", or suspicious references to internal attachment endpoints.
• Create IDS rules to flag requests to /attachment? or similar paths where the referrer is an FAQ edit or view page.
• Monitor for automatic downloads (high download counts with low user interactions) and investigate the FAQ content served immediately prior to downloads.

Responsible disclosure and timeline

The issue was responsibly disclosed to the project maintainers and recorded as CVE-2024-55889. Refer to the project advisory for the exact patch and release notes. Administrators should follow the vendor advisory and upgrade instructions.

Conclusion

CVE-2024-55889 demonstrates how stored HTML combined with permissive attachment serving can create surprising client-side effects such as automated downloads. The fix requires both sanitizing stored HTML to remove dangerous tags and ensuring attachment endpoints enforce access controls and safe delivery headers. Immediate mitigations (privilege restriction, disabling HTML source editing, and hardening headers) can lower risk prior to upgrading to the patched version.

References

• phpMyFAQ advisory: https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-m3r7-8gw7-qwvc
• Public writeup: https://geochen.medium.com/cve-2024-55889-03572ae6c35c