Critical PHP2Shell: two unauthenticated RCE flaws in PHP itself. Fixes shipped on 21 Oct 2026. Check if you are affected →

Professional PHP security team

Old PHP version?No official patch?We fix it.

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.

Human + AIevery change reviewed by an engineer
PHP 4 → 8.5every version we work on
Fixed quoteafter a free assessment

Security advisory · October 2026

PHP2Shell: patch now, even if your code is clean

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.

CVE-2026-109618 CVE-2026-109619 CVSS 9.2
Severity
CVSS v4.0 9.2 (both CVEs)
Attack
Remote, no login required
Runtimes
PHP-FPM, Apache mod_php and others
Reach
Vulnerable code reported back to PHP 5.4
In the wild
Attack traffic seen since 21 Oct 2026

Patched upstream releases

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 olderNo 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.

Can't patch today? Interim steps

  • Turn off session.upload_progress.enabled at the server level (php.ini or FPM pool, not ini_set()), then restart PHP workers.
  • If the app never accepts file uploads, block multipart/form-data requests at nginx or Apache.
  • Tighten request-size limits (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.

Quick self-check

  1. 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 after
  2. Debian / Ubuntu: see whether your package includes the fix (adjust the version).

    zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz
  3. RHEL / AlmaLinux / Rocky:

    rpm -q --changelog php-common | grep CVE-2026-109618

What our PHP2Shell response includes

  • Inventory of every PHP install on your servers: containers, parallel versions and bundled copies.
  • Patch to a fixed release, or apply a trusted backport for PHP 5.x – 8.1.
  • Interim mitigations applied and verified in the live config, not just in php.ini.
  • Compromise check: web shells, modified files, new admin users and suspicious cron jobs.
  • Short written report of what we found and what we changed.
Request a PHP2Shell patch

End-of-life PHP

No official fix for your version? That's exactly what we do.

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.

  1. Now01

    Stabilise

    Apply a vetted security backport or compensating controls to the version you run today, so the immediate risk is closed within days, not months.

  2. Next02

    Upgrade

    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.

  3. Always03

    Harden

    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

Faster than manual-only. Safer than AI-only.

Legacy PHP is full of surprises. We use AI for breadth and engineers for judgement, and nothing ships without a person signing it off.

AI

AI does the heavy reading

  • Scans the whole codebase for vulnerable patterns, removed functions and upgrade blockers
  • Traces data flow through code nobody has documented
  • Drafts fixes and tests for repetitive changes across thousands of files
Human

Engineers make the calls

  • Review every finding and discard false alarms
  • Read and approve every line of every change
  • Handle the tricky parts: business logic, data migrations, production cut-over

Services

Everything an old PHP codebase needs

Bug fixing & firefighting

White screens, 500 errors, broken checkouts, cron jobs that stopped. We find the cause in code you didn't write.

Version upgrades

PHP 5.x / 7.x → 8.x step by step: removed functions, mysql_* → PDO, deprecations, strict types and dependency updates.

Framework upgrades

Laravel, Symfony, CodeIgniter, ThinkPHP, Yii, Zend / Laminas, CakePHP, and WordPress, Magento or Drupal sites.

Security & cleanup

Patch known CVEs, remove malware and web shells, fix SQL injection and XSS, and harden server configuration.

Server & hosting moves

From shared hosting or a dying VPS to modern PHP-FPM, Docker or a managed platform, with no surprises on cut-over day.

Ongoing maintenance

Monthly patching, dependency updates, monitoring and a developer on call who already knows your code.

Versions

Any PHP version. Seriously.

Upstream support ends; your business doesn't. We work on code and servers across the whole PHP timeline.

  1. 42000
  2. 5.22006
  3. 5.32009
  4. 5.42012
  5. 5.62014
  6. 7.02015
  7. 7.42019
  8. 8.02020
  9. 8.12021
  10. 8.22022
  11. 8.32023
  12. 8.42024
  13. 8.52025
End of life: we still support it Supported upstream

How it works

Four steps, no lock-in

  1. 01

    Tell us what's broken

    Send the symptoms, PHP version and hosting details. Repository access helps but isn't required to start.

  2. 02

    Free assessment

    We review the code and environment and explain the risks in plain language.

  3. 03

    Fixed quote

    A clear scope and price before any work starts. No open-ended hourly billing.

  4. 04

    Fix & hand-over

    We fix, test and deploy, then document what changed so any developer can pick it up.

FAQ

Questions we hear a lot

Our PHP version has no official fix. What can you do?

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.

Is the work done by AI?

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.

Do we have to rewrite the project?

Almost never. Most legacy PHP can be stabilised and upgraded in place. We only suggest replacing parts when that is clearly cheaper over time.

Our site runs PHP 5.6 / 7.x. Are we affected by PHP2Shell?

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.

The original developer is gone and there are no docs.

That's our normal starting point. We map the code, the server and the deployment first, then write down what we learn.

Can you work on our servers without breaking production?

Yes. We work on a copy or staging environment first, schedule changes with you and keep a rollback path for every deployment.

Do you sign an NDA?

Yes. We are happy to sign your NDA before seeing any code.

Contact

Send us your PHP problem

Tell us your website and what is going on. We reply in English or Japanese.

Helpful to include

  • PHP version and framework (if known)
  • Hosting: shared, VPS, cloud or Docker
  • What is broken, or what needs upgrading
  • Deadline or urgency

Prefer email? hello@rescuephp.com

We only use these details to reply to you.