<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <link rel="alternate" type="text/html" href="https://status.infinityfree.com/"/>
    <title>Websites on InfinityFree Status</title>
    <link>https://status.infinityfree.com/affected/websites/</link>
    <description>Incident history</description>
    <generator>github.com/cstate</generator>
    <language>en</language>
    
    <lastBuildDate>2026-10-22T09:00:00+00:00</lastBuildDate>
    <updated>2026-10-22T09:00:00+00:00</updated>
    
    
    
      <atom:link href="https://status.infinityfree.com/affected/websites/index.xml" rel="self" type="application/rss+xml" />
    
    
      <item>
        <title>Critical PHP security vulnerabilities (CVE-2026-109618 and CVE-2026-109619)</title>
        <link>https://status.infinityfree.com/issues/2026-10-22-php-security-vulnerabilities/</link>
        <pubDate>Thu, 22 Oct 2026 09:00:00 +0000</pubDate>
        <guid>https://status.infinityfree.com/issues/2026-10-22-php-security-vulnerabilities/</guid>
        <category></category>
        <description>&lt;p&gt;&lt;em&gt;Identified&lt;/em&gt; - 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.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;What is the issue?&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;The 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&amp;rsquo;s own code runs. This means that every PHP website is affected, regardless of which software it uses (WordPress, Laravel, custom code, &amp;hellip;).&lt;/p&gt;</description>
        <content type="html">&lt;p&gt;&lt;em&gt;Identified&lt;/em&gt; - 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.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;What is the issue?&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;The 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&amp;rsquo;s own code runs. This means that every PHP website is affected, regardless of which software it uses (WordPress, Laravel, custom code, &amp;hellip;).&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Is InfinityFree affected?&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Yes. Like practically every PHP hosting provider, our hosting was affected by these vulnerabilities.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;What has been done so far?&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Our hosting uses PHP packages provided by CloudLinux. At the time the vulnerabilities were announced, CloudLinux did not have fixed PHP packages available yet.&lt;/p&gt;
&lt;p&gt;To protect our hosting and all websites on it in the meantime, iFastNet has temporarily blocked &lt;code&gt;multipart/form-data&lt;/code&gt; 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 &lt;a href=&#34;https://status.infinityfree.com/issues/2026-10-21-403-errors/&#34;&gt;this incident&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;CloudLinux has since released updated PHP packages that fix the vulnerabilities. iFastNet is preparing to roll these out to all hosting servers. Once that&amp;rsquo;s done, the temporary block will be lifted.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;What do I need to do?&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;You don&amp;rsquo;t need to do anything for your InfinityFree hosting account. PHP is managed by us, and will be updated on all servers automatically.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Why does my website still show an older PHP version?&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;The 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 &amp;ldquo;backporting&amp;rdquo;).&lt;/p&gt;
&lt;p&gt;This means that after the update, the PHP version shown for your website (for example in &lt;code&gt;phpinfo()&lt;/code&gt; 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&amp;rsquo;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&amp;rsquo;t.&lt;/p&gt;
&lt;p&gt;We will post an update here once the fixed PHP version is rolled out on all servers.&lt;/p&gt;

  &lt;span class=&#34;faded&#34;&gt;(22 Oct - 09:00 UTC)&lt;/span&gt;


</content>
      </item>
    
      <item>
        <title>Websites are returning 403 errors from OpenResty on POST requests</title>
        <link>https://status.infinityfree.com/issues/2026-10-21-403-errors/</link>
        <pubDate>Wed, 21 Oct 2026 17:46:00 +0000</pubDate>
        <guid>https://status.infinityfree.com/issues/2026-10-21-403-errors/</guid>
        <category></category>
        <description>&lt;p&gt;&lt;em&gt;Identified&lt;/em&gt; - iFastNet is currently preparing the PHP updates. Once they are ready, they will be rolled out to all servers, and the temporary block on &lt;code&gt;multipart/form-data&lt;/code&gt; POST requests will be lifted. They expect to be able to complete this within two hours. 
  &lt;span class=&#34;faded&#34;&gt;(22 Oct - 08:57 UTC)&lt;/span&gt;

&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;&lt;em&gt;Identified&lt;/em&gt; - CloudLinux has released updated PHP packages over the night to address the vulnerabilities. We are trying to get confirmation from iFastNet about when these updates will be rolled out. 
  &lt;span class=&#34;faded&#34;&gt;(22 Oct - 08:47 UTC)&lt;/span&gt;

&lt;/p&gt;</description>
        <content type="html">&lt;p&gt;&lt;em&gt;Identified&lt;/em&gt; - iFastNet is currently preparing the PHP updates. Once they are ready, they will be rolled out to all servers, and the temporary block on &lt;code&gt;multipart/form-data&lt;/code&gt; POST requests will be lifted. They expect to be able to complete this within two hours. 
  &lt;span class=&#34;faded&#34;&gt;(22 Oct - 08:57 UTC)&lt;/span&gt;

&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;&lt;em&gt;Identified&lt;/em&gt; - CloudLinux has released updated PHP packages over the night to address the vulnerabilities. We are trying to get confirmation from iFastNet about when these updates will be rolled out. 
  &lt;span class=&#34;faded&#34;&gt;(22 Oct - 08:47 UTC)&lt;/span&gt;

&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;&lt;em&gt;Identified&lt;/em&gt; - We have received confirmation from iFastNet about this issue.&lt;/p&gt;
&lt;p&gt;Earlier today, a critical update to PHP was released that fixes two severe security issues. These issues could cause serious harm on our hosting if exploited.&lt;/p&gt;
&lt;p&gt;Our hosting runs PHP packages provided by CloudLinux. CloudLinux has not yet distributed the fixed PHP version. We are waiting for them to provide the PHP version that contains the security fixes.&lt;/p&gt;
&lt;p&gt;Until then, to keep our hosting and all websites on it safe, iFastNet was forced to block certain requests from reaching PHP, which includes blocking all &lt;code&gt;multipart/form-data&lt;/code&gt; POST requests.&lt;/p&gt;
&lt;p&gt;This block will remain in effect until the new PHP packages are published and rolled out on all hosting servers.&lt;/p&gt;

  &lt;span class=&#34;faded&#34;&gt;(21 Oct - 19:14 UTC)&lt;/span&gt;


&lt;hr&gt;
&lt;p&gt;&lt;em&gt;Investigating&lt;/em&gt; - We have investigated the issue and have a better idea of the impact.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;The problem occurs when making a POST request to websites using the &lt;code&gt;multipart/form-data&lt;/code&gt; content type. POST requests using form-urlencoded data are not affected. Other data types are unclear at this time.
&lt;ul&gt;
&lt;li&gt;Explained simply: some forms on websites will return this error, other won&amp;rsquo;t. Notably forms that involve file uploads.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;All accounts seem to be affected by this, regardless of website IP or domain name used.&lt;/li&gt;
&lt;li&gt;This issue potentially affects all website software, including WordPress and Laravel. How much functionality is impacted by this issue depends on the website software used.&lt;/li&gt;
&lt;/ul&gt;

  &lt;span class=&#34;faded&#34;&gt;(21 Oct - 18:22 UTC)&lt;/span&gt;


&lt;hr&gt;
&lt;p&gt;&lt;em&gt;Investigating&lt;/em&gt; - We are currently investigating reports of 403 errors on websites on free hosting. 
  &lt;span class=&#34;faded&#34;&gt;(21 Oct - 17:46 UTC)&lt;/span&gt;

&lt;/p&gt;
</content>
      </item>
    
  </channel>
</rss>
