Brief Summary: CVE-2026-5127 PHP Object Injection in WP User Frontend Plugin

Introduction

A PHP Object Injection flaw in the WP User Frontend WordPress plugin lets any authenticated user with Subscriber privileges inject arbitrary serialized PHP objects into post metadata. The plugin deserializes those objects when the post is rendered. With over 20,000 active installations and a CVSS score of 8.8, this is a meaningful risk for WordPress sites that rely on the plugin for frontend content submission and user management.

WP User Frontend, developed by weDevs, lets users create posts, manage profiles, and handle memberships entirely from the site's front end. It fills a niche in the WordPress ecosystem, particularly for community-driven sites, directories, and membership platforms. The vulnerability is in one part of its broad feature set: the handling of file uploads during form submissions.

Technical Information

CVE-2026-5127 is classified under CWE-502 (Deserialization of Untrusted Data). It follows a two-stage pattern common in PHP deserialization attacks. Attacker-controlled data enters the system through an unsanitized ingress point, and a deserialization sink later instantiates that data as PHP objects.

The Ingress: Unsanitized wpuf_files Parameter

When a user submits a form through WP User Frontend, the plugin processes file attachment data from the $_POST['wpuf_files'] parameter. In versions up to and including 4.3.1, the plugin accepted this parameter without checking that its values were integers, the only legitimate data type for WordPress attachment IDs.

The vulnerable code paths are in three methods in includes/Traits/FieldableTrait.php.

In adjust_thumbnail_id(), the only processing applied to the raw POST data was wp_unslash():

// 4.3.1 (Vulnerable)
$wpuf_files = ! empty( $_POST['wpuf_files'] ) ? wp_unslash( $_POST['wpuf_files'] ) : [];

In update_post_meta(), there was no sanitization at all, which is arguably worse:

// 4.3.1 (Vulnerable)
$wpuf_files = isset( $_POST['wpuf_files'] ) ? $_POST['wpuf_files'] : [];

In prepare_meta_fields(), the file_upload/image_upload case used sanitize_text_field. That function strips HTML tags and extra whitespace, but a well-formed serialized PHP string passes through it intact:

// 4.3.1 (Vulnerable)
$wpuf_files = isset( $post_data['wpuf_files'] ) ? array_map( 'sanitize_text_field', ... ) : [];

In all three cases, an attacker could submit a crafted serialized PHP object string as a value in the wpuf_files array, and the plugin would store it in WordPress post meta with no type enforcement.

The Sink: Unconditional maybe_unserialize()

The injected payload sits in the database until the post content is displayed. When rendering post content, the plugin calls maybe_unserialize() inside the wpuf_get_form_fields function in wpuf-functions.php:

$field = (array) maybe_unserialize( $content->post_content );

When maybe_unserialize() reads the stored serialized string, it instantiates the PHP objects the string describes. If the target system has a suitable Property Oriented Programming (POP) chain, from another installed plugin, a theme, or WordPress core itself, the attacker can use magic methods such as __wakeup(), __destruct(), or __toString() to achieve arbitrary code execution, arbitrary file deletion, or other malicious outcomes.

Attack Flow

1. The attacker registers, or already has, a WordPress account with at least Subscriber-level privileges on the target site.
2. The attacker submits a form in which the wpuf_files parameter holds a serialized PHP object string instead of a legitimate integer attachment ID. They choose the object class and properties to match a POP chain available on the target.
3. The plugin processes the submission and stores the unsanitized serialized string in post meta through one of the three vulnerable methods in FieldableTrait.php.
4. When the post content is later rendered, whether because the attacker visits the post or because another user or an automated process triggers the display, maybe_unserialize() deserializes the stored payload.
5. The PHP engine instantiates the injected object, which triggers the POP chain and carries out the attacker's intended action.

The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects network accessibility, low attack complexity, a low privilege requirement, and the potential for high impact on confidentiality, integrity, and availability.

Patch Information

The vulnerability was patched in version 4.3.2 of the WP User Frontend plugin, released through the WordPress.org plugin repository. The fix is tracked in WordPress Plugin Trac changeset 3514258 and mainly touches includes/Traits/FieldableTrait.php.

The patch sanitizes with absint() in all three vulnerable methods. WordPress attachment IDs are unsigned integers by definition, so absint() is the semantically correct function. It casts any input to a non-negative integer, which reduces a serialized string payload to 0.

1. adjust_thumbnail_id() method:

// 4.3.1 (Vulnerable)
$wpuf_files = ! empty( $_POST['wpuf_files'] ) ? wp_unslash( $_POST['wpuf_files'] ) : [];

// 4.3.2 (Patched)
$wpuf_files_raw = ! empty( $_POST['wpuf_files'] ) ? wp_unslash( $_POST['wpuf_files'] ) : [];
$wpuf_files = [];
if ( ! empty( $wpuf_files_raw ) ) {
    foreach ( $wpuf_files_raw as $key => $value ) {
        $wpuf_files[ $key ] = array_map( 'absint', (array) $value );
    }
}

2. update_post_meta() method:

The patch replaces the raw $_POST['wpuf_files'] assignment with the same absint loop, so only integer values reach set_post_thumbnail() and wpuf_associate_attachment().

3. prepare_meta_fields() static method:

// 4.3.1 (Vulnerable)
$wpuf_files = isset( $post_data['wpuf_files'] ) ? array_map( 'sanitize_text_field', ... ) : [];

// 4.3.2 (Patched)
$wpuf_files = isset( $post_data['wpuf_files'] ) ? array_map( 'absint', ... ) : [];

sanitize_text_field let a well-formed serialized string through. absint forces the value to an integer, which rules out serialized payloads as a class.

Together, the three changes close the injection path at every point where user-supplied wpuf_files data enters the system, so malicious serialized objects never reach maybe_unserialize() downstream. The deserialization sink itself (maybe_unserialize() in wpuf-functions.php) is still in place, but the upstream data is now guaranteed to be integers, so the sink is no longer reachable for exploitation.

The full diff between versions 4.3.1 and 4.3.2 is available on the WordPress Plugin Trac.

Affected Systems and Versions

The vulnerability affects the WP User Frontend plugin (slug: wp-user-frontend) in all versions up to and including 4.3.1. Any WordPress installation running a vulnerable version with user registration enabled, which allows Subscriber-level accounts, is potentially at risk.

For the object injection to lead to code execution or another high-impact outcome, the target system also needs a usable POP chain from an installed plugin, a theme, or WordPress core.

Vendor Security History

weDevs has a record of addressing security issues in the WP User Frontend plugin. Version 4.1.13, released on October 7, 2025, improved security and capabilities checks. The version 4.3.2 changelog lists "Hardened Security & Sanitization" and notes stricter sanitization of file IDs using absint. The patch for CVE-2026-5127 shipped on April 24, 2026, before public disclosure on May 7, 2026. That timing indicates a coordinated disclosure process and a vendor that responds to security reports.

References

• NVD Entry for CVE-2026-5127
• Wordfence Threat Intelligence Advisory
• Patched FieldableTrait.php (4.3.2)
• Vulnerable FieldableTrait.php (4.3.1)
• Changeset 3514258: FieldableTrait.php Patch
• Full Diff: 4.3.1 to 4.3.2
• WP User Frontend on WordPress.org
• WP User Frontend Changelog
• FieldableTrait.php (4.2.10 reference)
• wpuf-functions.php (4.2.10 reference)