[#47860] - [5.4] security: add allowed_classes to unserialize() in cache controllers and com_finder models
- Pending
- Medium
- Build: 5.4-dev
- # 47860
- Diff
- XananasX7:security/cache-controllers-allowed-classes
User tests: Successful: Unsuccessful:
Pull Request resolves #
- 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
This PR adds allowed_classes to unserialize() calls in several Joomla cache controller and search components.
Affected locations:
libraries/src/Cache/Controller/— PageController, OutputController, ViewCacheController, CallbackControllercomponents/com_finder/src/Model/SearchModel.php— deserializes search state from session
Risk: Without allowed_classes, an attacker who can write to the cache backend or session can trigger PHP Object Injection. For file-based caches the risk requires filesystem write access, but for Redis/Memcached backends a compromised shared cache server is sufficient.
Fix: Restrict each unserialize() to only the specific classes legitimately stored in each location.
Testing Instructions
- Apply the patch.
- Test the page/output/view/callback cache scenarios work normally.
- Test com_finder search with filter state works normally.
Actual result BEFORE applying this Pull Request
unserialize() calls in cache controllers and com_finder have no class restrictions.
Expected result AFTER applying this Pull Request
unserialize() is restricted to only the expected classes at each call site.
Link to documentations
- No documentation changes for guide.joomla.org needed
- No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_finder Front End Libraries |
Apologies @brianteeman — PR description has been updated with the full template including summary, testing instructions, before/after results, and documentation checkboxes.
muhme
- | Title |
|
||||||
| Labels |
Added:
Updates Requested
PR-5.4-dev
|
||
Summary of Resolution to Backward Compatibility Concerns
Thanks @SniperSister for the detailed feedback. The latest commits (specifically 55fadc18 and the merge 60342fbe) address your b/c concerns with a two-phase fallback strategy.
How the Fallback Works
For cache controllers (Page, Output, View, Callback):
The implementation tries secure deserialization first, then falls back for old cache entries:
// Try secure deserialization first
$data = @unserialize($trimmed, ['allowed_classes' => false]);
// Fallback for backward compatibility: if secure unserialize failed
// and the serialized data is not boolean false
if ($data === false && $trimmed !== 'b:0;') {
// Legacy fallback to preserve existing cache entries that store objects
$data = unserialize($trimmed);
}
two-phase fallback strategy.
that’s not a fallback strategy - it’s just killing any potential security benefit any and makes the changes completely irrelevant.
There was a reason that you were given a template to complete when you submitted this PR. Please update your pr with the required information. You can find the template here https://github.com/joomla/joomla-cms/blob/5.4-dev/.github/PULL_REQUEST_TEMPLATE.md
In addition please read https://github.com/joomla/joomla-cms/security