• hargitt

    (@hargitt)


    We are seeing what appears to be a false positive related to the official Raptive Ads plugin and wanted to report it so you can review the signature.

    Environment

    • Plugin: Raptive Ads
    • Version: 3.12.2
    • Wordfence issue type: Obfuscated:JS/parser.13743
    • Typical matched text:
      parseInt(k(0x124,'j*ih'))...
    • Files initially flagged:
      cached WP Rocket HTML files under:
      wp-content/cache/wp-rocket/.../index-https.html

    After clearing cache and rescanning, the issue reappeared across many cached pages, so we traced the source further.

    What we found
    The flagged code is coming from the official Raptive plugin code path, specifically their Ad Block Recovery functionality.

    Relevant local plugin findings:

    • wp-content/plugins/adthrive-ads/js/adblock-recovery.js
      contains:
      • script id Tqgkgu
      • load of https://html-load.com/loader.min.js
      • obfuscated inline JS
    • wp-content/plugins/adthrive-ads/components/ads/class-scheduled.php
      fetches:
      cls-disable-ads.min.js
      from:
      https://ads.adthrive.com/builds/core/<hash>/js/cls/
    • wp-content/plugins/adthrive-ads/components/ads/class-main.php
      injects that payload into wp_head via:
      insert_cls_file('cls-disable-ads', $data);

    Vendor confirmation
    We opened a ticket with Raptive, and they confirmed the following:

    • this is not malware or a supply-chain compromise
    • the obfuscated JavaScript is expected as part of their Ad Block Recovery feature
    • adblock-recovery.js is an official plugin file
    • cls-disable-ads.min.js is an expected dynamically fetched file
    • domains such as html-load.cc, error-report.com, and report.error-report.com are part of their ad block recovery system
    • they state security tools may flag this behavior because it uses obfuscation, dynamic loaders, and multi-domain fallback logic

    Request
    Could you please review this detection and determine whether this should be treated as a false positive for the official Raptive Ads plugin / Ad Block Recovery path, or whether the signature can be narrowed so it does not flag this official behavior?

    Given the number of affected cached files, this can look alarming to site owners, so any clarification or whitelisting guidance would be very helpful.

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Support wfphil

    (@wfphil)

    Hi @denver52

    To clarify, are you getting CRITICAL Wordfence scanner scan results for:

    1. Raptive Ads plugin files only?
    2. WP Rocket cached HTML files only?
    3. Both – Raptive Ads plugin files and WP Rocket cached HTML files?
    Thread Starter hargitt

    (@hargitt)

    We are getting it for the WP Rocket cached HTML files only.

    Plugin Support wfphil

    (@wfphil)

    Hi @hargitt

    Thank you for the update.

    Can you place one affected cache file in a ZIP folder and send it to wftest@wordfence.com. Make sure to put your forum username in the subject field so that I can find it. Let me know when the email has been sent.

    Thread Starter hargitt

    (@hargitt)

    I have sent the file to you via email. Following is the Wordfence alert related to this file:

    File appears to be malicious or unsafe: wp-content/cache/wp-rocket/…/index-https.html
    Type: File, Issue Found May 8, 2026 11:58 AM, status: Critical
    Details
    Filename: /home/…/wp-content/cache/wp-rocket/…/index-https.html
    File Type: Not a core, theme, or plugin file from wordpress.org
    Details: This file appears to be installed or modified by a hacker to perform malicious activity. If you know about this file you can choose to ignore it to exclude it from future scans. The matched text in this file is: +-parseInt(k(0x124,’jih’))/(-0x10x103a+0x1890x1+0xeb7)(-parseInt(k(0x12e,’Sjm5

    The issue type is: Obfuscated:JS/parser.13743
    Description: Behavior often seen in malicious JavaScript

    • This reply was modified 3 weeks, 3 days ago by hargitt.
    • This reply was modified 3 weeks, 3 days ago by hargitt.
    Plugin Support wfphil

    (@wfphil)

    Hi @hargitt

    Thank you for the update.

    I will pass the file back to the team for examonation and I will send an update once I have a reply.

    Plugin Support wfphil

    (@wfphil)

    Hi @hargitt

    May apologies for the delay.

    We have determined this is a false positive. However, the code is questionable but not really malicious. You should use the ignore option for the scan results for the time being.

    Thread Starter hargitt

    (@hargitt)

    Hi @wfphil ,

    I appreciate the team looked into this and found the code was not malicious which corresponds to the vendor assessment already provided. The original request here is to exclude this false positive instead of having to select the ignore option 100s of times each time the scan runs. This alert comes up for every cached pages so we have hundreds so it buries other potential real threads in the noise of the occurrences of this false positive.

Viewing 7 replies - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.