Borlabs Cookie save blocked as XSS in fallbackCode

  • weckler

    (@weckler)


    3 days, 19 hours ago

    Hello Wordfence team,

    An authenticated save of a Borlabs Cookie Google Analytics service was blocked on 23 September 2026 at 18:38:09 UTC with HTTP 403. The recorded Wordfence reason is “XSS: Cross Site Scripting in POST body: fallbackCode”. The target was the regular /wp-admin/admin.php Borlabs service editor. The historical full POST payload and a numeric rule ID were not preserved. We have not repeated a production write merely to reproduce the block.

    Recorded versions on 24 September: Wordfence 9.0.1, Borlabs Cookie 3.4.4, WordPress 7.1.2, PHP 8.3.33. These are observed installation versions, not a claim about current releases. WAF is Enabled and Protecting with Basic WordPress Protection and Community rules.

    On 26 September at 15:52 UTC, a manual rules refresh returned “Rules updated” successfully. Live Traffic filtered by URL contains borlabs-cookie-services, with All Hits and no date filter, showed no matching retained requests. Neither observation confirms a fix for the historical block.

    Two older exceptions already exist for request.body[optInCode] and request.body[optOutCode] on /wp-admin/admin.php, listed as added via the false positive dialog on 5 September. They were not added or changed for this investigation. No fallbackCode exception is listed.

    Borlabs referred the Wordfence-specific question to your team. The separate consent-configuration question remains with Borlabs. We request a supported diagnosis:

    1. What minimum read-only evidence and rule identifier do you need, and how can we obtain them through the normal plugin interface?
    2. Is there a secure non-public channel for a limited sanitized code sample if required? We will not post credentials, tokens, full logs or customer data here.
    3. Is a rule or compatibility correction available without adding an exception, using Learning Mode, disabling a rule, obfuscating code or bypassing the normal save route?
    4. How should the necessity of the two existing exceptions be assessed without changing production protection first?
    5. Before today’s successful manual refresh, the next scheduled rule check was displayed as 30 September 2026, 14:20 UTC. Which limited diagnostic confirms whether scheduling is functioning correctly?

    Extended Protection is a separate pending hardening task requiring configuration-file backups and an independent recovery path. We do not assume that enabling it would resolve this POST block. Thank you.

Viewing 1 replies (of 1 total)
  • Plugin Support wfpeter

    (@wfpeter)

    1 day, 18 hours ago

    Hi @weckler,

    I do feel that Learning Mode or manually allowlisting a blocked item from your Live Traffic is likely to be the best solution despite your request to not use any of that in point 3 (above). As the rule catching it is a general XSS one, allowing the specific request for your use-case should ensure malicious attempts are still blocked in future. Disabling the rule to allow this one through would be the less secure solution.

    To resolve it without, add the allowlist entry either from the prompt that appears the next time the save is blocked, or manually under Firewall > All Firewall Options > Allowlisted URLs. That will match your two existing entries.

    To your questions:

    1. Evidence and rule ID: Not needed. The recorded reason and field name are enough to identify the cause. If you want to review blocks yourself, they appear in Live Traffic while retained, and in email alerts if those are enabled.
    2. Private channel: Not required for this issue.
    3. Fix without an exception: No. The rule deliberately matches script content, and a field built to store scripts will keep matching it. A parameter allowlist entry for request.body[fallbackCode] on /wp-admin/admin.php is the supported fix. It applies only to that field on an admin endpoint that still requires login, capability checks and a valid nonce.
    4. Existing exceptions: They cover the same kind of field for the same reason, and they’re what allows those fields to save. Removing them would bring the blocks back.
    5. Scheduling: Wordfence > Tools > Diagnostics > Cron Jobs shows the status of scheduled tasks and if any are overdue.

    I wouldn’t recommend Basic Protection over Extended Protection unless absolutely necessary for your server environment. In Extended Protection, Wordfence will run immediately after PHP starts (but before WordPress loads) to serve as little site content as possible to blocked IPs.

    Many thanks,
    Peter.

Viewing 1 replies (of 1 total)

You must be logged in to reply to this topic.