Skip to content

[Security] Add allowed_classes => false to LogTarget unserialize() to prevent PHP Object Injection#19008

Open
XananasX7 wants to merge 1 commit into
craftcms:5.xfrom
XananasX7:security/logtarget-unserialize-allowed-classes
Open

[Security] Add allowed_classes => false to LogTarget unserialize() to prevent PHP Object Injection#19008
XananasX7 wants to merge 1 commit into
craftcms:5.xfrom
XananasX7:security/logtarget-unserialize-allowed-classes

Conversation

@XananasX7
Copy link
Copy Markdown

Summary

The Craft CMS debug LogTarget serializes and deserializes panel data to/from the filesystem. All four unserialize() calls in LogTarget.php lack an allowed_classes restriction.

All panel save() methods return plain PHP arrays of scalars — no PHP objects are ever legitimately stored. Adding allowed_classes => false to all four call sites prevents PHP Object Injection if an attacker can write to the debug data path.

Note: ProjectConfig already uses allowed_classes => false correctly (line 1857). This PR applies the same pattern to LogTarget.

The debug LogTarget serializes and deserializes panel data to/from the
filesystem (debug data path). Without allowed_classes => false, an attacker
who can write to the debug data directory can inject a PHP Object Injection
payload that triggers a gadget chain when the Craft debug module renders.

All four call sites operate on data produced by Panel::save() which returns
plain PHP arrays of scalars — no objects are ever legitimately stored:
- getIndexFile(): reads summary index → array of scalar summaries
- loadTagToPanels(): reads per-tag outer array + per-panel arrays
- _updateIndexFile(): reads existing manifest array

Add allowed_classes => false to all four unserialize() calls as
defence-in-depth.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant