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

Thanks for the suggestion!

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!

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!

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!

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!

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

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

If you can fill out the 2nd level support request we can take a look for you to get you up and running ASAP:

https://interactivetools.com/support/request/

Thanks for the report! We tracked this down, and it's a timing issue with bulk uploads, not a permissions problem or an upload limit.

Two things are going on:

1. The upload form doesn't limit how many files it sends at once. Browsers used to cap this at about 6 requests per server, but on newer hosting with HTTP/2 that cap is gone, so dropping 100 images can start 100 uploads at the same time. Each one is a separate server process resizing images into thumbnails, and 100 of those at once is likely what's causing the hangs.
2. Each upload request also cleans up old temporary upload files. With that many requests running at once, they all try to erase the same files - the first one wins, and the others report "No such file or directory". The CMS was treating that as an error, but nothing is actually wrong: the file was already removed. That's the "Unable to remove file" message your client is seeing.

Here's a patch you can apply to the 3.84 site now. Both changes will also be in the next release.

In cmsb/lib/upload_storage_strategy.php (around line 123), find:

if (!@unlink($filepath)) {
    $error  = "Unable to remove file '" .htmlencode($filepath). "'\n\n";
    $error .= "Please ask your server administrator to check permissions on that file and directory.\n\n";
    $error .= "The PHP error message was: " .errorlog_lastError(). "\n";
    throw new RuntimeException($error);
}

And replace it with:

if (!@unlink($filepath)) {
    clearstatcache(true, $filepath);
    if (is_file($filepath)) {
        \Itools\Cmsb\CMS::log("Unable to remove upload file '$filepath': " . errorlog_lastError());
    }
}

Then in cmsb/lib/menus/default/edit_functions.js (around line 192), find 'multi' : true, and add this line below it:

'simUploadLimit': 10,

That uploads 10 files at a time - the rest queue up in the browser and go automatically, so your client can still select all 100 at once. It should take care of the hangs as well. After updating the .js file, have your client do a hard refresh (Ctrl+F5) so the browser picks up the new version.

Give that a try and let me know if that fixes it for your client. Thanks!

Happy to help with this one. In v3.83 we standardized the button order across all the admin pages: destructive actions (like Erase) on the far left, and the primary action (Save) always on the far right with Cancel beside it. That follows the convention Mac, iOS, and Android all use, but I can see how a change like that would throw off someone who's had years of muscle memory with the old layout.

I've attached a plugin that restores the buttons to their previous order (Cancel, Erase, Preview, Save). Just upload it to your cmsb/plugins/ folder and activate it under Admin → Plugins.

If your customer wants a different arrangement, there's a single line at the top of the plugin you can edit:

// Buttons appear left to right in the order below - rearrange as desired
// '*' is where buttons added by other plugins appear, e.g. "Save & Copy".
$buttonOrder = ['cancel', 'Erase', 'preview', '*', '_action=save'];

Rearrange those as desired. The '*' is where buttons added by other plugins (like Save & Copy) appear.

And good news on the "keep it from future changes" part: the plugin re-sorts whatever buttons the CMS generates, so the order will stick through future updates.

Let me know if that works for him!

Dave

Just tried this out.  It's really slick, nice work!  And thanks for contributing.  I'm sure a lot of people will find this helpful.

Thanks for the report! We were able to reproduce this locally and track it down, and we'll have this fixed in the next release.

If you'd like to patch it now, edit cmsb/lib/data-attr-handlers.js and search for "element.blur()"

And replace this:

                if (!confirm(message)) {
                    e.preventDefault();
                    e.stopImmediatePropagation();
                    element.blur();
                }
            }
        });

With this (adding ", true" before the final brace):

            if (!confirm(message)) {
                    e.preventDefault();
                    e.stopImmediatePropagation();
                    element.blur();
                }
            }
        }, true);

That makes the confirmation dialog run before anything else, so Cancel works again.

Hope that helps, and thanks so much for the bug report and confirmation!  Let me know if you any other questions.

The issue is that a checkbox column doesn't support the same data types as a text box. A text box stores NULL by default (or an empty string once you've saved content), but a checkbox only supports 1 or 0, never NULL. It's the same even if the text box had real content in it, since MySQL can't map arbitrary text to a number.

If the field is empty, the easiest fix is to just erase it and create the checkbox fresh. Or you can convert the existing values to 0 first:

UPDATE `your_table` SET `my_field` = 0 WHERE `my_field` IS NULL OR `my_field` = '';

Once the data in the column matches what a checkbox supports (in MySQL: tinyint unsigned NOT NULL), it should let you switch the type with no problem.

Hope that helps!  Let me know any questions.

Okay, great.  Glad it's working and thanks for the update!

I found a quick fix for this.

In cmsb/api/mcp.php search for "// Dispatch" and replace it with the following:

// Block all methods (no tool list, no dispatch) while the MCP server is disabled
mcpProtocolErrorIf(!isStillEnabled(), MCP_ERR_SERVER_DISABLED, 'MCP server is disabled. Enable it at Admin → Advanced → MCP Server');

// Dispatch

That will prevent the MCP server from showing anything if it's not enabled.

Can you give that a try and let me know if that works for you?

Thanks!

That is curious. I've attached a test script that shows whether OPcache is running and the key settings it's using (which php.ini is loaded, where PHP looks for the extension, and so on).

Can you run it from a location where OPcache is already working, and again from your cmsb folder, and let me know how the two differ?

It's also worth dropping it into a parallel directory (e.g.,/opcache_test/) to see if something in the CMSB .htaccess or config files is affecting it.

Let me know what you find. Thanks!

That notice just means the plugin is checking if it needs to create your accounts table on every page load. Newer CMSB versions save schema files as .schema.php, but your plugin is still looking for the old .ini.php files. It never finds them, so it assumes the table still needs creating and runs the full schema sync (and logs that notice) on every page view.

It's harmless, though, your table is fine, and logins work. It's just extra work each load, and your pages will load faster if you fix it. So a few options:

• Leave it. If the log noise doesn't bother you, ignore it. Nothing's broken.
• Quick fix. Your accounts table already exists, so you can just comment out the createMissingSchemaTablesAndFields(); call on line 360 of your custom plugin. 
• Proper fix. Download the latest Website Membership, diff it against your custom file, and merge in the schema-file check, making sure it looks for .schema.php. The sync then skips on its own once the table's set up.

Hope that helps, let me know any questions.

Yes, the CMS will automatically upgrade any .ini.php files it discovers.  Even when adding plugins or ini files after the fact.  

But if any of your plugins aren't working correctly, just download the latest version from the website.

Hope that helps!

So, with fingerprinting, any static response or file (CSS, JS, images, etc.) can be used. You just need to checksum a known response from some files from a given version of any software. There are actually some neat sites that do that (search "What CMS is this site running").

So the best solution for that is just to rename your /cmsb/ folder to something less guessable so no one can find it.

And/or, if you don't need the /api/ folder or /api/mcp.php, you should be able to safely just delete them.

But we want the UX to feel good end-to-end, so if seeing a big list of powerful tools, disabled or not, gives anyone pause, we could look into adding a one-time setting to enable it.  We have a few questions about it already.

Maybe the first time you open the MCP menu, we could have an option where you click to enable it, and until then, it returns nothing in the tools list.

Let me know if that would work for you. Thanks!

Thanks for the report, and good eye. This one's intentional, not a leak.

The tool list is static. It's the same hardcoded list on every install, and it already ships in the source you can download, so tools/list isn't handing out anything you couldn't read straight from our freely downloadable code. The only things we hold back until you authenticate are install-specific hints, like the server's working directory, OS, and shell, since those would fingerprint the actual box. Nothing in the public list is install-specific or secret.

The real security boundary is on running tools, not listing them. That's exactly what you ran into: the list comes back, but the second you try to call a tool, you get "MCP is disabled." Disabled means disabled, nothing executes, and that holds whether MCP is switched off or the auth is missing or wrong.

The other reason we always return the list is so you don't have to restart Claude every time you toggle MCP. Claude grabs the tool list once when it connects and caches it. If we only sent the list while MCP was enabled, every on/off would mean restarting Claude to pick the tools back up. Keeping the static list always on means you can flip MCP on and off, and it just works, since the tools are already known and only execution changes.

So the short version: the listing is public by design; execution is locked down.

This is also a common pattern for APIs built to be called by an external client. Plenty of public APIs serve their full OpenAPI/Swagger spec, every endpoint and parameter, to anyone, and gate only the actual calls behind a key. 

Hope that helps, let me know if you have any other questions or concerns!

Try this:

    'where'       => " category LIKE '%Telecoms%' AND num NOT IN (421,83,122)",

Just replace the numbers with the ones you want to exclude.

Let me know if that works for you.

Here's the full changelog: 

*** May 8, 2026 - Version 3.84 (Maintenance Release)

SERVER REQUIREMENTS (Since Jun 2025): PHP 8.1+ and MySQL 5.7+ (or MariaDB 10.2+)

BUG FIXES
    - Upgrade: Fixed an "Unknown column" error that could stop the upgrade partway through on older installs
        - Was caused by audit/error logging trying to write to columns the upgrade hadn't added yet
        - When the audit or error log can't write to its table, the failure and original message now go to data/_php_error.log instead
    - Developer Log: Displayed HTTP method now reads correctly from older error log entries logged in older format (was falling back to "CLI" before)

This is only needed if you got an error while upgrading or are upgrading from a much older version. If you already upgraded without issue, no action is required.

Let me know any questions. Thanks!