CVE-2026-7635: coreActivity WordPress Plugin DoS Vulnerability

CVE-2026-7635 Overview

CVE-2026-7635 is a PHP Object Injection vulnerability affecting the coreActivity: Activity Logging plugin for WordPress in all versions up to and including 3.0. The plugin stores attacker-controlled User-Agent HTTP header data in the logmeta table without stripping PHP serialization syntax. When an administrator opens the Logs page, the plugin calls maybe_unserialize() on every retrieved meta_value and forwards the result to DeviceDetector::setUserAgent(). Unauthenticated attackers can inject a crafted serialized payload that triggers a Fatal TypeError, producing a persistent denial-of-service condition that blocks administrator access to the Logs page. The vulnerability is tracked as [CWE-502] Deserialization of Untrusted Data.

Critical Impact

Unauthenticated attackers can permanently disable administrator access to the WordPress Logs page by sending a single crafted User-Agent header during any logged event.

Affected Products

• coreActivity: Activity Logging for WordPress plugin — all versions up to and including 3.0
• WordPress installations using the dev4press coreactivity plugin
• Sites where administrators rely on the plugin's Logs page for activity auditing

Discovery Timeline

• 2026-05-13 - CVE-2026-7635 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-7635

Vulnerability Analysis

The coreActivity plugin logs events such as failed login attempts and stores associated metadata, including the client User-Agent header, in the logmeta database table. The plugin does not validate or strip PHP serialization syntax from this header before storage. When an administrator views the Logs page, the query_metas() function retrieves each meta_value and applies WordPress's maybe_unserialize() helper without first verifying that the value was originally serialized by the application.

Because maybe_unserialize() will attempt to deserialize any string that looks like serialized PHP data, an attacker-supplied payload is converted into a PHP object. The deserialized object is then passed to DeviceDetector::setUserAgent(), which expects a string argument. The type mismatch raises a Fatal TypeError, halting page rendering. The malicious row remains in the database, so every subsequent visit to the Logs page repeats the failure, producing a persistent denial-of-service state.

Root Cause

The root cause is unsafe deserialization of attacker-controlled input [CWE-502]. The plugin treats stored log metadata as trusted and uses maybe_unserialize() as a generic decoder, but the original User-Agent string was never serialized by the application. Combined with the absence of input sanitization on inbound HTTP headers, the design allows untrusted client data to enter PHP's deserialization path.

Attack Vector

An unauthenticated remote attacker sends an HTTP request to the target WordPress site with a User-Agent header containing a PHP serialized payload. The request must trigger any event that coreActivity logs, such as a failed login attempt. The plugin writes the raw header into logmeta. When any administrator next opens the Logs page, the malicious row is read, deserialized, and passed to DeviceDetector::setUserAgent(), causing a Fatal TypeError and breaking the page. See the WordPress Core Log Code, WordPress Device Log Code, and WordPress Logs Table Code for the affected code paths.

Detection Methods for CVE-2026-7635

Indicators of Compromise

• HTTP request logs containing User-Agent headers that begin with PHP serialization prefixes such as O:, a:, or s: followed by length and type identifiers.
• Rows in the wp_logmeta table where meta_value for user_agent keys contains serialized PHP object syntax instead of a normal browser User-Agent string.
• PHP error log entries showing Fatal error: Uncaught TypeError originating from DeviceDetector::setUserAgent() when an administrator loads the coreActivity Logs page.
• Repeated failed login attempts immediately preceding malformed log metadata insertion.

Detection Strategies

• Inspect wp_logmeta for meta_value entries matching the regex ^[OaSsbidN]:[0-9]+: which indicates serialized PHP data in a field expected to hold a plain string.
• Monitor web server access logs for inbound User-Agent headers containing characters such as {, }, ;, or the literal sequence O: at the start of the value.
• Alert on PHP TypeError exceptions raised from wp-content/plugins/coreactivity/ paths in application error logs.

Monitoring Recommendations

• Forward WordPress PHP error logs and web access logs to a centralized analytics platform and create correlation rules tying malformed User-Agent strings to subsequent administrator-side errors.
• Track availability of the coreActivity Logs admin page with synthetic checks so a persistent DoS condition is detected before relying on user reports.
• Review failed-login telemetry for patterns that combine authentication failures with anomalous header content from the same source IP.

How to Mitigate CVE-2026-7635

Immediate Actions Required

• Disable or remove the coreActivity: Activity Logging plugin until a patched release is installed.
• Audit and purge any wp_logmeta rows where meta_value contains PHP serialization syntax for the user_agent field, restoring administrator access to the Logs page.
• Restrict access to the WordPress admin interface by IP allow-listing while triage is in progress.
• Apply web application firewall rules that reject inbound User-Agent headers containing PHP serialization markers.

Patch Information

The vendor has published code changes addressing the unsafe deserialization path. See the GitHub Pull Request Changes for the upstream fix and the Wordfence Vulnerability Intelligence entry for advisory details. Administrators should upgrade to a release later than 3.0 once the fixed version is available from the WordPress plugin repository.

Workarounds

• Block or sanitize HTTP User-Agent headers containing PHP serialization patterns at the reverse proxy or WAF layer before requests reach PHP.
• Patch the plugin locally by removing or replacing the call to maybe_unserialize() in query_metas() so stored values are returned as raw strings.
• Truncate or normalize User-Agent values before insertion into logmeta to strip non-printable and structural characters used by PHP serialization.

# Example WAF rule to drop requests with serialized payloads in User-Agent
# ModSecurity syntax
SecRule REQUEST_HEADERS:User-Agent "@rx ^[OaSsbidN]:[0-9]+:" \
    "id:1026763501,phase:1,deny,status:400,\
    msg:'Blocked PHP serialized payload in User-Agent (CVE-2026-7635)'"