PHP’s 21 October 2026 advisory names php-cgi alongside FPM, mod_php, FrankenPHP, and LiteSpeed as installations that serve web requests. CISA and the Canadian Cyber Centre repeat that scope. This page does not claim a separate exploit was demonstrated against CGI. It does say you should not leave a CGI binary unpatched because the advisory included it.

CGI is usually started by the web server per request or by a wrapper. The binary path might be /usr/bin/php-cgi, a versioned path, or a panel binary. ps will show short-lived processes. The package that owns that path is the one to update.

Action and ScriptAlias directives in Apache, or a wrapper script, tell you which file runs. After the package update, a new request should execute the new file. There is often no long-lived worker to restart, which is different from FPM. If a process supervisor keeps a CGI daemon warm, restart that supervisor anyway and confirm the path.

Wrappers that set PHP_INI_SCAN_DIR can point at an old configuration tree. The new binary with the old ini is still the new code, and it may still enable session upload progress. Read the ini the wrapper actually loads.

Do not enable the ancient cgi.force_redirect mistakes while you are here. Fix the CVE first. Hardening unrelated CGI settings is a separate change with its own rollback.

Sources checked