{
  "is": "issue",
  "title": "Critical PHP security vulnerabilities (CVE-2026-109618 and CVE-2026-109619)",
  "body": "\u003cp\u003e\u003cem\u003eIdentified\u003c/em\u003e - On October 21st, the PHP project released an emergency security update to fix two critical vulnerabilities in PHP, known as CVE-2026-109618 and CVE-2026-109619. Details of these vulnerabilities were leaked publicly before the fix was available.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhat is the issue?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe vulnerabilities allow an attacker to run their own code on a server by sending a specially crafted request to any website that runs PHP. No login or special access is needed, and the attack happens before the website\u0026rsquo;s own code runs. This means that every PHP website is affected, regardless of which software it uses (WordPress, Laravel, custom code, \u0026hellip;).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIs InfinityFree affected?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eYes. Like practically every PHP hosting provider, our hosting was affected by these vulnerabilities.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhat has been done so far?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eOur hosting uses PHP packages provided by CloudLinux. At the time the vulnerabilities were announced, CloudLinux did not have fixed PHP packages available yet.\u003c/p\u003e\n\u003cp\u003eTo protect our hosting and all websites on it in the meantime, iFastNet has temporarily blocked \u003ccode\u003emultipart/form-data\u003c/code\u003e POST requests, which are used by the attack. Unfortunately, these requests are also used by many regular website forms, notably forms with file uploads. This is causing the 403 errors described in \u003ca href=\"/issues/2026-10-21-403-errors/\"\u003ethis incident\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eCloudLinux has since released updated PHP packages that fix the vulnerabilities. iFastNet is preparing to roll these out to all hosting servers. Once that\u0026rsquo;s done, the temporary block will be lifted.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhat do I need to do?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eYou don\u0026rsquo;t need to do anything for your InfinityFree hosting account. PHP is managed by us, and will be updated on all servers automatically.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWhy does my website still show an older PHP version?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe PHP project fixed these vulnerabilities in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. However, CloudLinux has not upgraded to these versions. Instead, they have taken the security fixes and applied them to the PHP versions they already provide (this is called \u0026ldquo;backporting\u0026rdquo;).\u003c/p\u003e\n\u003cp\u003eThis means that after the update, the PHP version shown for your website (for example in \u003ccode\u003ephpinfo()\u003c/code\u003e or WordPress Site Health) will most likely still be a lower version number, likely still 8.4.25 instead of 8.4.27. This is expected: the version number doesn\u0026rsquo;t change, but the vulnerabilities are fixed. Security scanners and plugins that only look at the version number may still report your website as vulnerable, even though it isn\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003eWe will post an update here once the fixed PHP version is rolled out on all servers.\u003c/p\u003e\n\n  \u003cspan class=\"faded\"\u003e(22 Oct - 09:00 UTC)\u003c/span\u003e\n\n\n",
  "createdAt": "2026-10-22 09:00:00 +0000 UTC",
  "lastMod": "2026-10-22 09:03:54 +0000 UTC",
  "permalink": "https://status.infinityfree.com/issues/2026-10-22-php-security-vulnerabilities/",
  "severity": "notice",
  "resolved": false,
  "informational": false,
  "resolvedAt": "<no value>",
  "affected": ["Websites"],
  "filename": "2026-10-22-php-security-vulnerabilities.md"
}