DSInfraSupport: > Could you please check why the WordPress installation is getting stuck at 11% and help me complete the installation? Softaculous is an off-the-shelf product that isn’t actually made by InfinityFree or iFastNet. As an alternative you can try installing WordPress manually. WordPress.org ### Download Download WordPress today, and get started on creating your website with one of the most powerful, popular, and customizable platforms in the world.

I checked it, and it appears that the records in our nameservers were overridden by iFastNet, presumably because your website was migrated to premium hosting at some point. I cannot fix this from my end, but iFastNet can. Can you please contact them and let them know you want to switch back to free hosting? They can then revert all settings changed as part of the migration.

Singapoor: > Options +Includes This was blocked around a month ago by IFastNet who provide the underlying infrastructure. There were a few other security upgrades at the same time (including server side includes). There is no way to get around this.

Actually, issue that was happening is fixed now, i was actually trying to implement Vista Panel features on my site admin panel to display Account details and access to file manager, which later I have clarified from support of iFastNet, why it was not working, i was told, that type of request was permanently restricted for Panel from past 2-3 days(when they were dealing with php2shell) to increase security. That issue was limited to me and those who used the similar way to interact with panel. I have change the request type in order to fix it, but I don’t know why some other are experiencing issue with AJAX and POST request.

### Website URL https://bombexpo.great-site.net ### Error Message Is Infinityfree & ifastNet aware about this vulnerability? Please Patch up immediately ### Other Information BREAKING PHP warns of another UNPATCHED REC vulnerability just 2 days after releasing emergency patches for critical PHP2Shell flaws. New “CVE-2026-115560” affects only unusual session configurations. PHP has issued urgent mitigation guidance.

Yesterday, when I have contacted iFastNet, they respond me with this:

Thank you so much for your help and for keeping our websites safe! I truly appreciate the effort you and the IFastNet team put into resolving this issue. Really grateful for your support!

iFastNet had already deployed mitigations, just not the mitigations you described here which is known to not be a valid mitigation.

Thank you for looking into this and reaching out to iFastNet. If a full upgrade takes time, could you ask iFastNet if they can immediately apply the following temporary server-side mitigations across the fleet: 1. Disable PHP upload progress tracking by setting `session.upload_progress.enabled = 0` globally. 2. Enforce strict request size limits and multipart request validation at the Nginx/reverse-proxy layer before traffic even hits the PHP workers.

I don’t know what system your using to build your site. But if you’re trying to upload anything through an editor (like wordpress or MediaWiki, you may have some problems at the moment. Please see the banner at the top of the page, and the status page: status.infinityfree.com ### Websites are returning 403 errors from OpenResty on POST requests |... Identified - We have received confirmation from iFastNet about this issue. 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. Our hosting runs...

Take note this is an English forum. Please use an online translator before your post. Anyway, this is the update status.infinityfree.com ### Websites are returning 403 errors from OpenResty on POST requests |... Identified - We have received confirmation from iFastNet about this issue. 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. Our hosting runs...

You should definitely **not** see a cPanel page because free hosting doesn’t use cPanel. It is known that migrating from premium hosting back to free hosting could be very nasty. But this does mean that you probably need to contact iFastNet to get this fixed for you.

Welcome to the forum I’m going to assume you’ve read the banner at the top of the page that explains this? The link the bot posted: status.infinityfree.com ### Websites are returning 403 errors from OpenResty on POST requests |... Identified - We have received confirmation from iFastNet about this issue. 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. Our hosting runs... will give you more details This has been done by IFastNet (who provide the infrastructure that InfinityFree is built on) to mitigate some major security vulnerabilities in the current PHP version. Once they’ve been able to update the PHP version, this restriction should be lifted.

mady001: > So the account and files look fine, and the problem seems to be how the custom domain is routed on the server: before the old iFastNet package was terminated it showed “Account Suspended”, and now it returns the cPanel default page. Could a staff member check the domain’s virtual host configuration? I think you’re right here. I know that websites on free hosting are redirected to premium hosting when the website is migrated to premium hosting, and it sounds like that redirect was never removed. And that’s something staff needs to check and fix. However, that’s **iFastNet staff** who needs to do that. So please send iFastNet a ticket and tell them that you’re trying to switch back to free hosting. Then can remove the redirect for you.

Securing the servers is iFastNet’s responsibility. The servers appear to be running PHP 8.4.25 right now, which could be vulnerable. However, it’s possible that iFastNet implemented other mitigations to keep websites secure. But I too am curious what their plans actually are, so I’ve sent them a message asking for clarification on this.

_Beep boop, I’m a bot! I dug through the forum to get you started. I sometimes get things wrong though, so do with this what you will until a human has a look._ This looks like the open incident on our status page. It’s the same 403 from OpenResty on POST requests. status.infinityfree.com ### Websites are returning 403 errors from OpenResty on POST requests |... Identified - We have received confirmation from iFastNet about this issue. 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. Our hosting runs... A critical PHP security update was released, and CloudLinux hasn’t yet distributed the fixed version. Until it is, iFastNet is blocking some requests from reaching PHP, including all `multipart/form-data` POST requests. The incident says the block stays until the new PHP packages are published and rolled out on all hosting servers. Nothing in your account or code causes it, and you can’t fix it on your side. It affects all accounts. Forms sent as `form-urlencoded` aren’t affected. Forms that upload files, or that are set to `enctype="multipart/form-data"`, are. Does the form that fails when you save records have a file upload, or that `enctype`? If it doesn’t, the incident may not be the cause, and I’d need to know exactly which page and action return the 403.

It’s a WAF rule. Specifically, one to mitigate the security vulnerabilities in PHP that were disclosed earlier today. An issue is now up on the status page to track the status of this: status.infinityfree.com ### Websites are returning 403 errors from OpenResty on POST requests |... Identified - We have received confirmation from iFastNet about this issue. 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. Our hosting runs...

_Beep boop, I’m a bot! I dug through the forum to get you started. I sometimes get things wrong though, so do with this what you will until a human has a look._ Uploads are probably failing because of an open incident on our status page, not because of your site or the size of your images. Since 21 Oct, multipart/form-data POST requests are being blocked on the hosting, and that is how file uploads are sent. iFastNet has blocked them as a security measure until a fixed PHP version is rolled out to all servers. The incident says this affects all accounts, and that WordPress is one of the pieces of software that can be hit. It says forms with file uploads are the most notable ones to fail. Uploading to the Media Library and restoring a backup with UpdraftPlus both work that way. The incident page has the current status and will show when the block is lifted: status.infinityfree.com ### Websites are returning 403 errors from OpenResty on POST requests |... Identified - We have received confirmation from iFastNet about this issue. 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. Our hosting runs... I haven’t found anything you can change on your side to get around the block.

### Website URL http://www.aveva-av.com/ ### Error Message SORRY! If you are the owner of this website, please contact your hosting provider. It is possible you have reached this page because: The IP address has changed / There has been a server misconfiguration. (cPanel default page at /cgi-sys/defaultwebpage.cgi ### Other Information Hello, My domain aveva-av.com used to be on an iFastNet premium package that has now been terminated. I moved it to my account if0_43088511 (vol14_5, IP 185.27.134.129). The domain is added with its document root, an SSL certificate is issued, and the A records point to 185.27.134.129 (Cloudflare, DNS only). The WordPress files are in place and the account is active. But the domain returns the cPanel default page, so the server seems to have no virtual host for it. Before the old package was terminated it showed “Account Suspended”. I removed and re-added the domain, with no change. Could someone check that the domain is released from the old package and configured on my account? I also opened a ticket with iFastNet. Thank you.

Welcome to the InfinityFree community forum! Good to have you here. * Most people answering here are volunteers. They’re often the fastest source of help. Admin (the only staff member) checks in about once a day for issues on our end. * Volunteers can’t see your account or website. Share what you actually see, like error messages and what happens when you try something. That’s more useful than your theory of what’s wrong. * AI tools often get InfinityFree wrong. If a volunteer’s advice differs from what an AI told you, please try the volunteer’s suggestion first. * Solving an issue is a joint effort. Try the suggestions you get and report back what happened.

_Beep boop, I’m a bot! I dug through the forum to get you started. I sometimes get things wrong though, so do with this what you will until a human has a look._ Does your free subdomain, `aveva-av.infinityfreeapp.com`, load the WordPress site? And does `aveva-av.com` without the `www` show the same cPanel page as `www.aveva-av.com`? If the free subdomain works, your files and the account are fine and the problem is only how the custom domain is being routed. If it shows the same page too, the problem is with the account itself. Those two cases need different answers. I searched the forum and knowledge base for this symptom, a domain that returns the cPanel default page after being moved from another host’s package. I found nothing that explains it, so I can’t say yet what’s wrong.

Thanks for checking. The free subdomain works: it shows the InfinityFree “Your domain is ready!” page, loaded from the account’s root htdocs folder. So the account is active and serving files. It does not load the WordPress site because that is in the custom domain’s own folder. Yes, the domain without www shows exactly the same cPanel default page as the www version (tested in incognito and in different browsers). So the account and files look fine, and the problem seems to be how the custom domain is routed on the server: before the old iFastNet package was terminated it showed “Account Suspended”, and now it returns the cPanel default page. Could a staff member check the domain’s virtual host configuration?

Welcome to the forum. Suspensions are not handled by anyone here on the forum, but by IFastNet. You’ll see in the suspension banner what the next steps are. But they boil down to 1 of 2 options: 1. If its a temporary suspension, due to reaching hit limits, then you just need to wait 2. if it’s a permeant suspension for abuse, you’ll need to follow the link to raise a ticket. I can see the bot says its the latter (I can’t see you account, but it can). So you’ll need to raise a ticket. Sakhz9238: > I will remove any harmful or illegal content If the content was serious (such as illegal content) then they may choose not to reactivate your account, or provide a backup. In extreme cases they may choose not to reply to a ticket.

This article indeed explains the error: This site/page has used all available php / apache processes Fair Usage Limits > Some people see an error page on their website with the following contents: This site / page has used all avaialble php / apache processes allowed on free hosting. Refreshing the page once the amount of apache / php processes are reduced will cause the site to work We would recommend upgrading your hosting account at IFastNet Premium hosting accounts, premium hosting accounts have MUCH higher resources dedicated to them. This article explains why you may see this page, and what you can do … The 0 hits doesn’t really align with it, but remember that none of the stats counters in the panel are truly live counters. After all, your visit also generated hits, so the real number of hits is not zero, but it might take some time for the counters to update.

whos_eddie: > Could you please confirm whether InfinityFree’s browser-verification mechanism or any injected hosting scripts could be contributing to this detection? Since I don’t work for InfinityFree, IFastNet or Google, I can’t. However, I think it’s unlikely otherwise every site hosted here would have the same problem.