CVE-2026-7654: Admin Columns WordPress Plugin Vulnerability

Affected Versions and Exposure Assessment

The affected product is the Admin Columns plugin for WordPress, plugin slug codepress-admin-columns. The vulnerable range, based on the NVD description, is all versions up to and including 7.0.18. That means if your environment is running 7.0.18, 7.0.17, or any earlier release in the branch, you should treat it as exposed until you validate otherwise.

The fixed version is likely 7.0.19. That wording is deliberate. The evidence confirms that version 7.0.19 is published on WordPress.org and that the vulnerable range ends at 7.0.18, but the retrieved vendor content did not explicitly say “security fix for CVE-2026-7654.” In security operations, that is enough to justify patching, but not enough to overstate vendor confirmation. If you need strict change-control documentation, record the caveat in your ticket: “7.0.19 appears to be the first non-vulnerable version based on available metadata; direct vendor security advisory not retrieved.”

A quick way to assess exposure is to inventory the plugin across all WordPress instances, including forgotten staging systems, low-traffic microsites, and customer-managed subdomains. WordPress plugin risk is often not concentrated on primary production sites alone. Old admin utilities, cloned environments, and abandoned content sites tend to lag patching and are commonly overlooked. If Contributor accounts exist on any of those instances, this vulnerability becomes operationally relevant.

Where version discovery is incomplete, assume the worst until verified. If your asset inventory cannot reliably tell you whether Admin Columns is installed, you should check directly on disk or through WP-CLI. In the absence of central data, defenders should assume that any WordPress site with the plugin present and version <= 7.0.18 is vulnerable.

Technical Notes

Use WP-CLI to identify the installed version:

wp plugin list --format=table | grep codepress-admin-columns

Check the plugin version from its header on disk:

grep -E "Version:" /var/www/html/wp-content/plugins/codepress-admin-columns/codepress-admin-columns.php

Find WordPress installs that have the plugin deployed:

find /var/www -type d -path "*/wp-content/plugins/codepress-admin-columns" 2>/dev/null

Exploitation Status, PoC Status, and Threat Reality

At the time of writing, exploitation in the wild is not confirmed from the provided primary-source evidence. Specifically, CVE-2026-7654 is not listed in CISA’s Known Exploited Vulnerabilities catalog, so there is no CISA-backed confirmation of active exploitation. That does not mean exploitation is impossible or absent; it means defenders should avoid claiming confirmed in-the-wild abuse without stronger evidence.

Likewise, a public PoC was not verified from the collected research set. Search-derived references surfaced aggregation pages, but no authoritative GitHub PoC or primary exploit publication for this exact CVE was confirmed. So the correct statement is: no verified public PoC is known from the collected evidence. Do not translate that into “safe to defer.” Authenticated WordPress RCEs often become reproducible quickly once root cause details are public, especially when the issue involves a straightforward unserialize() misuse and referenced code locations are known.

The absence of a KEV entry and the absence of a verified public PoC should affect prioritization only slightly, not fundamentally. Because this flaw yields RCE and only requires Contributor-level privileges, it is still a strong candidate for expedited patching. In environments where contributor accounts are internet-accessible, where account takeover risk is non-trivial, or where multiple users manage content, the practical exploitability can still be high even without broad public weaponization.

If you need a conservative planning assumption, use this: treat the vulnerability as exploit-ready by any attacker who can obtain or create a Contributor-level account, or who can compromise one through credential reuse, phishing, or another WordPress weakness. That assumption is operationally safer than waiting for public exploit telemetry.

Technical Root Cause

The root cause described by NVD is unsafe PHP deserialization. The plugin reportedly uses unserialize() without the allowed_classes restriction in IdsToCollection::get_ids_from_string(), while handling attacker-controlled post meta values. In PHP applications, this is dangerous because deserializing untrusted data can instantiate attacker-chosen objects and trigger magic methods during object lifecycle events. If a usable gadget chain is present, the result can be code execution, file writes, or other dangerous side effects.

In this case, the available references also point to bundled Laravel Serializable Closure components, which suggests a POP gadget chain is involved in reaching code execution. That is consistent with the NVD statement that the issue can be exploited via a bundled POP gadget chain. Direct retrieval of the referenced WordPress Trac source URLs was not possible in this environment due to HTTP 403 responses, so defenders should rely on the NVD description and linked file paths rather than claiming direct source review here.

The practical lesson for defenders and developers is broader than this single CVE. Any plugin or PHP application that deserializes user-controlled data without strict constraints should be treated as a high-risk code pattern. Even when the initial input seems limited to “metadata” or “custom fields,” deserialization vulnerabilities often become severe because the application or its dependencies already contain the classes needed to form a gadget chain.

Technical Notes

Referenced code locations from the CVE research set include:

classes/Formatter/IdsToCollection.php
classes/Formatter/Meta.php
vendor/laravel/serializable-closure/src/Serializers/Native.php
vendor/laravel/serializable-closure/src/Support/ClosureStream.php

Safer PHP deserialization pattern, where unavoidable:

$data = unserialize($input, ['allowed_classes' => false]);

Best practice is to avoid unserialize() on untrusted input entirely and prefer formats like JSON with strict schema validation.

What Defenders Should Do Next

If you run WordPress at scale, the immediate task is straightforward: find every instance of Admin Columns, identify versions, and upgrade any installation at 7.0.18 or earlier. Prioritize systems with many authors, guest contributors, external content teams, or weak identity controls. Those environments align most closely with the stated privilege requirement.

Next, decide whether you need threat hunting. If the plugin was exposed and Contributor-level accounts existed, check logs, recent post meta activity, and file integrity. If you find suspicious indicators or cannot rule out compromise, move into formal incident response and preserve evidence before cleaning up. For SMB operators without deep telemetry, at minimum review user accounts, new admin creation, plugin/theme file changes, unexpected scheduled tasks, and outbound connections from the web server.

Finally, document the uncertainty correctly. There is no confirmed CISA KEV exploitation, no verified public PoC from the collected evidence, and the fix version is strongly indicated as 7.0.19 but not explicitly vendor-confirmed in the fetched content. That does not weaken the remediation case. It just keeps the advisory accurate, which matters when security teams are making patch decisions under scrutiny.