baserCMS EUVD-2026-108983

Exploitation requires that an administrator installs the BcCustomContent plugin (which is NOT in BcApp.defaultInstallCorePlugins, so it is absent from default installs) and leaves the pre-selected 'available to all users' radio during install - that acceptance is precisely what causes PermissionGroupsService::build() to write the wildcard allow rules (url /baser/<prefix>/bc-custom-content/*, method *, auth true) for every non-admin group because BcCustomContent ships no config/permission.php. Given that, the attacker needs only an account in the default 'operators' group. The attacker then edits the custom field's allowed upload extensions to 'php' (validated only against /^[a-z,]+$/ in CustomFieldsTable.php:140, and used verbatim as the allowlist in CustomEntriesTable.php:337-358) and uploads a .php file that is served as executed PHP. Limiting factors: requires administrator installation of a non-default plugin plus acceptance of the default radio; requires an authenticated operator-level account; reproduction was confirmed only on Apache (apache2handler); on releases before 5.1.10 the extension-editing step is unnecessary because setValidateFileExt() skips the check when file_ext is empty. USE_CORE_API and USE_CORE_ADMIN_API are false in the shipped .env.example.

This is a genuine high-severity flaw (CVSS 4.0 8.5) but its real-world urgency is tempered by chained preconditions rather than being a drive-by remote exploit. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:A/VC:H/VI:H/VA:H) is internally consistent with the mechanism: network-reachable, low attacker privilege (a default 'operators' account), but requiring active user interaction - here supplied by an administrator who installs BcCustomContent and accepts the pre-selected 'available to all users' radio, which is what writes the wildcard permission rules. The vuln.today Decision label is 'this_week', consistent with a serious-but-not-emergency priority. No EPSS score and no CISA KEV status are present in the input, so there is no signal of widespread or active exploitation; exploitation status is therefore 'no public exploit identified at time of analysis' in the KEV sense, but note a detailed, reporter-demonstrated reproduction is published in the GHSA advisory (a public PoC reference exists; it is not verified as packaged working exploit code beyond the single commit 02d37a7 the reporter ran it on). No SSVC exploitation/automatable/technical-impact decision points are supplied beyond the Decision label. The limiting factors - an administrator must install a non-default plugin and leave the default radio, and the attacker needs an authenticated operator account - mean this is a real priority for baserCMS 5.x operators but not mass-exploitable against default installs, since BcCustomContent is absent from BcApp.defaultInstallCorePlugins.

An administrator installs the BcCustomContent plugin and leaves the pre-selected 'available to all users' radio, which writes wildcard allow rules granting the default operators group full access to the plugin's screens. An attacker holding only an operators account then creates a custom BcCcFile field, edits its allowed extensions to 'php' (the value is only checked against /^[a-z,]+$/), uploads a PHP webshell through a custom entry, and requests it under /files/ to execute arbitrary code as the web server user. A detailed working reproduction of this chain is published in the GHSA advisory.