[agentosiwp]

Summary

Hardening release for the SQL editor's serialized-data validation check.

Serialized_Data::run() (includes/Extension/SQL/Tests/class-serialized-data.php) confirms that a value being saved from the database editor is well-formed serialized PHP. It needs only the shape of the data, never the objects that data describes — but it called unserialize() without an allowed_classes restriction, so validation constructed whatever classes the value named.

This passes allowed_classes => false, the same restriction recursive_unserialize_replace() already carries since 2.6.7. That earlier sweep missed this call site; this completes it.

Reported responsibly by Raphael P. Cigana via WPScan. Detail is held until a fixed version is published.

Why validation still behaves identically

With allowed_classes => false, an object decodes to __PHP_Incomplete_Class rather than false, so the false === $test_data validity test is unaffected.

Verified by executing the real run() method against WordPress's real is_serialized(), across 18 inputs, A/B against the unpatched 2.6.7 code:

	2.6.7	this PR
save/block verdict, all 18 cases	—	byte-identical
lifecycle hooks invoked on object payloads	__wakeup, __destruct (3 cases)	none

Cases covered: plain text; serialized string / int / bool / null / array / empty array; b:0;; stdClass; an object of a class that exists; an object of a class that does not; an object nested in an array; an object nested in an object; a PHP 8.1 enum (E: token); C: (Serializable) format; and three malformed payloads (truncated array, wrong string length, wrong element count). The three malformed payloads still correctly block the save; everything else still saves.

The unpatched leg firing __wakeup/__destruct is the positive control — it proves the harness can actually observe instantiation, so "none fired" on the patched leg is a measurement rather than a blind spot.

Also audited

Every other deserialization site in the plugin was reviewed. Findings are on the internal ticket; nothing else required a change in this PR.

Version

2.6.7 → 2.6.8 (plugin header, docs/readme.txt Stable tag, docs/readme.txt + docs/changelog.txt changelogs).

Checks

• php -l clean on both changed PHP files (mirrors the CI syntax step).
• composer run check-cs (PHPCS/WPCS) clean on both changed PHP files.
• docs/readme.txt is CRLF; the edit preserves it, so the diff is 3 added lines rather than a whole-file rewrite.

Notes for the merger

• Do not tag until the release is agreed. A tag matching [0-9]+.[0-9]+* publishes to WordPress.org via trunk-release-tag.yml. The wp.org release, the public version number and the disclosure timing are Vikas's call — see the ticket.
• Next step (human): /code-review ultra <this PR#> before merge.

---

Engineer (agent-os)

[kilo-code-bot]

Kilo Code Review could not run — your account is out of credits.

Add credits or switch to a free model to enable reviews on this change.

[agentosiwp]

Updated at 775c536 — removed the Upgrade Notice section from docs/readme.txt per owner instruction (it only existed to carry the "Security release. Updating is recommended for all sites." line, now dropped). No other section changed; Changelog still reads Security: hardened serialized data processing.

Docs-only again — the fix file and its two QA PASS + code-review PASS verdicts above are unaffected.

Still human: /code-review ultra 406, merge, tag 2.6.8 (= wp.org publish, Vikas's call), confirm wp.org serving it, reply to WPScan (credit still owed there per their disclosure policy — see prior comment).

— Engineer (agent-os)

[janakkapadia]

QA: PASS ✅
Env: throwaway docker WordPress 7.1 · PHP 8.2.33 · String Locator 2.6.7 from wp.org, with only includes/Extension/SQL/Tests/class-serialized-data.php replaced by the PR head blob b2daf3be (verified byte-identical in-container; trunk blob 4b2c5b52) · PR #406 @734c9d0
Criteria: the five database-editor save cases, plus no regression to the file editor.

#	case (validate ✔ unless noted)	result
1	serialized array containing an object — unknown class O:8:"SLQA_Obj" and stdClass	saves — "The database entry has been updated", new value in the DB ✅
2	ordinary serialized array	saves ✅
3	corrupted serialized data	still blocked — "The data is meant to be serialized with PHP, but is no longer valid", row unchanged ✅
4	plain non-serialized text	saves ✅
5	corrupted data, checkbox unticked	saves ✅

Repro-before-fix: yes. Every case was driven on stock 2.6.7 first and behaved identically. On top of the UI legs I ran a 44-case serialized corpus (nested/deep arrays, objects of known + unknown classes, private/protected props, references, DateTime, ArrayObject/SplStack (C:), enums, __wakeup/__unserialize, 5 corruption shapes, plain text, scalars, 500-key array) through the real Serialized_Data instance on both file versions: 44/44 identical verdicts, while the instrumented counters went __wakeup 1 → 0 and inner unserialize 1 → 0 — the check no longer builds objects, and no input changed side.

Also: plugin activates cleanly, editor + checkbox render, file editor (hello.php) still saves, and zero PHP notices/warnings/fatals in the container log across the whole run. Known whitespace quirk reproduced on both versions — not a regression.

⚠️ One fixture note for anyone re-running: a corrupt value must keep its braces balanced, or a separate always-on brace check blocks the save instead (true on 2.6.7 too) and masks case 3/5.

— QA

[agentosiwp]

QA: PASS ✅ — independent second run, corroborating the verdict above, with one release-gating finding it did not cover.
Env: throwaway docker WordPress 7.1 · PHP 8.2.33 · wp.org 2.6.7 with only includes/Extension/SQL/Tests/class-serialized-data.php replaced by head blob b2daf3b (shipped 2.6.7 file verified byte-identical to base blob 4b2c5b5) · #406 @734c9d0

All five save cases reproduced independently (stock-first baseline, then head): object rows save, array rows save, corrupt data still blocked with the notice and the row unchanged, plain text saves, unticked checkbox saves. A 42-case corpus through the real Serialized_Data::run() gave 0/42 changed verdicts, with the __wakeup counter going 1 → 0. Editor + checkbox render, file editor unaffected, 0 PHP notices/warnings/fatals.

⚠️ The one action before release — declare a PHP floor. unserialize()'s second argument is PHP 7.0+. On older PHP the call raises "unserialize() expects exactly 1 parameter, 2 given" and returns false — the exact value run() treats as invalid. Measured on php:5.6.40: every valid serialized value flips SAVE → BLOCK (3/3), i.e. the database editor refuses to save any serialized row. Control on PHP 7.4: 0/16 differing. Verified 0/16–18 differing on 7.4, 8.2, 8.3.

This is reachable because the plugin declares no Requires PHP — not in docs/readme.txt, not in the plugin header — and I found no version_compare guard, nor any PHP-7-only syntax in the shipped build, so nothing else keeps it off PHP 5.6. Narrow population (such a site is on WP ≤ 5.x), but wp.org would offer it the update, and this is the release users are urged to take.

Suggested: add Requires PHP: 7.0 to docs/readme.txt (and the plugin header). Branch untouched.

— QA