PHP2Shell (CVE-2026-109618, CVE-2026-109619) on Kayako Classic: Patch PHP 7.3 Instead of Upgrading to PHP 8

Overview

On October 21, 2026, the PHP project disclosed two critical vulnerabilities, often called "PHP2Shell":

• CVE-2026-109618: remote code execution through out-of-memory corruption
• CVE-2026-109619: remote code execution through stale global state

Both flaws are in PHP itself, not in Kayako Classic's code. php.net lists Apache with mod_php, PHP-FPM and php-cgi as affected. php-cgi is what IIS uses through FastCGI. php.net doesn't exempt any operating system, so treat Windows servers as affected too.

The flaws can be triggered by an unauthenticated request before any application code runs. That means Kayako Classic's logins, permissions and area restrictions don't protect against them. Only a fixed PHP build does.

The PHP project fixed the vulnerabilities in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Security teams and scanners often recommend upgrading to one of these versions. Kayako Classic doesn't support any of them. The latest stable release, Kayako Classic 4.98.9, is documented for PHP 7.3.

The supported fix is to stay on PHP 7.3 and install a PHP 7.3 build with the fixes backported. Until that build is in place, the interim measures below reduce exposure, but they don't make the server safe.

Solution

1. Don't move Kayako Classic to PHP 8.x

• Kayako Classic 4.93.0 through 4.98.9 fully support PHP 7.3. 4.98.9 is the latest stable release.
• No supported Kayako Classic version runs on PHP 8.
• The 4.99.x builds target PHP 8 but aren't supported, because they have known stability problems. They aren't a safe way to move to a newer PHP version.
• PHP 8.2 reaches end of life on December 31, 2026, according to php.net.

To find your version, open the Admin Control Panel dashboard. If you run a version older than 4.98.9, or any 4.99.x build, move to 4.98.9 as described in What is the latest version of Kayako Classic?

2. Install a patched PHP 7.3 build (the permanent fix)

The PHP project published source backports only for PHP 7.4, 8.0 and 8.1, not for 7.3. Patched PHP 7.3 builds come from operating system distributions and long-term-support (LTS) vendors instead.

A patched build still reports a 7.3.x version number. It stays a supported runtime for Kayako Classic, so you don't need to upgrade Kayako.

These sources listed PHP 7.3 coverage at the time of writing. Listings change, so check each vendor's current status:

Platform	Source	Notes
Debian 10	Freexian Extended LTS	Paid
AlmaLinux 8	AlmaLinux (php:7.3 module stream)	Free. The fixed package is php-7.3.20-1.module_el8.10.0+4316+90ea5fe5.alma.1 or later. AlmaLinux says future fixes for retired streams aren't guaranteed.
RHEL / AlmaLinux / Rocky / Fedora	Remi's repository	Free. PHP 7.3 is listed as "to follow".
Linux (RHEL-family EL6–EL10, Ubuntu, Debian 10–13, Alpine 3.23–3.24)	TuxCare ELS for PHP	Paid
Windows Server 2019, 2022, 2025 (x64 and x86)	TuxCare ELS for PHP	Paid. Windows Server 2016 and older aren't listed.
Linux distributions (Windows: confirm with the vendor)	ZendPHP LTS	Paid. Zend describes its PHP2Shell patches as initial patches.

For the full vendor details, see:

• PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619) | Sansec
• php2shell Patch FAQ for PHP 5.2 Through 8.5 | TuxCare
• php2shell (CVE-2026-109618, CVE-2026-109619): Patched PHP packages released | AlmaLinux OS

Before you buy or install a build, ask the vendor to confirm that its PHP 7.3 build for your operating system fixes both CVE-2026-109618 and CVE-2026-109619.

When you switch to the new PHP build:

1. Back up first. Keep a copy of your current PHP folder or packages and your php.ini. Some Windows installers offer Replace (removes the existing PHP) or Alongside (keeps it). Choose Alongside so you can roll back.
2. Match your current build type (Windows). Under Admin Control Panel > Diagnostics > PHP Info, check Thread Safety (disabled means Non-Thread Safe) and Architecture. Install the same type.
3. Re-apply the Kayako Classic PHP settings. Some installers create a new php.ini from php.ini-production. Re-apply the values from Kayako Classic Server Configuration and System Requirements:
   • max_execution_time = 600
   • max_input_time = 600
   • output_buffering = 4096
   • file_uploads = On
   • max_file_uploads = 20
   • leave open_basedir unset
4. Enable every required PHP module. Vendor builds may install some modules as optional. Enable mbstring, openssl, gd (with FreeType), curl, mysqli, pdo_mysql, imap, intl, fileinfo and sockets, and opcache (recommended). PDO, SimpleXML, filter, json, xml and dom are usually built in; confirm they appear in PHP Info.
5. Point the web server at the new build.
   • IIS: IIS runs the php-cgi.exe named in its own configuration, not the one on the system Path. In IIS Manager, update both FastCGI Settings and Handler Mappings to the new PHP folder. Also update any PHPRC environment variable that points to the old php.ini.
   • PHP-FPM / Apache: make sure the pool or module that serves the helpdesk loads the patched packages.
6. Restart every PHP worker so no process keeps running the old code:
   • PHP-FPM: reload or restart the service
   • Apache with mod_php: restart Apache
   • IIS: recycle the application pool or run iisreset

3. Apply interim php.ini hardening until the patched build is in place

php.net lists settings that "reduce exposure to specific attack paths but do not make an installation safe" (PHP: News Archive - 2026, October 21 advisory). The table shows how each one fits Kayako Classic.

Apply them where PHP reads them before it parses requests:

• php.ini (check Loaded Configuration File in PHP Info)
• a PHP-FPM pool, using php_admin_value / php_admin_flag
• the Apache configuration

Don't rely on ini_set() or .user.ini files.

Setting	Interim value	Kayako Classic compatibility
session.upload_progress.enabled	0	Kayako Classic doesn't use PHP's session upload progress feature, so you can leave this off permanently, even after patching. On October 23, 2026, php.net also advised keeping it at 0 until the next regular PHP release.
memory_limit	-1	Kayako Classic 4.98.9 doesn't change memory_limit while it runs, and treats -1 as "no limit." The trade-off is that a single request can use much more server memory. On Linux, php.net suggests a container or cgroup memory limit as a safety net and warns against RLIMIT_AS and RLIMIT_DATA. On Windows, don't use a per-process memory cap such as a Job Object limit as a replacement: it makes memory allocations fail, which can reach the vulnerable code. After patching, you can return to the documented 512M.
post_max_size / upload_max_filesize	Keep upload_max_filesize below post_max_size	php.net suggests post_max_size = 32M for applications that need uploads. The documented Kayako value is 20M for both settings. Either keep post_max_size = 20M and lower upload_max_filesize slightly (for example 18M), or set post_max_size = 32M and keep upload_max_filesize = 20M. PHP rejects files larger than upload_max_filesize, so choose a size that still fits your ticket attachments.

For PHP-FPM, make sure no other pool, directory or .user.ini sets a finite memory_limit again. On IIS, check the helpdesk folders for a .user.ini. Restart every PHP worker after changing these settings.

4. Add limits at the network, web server, proxy or WAF

• Restrict network access to the whole helpdesk. Restricting only the admin and staff areas isn't enough: the vulnerable request handling happens before Kayako Classic's code runs, so public pages such as the support center stay exposed. Until PHP is patched, consider allowing only the networks that need the helpdesk.
• Set request limits. php.net recommends limits on:
  • decoded request size
  • number of input fields
  • number of multipart parts
  • number of headers
  • nesting depth
• These limits must also cover requests without a usable Content-Length.
• Azure Application Gateway: Microsoft has published temporary, partial mitigations.
  • Any v2 gateway: a header rewrite rule that deletes Set-Cookie headers matching a specific PHPSESSID pattern. Kayako Classic doesn't use PHP's native PHPSESSID cookie, so this rule doesn't affect helpdesk logins. See Addressing PHP2Shell CVE-2026-109618 and CVE-2026-109619: upgrade guidance and Azure WAF mitigations.
  • WAF tier only: three custom rules. The first blocks multipart requests that contain php_session_upload_progress. Kayako Classic never sends this, but the rule can match if the text appears inside an uploaded file. Microsoft ships the two nesting rules in Log mode; review their matches before switching them to Block. See Azure WAF custom rules for PHP2Shell mitigation.

Verification

1. Confirm the patch from the package changelog, not the version number. Look for both CVE IDs:
   • Debian: zgrep CVE-2026-109618 /usr/share/doc/php7.3-common/changelog.Debian.gz
   • RHEL / AlmaLinux / Rocky: rpm -q --changelog php-common | grep CVE-2026-109618
   • Windows and other vendor builds: the vendor's release notes
2. Check the running configuration. Open Admin Control Panel > Diagnostics > PHP Info and confirm that:
   • the PHP build and Loaded Configuration File are the ones you expect
   • the hardening values are active
   • all required modules are listed
3. Use PHP Info in the helpdesk rather than php -v or php -i on the command line. The command line can load a different configuration from the web server.
4. Test the helpdesk:
   • log in to the staff control panel
   • submit a ticket with an attachment from the support center
   • confirm the email parser is still fetching mail

Additional Notes

• Scanners may still flag the server. A patched build keeps its 7.3.x version string, so scanners that only read version numbers can keep reporting it as vulnerable. Use the changelog check as proof of the fix.
• Don't block all multipart/form-data requests. Some third-party guides suggest this as a temporary measure, but it also blocks file uploads, including Kayako Classic ticket attachments.
• Restricting network access can stop scheduled tasks. The documented scheduled task or cron job calls the helpdesk's /cron/index.php URL over HTTP(S) (Manually Scheduling a Server Task/Cron Job for Kayako Classic Download). Keep the task's source address allowed, or tasks such as email fetching won't run on schedule.
• Interim measures don't replace patching. php.net states: "There are no complete mitigations, updating is the only safe choice."
• Server changes are the administrator's responsibility. Installing PHP and changing the web server, proxy or firewall are tasks for whoever manages the server. If you want this work carried out for you, a Professional Services engagement is available and may involve additional cost.
• When requesting help, include:
  • Kayako Classic version
  • operating system and version
  • web server and PHP handler (mod_php, PHP-FPM or IIS FastCGI)
  • PHP build source (OS packages, a vendor, or compiled from source)
  • the PHP Info values for session.upload_progress.enabled, memory_limit, post_max_size, upload_max_filesize and Loaded Configuration File

References

Relevant Knowledge Base Articles

• Kayako Classic Server Configuration and System Requirements
• What is the latest version of Kayako Classic?
• "Cannot access protected property" PHP Error After Upgrading to Version 4.99.8
• Manually Scheduling a Server Task/Cron Job for Kayako Classic Download
• Accessing Kayako Classic Diagnostic Tools