# PHP2Shell: how we protected Mikhmon and why access felt slower > On October 22, 2026, we updated Mikhmon's PHP runtimes to patched PHP 8.5.12. We also used Cloudflare WAF temporarily as an extra precaution, during which some users experienced slower access. Published: 23 Oct 2026. Basics. **Pro tip.** If you host Mikhmon yourself, update PHP on that server and restart its PHP workers. Updating Mikhmon application files alone does not update PHP. ## If Mikhmon felt slower on October 22 While responding to PHP2Shell, we temporarily used Cloudflare WAF to add screening before requests reached Mikhmon. Some users experienced slower access during that protection. We understand that delays get in the way when you are managing a network or printing vouchers. This article explains what happened and what we changed in plain language. ## The flaw was in PHP itself PHP is server software that runs part of Mikhmon's code. On October 21, 2026, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Under certain conditions, attackers could read sensitive process memory or run their own code on affected systems without logging in. Imagine a worker serving people at a counter. After each job, the worker needs to clear the previous person's notes before serving the next person. PHP2Shell involves mistakes in handling failures and cleaning up request data. State left behind by one request can affect a later request. The vulnerable software is PHP itself. Even a carefully written application needs its underlying PHP runtime updated. - [Official PHP security announcement, October 21, 2026](https://www.php.net/archive/2026.php) - [PHP2Shell researcher overview](https://www.php2shell.com/) ## Temporary protection and slower access A web application firewall, or WAF, examines incoming traffic and blocks requests matching suspicious patterns. Cloudflare released emergency blocking rules on October 21. We used Cloudflare WAF temporarily during our response. Additional checks can make access less smooth. If a rule requires browser verification, the page waits until that check finishes. Different visitors can experience different delays. We do not have measurements in this article that attribute an exact share of each connection's delay to the WAF. But the inconvenience during this temporary protection deserves an explanation. A firewall helps filter attacks it recognizes. Repairing the flaw inside PHP still requires updating PHP, so our response also covered the software running Mikhmon. - [Cloudflare emergency WAF release, October 21, 2026](https://developers.cloudflare.com/changelog/post/2026-10-21-emergency-waf-release-cfmr/) - [How Cloudflare browser challenges work](https://developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/) ## What we changed on October 22 We updated the PHP runtime serving Mikhmon v3 to PHP 8.5.12, a fixed release. We also updated the separate PHP runtime used to render vouchers. We disabled PHP's session upload-progress feature, which is involved in confirmed attack paths. This is an additional precaution alongside the patched runtime. Moving to the newer runtime required compatibility changes in older Mikhmon code. We updated backend response handling and added checks for successful responses, service failures, and failed connections accidentally reusing an earlier response's status. We adjusted legacy router-password handling to avoid a PHP 8.5 warning while preserving its existing output. Server warnings now go to server logs instead of interrupting customer pages. This warning cleanup is separate from the PHP2Shell fix, which comes from the PHP update. ## Protections already in place before disclosure On October 14, before PHP2Shell was announced, we tightened the shared PHP environment around the assumption that someone might eventually run unauthorized code inside it. PHP does not hold our database, session-store, or object-storage credentials. It asks a separate backend to perform the operations it needs. Access tokens handed to PHP work only while their originating request is being handled. Once that request ends, the backend rejects those tokens. Think of a temporary pass that stops working when its assigned job is finished. A token observed inside PHP cannot be saved and reused after its originating request ends. We also restricted PHP workers' permissions and their connection to the web server. These controls limit the impact of a compromise. Requests happening at that moment can still be affected because customers share the PHP runtime, so patching PHP remained necessary. ## What customers need to do For customers using our hosted Mikhmon Pro service, we handle this PHP maintenance on the server. You do not need to install PHP on your phone or laptop. We also added a customer-panel notice explaining the patch. If you run a separate Mikhmon installation on your own server, it needs its own PHP update. Our hosted-service update does not change your server. If you had to wait longer to open Mikhmon during our response, we are sorry for the inconvenience. You deserve to know what we addressed and what changed on the service you use. --- Source: https://mikhmon.pro/blog/en/php2shell-how-we-protected-mikhmon Bahasa Indonesia version: https://mikhmon.pro/blog/php2shell-cara-kami-mengamankan-mikhmon.md Run Mikhmon online with Mikhmon Online, free for 30 days: https://mikhmon.pro/en