CVE-2026-109218: Contact Manager File Upload Flaw

Are You Affected?

The vulnerable functionality handles file uploads without requiring authentication. An incomplete extension blacklist can be bypassed with a specially crafted filename containing a trailing dot. WordPress subsequently normalizes the filename before writing it to disk, creating a mismatch between the name that passed validation and the name ultimately stored.

The official WordPress.org plugin page showed version 9.1.3 and a corresponding contact-manager.9.1.3.zip package. The available NVD record did not explicitly document a fixed version, so administrators should confirm the release with the plugin maintainer where possible. Remediation should not be delayed on exposed installations.

Analyst’s take: Upgrade first, then verify that upload directories cannot execute PHP-related extensions. The absence of a CISA KEV listing or confirmed public proof of concept lowers the evidence of active exploitation, but it does not eliminate the risk created by unauthenticated uploads.

Risk is highest where WordPress runs on Apache with libapache2-mod-php, .phar files are mapped to PHP by default, and uploaded files are reachable before the plugin deletes them. Even without those exact conditions, arbitrary file upload remains a serious integrity and abuse concern.

The Fix, If You’re in a Hurry

Upgrade Contact Manager to 9.1.3 or later. WordPress administrators can use the dashboard’s plugin update mechanism or WP-CLI:

wp plugin update contact-manager
wp plugin status contact-manager

To verify the installed version:

wp plugin get contact-manager --field=version

If the plugin is pinned to a specific package or managed outside the WordPress dashboard, obtain the release from the official WordPress.org plugin listing and verify that the installed version is at least 9.1.3.

The available evidence identifies 9.1.3 as the apparent post-vulnerability release, but does not include a formal vendor statement explicitly confirming that this version fixes CVE-2026-109218. If an immediate upgrade is not possible, temporarily deactivate and remove the plugin where operationally feasible. Blocking unauthenticated access to the affected message-submission functionality can reduce exposure, but it is a compensating control rather than a confirmed complete fix.

For broader WordPress hardening guidance, review the WordPress plugin security glossary and related security resources.

Technical Notes

Prevent web-server execution in WordPress upload locations. The precise configuration depends on the hosting stack, and changes should be tested before deployment. For Apache configurations that permit directory-level overrides, a defensive .htaccess rule can deny access to common PHP handlers:

<FilesMatch "\.(php|php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

Review Apache MIME and handler mappings as well. If .phar is mapped to PHP and that behavior is not required, remove or disable the mapping in the applicable Apache or PHP configuration, then reload Apache using the service process appropriate to the operating system:

sudo apachectl configtest
sudo systemctl reload apache2

Blocking .php alone is not sufficient. The reported exploitation path specifically depends on .phar handling, so upload-directory protections should cover all executable PHP-related extensions supported by the deployment.

How This Vulnerability Works

The vulnerability is caused by a filename-validation and normalization mismatch. Contact Manager’s vulnerable add_message functionality uses an extension blacklist to reject dangerous uploads. A filename ending in a trailing dot can cause the extension-derivation routine to return an empty extension. Because that value does not match the blacklist, validation proceeds.

WordPress then applies sanitize_file_name(). This normalization step removes the trailing dot before the file is written to disk. The filename that passed validation is therefore different from the filename ultimately stored by the application. A file that evaded the blacklist can consequently be written under a potentially executable name.

The file is later removed with unlink() at the end of the request. That cleanup reduces persistence but does not eliminate risk. An attacker may attempt to retrieve the uploaded object during the short interval between file creation and cleanup.

Successful remote code execution requires additional environmental conditions, including Apache, libapache2-mod-php, default .phar-to-PHP handling, and successful timing of the retrieval request.

Technical Notes

The important defensive sequence is:

1. An unauthenticated request reaches the message-upload path.
2. A crafted trailing-dot filename bypasses the blacklist.
3. WordPress normalizes the filename.
4. The file is temporarily written under a potentially executable name.
5. The attacker attempts retrieval before cleanup.

The supplied research identifies source references in the Contact Manager 9.1.2 tree, including add-message.php, processing.php, and the plugin’s primary source file. Those Trac pages returned HTTP 403 during retrieval, so defenders should treat the root-cause description as based on the published CVE record rather than independently reproduced source code.

Severity Explained

CVE-2026-109218 carries a CVSS base score of 9.8, classified as Critical. The retrieved NVD data did not provide the full CVSS vector string, so the exact individual metric selections cannot be verified from the available record.

The reported characteristics explain the high score: the attack is network-reachable, does not require authentication, and does not require pre-existing privileges.

An arbitrary file-upload issue can affect confidentiality, integrity, and availability. If the uploaded content becomes executable, an attacker could potentially run code with the privileges of the web-server process. Possible consequences include:

• Website defacement
• Credential theft
• Malware deployment
• Unauthorized data access
• Further compromise of the WordPress host
• Use of the server as a foothold into connected systems

The practical impact is configuration-dependent because the described execution path requires specific Apache/PHP behavior and a narrow retrieval window.

Administrators should not downgrade the issue solely because the application deletes the file. Short-lived files can still be retrieved, and the upload capability itself may support additional abuse depending on permissions, storage paths, monitoring coverage, and web-server behavior.

Is CVE-2026-109218 Being Exploited?

CVE-2026-109218 is not listed in CISA’s Known Exploited Vulnerabilities catalog according to the supplied lookup. There is no CISA KEV due date, required action, or ransomware-campaign designation for this CVE.

KEV absence is not proof that exploitation has never occurred. It means that confirmed exploitation was not represented in that catalog at the time of assessment.

No confirmed in-the-wild exploitation was identified in the supplied NVD or KEV data. No known public proof-of-concept repository was identified in the research results either. The vulnerability remains technically plausible for exploitation because it is unauthenticated and carries a 9.8 CVSS score, but successful code execution depends on the target’s Apache/PHP configuration and the timing of file retrieval.

The Wordfence vulnerability database independently describes the issue as “Contact Manager <= 9.1.2 - Unauthenticated Arbitrary File Upload via Trailing-Dot Filename Blacklist Bypass” and attributes the research to sermsak. This corroborates the affected versions and vulnerability class, but it is not evidence of active exploitation or a public exploit.