MEDIUM 6.5

CVE-2026-3173

The Meta Field Block plugin for WordPress has a permission-checking flaw that lets Contributor-level users and above read sensitive data stored in WordPress metadata. An attacker with basic contributor access can specify any object ID and type—bypassing the plugin's validation—to retrieve private information like user details, customer billing addresses, or other metadata that WordPress site administrators expected to keep hidden. On sites running e-commerce or membership plugins, this can expose personally identifiable information at scale.

Source data · NVD / CISA · public domain

CVSS
3.1 · 6.5 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Weaknesses (CWE)
CWE-639
Affected products
0 configuration(s)
Published / Modified
2026-05-28 / 2026-06-17

NVD description (verbatim)

The Meta Field Block plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 1.5.1. This is due to the plugin allowing users to specify arbitrary object IDs and object types via block attributes without validating whether the authenticated user has permission to access the requested object's metadata. This makes it possible for authenticated attackers, with Contributor-level access and above, to read arbitrary user meta, post meta, and term meta data from any object in the database. On sites using plugins that store sensitive data in meta fields (e.g., WooCommerce billing/shipping information), this could lead to the exposure of Personally Identifiable Information (PII) including names, email addresses, phone numbers, and physical addresses.

4 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-3173 is an Insecure Direct Object Reference (IDOR) vulnerability in the Meta Field Block plugin affecting all versions through 1.5.1. The plugin accepts user-supplied object IDs and object types as block attributes without performing authorization checks to confirm the authenticated user has permission to access the requested metadata. This permits authenticated users with Contributor role or higher to enumerate and retrieve arbitrary user_meta, post_meta, and term_meta records. The vulnerability is network-accessible and requires only that an attacker possess valid WordPress credentials at the Contributor level or above.

Business impact

Organizations using WordPress with Meta Field Block are at risk of unauthorized data disclosure. If site administrators rely on meta fields to store customer PII—such as WooCommerce order details, billing addresses, phone numbers, or custom membership data—a compromised or malicious Contributor account can extract that data without detection. This can result in regulatory exposure under GDPR, CCPA, or similar privacy frameworks; reputational damage; and liability if customer data is exfiltrated. Sites hosting multiple clients or third-party content are particularly vulnerable if contributor accounts are distributed to external users.

Affected systems

The Meta Field Block plugin for WordPress in versions up to and including 1.5.1 is affected. Any WordPress installation running this plugin with Contributor-or-higher user roles is susceptible. The vulnerability does not require administrative access or network-level exploitation—only valid WordPress account credentials at Contributor level. Sites using plugins that store sensitive data in metadata fields (including WooCommerce, membership platforms, and custom meta-driven applications) face elevated risk of information disclosure.

Exploitability

Exploitation requires valid WordPress login credentials at Contributor level or above. An attacker must be able to create or authenticate as a user with this role, then craft requests specifying arbitrary object IDs and types to retrieve metadata. The CVSS vector reflects low attack complexity and no user interaction required: once authenticated, the attacker can programmatically extract large volumes of metadata. The barrier to entry is moderate—Contributor access must be obtained or already held—but once acquired, the attack is trivial and leaves minimal audit trails if the site does not log meta queries.

Remediation

Upgrade the Meta Field Block plugin to a patched version released after this vulnerability's disclosure. Verify the vendor advisory for the specific version addressing CVE-2026-3173. Additionally, audit user roles across WordPress installations: remove unnecessary Contributor and Author privileges, restrict access to only users who require it, and consider using capability-based access control to limit who can use the Meta Field Block. Review stored metadata to identify and remove sensitive information that does not require persistence in meta fields, or encrypt it where possible.

Patch guidance

Apply the vendor's patched version of Meta Field Block as soon as it becomes available—track the plugin's releases and security advisories. Verify patch availability by visiting the plugin's official repository or vendor security page, as no specific patched version is currently listed in this advisory. In the interim, restrict Contributor-level access to trusted users only, and consider disabling the Meta Field Block plugin if it is not actively used. Test any patch in a staging environment before deploying to production.

Detection guidance

Monitor WordPress logs for suspicious meta queries or unusual access patterns, particularly database queries targeting wp_usermeta, wp_postmeta, or wp_termmeta tables initiated by lower-privilege users. Audit user role assignments to identify unexpected Contributor or Author accounts. Review meta access logs if your WordPress installation or plugins provide query logging; look for patterns of sequential object ID enumeration. Use Web Application Firewalls (WAF) to detect and flag requests that attempt to enumerate or extract metadata in bulk. Check for unusual plugin settings or block configurations that expose meta fields to broader access than intended.

Why prioritize this

This vulnerability merits prompt remediation because it enables direct unauthorized access to potentially sensitive customer and user data without requiring privilege escalation or advanced exploitation techniques. The MEDIUM severity rating reflects the requirement for authenticated access, but organizations handling PII should treat this as higher priority. The ease of exploitation once credentials are obtained, combined with the scope of data at risk (user, post, and term metadata across the entire database), makes this a legitimate privacy and compliance concern for WordPress administrators.

Risk score, explained

CVE-2026-3173 scores 6.5 on CVSS 3.1 (MEDIUM severity) based on the following factors: Network-accessible attack vector; low attack complexity (straightforward object ID enumeration); requirement for local user authentication; no user interaction; impact limited to confidentiality with no integrity or availability consequences. The score reflects the controlled blast radius (authenticated users only) but recognizes the high confidentiality impact once access is obtained. Organizations with robust user provisioning practices and minimal Contributor accounts will experience lower practical risk; those with looser access policies face greater exposure.

Frequently asked questions

Can a site be exploited if Contributor accounts are not distributed to external users?

The vulnerability still exists for any authenticated Contributor or above. Internal staff, contractors, or temporarily granted Contributor access increases risk. However, sites that strictly limit Contributor roles to highly trusted individuals significantly reduce the attack surface compared to those that distribute Contributor access broadly.

Does the vulnerability require the Meta Field Block to be actively used in the site layout?

The vulnerable code path exists within the plugin regardless of whether Meta Field Block is actively displayed. An attacker with Contributor access can trigger the vulnerability programmatically by crafting requests that invoke the vulnerable metadata-retrieval logic, even if the block is not visible in published posts.

Will enabling two-factor authentication prevent exploitation?

Two-factor authentication (2FA) will prevent unauthorized login with stolen credentials, but it does not address the underlying IDOR flaw. Once a legitimate Contributor account is compromised or an internal user acts maliciously, 2FA is bypassed. The fundamental fix is to upgrade the plugin and implement proper authorization checks.

What if we do not know which metadata is stored by third-party plugins?

Conduct a database audit to catalog what information is stored in wp_usermeta, wp_postmeta, and wp_termmeta. Query your database to see what keys are present and their values. This visibility will help you prioritize remediation and identify especially sensitive data (PII, encryption keys, payment tokens) that should never be stored in metadata or should be encrypted at rest.

This analysis is provided for informational purposes only and reflects the CVE record and vulnerability description as published. Specific patch versions, release dates, and vendor remediation timelines should be verified directly with the plugin vendor's official security advisory. Organizations should conduct thorough risk assessments tailored to their specific WordPress configurations, installed plugins, and user role policies before prioritizing remediation efforts. No liability is assumed for the accuracy of derived technical details or business impact assessments. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).

Weaknesses (CWE)

Related vulnerabilities