This is a bug that we're aware of, and it should be fixed in an upcoming update to the plugin. However, in the meantime, here's how you can get it working.

Starting from a fresh copy of CSV Import 1.18 (https://interactivetools.com/plugins/csv-import/)

In csvImport_functions.php, on line 252, change this:

[$colValues, $offset] = _csvParser_getNextLine($csvFilepath);

to this:

$nextLine = _csvParser_getNextLine($csvFilepath);
if (!$nextLine) { break; }
[$colValues, $offset] = $nextLine;

And then on line 503, change this:

[$colValues, $offset] = _csvParser_getNextLine($csvFilepath, $setOffset);

to this:

$nextLine = _csvParser_getNextLine($csvFilepath, $setOffset);
if (!$nextLine) { $done = true; break; } // end of file
[$colValues, $offset] = $nextLine;

Let me know if you have any further issues!

Thanks,

I removed the array function preset in the array_functions.php file when I moved to PHP version 8.5 to correct for PHP now using a preset array and I'm now receiving the following error when importing:

Warning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as arrayWarning: Cannot use bool as array

Sure, we'll include that in the next release.

Thanks for the suggestion!

Any chance the addCronJob function (well, actually cronExpression_getValidValuesForField) can be updated to support */number support? e.g. 

*/2 * * * *

instead of having to write

0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58 * * * *

Thanks!

Thanks for posting this, and for the detailed write-up. Your post was actually the first place I saw it.

I've confirmed it on php.net. Their Oct 23 notice says the Oct 21 releases don't fix this one. The fix and the full advisory will come in PHP's next regular release, and until then they haven't published how the issue works: https://www.php.net/archive/2026.php#2026-10-23-1

Here's a patch anyone can apply now to be extra safe, and we'll include it in the next release as well.

In cmsb/lib/SessionHandler.php, search for this line:

ini_set('session.serialize_handler', 'php');

And replace it with this:

// CVE-2026-115560: temporary workaround until servers install PHP's fix.
// Reference: https://www.php.net/archive/2026.php#2026-10-23-1
// Attackers could potentially run code, but only when all three of these are true:
// - phpinfo() shows session.serialize_handler as php_serialize or php_binary (not the default, php)
// - the line below switches it to php
// - session.upload_progress.enabled is on, which is PHP's default
// Once most servers run a PHP version that fixes this CVE, delete this note and uncomment the line below.
//ini_set('session.serialize_handler', 'php'); // Use PHP's built-in session serialization

On servers where session.serialize_handler isn't set to php, existing sessions won't load after this change, so users will need to log in again once. Servers using PHP's default won't notice any difference. Versions before v3.67 don't have this line and don't need the patch.

Setting session.upload_progress.enabled = 0 server-wide, as you described, is still a good idea. It also covers one of the php2shell issues on servers that haven't been updated yet.

Thanks again for the heads up! Let me know any questions or more news.

Thanks for posting the error. There are two ways to fix it:

• Upgrade to v3.81 or later, which supports PHP 8.5.
• Or remove the array_first() function from cmsAdmin/lib/array_functions.php (it starts at line 6).

We've had our own array_first() function in CMS Builder for years, because PHP didn't have one. PHP 8.5 added its own array_first(), and PHP doesn't allow two functions with the same name, so now the two conflict. Newer versions of CMS Builder use PHP's built-in version instead.

Hope that helps, let me know any other questions.

Thanks!

Thanks so much for the detailed report and the workaround!

We've added both fixes for the next release (v3.85): the Media Library deprecation notice, and fallbacks for when a host disables disk_total_space() or disk_free_space(). Your plugin will work around it until then.

We want to support the default configurations of big providers like Hostinger Cloud, so reports like this help. Feel free to post anything else you run into.

Thanks!

What we did for php2shell

We manage our own server, and all of our CMS Builder sites are now patched:

• We updated PHP to 8.3.36.
• We moved everything that was still on PHP 8.1 to 8.3: webmail, phpMyAdmin, our internal APIs and a few older sites. There will never be an official 8.1 release with this fix, so moving was the only real option.
• We removed the old PHP versions (7.3, 7.4 and 8.1) from the server completely, so nothing can fall back to them.
• We updated the control panel software and the rest of the server stack.

If you run DirectAdmin: phpMyAdmin and Roundcube run on the server's own PHP. If an old PHP version is still installed for them, they're still exposed even after your websites are updated.

Attack attempts are real. Cloudflare reported millions of exploit attempts within a day of the announcement, so please don't put this off.

The new one: CVE-2026-115560 (October 23)

The PHP releases Dave listed do not fix this issue. PHP rates it unlikely, and there's no emergency release. The fix will come in the next regular release. A site is exposed when all of these are true:

1. The server's php.ini setssession.serialize_handlertophp_binaryorphp_serialize.
2. The application changes it tophpwithini_set()before callingsession_start().
3. Session upload progress is on, which is PHP's default.

CMS Builder always does #2. In webadmin/lib/SessionHandler.php, register() calls ini_set('session.serialize_handler', 'php') before the session starts. That's harmless on a default server, where the handler is already php. But on a host whose php.ini uses php_serialize or php_binary, a CMSB site meets all three conditions.

What to do (one setting)

Set this in php.ini or in your PHP-FPM pool config, then restart PHP:

session.upload_progress.enabled = 0

• Don'tset it withini_set()or.user.ini. PHP says it has to apply before the request is processed.
• This is also one of PHP's listed mitigations for CVE-2026-109619, one of the two php2shell flaws. If you already turned it off for that, you're covered.
• To check your server, look atsession.serialize_handlerandsession.upload_progress.enabledin phpinfo (CMS Builder: Admin → General Settings → Server Info).
• On shared hosting, ask your host to turn it off.

We turned it off server-wide on October 23. The only side effect we've seen is that phpMyAdmin's import progress bar no longer shows.

Dave, would it make sense for CMSB to skip that ini_set() when the server's handler isn't already php? Or Server Info could flag a non-default handler while upload progress is on. Either would protect anyone whose host doesn't make the change.

Links:

• PHP's advisories:https://www.php.net/archive/2026.php
• Tenable's FAQ on php2shell:https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote

Fatal error: Cannot redeclare function array_first() in /home/creditsc/public_html/cmsAdmin/lib/array_functions.php on line 6 Stack trace: #0 /home/creditsc/public_html/cmsAdmin/lib/init.php(26): Itools\Cmsb\init() #1 /home/creditsc/public_html/cmsAdmin/lib/viewer_functions.php(13): require_once('/home/creditsc/...') #2 /home/creditsc/public_html/collections/workAccounts.php(8): include_once('/home/creditsc/...') #3 {main}

Just a heads up, you may have already heard about this. This week, PHP released fixes for two critical security issues called php2shell (CVE-2026-109618 and CVE-2026-109619). They let someone run their own code on your server, with no login, just by sending a request to a PHP page. Attack attempts have already been reported.

This is a bug in PHP itself. It has nothing to do with CMS Builder or any other website software. If your server runs PHP and has even one PHP file accessible from the web, it's affected, no matter what else is on it.

This is the most serious PHP security issue we've seen in over 10 years.

What to do: upgrade PHP to one of these versions or newer:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1 and older are end-of-life, so there's no official release with this fix. The PHP team published fix code for 7.4, 8.0, and 8.1 for people who build PHP themselves, and some hosts and support vendors provide patched versions. If you're on 8.1 or older, upgrade to 8.2 or newer, or check with your host to confirm you're running a patched version.

If you're on shared hosting or aren't sure what you're running, check with your hosting provider. You can see your PHP version in CMS Builder under: Admin → General Settings → Server Info

If you manage your own server: Plesk and cPanel each run their own separate copy of PHP for the control panel, and updating your website PHP doesn't update it. Make sure you're running the latest control panel update, and restart your server after you update.

More details are on the PHP site: https://www.php.net/archive/2026.php#2026-10-21-5

Let me know any questions.

Thanks!

Migrating a site to Hostinger Cloud (CMSB v3.84, testing on PHP 8.1 and 8.5) and ran into two issues:

1. Media Library Deprecation Notice (PHP 8.1+)
- Error: Deprecated: Using null as an array offset is deprecated, use an empty string instead in /lib/menus/default/list_functions.php on line 284
- Trigger: Viewing the Media Library list (admin.php?menu=_media)
- Workaround: Suppressed for now. Edit: set to PHP 8.1

2. Fatal Error: disk_total_space() and disk_free_space()
- Issue: Hostinger disables both functions via disable_functions in php.ini.
- Cause: In PHP 8+, invoking a disabled function throws a fatal "Call to undefined function" error. CMSB core uses @disk_total_space(), but the @ operator does not suppress fatal undefined function errors in PHP 8. This breaks General Settings and Backup and Restore.
- Solution: Because disabled internal functions are not declared, I created a drop-in polyfill plugin (manage/plugins/hostinger_compatibility.php) to safely define them without touching core

<?php
/*
Plugin Name: Hostinger Cloud Compatibility
Description: Provides safe polyfills for Hostinger-disabled PHP functions (disk_total_space, disk_free_space).
Version: 1.00
CMS Version Required: 3.00
*/

if ( ! function_exists('disk_total_space') ) {
    function disk_total_space(string $directory): float|false {
        return 500 * 1024 * 1024 * 1024; // 500 GB fallback
    }
}

if ( ! function_exists('disk_free_space') ) {
    function disk_free_space(string $directory): float|false {
        return 250 * 1024 * 1024 * 1024; // 250 GB fallback
    }
}

Tested and verified on Hostinger - General Settings and Backups now run clean. Sanity check appreciated if core plans to handle disabled space functions differently in future or if I am misunderstanding things.
NOTE: I should probably make this return unverified instead of made-up values.

It's definitely a false positive.  And because you clicked "false positive," the vendor may whitelist our code, but it can take a little while.

If it's still not working, feel free to send me server details, and I can take a look and try to find some code that works but doesn't trigger CPGuard.

Thanks for the report!

In the code block for $colsToValues, what is 'hidden' set to?  And can you try setting it to 0 (that's a zero)?

If that doesn't work, feel free to attach your form and/or email me at dave@interactivetools.com.

Hope that helps!

All of the below is written by Claude. I’ve copied it completely so you can pick out what you need if you think it is something you could improve. Or if you think this is a host problem and I should go to them, let me know.

The issue:

After the upgrade, the site started throwing this fatal error:

Warning: require_once(/home/*********/public_html/cmsb/plugins/developerConsole/consoles/shellConsole.php): Failed to open stream: No such file or directory

Error: Failed opening required '/home/*********/public_html/cmsb/plugins/developerConsole/consoles/shellConsole.php’

I re-uploaded the file and it worked briefly, then the exact same error came back a short time later. This repeated a few times before I dug into it properly.

Root cause:

My host runs CPGuard, which includes a background malware scanner. I found the file in its quarantine log, flagged repeatedly under the signature {HEX}Malware.Expert.php.command.passthru — it's detecting shellConsole.php's use of proc_open() (the mechanism behind Shell Console's command execution) as shell-execution malware and quarantining it, then re-detecting it every time it's restored.

I understand this isn't something you can really "fix" in the sense of making proc_open()-based command execution invisible to malware scanners — a legitimate remote shell-command tool and a malicious one look identical at the code level. Given how common malware scanners are on shared/managed cPanel hosting, I'd guess this could affect other customers too, so I wanted to flag it in case it's useful.

What I did in the meantime:

Since re-uploading the file was never going to stick with the scanner re-checking this aggressively, I disabled Shell Console directly in developerConsole.php rather than keep fighting it — commented out its require_once, its pluginAction_addHandlerAndLink() registration, its entry in the dispatch() match statement, and its nav button in getNavButtons(). MySQL Console and PHP Console are unaffected and working normally. I'm aware this lives in a core-bundled file and will need to be reapplied on the next upgrade.

I've also marked the file as a false positive in CPGuard, which didn't have any effect. The file is still removed from the folder.

Thanks
Jeff

Sorry for taking so long...client went on a sabbatical or something but is back.  THANK YOU!  Works terrific! Brilliant work.

I've tested this form a LOT but I think that was prior to upgrading to v1.03 of the plugin with CMSB v3.84 (Build 3130) . Once the form is filled in by a visitor and clicks "submit" this error pops up in the browser:

Error: Column 'hidden' cannot be null in /home/xxxxxx/public_html/cecmsuAdminxxxx/plugins/formgenerator_1-03/formGenerator/formGenerator.php:125

We usually upgrade both at the same time.  So upload the latest CMSB, then switch PHP over to the latest version your hosting supports.  Then monitor the CMS Developer Log for any issues.

Our upgrade docs are here: https://interactivetools.com/docs/cmsbuilder/getting-started/upgrading/

And if you have older plugins, you may need to upgrade those as well.  But you can wait and see if they generate any errors.

Hope that helps!

I’m preparing to upgrade a fairly old but fully functional CMS Builder installation and would appreciate advice from anyone who has done a similar migration.

Current setup:

• CMS Builder v3.54 (Build 2280)
• PHP 7.4.33
• MariaDB 10.11.19
• Apache

The installation includes several custom sections, custom viewers, and some custom PHP code.

I have already created a complete staging copy, including files and database, so I'll do all testing there before touching production.

My main question is about the safest upgrade sequence.

Would you recommend:

A. Upgrading CMS Builder first while still on PHP 7.4, then moving to PHP 8.x
or
B. Moving directly to a newer CMS Builder release together with PHP 8.x?

I was considering using an intermediate CMS Builder release such as v3.59, since it appears to be one of the last versions compatible with PHP 7.x, but I would be very interested to hear what others have done in practice. Any advice and assistance would be greatly appreciated. 

Kind regards.

Andreas Lazaris

Okay, yea I'd recommend using the latest version.  Also, we have another big update coming very soon!

Error: Call to undefined function DeveloperConsole\phpConsole()

#0 Script started at /home/xxx/public_html/cmsb/admin.php:0
#1 require() at /home/xxx/public_html/cmsb/admin.php:81
#2 include() at /home/xxx/public_html/cmsb/lib/menus/default/actionHandler.php:62
#3 admin_dispatchAction() at /home/xxx/public_html/cmsb/lib/menus/admin/actionHandler.php:30
#4 require() at /home/xxx/public_html/cmsb/lib/menus/admin/actionHandler.php:81
#5 Itools\Cmsb\Admin\Plugins\activatePluginAction() at /home/xxx/public_html/cmsb/lib/menus/admin/plugins.php:20
#6 activatePlugin() at /home/xxx/public_html/cmsb/lib/menus/admin/plugins.php:261
#7 include() at /home/xxx/public_html/cmsb/lib/plugin_functions.php:309
#8 Error thrown at /home/xxx/public_html/cmsb/plugins/developerConsole/developerConsole.php:30

That error means plugins/developerConsole/consoles/phpConsole.php isn't defining the phpConsole() function it should. The file is loading (the console registrations just above that line worked), but the file's contents are seemingly not what's expected.

Can you check that file on your server? In a stock 3.82 it's 260 lines (about 10 KB), with function phpConsole() near the top. If yours is empty, truncated, or different, re-upload a fresh copy of the plugins/developerConsole/ folder and that should fix it.

If the file matches the stock one, let me know and I'll dig further.

We generally recommend running the latest release, as it includes the most fixes.   What are you trying to do?