FoF Pretty Mail 1.1.2 - Local File Inclusion (LFI)

FoF Pretty Mail 1.1.2 — Local File Inclusion (LFI) Vulnerability Overview

The FoF Pretty Mail extension for Flarum (version 1.1.2) contains a Local File Inclusion (LFI) weakness arising from unsafe handling of email template includes. In environments where an attacker or a low-trust administrator can inject template code, this weakness can lead to sensitive files from the host filesystem being embedded into outgoing email content, causing information disclosure and compliance exposure.

What is Local File Inclusion (LFI)?

Local File Inclusion is a class of vulnerability where application logic allows a user-controllable input to reference local files on the server and the application reads or outputs those files without proper validation. Typical impacts include disclosure of configuration files, secrets, credentials, and source code.

Why this matters for FoF Pretty Mail

• FoF Pretty Mail renders customizable email templates before sending messages. If template features that include external content are not restricted or sanitized, template authors can cause server files to be embedded into email bodies.
• Even though the risk surface is reduced when the attacker must have administrative access to change templates, in many deployments administrative privileges are shared or weakly controlled. Malicious insiders, compromised admin accounts, or abused delegated access are realistic threat vectors.
• Emails that contain embedded file contents can leak system secrets off-host (to mailboxes, backups, logs), amplifying the impact.

Typical root cause

The issue commonly arises when template engines allow dynamic include mechanisms (e.g., include tags/functions) and template content is created, edited, or influenced by users without strict path validation or sandboxing. If the include directive can accept arbitrary file paths, it can be used to read local filesystem content.

Potential impact and risk scenarios

• Disclosure of system configuration files (for example, passwd-like files, service credentials, or configuration files containing API keys).
• Exposure of application source code or template files that reveal further vulnerabilities.
• Information leakage leading to lateral movement or targeted attacks against the infrastructure.
• Regulatory or privacy violations if customer data is accidentally sent in email bodies.

Detection and indicators

• Outgoing email bodies that contain raw file contents or unusual server text fragments not expected in templates.
• Changes to email templates performed by accounts that normally do not edit templates, or template edits outside normal change windows.
• Application logs showing template rendering that references unexpected file paths, or rendering operations that read large text blocks from disk.
• Audit trails showing use of include-style template constructs where previously none existed.

High-level remediation and mitigation strategy

• Apply vendor fixes: upgrade FoF Pretty Mail to the latest patched version as soon as a vendor patch is available.
• Restrict administrative capability: enforce least privilege for accounts that can edit templates — use role-based access controls, Multi-Factor Authentication (MFA), and dedicated change management.
• Disable dangerous template features: if include/composable file-inclusion features are not needed, disable them or remove templates that use them.
• Sandbox the template engine: configure the template renderer to disallow or restrict include tags, functions, and arbitrary filesystem access.
• Implement allowlist policy: only allow template includes from a specific internal template directory. Reject or normalize user-supplied paths via realpath checks.
• Harden file permissions: limit what the web/application user can read on the filesystem to reduce exposure even if includes are misused.
• Monitor outgoing emails and scan for unexpected content. Implement email DLP controls if feasible.

Secure coding patterns — validating and restricting file includes

Below are examples showing a safe approach to validating a requested include file before reading it. The examples are intended to demonstrate defensive techniques: enforcing an allowlist directory, resolving canonical paths, and refusing access when checks fail.

// Secure PHP example: allowlist directory + realpath validation
function readTemplateInclude(string $userPath): ?string {
    // Directory where allowed template fragments live (absolute)
    $allowedBase = '/var/www/flarum/extensions/pretty-mail/templates/includes';
    // Normalize and resolve the requested path (prevent ../ escapes)
    $resolved = @realpath($userPath);
    if ($resolved === false) {
        return null; // invalid path
    }
    // Ensure the resolved path is inside the allowlist directory
    if (strpos($resolved, rtrim($allowedBase, DIRECTORY_SEPARATOR) . DIRECTORY_SEPARATOR) !== 0) {
        return null; // disallowed
    }
    if (!is_file($resolved) || !is_readable($resolved)) {
        return null; // missing/unreadable
    }
    return file_get_contents($resolved);
}

Explanation: This function only permits reads of files that physically reside under a single predefined directory. realpath() resolves symbolic links and removes path traversal components; the subsequent prefix check enforces the allowlist. Denying access on any mismatch prevents files outside the allowlist from being included even if a template author attempts a traversal-style path.

Sandboxing the template engine (Twig example)

Twig supports a sandbox mode where you can specify allowed tags, filters, functions, and methods. By constructing a restrictive SecurityPolicy you can prevent use of include and other capability-heavy tags in user-edited templates.

// Example: configure Twig Sandbox to disallow include tag
use Twig\Environment;
use Twig\Loader\ArrayLoader;
use Twig\Sandbox\SecurityPolicy;
use Twig\Extension\SandboxExtension;

$loader = new ArrayLoader();
$twig = new Environment($loader);

// Define a very restrictive policy: remove 'include' and other risky constructs
$allowedTags = ['if', 'for', 'block']; // do not include 'include'
$allowedFilters = ['escape', 'upper']; // minimal filters
$allowedFunctions = []; // no functions allowed
$allowedMethods = [];
$allowedProperties = [];

$policy = new SecurityPolicy($allowedTags, $allowedFilters, $allowedFunctions, $allowedMethods, $allowedProperties);
$twig->addExtension(new SandboxExtension($policy, true));

Explanation: The SecurityPolicy object specifies permitted constructs. By excluding the include tag and disallowing arbitrary functions, template authors cannot invoke file inclusion or other powerful operations from templates. Note: disabling tags may also remove legitimate functionality; test changes cautiously.

Responsible disclosure and vendor steps

• If you maintain a Flarum instance with FoF Pretty Mail, check the extension’s GitHub repository for security advisories and apply recommended updates. The extension source is hosted at the FriendsOfFlarum organization on GitHub.
• Vendors should issue a patch that either removes unrestricted include support from editable templates, enforces an allowlist for include paths, or enforces robust sandboxing by default.
• Document the change and communicate to administrators that any existing templates should be reviewed for unsafe include usage.

Operational recommendations for administrators

• Immediately review editable email templates and remove or sanitize any include-like constructs that reference external files or variable-driven paths.
• Rotate secrets that may have been exposed in emails or templates (API keys, database credentials) as part of an incident response if you suspect compromise.
• Restrict access to the administration interface and enable strong authentication controls for all admin accounts.
• Implement continuous monitoring of email content and archive copies to detect anomalous transmissions.

For developers: secure-by-default template handling checklist

• Do not render template or include directives that allow arbitrary filesystem access from untrusted or lightly-trusted users.
• Prefer an allowlist of template fragments in a controlled directory; never allow arbitrary absolute paths supplied by users.
• Use the template engine’s sandbox features and explicitly deny risky tags/functions by default.
• Normalize and validate paths with realpath(), and check that the canonical path begins with the allowlisted base path.
• Log and alert on template edits and unusual rendering behavior.

Closing remarks

Local File Inclusion in email template systems is a serious issue because email content can easily leave the host and be stored in multiple locations (recipient mailboxes, relay logs, backups). The best mitigation is to apply vendor patches, harden template handling via allowlists and sandboxing, and reduce the number of users who can modify templates. Combining secure coding practices with operational controls (access management, monitoring, and DLP) will greatly reduce the risk posed by this kind of vulnerability.