When to add NIcepage as an exception

Hola Jose!

One of my client's sites uses the Nicepage Page Builder extension to handle layout. It seems that some of the pages are crashing and the layouts are jumbled.
It looks like Nicepage needs full permissions to work. If you have some time can you please look into its requirements and perhaps recommend a configuration so that it can work?
I suppose I could just set SCP up to exclude Nicepage in the filters. But there are so many. Which filters would need to have it added to?

Thanks!

Hi azurelink,

Thanks for the details. Based on what you're describing, I don't think this is Securitycheck Pro's firewall blocking Nicepage — if it were, you'd see a block page and a matching entry in the SCP firewall log, and neither seems to be happening here.

What's more likely is a conflict with the .htaccess-level protection that SCP adds, specifically the backend protection layer. This works differently from the firewall: it applies Apache-level rules (similar to how mod_security works) that can silently interfere with AJAX requests, script loading, or POST size limits that page builders like Nicepage rely on heavily in the backend — which matches the crashing/jumbled-layout behavior you're seeing rather than a clean 403 block.

This actually lines up with Nicepage's own documentation: their support page for editor/save failures on Joomla and WordPress identifies ModSecurity as one of the most common causes, since it can misidentify legitimate editor requests as malicious and block them, and notes that firewall-imposed memory limits can also break the editor. Their recommended fix is the same as what I'm suggesting here — disable that protection layer temporarily to confirm it's the cause, then check the logs for the specific rule involved rather than leaving it off permanently.

Could you try the following and let me know the result?

1. In SCP, go to the .htaccess / Hardening protection settings and temporarily disable the backend protection rule.
2. Reload the affected pages in Nicepage and check whether the layout and crashing issue is resolved.
3. If it's still failing, also try disabling the firewall entirely. If the problem persists with both disabled, the firewall isn't the culprit either, and we're looking at something else (mod_security). In that case I'd ask your hosting provider to check their mod_security logs, since that layer runs at the server level and isn't something SCP controls.

Let me know how it goes.

Regards,
Jose

Thanks for your quick reply, Jose.
Unfortunately, we were working on the issue and did the following things:

1. Added com_nicepage to the XSS, LFI, and Second Level Filters.
That allowed us to save and test, which we couldn't do before.
Then we...
2. Created some custom CSS to allow sections to have auto-height which fixed the overlap issue(s).

Apparently, Nicepage Builder has an issue where it does not allow blocks to have an option to assign auto height. Which in turn was causing all the content to be displayed in overlap.

If the issue repeats, I will implement your suggested testing procedure.

Of course, I have no idea how those specific SCP filter exceptions would have affected the issue, LoL!

Another note...
SCP flagged the following file as having malware:
/var/www/vhosts/mysite/administrator/components/com_nicepage/helpers/forms/FormProcessor.php

Pattern 84 - Superglobal as function call.Found 1 occurence(s).Details: Calling a function whose name comes directly from a superglobal. Very compact webshell technique used to execute arbitrary code.

I ran a maldet scan of the file and it came back clean. Should I add it as an exception?

Hi azurelinksc,

Glad you got it working! And that actually explains a lot.

Nicepage saves its layout data as raw inline CSS/HTML through com_nicepage's own endpoints, and that kind of payload can look like an XSS or LFI attempt to a generic pattern-matching filter — style attributes, inline `<style>` blocks, path-like values in CSS, etc. So it's very plausible those specific filters were the ones blocking the save requests, which is why excluding com_nicepage from XSS, LFI, and Second Level fixed it. That's a different layer from the backend .htaccess protection I mentioned, so both could technically have been involved — good that you isolated it by testing directly.

One thing worth checking when you have a moment: if you still have last week's SCP firewall log, a quick look at the entries from before you added the exclusions would show which exact rule/filter was triggering on the save requests. Not urgent, but it'd help me note this as a known Nicepage compatibility pattern for other users hitting the same thing.

And nice catch on the auto-height bug — good it was isolated as a genuine Nicepage limitation and not something on the security side.

On the FormProcessor.php flag: Pattern 84 is a heuristic, not a malware signature — it flags the file as suspicious because of the coding pattern (calling a function whose name comes from a superglobal), not because it matched known malicious code. It's a technique real webshells use, but legitimate extensions occasionally do it too for dynamic dispatch. Since maldet came back clean on it, go ahead and mark it as an exception.

If you can attach the file itself (as a zip file), I'd like to take a look to confirm it's a false positive on my end too, and see if I can refine that pattern so it doesn't flag this specific case going forward.

One more thing for down the line: in the next SCP version, you'll be able to mark detections like this as "reviewed" instead of adding a full exception. That's tied to the file's hash, so the alert stays hidden only as long as the file doesn't change — if FormProcessor.php is ever modified (by an update or otherwise), the alert will automatically reappear. That'll be a bit safer than a blanket exception for cases like this.

Thanks for the update, and let me know if anything comes back up.

Regards,
Jose

 I've uploaded the zipped Formprocessor.php file for your review. Looks like a variant of phpmailer.

 

As for the logs, the type were XSS and File Upload.

First one is: Type: XSS Tags stripped from string (possible XSS attack) [POST:data]

In the String field it is the code from in the <html> <head> tag. Stylesheet links, script links, etc., other meta data. I'm attaching a txt file with that info.

 

Next:
Type: Upload
Description: Upload Scanner (File Deleted)
String:
IMG_2495.JPG Mime-type not allowed: PHP/script content in image file [full_uri]: /administrator/index.php?option=com_nicepage&38cc7a63fe11e5401a13a172e1e72716=1&task=actions.uploadImage

---

NEXT:

Type: XSS
Description: Tags stripped from string (possible XSS attack):

<span style="height: 64px; width: 64px; margin-left: 0px; margin-right: auto; margin-top: 0px; background-image: none; right: 20px; bottom: 20px; padding: 15px;" class="u-back-to-top u-icon u-icon-circle u-opacity u-opacity-85 u-palette-1-base" data-href="#"> <svg class="u-svg-link" preserveAspectRatio="xMidYMin slice" viewBox="0 0 551.13 551.13"> <use xmlns:xlink=" www.w3.org/1999/xlink " xlink:href="#svg-1d98"> [full_uri]: /administrator/index.php?option=com_nicepage&38cc7a63fe11e5401a13a172e1e72716=1&task=actions.saveSiteSettings