Skip to content

PHP security & support

Two critical PHP flaws. One support deadline. Is your site still covered?

On 21 October 2026, PHP fixed two critical flaws (CVSS v4.0 9.2) that let an unauthenticated request run code on the server. Every PHP install that serves web requests is affected, and attacks have already been reported. Separately, PHP 8.2 loses security support on 31 December 2026. We audit what you run, patch it, and migrate what cannot be patched.

Fixed price per property. No retainer. Server or admin access needed for the version check.

Check your PHP version first

The same lookup our audit starts with.

Not sure where to find it? WordPress: Tools, then Site Health. cPanel: MultiPHP Manager. Laravel: php -v.

  • 9.2

    CVSS v4.0, both flaws

  • All

    PHP installs serving web requests

  • 21 Oct

    Fixed in 8.5.12, 8.4.27, 8.3.36, 8.2.35

  • 31 Dec

    PHP 8.2 support ends

What we look at

Six things decide whether you are exposed

Most of it is invisible from a browser. The version is rarely in the headers, and Linux packages can be patched without the version changing. That is why the audit needs server access, and why a free online scanner will not tell you the truth.

  1. 01

    PHP version and patch level

    Exact branch and build, checked against the 21 October fixes: 8.5.12, 8.4.27, 8.3.36, 8.2.35. For Ubuntu, Debian and Red Hat packages, we read the package changelog too.

  2. 02

    Framework, CMS and server mode

    WordPress, WooCommerce, Laravel, Drupal, Joomla, Magento or Shopware, and how PHP runs. The advisory rates Apache mod_php as the highest risk.

  3. 03

    Branch support status

    PHP 8.1 and older are end of life. PHP 8.2 ends on 31 December 2026. Which one you are on decides whether the fix is a patch or a migration.

  4. 04

    Credential exposure

    Code runs with the web server's privileges, so database passwords, API keys and payment credentials the site can read are at risk. We list what to rotate.

  5. 05

    Edge protection

    Whether a firewall or proxy sits in front, and whether it limits request size and multipart uploads, as the advisory recommends.

  6. 06

    Header hygiene

    Version disclosure, HSTS, referrer and content security policy, and what those gaps actually expose.

Fixed prices

Priced before we start, not after

Every line is a fixed fee for a defined scope. Your audit report states effort in hours, so you can match it to the band before you commit to anything.

ServiceWhat you getTypical scopeFrom
AuditReport per property: version, patch state, risk, recommended action and effort1 property$400
Audit, three propertiesThe same report covering three properties, in one document3 properties$1,200
Patch and verifyUpgrade to the patched build, regression pass, credential rotationper property$250
Migration: WordPressMove to PHP 8.4 or 8.5, plugin and theme compatibility, staged cutoversmall store$800
Migration: custom appLaravel, Symfony or Magento, test coverage, rollback plancustom build$2,500
MaintenanceSecurity releases within 72 hours, version currency, quarterly reportper month$250

Prices are starting points for the smallest scope in each band. The quote you receive is fixed against the effort stated in your audit report.

How it runs

Four steps, no discovery phase

  1. Send access

    SSH, hosting panel or CMS admin for each property. We do not need a call to start.

  2. Get the report

    A two-page report within three working days. Findings only, no invoice attached.

  3. Choose the fix

    Patch, migrate, or harden the server for now while a migration is planned. The report gives effort per item, so you decide per property.

  4. We ship it

    Fixed fee, staged where it matters, with a rollback plan and credential rotation as standard.

Frequently asked questions

Yes. Both flaws are in PHP itself, not in your site's code. A site can be perfectly stable and still run an affected build. Being unpatched does not look like anything until it is exploited.

Usually not. Most hosts hide the X-Powered-By header, and CMS generator tags are unreliable. Linux distributions also patch PHP without changing the version number. Server access or the CMS health screen is the only reliable check, which is why the audit is priced as work rather than offered as a free tool.

Possibly both. Ubuntu, Debian and Red Hat apply security fixes to their own PHP packages and keep the old version number. The audit checks the package changelog, so the answer is based on what is installed, not on the number.

Partly. The PHP advisory lists settings and request limits that narrow the attack, and we can apply them the same day. PHP is clear that these are not a complete fix, so we treat them as a bridge to the patch or migration.

Then the report says so, and you owe us nothing further. We would rather tell you that in a page than sell you a migration you do not need.

No. It is a version, configuration and exposure audit. We attempt no exploitation, and the report says so. If you need a penetration test, we will tell you who to talk to.

Yes, and most audits are exactly that. We support WordPress, WooCommerce, Laravel, Symfony, Drupal, Joomla, Magento and Shopware.

You do not run or manage PHP on Shopify, so there is nothing for you to patch there. This matters for self-hosted stores such as WooCommerce and Magento, and for any other PHP site you run beside your store.

PHP 8.2 loses security support at the end of 2026. Sites on 8.2 keep working but stop receiving security fixes. A migration is cheaper planned in November than rushed in December, and much cheaper than an incident.

Sources

Facts on this page come from the PHP project. Last checked 22 October 2026.

Start with the version.

Send us one URL per property and we will confirm scope and price the same working day. If you already know your PHP version, say so and skip the first step.

Request an audit

Devoptly builds Shopify apps and custom PHP. The team that quotes the work does the work.