Bug fixing & firefighting
White screens, 500 errors, broken checkouts, cron jobs that stopped. We find the cause in code you didn't write.
Professional PHP security team
We are a team of PHP security engineers. AI helps us read through large, undocumented codebases fast; experienced engineers review every finding and every change by hand. Together we untangle the hard cases, from a PHP 5.2 monolith nobody dares to touch to an app stuck two majors behind, without forcing a rewrite.
Security advisory · October 2026
PHP2Shell is the name given to CVE-2026-109618 and CVE-2026-109619, two critical memory-safety bugs in the PHP engine. They can allow unauthenticated remote code execution, and one path can leak other requests' memory (passwords, session tokens, API keys) back to an attacker. Because the bugs are in PHP itself, WordPress, Magento, Laravel and hand-written apps are exposed alike.
| PHP 8.5 | ≥ 8.5.12 |
| PHP 8.4 | ≥ 8.4.27 |
| PHP 8.3 | ≥ 8.3.36 |
| PHP 8.2 | ≥ 8.2.35 |
| PHP 8.1 and older | No upstream release: backport or upgrade |
PHP 8.1 and older get no new upstream release. Fixes exist only as distribution or vendor backports, or by upgrading. This is where most old projects are stuck, and where we help.
session.upload_progress.enabled at the server level (php.ini or FPM pool, not ini_set()), then restart PHP workers.multipart/form-data requests at nginx or Apache.post_max_size, upload_max_filesize) and restrict public access to anything non-essential.These steps only reduce exposure. Updating PHP is the only complete fix.
Find the PHP that actually serves web requests. The CLI php -v can differ from the FPM or Apache build.
<?php echo PHP_VERSION; // temporary file, delete afterDebian / Ubuntu: see whether your package includes the fix (adjust the version).
zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gzRHEL / AlmaLinux / Rocky:
rpm -q --changelog php-common | grep CVE-2026-109618End-of-life PHP
PHP 8.1 and everything before it no longer receive security releases from the PHP project, including for PHP2Shell. Most hosting panels, Docker images and old servers are still running these versions. Waiting for an official patch means waiting forever, so we bring you to a secure state in three steps.
Apply a vetted security backport or compensating controls to the version you run today, so the immediate risk is closed within days, not months.
Move step by step to the latest secure PHP release (8.4 / 8.5): fix removed functions, update dependencies and test every stage before it reaches production.
Lock down php.ini and PHP-FPM, disable dangerous functions, fix file permissions, add WAF rules and monitoring so the next PHP2Shell does less damage.
Human review + AI
Legacy PHP is full of surprises. We use AI for breadth and engineers for judgement, and nothing ships without a person signing it off.
Services
White screens, 500 errors, broken checkouts, cron jobs that stopped. We find the cause in code you didn't write.
PHP 5.x / 7.x → 8.x step by step: removed functions, mysql_* → PDO, deprecations, strict types and dependency updates.
Laravel, Symfony, CodeIgniter, ThinkPHP, Yii, Zend / Laminas, CakePHP, and WordPress, Magento or Drupal sites.
Patch known CVEs, remove malware and web shells, fix SQL injection and XSS, and harden server configuration.
From shared hosting or a dying VPS to modern PHP-FPM, Docker or a managed platform, with no surprises on cut-over day.
Monthly patching, dependency updates, monitoring and a developer on call who already knows your code.
Versions
Upstream support ends; your business doesn't. We work on code and servers across the whole PHP timeline.
How it works
Send the symptoms, PHP version and hosting details. Repository access helps but isn't required to start.
We review the code and environment and explain the risks in plain language.
A clear scope and price before any work starts. No open-ended hourly billing.
We fix, test and deploy, then document what changed so any developer can pick it up.
FAQ
We close the immediate risk first with a vetted backport or compensating controls, then plan an upgrade to the latest secure PHP release and harden the server along the way.
AI helps us read and search large codebases quickly. Every finding is checked and every change is written or approved by an engineer before it reaches your servers.
Almost never. Most legacy PHP can be stabilised and upgraded in place. We only suggest replacing parts when that is clearly cheaper over time.
Reports say the vulnerable code goes back to PHP 5.4, and PHP 8.1 and older receive no upstream fix. Treat old versions as affected until a backport or upgrade is in place.
That's our normal starting point. We map the code, the server and the deployment first, then write down what we learn.
Yes. We work on a copy or staging environment first, schedule changes with you and keep a rollback path for every deployment.
Yes. We are happy to sign your NDA before seeing any code.
Contact
Tell us your website and what is going on. We reply in English or Japanese.
Prefer email? hello@rescuephp.com