[#48170] - [5.4] [AI] Prevent arrays from poisoning scalar user state
- Closed
- 9 Sep 2026
- Medium
- Build: 5.4-dev
- # 48170
- Diff
- carrerasdarren-cell:fix-user-state-array-poisoning
User tests: Successful: Unsuccessful:
Pull Request resolves #48158.
Credit to @CyrusXxXxX for reporting and documenting the original issue.
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Summary of Changes
CMSApplication::getUserStateFromRequest() now infers whether arrays are
expected from the caller's default and explicit filter.
- An array returned by a scalar filter no longer replaces scalar user state.
- Previously stored array state is repaired to the scalar default.
- Intentional array defaults and explicit
array,raw, ornonefilters
keep their existing array behavior. - Unit coverage exercises rejected array input, repaired stored state, normal
scalar input, and intentional recursively filtered arrays.
Testing Instructions
- Run:
libraries/vendor/bin/phpunit tests/Unit/Libraries/Cms/Application/CMSApplicationTest.php - Confirm all four tests and eight assertions pass.
- Optionally request a core list view with an array parameter such as
limit[]=5, then confirm scalarglobal.list.limitstate is not replaced
by an array.
Validation performed locally:
- Focused test file: 4 tests, 8 assertions
- Application unit-test directory: 5 tests, 10 assertions
- Full unit suite: 1,133 tests, 1,640 assertions
- Focused PHPStan: no errors
- Joomla PHPCS on both changed files: pass
git diff --check: pass
Actual result BEFORE applying this Pull Request
An array request filtered as uint remains an array because Joomla Framework's
input filter recursively filters array values. The application persists that
array into scalar session state such as global.list.limit.
Expected result AFTER applying this Pull Request
Scalar user state remains scalar. Array input is ignored for scalar state, and
already poisoned state is repaired to the caller's scalar default. Callers that
intentionally expect arrays retain their existing behavior.
Link to documentations
Please select:
-
No documentation changes for guide.joomla.org needed
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries Unit Tests |
| Labels |
Added:
Unit/System Tests
PR-5.4-dev
|
||
I have tested this item ✅ successfully on 607247e
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48170.
I have tested this item ✅ successfully on 607247e
I have tested this item successfully using the Joomla! Patch Tester. The unsupported operand types: int / array error was resolved after applying the patch, and no issues were observed during testing.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48170.
I have tested this item ✅ successfully on 607247e
I have tested this item successfully using the Joomla! Patch Tester. The unsupported operand types: int / array error was resolved after applying the patch, and no issues were observed during testing.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48170.
| Labels |
Added:
PBF
|
||
| Status | Pending | ⇒ | Ready to Commit |
RTC as it has 2 successful human tests.
But I am not sure if this PR might break something. The method modified by this PR is widely used, and we haven't been reported any issues with that.
So I will also set the RMDQ (release managers decision queue) label, and we will have a deeper look on it.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48170.
RTC as it has 2 successful human tests.
But I am not sure if this PR might break something. The method modified by this PR is widely used, and we haven't been reported any issues with that.
So I will also set the RMDQ (release managers decision queue) label, and we will have a deeper look on it.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48170.
| Labels |
Added:
RTC
RMDQ
|
||
Thanks for requesting the broader compatibility review. At e54cf1be865e6f36c0ac32c641dc9197aed94c67, a static inventory found 61 literal application-level calls. The four explicit collection callers all pass [] and 'array': the ListModel filter/list paths, SqlField and Scheduler. Five calls omit the filter and retain the permissive 'none' default. The separate ListModel::getUserStateFromRequest() implementation does not delegate to this method, so its 32 model calls were excluded from that inventory.
With 14 additional positive compatibility cases and the two existing positive tests, the selected run passes against both the current application method and its pre-change version from cd2cf04f884885f8492f0535964985cf03ddaf2d: 16 tests, 32 assertions on each, using PHP 8.5.8 and PHPUnit 9.6.34. The final current tests also pass on PHP 8.4.25. This covers ordinary scalar updates, missing inputs and explicitly permitted collection state, including Scheduler's nested ordering shape. It is a focused unit check, not a full application or extension test. Syntax, PSR-12 and the configured PHP CS Fixer checks passed.
This does not establish universal backward compatibility. The intended behavior change concerns arrays where neither the default nor the filter declares collection use. The API still documents a mixed return, and extensions, dynamic defaults and existing state need release-manager judgment. I agree that RMDQ should remain until that compatibility decision is made.
AI assistance was used for this compatibility inventory, test expansion and response.
Thanks for you PR sadly that's against how our input framework works. At the moment it's an unsolved issue, what you can do is to fix it on the position where the variable is used and check if it's a array.
| Status | Ready to Commit | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-09-09 17:17:03 |
| Closed_By | ⇒ | HLeithner |
I have tested this item ✅ successfully on 607247e
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48170.