Flood notification: Event Triggered: user_ban_flood ->> Fatal error:?

[Alex-e107nl]

@e107help Hi it seems like there's a problem with certain links being called to scan e107 websites:

https://********.nl/nieuws/?page=%29%2F**%2FAND%2F**%2F%28199285712%3D199285712%2F**%2FUNION%2F**%2FALL%2F**%2FSELECT%2F**%2FNULL%2CNULL%2CNULL%2C%27nxxtxdwfockkdvqtjhryvodbfajtiesx%27%2CNULL--%2F**%2Fiwbdh9

Gives:

Fatal error: Uncaught TypeError: Unsupported operand types: string - int in /home/********/domains/********/private_html/e107_plugins/news/news.php:442 Stack trace: #0 /home/********/domains/********/private_html/e107_plugins/news/news.php(83): news_front->setPagination() #1 /home/********/domains/********/private_html/e107_plugins/news/news.php(2107): news_front->__construct() #2 /home/********/domains/********/private_html/news.php(23): require_once('...') #3 /home/********/domains/********/private_html/index.php(107): include('...') #4 {main} thrown in /home/********/domains/********/private_html/e107_plugins/news/news.php on line 442

But it should give a error page?

A lot of these scans are captured by modsecurity but this one not:
[Sun Aug 30 04:48:57.184924 2026] [proxy_fcgi:error] [pid 3248396:tid 3248430] [remote 217.62.133.37:57578] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught TypeError: Unsupported operand types: string - int in /home/********/domains/********/private_html/e107_plugins/news/news.php:442\nStack trace:\n#0 /home/********/domains/********/private_html/e107_plugins/news/news.php(83): news_front->setPagination()\n#1 /home/********/domains/********/private_html/e107_plugins/news/news.php(2107): news_front->__construct()\n#2 /home/********/domains/********/private_html/news.php(23): require_once('...')\n#3 /home/********/domains/********/private_html/index.php(107): include('...')\n#4 {main}\n thrown in /home/********/domains/********/private_html/e107_plugins/news/news.php on line 442'

Can you check this?

PHP Version 8.2.33 e107 Version 2.4.0 (git) (28/08/2026)

[e107help[bot]]

@Alex-e107nl Confirmed, and it is ours rather than anything the scanner got through with. I reproduced it: on master that URL comes back with your fatal at news.php:442 and the same three frames, and on release/v2.3.x the same code sits at line 436.

Until a fix lands, the quickest way to stop it is the news preference: Admin > News > Preferences, General tab, set Pagination back to Record. The crashing block only runs while it is set to Page (news.php#L430), and Record is what e107 ships. It is not free: under Record the number in a news URL is a record offset rather than a page number, so an existing bookmark or an indexed ?page=2 lands somewhere else. Your own links are rebuilt either way.

What goes wrong. news_front::setPagination() subtracts before it casts, in both arms of the switch (#L438, #L442):

$this->from = (int) ($_GET['page'] - 1)  * ITEMVIEW;

PHP 8 refuses to subtract 1 from a non-numeric string, so it throws the TypeError and the (int) that would have made the value safe never runs. On PHP 7 that same line read the string as zero and served page 1 without complaint, which is why this surfaced on the move to 8.

Nothing was injected. The cast wraps the whole expression, so $this->from is an integer on every path that does not fatal, and no part of that probe string reached the database. Worth a separate look on your own server, though: what you pasted first is what a browser receives, and it carries your absolute document root, the plugin path and four frames. That is display_errors left on in production, which e107 does not set anywhere, so it is a php.ini line you can turn off today whatever happens to the fix. The reason to fix the crash is the one you gave: a rubbish query string should give a page, not a stack trace.

The user_ban_flood notice is a separate thing, and that one is working as intended: flood protection reacting to the rate the scanner was hitting you at. If the notification itself looks wrong rather than merely unwelcome, say so and I will look at it properly.

The fix, one pull request per branch:

• master: fix(news): keep a non-numeric ?page out of the pagination arithmetic #6130
• release/v2.3.x: fix(news): keep a non-numeric ?page out of the pagination arithmetic #6131

A ?page value that is not a number becomes page 1, which is what the two readers just above it already do with rubbish (#L402, #L417). A third, at #L658, builds the canonical URL and turns rubbish into page=0; that one is untouched here. A numeric one goes through the arithmetic it always did, so page 2 is still page 2, and the offset is floored at nothing and capped so an eighteen-digit page number cannot overflow it. Rendered HTML and the generated URLs are untouched. Your scan URL is in an acceptance test that fails without the fix.

Whether and when either one is merged is Deltik's call.