• Resolved oliverkardos

    (@oliverkardos)


    The “Block IPs who send POST requests with blank User-Agent and Referer” option in WordFence conflicts with popular WP cache plugin called WP-Rocket, more specifically the automated preload function of the latter.

    This is undesirable and wrecks unimaginable havoc on my website. I had to manually unblock the IP of MY HOST and then disable this security option as a workaround.

    Please either:

    • add an option to whitelist WP-Rocket’s functions
    • auto-detect if the IP is the host itself, in which case don’t block it
    • add better detection on why a post request might be empty. In this case these requests are CLEARLY identified as WP Rocket/Preload in WordFence, so I am really smashing my head into the wall now on WHY Wordfence was unable to see this coming. (or neither I)

    All in all, I am super mad now, as it caused a cache failure on my website.

    Here is a screenshot of the problem:

    • https://i.kek.sh/ivwtA3Rmbhn.png
    • I hope you don’t put it in a ticket for this but handle it as an absolute emergency as WP-Rocket is an extremely popular plugin, so is WordFence, so the two of them being incompatible is a nightmare for everyone and needs immediate addressing. Thank you.

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Support wfpeter

    (@wfpeter)

    Hi @oliverkardos, thanks for getting in touch!

    I spoke directly to the QA team regarding this one as we’ve not seen a report of this nature about this feature before. The WP Rocket/Preload text on your Live Traffic screenshot is the User-Agent, so this suggests that the block occurred because the IP had previously made a request with a blank User-Agent and Referer, and was still blocked when it made this request. That could be from a different plugin, or something that the host does.

    WP Rocket wouldn’t be making POST requests to preload the cache, they would be GET requests, so we don’t think the issue is related to WP Rocket. That’s not to say this request wasn’t legitimately WP Rocket, but the original block reason is given if it blocks the IP again before the block is lifted.

    To troubleshoot the issue further, you can try looking for the earliest blocked request that was logged for the server IP, and see what it was. Live Traffic can be filtered by IP in Live Traffic’s advanced filters to make the task easier. If you could share that with us, it should confirm the original reason.

    We can consider methods of preventing this kind of blocking, but they can’t work with all hosts. For example, we can’t allow everything from the server’s own IP because on shared hosting there can be malicious sites attacking sites on the same server. Also, if we allow all hits that look like WP Rocket hits, that could be used to bypass other rules where attackers send fake requests that appear to be from WP Rocket, but have other parameters that are dangerous.

    Let me know what you find out!

    Peter.

    Thread Starter oliverkardos

    (@oliverkardos)

    Hello Peter!

    Thank you for your prompt reply & taking the time to diagnose this with your team! I really appreciate your help because this is a critical issue to me.

    Upon digging further, it seems that you are right – the were numerous questionable connections from my host to my website (shared hosting).

    Some of them don’t even have WPROCKET user agent, so then again, you are spot on! Actually, the first blocked requests were empty POST requests with empty user agents!

    I’ll contact my host and I’m sorry if this was a false alarm. However, this is a real issue (regardless of whether it’s an attack or not), I think WordFence should at least put up a warning note or an email if it blocks the address that belongs to the host, or at least in cases if it blocks an address to which cache GET requests originate from. WordFence can easily tell if the said wordpress installation has a caching plugin or not,because it can list the installed plugins.

    Thank you.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘(High Priority Bug Report) WordFence Conflicts with WP-Rocket Preload’ is closed to new replies.