[mrrobot47]

What

After ee site restore restores a site's PHP config, add session.upload_progress.enabled = Off back to the top of its custom.ini unless the restored file already sets the directive.

Also add a one-off container migration that checks every WordPress and PHP site's custom.ini again with the same parser and adds the line where the v4.13.3 migrations missed it.

Why

v4.13.3 turned session upload progress off by adding session.upload_progress.enabled = Off to every site's custom.ini (EasyEngine/site-type-wp#246, EasyEngine/site-type-php#120). EasyEngine/dockerfiles#374 makes Off the default in the images' php.ini too, which covers new sites but not a restore, since a restore also brings back the backup's php.ini. PHP's informational advisory of 2026-10-23 for CVE-2026-115560 asks to keep it off until the next regular bugfix release.

restore_php_conf() copies custom.ini and php.ini from the backup over the site's files. A backup taken before v4.13.3 has neither the line in custom.ini nor a php.ini that sets it, so the restored site runs with upload progress On again, PHP's default. Shown on a runner with develop: a WordPress site with a pre-v4.13.3 custom.ini was backed up, upgraded to the v4.13.3 custom.ini (FPM reports Off), then restored: the line was gone and FPM reported On.

How

• New helpers in site-utils.php: add_session_upload_progress_off() returns the content with the setting added, or null when the content already sets it outside a [PATH=]/[HOST=] section; ini_sets_globally() and ini_global_part() decide that. The rule is the v4.13.3 migrations' rule: an effective global line, On or Off, is the user's choice and is kept; a commented-out line, another spelling, or a setting only inside a [PATH=]/[HOST=] section doesn't count. The lines go at the very top, so neither such a section nor a multi-line quoted value can capture them; CRLF, a UTF-8 BOM and the rest of the file are kept.
• ini_global_part() lets PHP's ini parser decide where each section header starts, ends and what it is called: a [ counts only where the parser would take a new entry, and the header is named by parsing it alone. The migrations' version only recognised a header that was unquoted and alone on an LF-terminated line, so in a CRLF or CR-only file, with a quoted name like ["PATH=/x"], or with [PATH=/x][Session] on one line, a setting inside the section counted as global and the line wasn't added. The part before such a section is read without sections, so an array entry keyed by the directive doesn't count either.
• restore_php_conf() calls the new keep_session_upload_progress_off() after copying the files. It writes custom.ini in place (owner, mode and inode kept) through a checked handle (see below), puts the restored file back if a write fails part way, warns with the manual fix when the file is missing or can't be read or written, and logs when it adds the line. The site reload at the end of the restore applies it.

Re-check migration

The v4.13.3 migrations (EasyEngine/site-type-wp#246, EasyEngine/site-type-php#120) used the older header check, so they skipped every custom.ini whose only session.upload_progress.enabled line is inside a [PATH=]/[HOST=] section with a quoted header, two headers on one line, a header named like an earlier key, or CRLF/CR line endings, and every file with an array entry keyed by the directive. Those sites still run with upload progress On. Hosts that upgrade from v4.13.2 run those migrations first, so the new one is ordered after them.

migrations/container/20261023233000_site-command_recheck_session_upload_progress.php:

• Goes through every wp and php site, enabled or disabled, and adds the same two lines at the top of custom.ini where the directive isn't set outside a [PATH=]/[HOST=] section. A missing custom.ini gets a warning with the manual fix instead of being created; the v4.13.3 migrations already created it wherever conf.d existed. A global On or Off is kept; a global On is logged, naming the site. A file that already has the line is left alone, so a second run changes nothing.
• Each changed file is backed up under .backup/session-upload-progress-recheck-<time>/<site>/custom.ini and rewritten in place, keeping owner, mode and inode. down() restores the files byte for byte, so core reverts it when a later upgrade step fails.
• Running php containers of enabled sites get the graceful FPM reload the v4.13.3 migrations use, after the image migration and only when the container wasn't recreated. Disabled and stopped sites read the file when they start.
• A failure on one site is a warning with the manual fix, and that site's file is restored; the other sites go on.
• custom.ini and the directories above it, up to config/php, are in the site's config volume, which its php container can change. New helpers in site-utils.php, used by both the restore and the migration, open the file once and check that the handle is the regular, singly linked file in that site's conf.d before anything is read or written through it: on Linux by the kernel's path of the open file (/proc/self/fd), which a directory swapped for a symlink and back around the open can't fake; elsewhere by resolving conf.d before and after the open. Reads stop at 64 KB. So a symlink, hard link or swapped directory doesn't send a write anywhere else on the host. Nothing is created in that directory, because PHP's fopen() and link() expand the path to an absolute one, which a swapped directory could redirect before any check. A file is opened for writing only when the line has to be added, so a read-only file that already sets the directive is fine. Files over 64 KB are skipped with a warning.

The helpers also gained ini_global_value(), so the migration can tell an explicit On from an Off. A bare [PATH] or [HOST] header (nothing after the word) doesn't scope anything in PHP, and the helpers now treat entries under it as global too.

Testing

• Case matrix for the helpers on PHP 7.4 and 8.5 (CI) and 8.5 locally: empty or missing file, the v4.13.2 and v4.13.3 templates (LF, CRLF, BOM, the 5.6 template), explicit On/Off/1/"0", commented-out (; and #), wrong case, other session.upload_progress.* keys, a setting only in [PATH=], ["PATH=..."], ['PATH=...'], [path=...], [PATH = ...], [HOST=...] and ["HOST=..."] (LF, CRLF and CR-only), [PATH=...][Session] on one line, quoted PATH names containing a newline or ], a CR before a header, an array entry keyed by the directive (custom_flags[session.upload_progress.enabled]), a PATH header named like an earlier global key or array, PATH-like text in comments, values and array keys, an ordinary section after a PATH one, [ PATH=...] (global for PHP), a PATH-like line inside a multi-line quoted value or a comment, a [ inside a quoted value before a real header, and settings before and after a syntax error. Each added result is a no-op on a second run, sets the directive globally, keeps line endings, BOM and the original lines, and parses as Off with real PHP. The migrations' version of the check gets 15 of these cases wrong.
• The global/scoped verdict of every case was checked against real PHP-FPM (easyengine/php8.4), requesting a script inside and outside the section: all match.
• The real restore_php_conf() with stubs: pre-v4.13.3 backup, v4.13.3 backup, explicit On, CRLF [PATH=] On, ["PATH=..."] On, backup without custom.ini; develop leaves three of them On, this branch none.
• Re-check migration, in isolation on PHP 7.4 and 8.5 against the real v4.13.3 migration: the case matrix above (56 entries), starting both from the state the v4.13.3 migration leaves and from the untouched files, on enabled and disabled wp and php sites, plus a missing custom.ini, a missing conf.d, a symlinked or hard-linked custom.ini, a hard-linked file that already sets Off, a symlinked conf.d and php/ pointing out of the site, a file over 64 KB, and a site whose container lookup throws. It changes exactly the files that lack a global setting (15 of them after v4.13.3, 34 untouched), keeps everything else, the backups equal the old files, a second run and its down() change nothing, down() restores every file byte for byte, and only running enabled sites whose container wasn't recreated get reloaded. Every end state was served by real PHP-FPM (easyengine/php8.4): the global value is Off for all of them except the seven that set a global On or "0" themselves, which keep it; before the migration the same requests show On for those 15 and 34 files.
• The file helpers under a race: conf.d flipped between the real directory and a symlink to an outside directory about 44,000 times while open-and-write ran in a loop; the outside file was never written (with only the before/after path checks, it was).
• Re-check migration end to end on a fresh runner: sites with the 15 layouts (two of them WordPress, one disabled), an explicit global On and an Off control, created with core develop, which then re-ran the v4.13.3 migrations: they left all 15 files unchanged and FPM still reported On. Then this branch: an upgrade that fails in the image migration reverts the migration, and every file, its mode, owner and inode, the containers and FPM's values are as before; the next upgrade turns all 15 Off in FPM without restarting a container, keeps the values inside the [PATH=] sections, keeps the explicit On (logged), leaves the control alone, and the disabled site reports Off once enabled; a second run changes nothing and reloads nothing.
• On a fresh runner with core develop: a WordPress site with a pre-v4.13.3 custom.ini restored with this branch gets the line back at the top and FPM reports Off; a PHP site whose backup sets session.upload_progress.enabled = On (changed to Off after the backup) is restored with On kept and FPM reports On. The site-command Behat suite passes, also with three extra scenarios for the migration (a CRLF [PATH=]-only file gets Off, a second run changes nothing, an explicit On is kept).

[Copilot]

🟡 Changes recommended

Verified INI-classification errors can skip the mitigation and leave session upload progress globally enabled.

2 open issues

• Avoid mistaking unrelated array entries for global directives · New
• Detect scoped INI headers across line endings and combined headers · New

What changed in this PR

This PR restores the session upload-progress mitigation when older backups overwrite a site's PHP configuration, while preserving explicit global settings.

Changes:

• Add INI helpers to distinguish global directives from PATH/HOST-scoped settings.
• Check restored custom.ini, prepend Off when needed, and warn when the file cannot be updated.

File	Description
src/​helper/​site-utils.php	Adds INI inspection and upload-progress mitigation helpers.
src/​helper/​Site_Backup_Restore.php	Applies the mitigation after restoring PHP configuration.

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The security-sensitive INI parser has an unresolved scope-detection edge case and needs final human validation across supported PHP versions.

No open issues 🎉

1 previously missed issue

In code that hasn't changed since last review

Handle scoped headers colliding with existing global keys

src/​helper/​site-utils.php:1704

A scoped header is missed when its name already exists as a global key. For example:

PATHprivate = ignored
[Session]
[PATHprivate]
session.upload_progress.enabled = Off

Parsing [PATHprivate] replaces the earlier PATHprivate entry without moving it after Session, so end($ini) still sees Session. The helper then treats the scoped directive as global and returns null. If the restored php.ini leaves upload progress enabled, restore skips the mitigation and it stays enabled globally. Identify the header just parsed independently of the result array's insertion order, and add this collision case to the regression checks.

2 resolved since last review

• Detect scoped INI headers across line endings and combined headers
• Avoid mistaking unrelated array entries for global directives

_{Review effort: Balanced}

[mrrobot47]

The header-name collision case (PATHprivate = ignored, [Session], [PATHprivate]) is fixed in b1792c3: each header is now named by parsing it alone and only counts when it adds that section, so the scoped directive is no longer taken as global. The case is in the regression matrix and matches php-fpm.

[Copilot]

🟡 Changes recommended

A scoped-header detection bug can skip the safeguard and leave session upload progress globally enabled.

1 open issue

• Reset stale array state when parsing scoped headers · New

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Security-sensitive INI parsing and restore behavior need final human validation across supported PHP runtimes.

No open issues 🎉

1 resolved since last review

• Reset stale array state when parsing scoped headers

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

File-access races can permit host-file overwrites, and write-failure paths can leave incomplete configurations without reliable recovery.

4 open issues

• Prevent directory-swap symlink race during config rewrite · New
• Prevent custom.ini symlink race during config write · New
• Rethrow rewrite failure to trigger cleanup · New
• Preserve configuration when restoration write is short · New

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Ownership and deletion operations remain vulnerable to directory-swap races, and configuration reads need enforced size limits.

2 open issues

• Pathname ownership changes remain vulnerable to symlink swaps · New
• Pathname unlink can delete an outside file after symlink swap · New

2 previously missed issues

In code that hasn't changed since last review

Unbounded reads bypass MAX_SIZE and can exhaust memory

migrations/​container/​20261023233000_site-command_recheck_session_upload_progress.php:207

The fstat() check does not enforce MAX_SIZE on this read. The site's PHP container can grow the same file after the check, allowing stream_get_contents() to allocate oversized content and pass it to the repeatedly reparsing helpers. Read at most MAX_SIZE + 1 bytes and reject an oversized result before parsing. Also bound the pre-write comparison at line 237 to MAX_SIZE + 1 bytes so growth during parsing cannot exhaust memory there instead.

Unbounded restore parsing can exhaust memory or cause quadratic work

src/​helper/​Site_Backup_Restore.php:1741

Unlike the migration, restore reads the entire custom.ini before invoking ini_global_part(), which reparses the preceding content for every [. A large restored file with many array entries can exhaust CLI memory or stall restore with quadratic parsing work. Bound the initial read to 65537 bytes and warn/skip when it exceeds 64 KB. Bound the pre-write comparison read too, so a file that grows during parsing cannot cause an unbounded allocation there.

4 resolved since last review

• Prevent custom.ini symlink race during config write
• Prevent directory-swap symlink race during config rewrite
• Preserve configuration when restoration write is short
• Rethrow rewrite failure to trigger cleanup

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

The shared file helpers still allow outside-directory file creation during a directory swap and unbounded verification reads.

2 open issues

• Validate target directory before creating or linking files · New
• Bound post-write verification read to prevent excessive memory use · New

2 resolved since last review

• Pathname unlink can delete an outside file after symlink swap
• Pathname ownership changes remain vulnerable to symlink swaps

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Security-sensitive INI parsing, privileged filesystem handling, and rollback behavior require final human validation.

1 open issue

• Prevent FIFO race from blocking custom.ini validation · New

2 resolved since last review

• Bound post-write verification read to prevent excessive memory use
• Validate target directory before creating or linking files

_{Review effort: Balanced}