Pluginnaam	Geavanceerde aangepaste velden
Type kwetsbaarheid	Gebroken toegangscontrole
CVE-nummer	CVE-2026-4812
Urgentie	Laag
CVE-publicatiedatum	2026-04-15
Bron-URL	CVE-2026-4812

Broken Access Control in Advanced Custom Fields (ACF) — What WordPress Site Owners Must Do Right Now

Datum: 15 April, 2026
Betrokken plugin: Advanced Custom Fields (ACF) — versions <= 6.7.0
Gepatcht in: 6.7.1
Ernst: Low / CVSS 5.3 (Broken Access Control)
CVE: CVE-2026-4812

As a WordPress security team working every day to protect thousands of sites, we need to be blunt: even “low” severity access control issues matter. This ACF bug allows unauthenticated requests to retrieve field data tied to arbitrary post/page IDs via an AJAX field query. That means an attacker — without logging in — may be able to probe your site and retrieve information that should be private: draft content, private post fields, or other sensitive metadata stored by ACF fields.

If you run ACF on any WordPress site, read this end-to-end advisory. We’ll explain exactly what’s happening, why it matters, how to detect if you’ve been probed or worse, and concrete mitigations you can apply immediately — including WAF rules and short code fixes — to block attack attempts until you can update to ACF 6.7.1.

---

Samenvatting voor leidinggevenden (wat elke site-eigenaar moet weten)

• The vulnerability affects Advanced Custom Fields (ACF) versions up to and including 6.7.0.
• It is a broken access control issue in an AJAX field query handler: missing authorization checks allow unauthenticated requests to disclose fields for arbitrary post/page IDs.
• The vendor patched it in 6.7.1. Updating the plugin is the recommended fix.
• If you cannot update immediately, place immediate mitigations: apply a virtual patch via your WAF, restrict the vulnerable AJAX endpoints at server level, or apply a temporary code-level check to block unauthenticated queries.
• Review logs for suspicious activity: high-volume admin-ajax requests or repeated queries that enumerate post IDs are key indicators.
• Even though the CVSS is moderate (5.3), the exposure can be meaningful (private drafts, PII, unpublished content). Treat it seriously.

---

Waarom deze kwetsbaarheid belangrijk is

Advanced Custom Fields is widely used to store structured content: pieces of text, meta values, private notes, user-provided data, and more. Many sites use ACF fields to handle content that is not intended for public view — internal notes, draft versions, or fields used by membership or private content flows.

When an unauthenticated HTTP request can query ACF’s AJAX field handler and retrieve data tied to arbitrary post IDs, the immediate risk is sensitive data leakage:

• Private or draft post content may be disclosed.
• Member-only content or subscription metadata could be exposed.
• Internal business data stored in custom fields (addresses, phone numbers, product staging notes) might be retrieved.
• Attackers can perform reconnaissance: map post IDs, content types, and discover unpublished content to be used for later exploitation or social engineering.

Even if no direct site takeover results, the confidentiality breach alone is a real risk to businesses and publishers.

---

Technical overview (high level, non-exploitative)

• ACF registers (or previously registered) an AJAX endpoint that accepts field query parameters, including a post identifier parameter. The endpoint is intended to return field data relevant to a post or page.
• Due to missing authorization checks (no capability/nonce/user authentication enforcement), that endpoint accepts requests from unauthenticated users and returns field values for the requested post ID.
• An attacker can issue repeated requests, iterating over post IDs, to harvest fields and content until they find useful or sensitive data.

Belangrijk: We won’t provide exploit proof-of-concept code here. The purpose of this write-up is to inform site owners and administrators so they can protect their sites and users.

---

Wat nu te doen — geprioriteerde checklist

1. Update ACF to 6.7.1 (or later) immediately.
   This is the published fix. Updating is the single best step.
2. If you can’t update immediately, apply virtual patching via WAF.
   Block unauthenticated requests to the ACF AJAX endpoints by matching the AJAX action or query parameters associated with field queries. See the “WAF rules and examples” section below for guidance.
3. Harden access to admin-ajax.php and other AJAX endpoints.
   If your site doesn’t need anonymous front-end ACF AJAX access, restrict access by IP, require authentication, or reject requests with specific query string patterns.
4. Add a short code-level guard as a temporary mitigation.
   Insert a small check to ensure only authenticated users can get ACF field data via AJAX. (Code example provided later.)
5. Monitor logs and detect reconnaissance patterns.
   Look for repeated requests to admin-ajax.php (or endpoints created by ACF) with parameters like action=acf* and post_id or post. Repeated enumeration of post IDs is a red flag.
6. If you suspect data access or exfiltration, follow incident response steps.
   Preserve logs, rotate secrets if needed, audit user accounts, and restore from a clean backup if modifications occurred.

---

How attackers abuse this bug — realistic scenarios

• Content scraping: An attacker enumerates post IDs and harvests unpublished content, which could be leaked or sold.
• Reconnaissance for larger campaigns: Information discovered here helps craft spear-phishing messages targeted at site authors or editors.
• PII exposure: If custom fields include personal data (addresses, phone numbers, email records), this becomes a privacy breach and may trigger compliance obligations.
• Competitive intelligence: Draft product descriptions, pricing notes, or embargoed announcements may be exposed.
• Secondary exploitation: Data found via field disclosure may give clues for privilege escalation or help identify admin usernames to target credential stuffing or social engineering.

Because this can be automated at scale, many sites can be probed in minutes after a vulnerability is published.

---

Indicators of compromise / detection tips

Watch your server and application logs for the following patterns:

• Repeated requests to admin-ajax.php from the same IP, especially GET or POST calls with query strings containing:
  • action=acf…
  • action=acf/field_group… or action=acf/load_field or similar ACF-specific actions
  • parameters named post_id, post, or ID with different numeric values
• High volume of 200 responses that include JSON with field values even when the request is unauthenticated.
• Requests for admin-ajax.php from unusual user-agents or IPs known for scanning.
• Unusual traffic spikes to AJAX endpoints outside of normal site behavior (e.g., a blog with no front-end AJAX suddenly receiving lots of admin-ajax traffic).
• Failed login attempts or new user registrations in coordination with field queries (reconscape plus later exploitation).

Stel waarschuwingen in voor:

• More than X requests to admin-ajax.php in Y minutes from a single IP.
• Any 200 response from admin-ajax.php that returns content for an unauthenticated request when normally that endpoint should reject anonymous calls.

---

Short-term code mitigation (temporary, until you update)

If you cannot upgrade right away, add a guard to your theme or a small mu-plugin that blocks unauthenticated requests to ACF’s AJAX actions. Place this in a tiny drop-in plugin or your theme’s functies.php (prefer a mu-plugin to ensure it runs even if themes change).

Example (conceptual, safe to implement):

<?php
// Disable anonymous access to ACF AJAX actions (temporary mitigation)
// Save this as wp-content/mu-plugins/acf-anon-guard.php

add_action('admin_init', function() {
    // Only run for front-end AJAX requests
    if ( defined('DOING_AJAX') && DOING_AJAX ) {
        // If user is not logged in and the request appears to be for ACF field AJAX
        $action = isset($_REQUEST['action']) ? sanitize_text_field($_REQUEST['action']) : '';
        $post_param = isset($_REQUEST['post_id']) ? intval($_REQUEST['post_id']) : null;

        // Adjust these checks to match the specific ACF actions you see in logs
        if ( !is_user_logged_in() && ( strpos($action, 'acf') !== false || $post_param ) ) {
            // Return a generic 403 and stop further processing
            status_header(403);
            wp_die('Forbidden', 'Forbidden', array('response' => 403));
        }
    }
});

Opmerkingen:

• This is a temporary stop-gap. It intentionally errs on the side of blocking potential valid front-end anonymous ACF features, so test on staging before applying on high-traffic production sites.
• Use a Must-Use (mu) plugin so it’s hard to accidentally deactivate.
• When you update ACF, remove this guard if it blocks legitimate behavior, or refine it to only block the action names associated with the vulnerability.

---

Server-level protections (Nginx / Apache examples)

If you can control server configuration, you can block suspicious query-string patterns globally:

Nginx (voorbeeld)

# Block requests to admin-ajax.php that include acf-related actions and a post_id when unauthenticated
location = /wp-admin/admin-ajax.php {
    if ($args ~* "action=.*acf.*" ) {
        return 403;
    }
    if ($args ~* "post_id=[0-9]+" ) {
        return 403;
    }
    # pass to php-fpm as usual otherwise
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Apache mod_rewrite (example)

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-admin/admin-ajax.php$
RewriteCond %{QUERY_STRING} (action=.*acf.*|post_id=[0-9]+) [NC]
RewriteRule .* - [F]

Be careful: these rules are blunt. Test them on staging before deploying, because some legitimate front-end ACF features (some themes/apps use public ACF AJAX) could be broken. If you have specific action names from your logs, target those more narrowly.

---

WAF rules and virtual patching (recommended if you have a managed WAF)

If you use a Web Application Firewall, virtual patching is the fastest way to block exploitation across all sites. Typical pattern-based WAF rules we recommend:

• Block unauthenticated requests to admin-ajax.php where:
  • Query string contains action values that contain “acf” or known vulnerable strings (e.g., acf/load_field, acf/field_group/get_fields).
  • Query string includes post_id or post parameters with numeric values and the request is GET or POST without authenticated cookies.
• Rate-limit client IPs issuing more than N requests to admin-ajax.php within M seconds.
• Raise alerts on responses returning JSON content that appears to include ACF field keys/values for anonymous requests.

Sample conceptual WAF rule logic:

• IF request.path == “/wp-admin/admin-ajax.php” AND request.method IN (GET, POST) AND request.query.action matches /acf/i AND NOT request.cookies contains authentication cookie THEN block (403) and alert.

A well-tuned WAF will also:

• Allow authenticated requests from session cookies (so logged-in editors aren’t blocked).
• Notify site admins when the rule triggers with a sample request and originating IP.

If you already use an application-layer protection, enable an emergency rule that targets the ACF endpoints until you upgrade.

---

Detection queries and log hunting (practical examples)

Use your server logs or SIEM to search for:

• admin-ajax.php requests:
  • grep "admin-ajax.php" access.log | grep -i acf
• Queries with action parameters:
  • access.log entries containing “action=acf” or “action=acf/load_field” or similar.
• Enumeration patterns:
  • Many requests from same IP with sequential post_id values (1,2,3,… or 100,101,102,…).
• Response content:
  • Any 200 response to admin-ajax.php returning JSON payloads that include known ACF field keys or field groups (field_XXXX identifiers).

Make these searches part of your routine when a new plugin vulnerability is public; attackers often scan widely after disclosure.

---

Incident response — if you think your site was probed or data retrieved

1. Preserve logs immediately. Do not overwrite or rotate until investigation is done.
2. Identify the timeframe of suspicious requests and the originating IP addresses.
3. Cross-check those IPs for other suspicious behavior (logins, plugin uploads, file edits).
4. If you detect sensitive data disclosure:
   • Notify your legal / privacy teams if personal data was potentially exposed.
   • Rotate API keys, tokens, or any secrets that may have been exposed.
5. Scan the site for malware and webshells. An attacker who obtains information may attempt follow-on actions.
6. Restore from a clean snapshot if you find modifications you cannot confidently remediate.
7. Change passwords for admin users and ensure any compromised accounts are removed and investigated.

---

Langdurige hardening en beste praktijken

• Keep plugins, themes, and WordPress core up to date. Period.
• Use a managed WAF or implement rule-based blocking tailored to WordPress AJAX endpoints.
• Limit unauthenticated exposure of admin AJAX endpoints. If your site does not need public AJAX entry points, restrict access.
• Reduce privilege creep: minimize the number of administrators and review user roles monthly.
• Implement logging and alerting for anomalous traffic patterns to admin-ajax.php, wp-json endpoints, and file upload paths.
• Make backups and retain them offsite with retention long enough to roll back to a clean state if needed.
• Treat CVEs as actionable intelligence. Even “low” CVSS issues can yield significant leaks depending on what data is stored.

---

How we (WP-Firewall) protect your site from issues like this

As a managed WordPress security provider, our goal is to close the window between disclosure and protection. Here’s what we do that directly defends sites from vulnerabilities like the ACF broken access control:

• Managed WAF and virtual patching: We push targeted rules to block attempts against known vulnerable endpoints so your site is protected even before you can update.
• Actionable alerts: You’ll receive clear, prioritized notifications when we detect exploit attempts or suspicious activity against plugin endpoints like ACF.
• Malware scanning and automated mitigation: We scan for indicators that an attacker moved from reconnaissance to foothold and remove common web-based threats.
• Tailored recommendations: We give step-by-step remediation guidance to update the plugin safely and remove temporary mitigations after patching.
• Rate limiting and anomaly detection: We throttle suspicious request patterns to prevent rapid automated enumeration of post IDs.

If you use our managed WAF, we can virtual patch this class of vulnerability across all protected sites immediately, cutting off mass-scanning campaigns and reducing the risk while you update plugins.

---

Practical example: what a good WAF rule could look like (conceptual)

Below is a conceptual rule you can ask your WAF admin to implement. This is intentionally non-vendor-specific. Share it with whoever manages your WAF or host.

Rule intent: Block anonymous requests to admin-ajax.php that appear to be ACF field queries.

• Condition A: REQUEST_URI equals “/wp-admin/admin-ajax.php”
• Condition B: QUERY_STRING contains “action=” and that value matches regex /acf/i OR QUERY_STRING contains “post_id=[0-9]+”
• Condition C: Incoming request does NOT include a valid WordPress authentication cookie (wordpress_logged_in_* or similar)
• Action: Block (403) and log details (IP, timestamp, user-agent, full query)

Remember: test any rule in monitor/log-only mode first to avoid blocking legitimate traffic.

---

Veelgestelde vragen

V: Is deze kwetsbaarheid een volledige overname van de site?
A: No, the issue is broken access control for data disclosure via AJAX field queries — it doesn’t directly grant remote code execution or admin creation. But data disclosure can enable social engineering or secondary attacks, so treat it seriously.

Q: My site does use ACF front-end AJAX. Will temporary blocks break functionality?
A: Possibly. If you rely on anonymous front-end ACF AJAX for legitimate functionality (e.g., front-end forms that return field groups), you must test changes on staging. Prefer targeted blocking by specific action names rather than broad admin-ajax.php locks.

Q: How urgent is this fix?
A: Update ACF as soon as possible. If you cannot, implement WAF protections and server-level restrictions today. Attackers scan automatically after vulnerability disclosures.

---

Protect your site now with a free baseline — WP-Firewall Basic (Free)

Protecting your WordPress site doesn’t need to be expensive to start. If you want immediate, managed protection for issues like this — including a managed firewall, malware scanner, and mitigation of OWASP Top 10 risks — we offer a Free Basic plan that covers the essentials.

Protect Your Site Immediately — Start with WP-Firewall’s Free Plan

• Essential protection: managed firewall with virtual patching, unlimited bandwidth, web application firewall (WAF), malware scanner, and automated mitigation of OWASP Top 10 risks.
• Perfect for site owners who want fast, easy protection while they update plugins and harden configurations.
• Sign up and turn on protection in minutes: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

If you later want automatic malware removal, IP allow/deny lists, monthly security reports, auto-virtual patching, or a dedicated security manager, we also offer Standard and Pro plans to scale with your needs.

---

Checklist — actions to complete today

• Update ACF to 6.7.1 or later.
• If you cannot update immediately, enable a WAF rule to block unauthenticated ACF AJAX requests.
• Add short-term mu-plugin guard (if safe in your environment).
• Check server logs for admin-ajax.php scans and enumerate suspicious IPs.
• Audit custom fields: identify where sensitive data is stored in ACF fields and consider moving it behind stronger access controls.
• Ensure you have recent backups and a rollback plan.
• Consider enabling a managed firewall or security service that offers virtual patching and active monitoring.

---

Slotgedachten

Broken access control issues like this one are a reminder: security is not only about preventing code execution or privilege escalation — it’s also about protecting confidentiality. WordPress sites often accumulate valuable or sensitive structured data in places plugins are intended to manage. When a plugin inadvertently exposes that data to unauthenticated requests, the impact can be real.

Patch the plugin, but don’t stop there. Combine patching with defense-in-depth: server rules, WAF virtual patches, logging and alerts, and routine audits of content and user accounts. If you’d like help during the update window or want to reduce the time between disclosure and protection, our team can deploy emergency WAF protection and help you validate that your site is no longer exposed.

Stay safe, and if you need assistance, consider starting with the free WP-Firewall Basic plan to get managed protection turned on for your site quickly: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

— Het WP-Firewall Beveiligingsteam