Magento Open Source and Adobe Commerce

Magento 2 PHP version requirements, release by release

Each Magento 2.4 release line runs only on the PHP branches Adobe lists for it: 2.4.9 on PHP 8.5, 2.4.8 on 8.3 or 8.4, 2.4.7 on 8.2 or 8.3, and 2.4.6 on 8.1 or 8.2. Lines 2.4.4 and 2.4.5 are listed with PHP 8.1 alone, a branch that got no PHP2Shell release from the PHP project.

Last reviewed against Adobe's system requirements, Adobe's lifecycle policy and php.net.

Requirements table

Which PHP version each Magento 2.4 line supports

Read across from your release line. The fixed release column is the PHP2Shell answer: the PHP project's 21 October 2026 release on each branch Adobe supports for that line.

Release line Newest release PHP Adobe lists PHP2Shell-fixed PHP you can run Composer Adobe lists Adobe Commerce support
2.4.9 2.4.9 (released 12 May 2026) 8.5 8.5.12 2.10 Standard support until 31 May 2029
2.4.8 2.4.8-p5 8.3 and 8.4 8.4.27 or 8.3.36 2.10 for p5; 2.9.3 or later for earlier 2.4.8 patches Standard support until 31 May 2028
2.4.7 2.4.7-p10 8.2 and 8.3 8.3.36 (or 8.2.35, which runs out on 31 December 2026) 2.10 for p10; 2.9.3 or later for earlier 2.4.7 patches Standard support until 31 May 2027; extended support until 31 May 2028
2.4.6 2.4.6-p15 8.1 and 8.2 8.2.35 only 2.2.26 or later Standard support ended 11 August 2026; extended support until 31 August 2027
2.4.5 2.4.5-p17 8.1 None from the PHP project 2.2.26 or later Extended support ended 11 August 2026; security-only period until 31 May 2027
2.4.4 2.4.4-p18 8.1 None from the PHP project 2.2.26 or later Extended support ended 14 April 2026; security-only period until 31 May 2027

Adobe states that it supports only the combinations in its system requirements tables and does not validate any other pairing. The tables are headed for Adobe Commerce on-premises, and the same page sets out the PHP extensions Magento Open Source needs. The support dates come from Adobe's lifecycle policy, which is written for Adobe Commerce; it does not say whether the extended and security-only periods also apply to Magento Open Source. A 2.4.10 alpha, listed with PHP 8.5, is a pre-release and not for live stores.

Sources: Adobe system requirements (updated 13 October 2026); Adobe lifecycle policy (updated 18 September 2026). Branch dates for PHP itself sit on PHP end of life; for every other platform, start at the PHP version requirements hub.

Planning the upgrade

Every hop shares a PHP branch, except the last

Adobe's table has a useful pattern. Each release line lists one PHP branch in common with the line after it, so you can upgrade Magento without changing PHP on the same night, then move PHP once the new release has settled.

The exception is the newest hop. 2.4.8 runs on 8.3 and 8.4, while 2.4.9 is listed with 8.5 only, so a store going to 2.4.9 changes its PHP branch as part of the same piece of work.

Upgrade PHP branch both lines list What it means
2.4.4 or 2.4.5 to 2.4.6 8.1 The upgrade can run on the PHP 8.1 you have; move to 8.2 straight afterwards.
2.4.6 to 2.4.7 8.2 Get onto 8.2.35 under 2.4.6 first, upgrade Magento, then take PHP to 8.3.
2.4.7 to 2.4.8 8.3 Upgrade on 8.3.36, then decide whether to move PHP on to 8.4.
2.4.8 to 2.4.9 None 2.4.9 is listed with 8.5 only, so the Magento upgrade and the PHP change belong in the same maintenance window.

Built from Adobe's system requirements table. Any hop through PHP 8.1 is a bridge to cross quickly: 8.1 never received a fixed release upstream.

Where your store stands

Four Magento positions, four different jobs

Find your release line with bin/magento --version, then read the card that matches it.

3D shield with a green tick above a device, for stores already on a current release

On 2.4.8 or 2.4.9: patch PHP and carry on

Your release line already sits on supported branches. The only job is the fixed release on the branch you run: 8.5.12 for 2.4.9, or 8.4.27 or 8.3.36 for 2.4.8, then a restart of every PHP worker.

3D signpost and paper plane, for moving PHP from 8.2 to 8.3 on Magento 2.4.7

On 2.4.7: move PHP to 8.3 without touching Magento

If the store runs PHP 8.2, the 8.2.35 release closes PHP2Shell, but that branch loses PHP project support at the end of 2026. Adobe lists 8.3 for 2.4.7 too, so the branch change needs no Magento upgrade.

3D dynamite with a smoking fuse, for Magento 2.4.6 on a branch ending 31 December 2026

On 2.4.6: one fixed release, with a deadline

8.2.35 is the highest fixed release Adobe supports for this line. Take it now if you are still on 8.1, and plan 2.4.7 or later before 31 December 2026, when PHP 8.2 reaches end of life.

3D maze with a route out, for Magento 2.4.4 and 2.4.5 stores that must upgrade

On 2.4.4 or 2.4.5: Magento has to move

Both lines are listed with PHP 8.1 alone, and the PHP project shipped no PHP2Shell release for 8.1. A patched 8.1 build from your supplier covers the gap; a Magento upgrade is the only route to a branch with upstream fixes.

The 2.4.4 and 2.4.5 cohort

Stores held on PHP 8.1 by their Magento release

For 2.4.4 and 2.4.5, Adobe lists PHP 8.1 and nothing else. The restriction is built into the code as well: at the 2.4.4-p13 and 2.4.5-p14 tags in Adobe's public magento2 repository, composer.json accepts only PHP 7.4 or 8.1, so Composer itself will not install those releases on 8.2 or later.

For a store that takes card payments, an unfixed PHP build lets an unauthenticated attacker execute code on the very server that produces the checkout, which puts the payment pages themselves within reach. The work splits into two tracks, and the first one cannot wait for the second.

Now

A PHP 8.1 build that carries the fix

  • From your supplier. php.net tells owners of 8.1 and older to contact their distribution or long-term support vendor, some of which backport fixes. Ubuntu 22.04 is one example: its php8.1 package 8.1.2-1ubuntu2.28, in security notice USN-8948-1, carries both fixes. Distribution packages that include them.
  • From source. For teams that compile PHP themselves, the PHP security team published a minimal source-only backport for 8.1. It has no release and no version number of its own. What the backports are.
  • If neither is possible yet. CISA's guidance is to take PHP systems running 8.1 or earlier offline, and the NCSC's is to consider it when you cannot update or mitigate in time. Work through the decision.

Next

The Magento upgrade

  • Adobe's clock is running. Both lines are in a one-time security-only period to 31 May 2027, with limited isolated security fixes and no quality fixes. Adobe describes the period as time to migrate and says it will not be extended.
  • Payment compliance. Adobe's lifecycle policy flags PCI compliance as at risk for stores still on PHP 8.1 after its end of life. It leaves that assessment to the merchant, and its advice is to get both Commerce and PHP back onto supported versions.
  • Where to land. 2.4.6 is the shortest hop, since it accepts 8.1 and 8.2, but it leaves you on PHP 8.2, which ends on 31 December 2026. Going to 2.4.7 or 2.4.8 means changing PHP to 8.3 in the same window.

Step by step

Changing the PHP branch under Magento

These steps cover a PHP branch change on a self-hosted store, such as 2.4.7 moving from 8.2 to 8.3. A release on the same branch, such as 8.4.20 to 8.4.27, needs only steps 6 and 7. The server side of the change is covered on how to update PHP.

  1. Step 1

    Write down the starting point

    Record the Magento release and the PHP version. The command line can report a different PHP from the one serving the store, so also check what the web server runs: why they can differ. 

    bin/magento --version
php -v

  2. Step 2

    Pick the target from Adobe's table

    Choose the highest branch Adobe lists for your line: 8.4 on 2.4.8, 8.3 on 2.4.7. On 2.4.6, 8.2 is the only fixed branch on offer, so treat it as a stopping point on the way to 2.4.7.

  3. Step 3

    Install every extension Magento needs

    Adobe's list is long and includes bcmath, intl, soap, sockets, sodium, xsl and zip. Where extensions are packaged per branch, as on Ubuntu (php8.3-soap belongs to 8.3 alone), a new branch starts without them. Compare php -m on the old and new builds.

  4. Step 4

    Carry the settings across

    Each branch reads its own configuration files, and php --ini shows which ones are loaded. Adobe's upgrade prerequisites warn against setting pcre.recursion_limit, which can leave a rollback incomplete without reporting a failure.

  5. Step 5

    Test a copy of the store

    On a staging copy running the new PHP, browse the catalogue, place an order with each payment method in its test mode, then handle that order in the admin. Let cron run, and read the logs for deprecation notices and errors.

  6. Step 6

    Switch production in a window

    Run bin/magento maintenance:enable, point the web server and the Magento crontab at the new PHP, restart the PHP workers, then bin/magento maintenance:disable.

  7. Step 7

    If Magento has to move as well

    Adobe's upgrade guide runs the Magento upgrade through Composer: maintenance mode on, cron stopped, a backup of composer.json, composer require-commerce for the target release, composer update, caches and generated code cleared, bin/magento setup:upgrade, then maintenance mode off. It also requires a PHP version the target release supports before you start, which is why the hop table above matters. Follow Adobe's upgrade instructions for the exact commands.

Composer and extensions

What Composer will tell you, and what it will not

A Magento store is a Composer project, so Composer is the quickest way to find out which packages object to a new PHP branch. Run these with the new PHP binary, on the staging copy. 

composer check-platform-reqs --no-dev
composer prohibits php 8.3

The first compares the PHP version and extensions actually present with what every installed package requires. Composer's documentation notes that it ignores any config.platform override and checks the real platform. The second names each package that blocks the branch you give it, along with the constraint it declares.

Composer accepts more than Adobe supports

In Adobe's public magento2 repository, composer.json for 2.4.9 accepts PHP 8.3 to 8.5, for 2.4.8-p5 8.2 to 8.4, and for 2.4.7-p10 8.1 to 8.3. Each range is wider than Adobe's support list, so a clean install proves the packages resolve, not that Adobe supports the pairing.

Third-party modules set their own limits

Every module installed through Composer declares the PHP it accepts, and one stale constraint can block the change. Modules copied onto the server by hand never pass through Composer, so only running them on the staging copy will show whether they work.

Adobe Commerce extras

Adobe's Upgrade Compatibility Tool checks a customised Adobe Commerce instance against a target Commerce version; Adobe says it is for Adobe Commerce only. On Adobe Commerce on cloud infrastructure, Adobe's prerequisites route service changes on Pro projects through a support ticket that includes the updated .magento.app.yaml and services.yaml files.

Sources: Composer command reference; Adobe's magento2 repository; Upgrade Compatibility Tool; Adobe upgrade prerequisites.

Confirm it worked

Prove both PHP paths moved

Magento uses PHP in two places: the web server that builds every page, and the cron jobs Magento schedules for its background tasks. Both have to be on the fixed release. 

bin/magento --version
crontab -l
/path/to/the/php/in/your/crontab -v
composer check-platform-reqs --no-dev
  • The web server's PHP. Read the version the site itself reports and compare it with the fixed release for its branch: ways to check.
  • Cron's PHP. The Magento crontab names a PHP binary in each line (Adobe's example uses /usr/bin/php). Run that binary with -v; if it still reports the old branch, cron is running on it.
  • The Magento release. After a platform upgrade, bin/magento --version should show the target. Adobe's developer documentation also lists the admin footer, a request to /magento_version and composer.lock.
  • No stale workers. A PHP-FPM or Apache process started before the update keeps serving the old build until it restarts: restart and confirm.
  • The time it was exposed. A store that ran unfixed PHP on the internet is worth checking for planted files and checkout changes, even now it is patched: signs of compromise.

For what the fixes are and why they matter, see PHP2Shell explained. Running a different shop platform? See Magento 1 and OpenMage, PrestaShop or WooCommerce.

Quick answers

Magento PHP version questions

What PHP version does Magento 2 need?

It depends on the 2.4 release line. Adobe lists PHP 8.5 for 2.4.9, 8.3 and 8.4 for 2.4.8, 8.2 and 8.3 for 2.4.7, 8.1 and 8.2 for 2.4.6, and 8.1 alone for 2.4.5 and 2.4.4. Adobe supports only the combinations in its table.

Within the branch, the release number matters for PHP2Shell: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and later are fixed.

Can Magento 2.4.9 run on PHP 8.4?

Composer will install it: the composer.json in Adobe's public magento2 repository for 2.4.9 accepts PHP 8.3, 8.4 and 8.5. Adobe's system requirements, though, list 8.5 alone for 2.4.9, so 8.4 is outside the combinations Adobe supports. Plan the move to 8.5.12 or later as part of the 2.4.9 upgrade.

Is Magento 2.4.5 safe on PHP 8.1?

Only on a PHP 8.1 build that carries the PHP2Shell fixes, because the PHP project itself released none for 8.1. Some Linux distributions and long-term support vendors have backported them, so ask whoever supplies your PHP for written confirmation.

Without that, CISA's guidance is to take PHP systems running 8.1 or earlier offline. Adobe's own lifecycle policy also says that running PHP 8.1 past its end of life puts PCI compliance at risk.

Should I take my website offline?

Should I upgrade PHP or Magento first?

PHP first whenever your current release line lists a newer branch than the one you run: 8.2 on 2.4.6, 8.3 on 2.4.7, 8.4 on 2.4.8. It is the smaller change and it closes PHP2Shell sooner.

Magento first on 2.4.4 and 2.4.5, which list nothing beyond 8.1. And because 2.4.9 lists only 8.5, the move from 2.4.8 to 2.4.9 and the change to PHP 8.5 go together.

Does Adobe patch PHP for Magento stores?

No. Adobe's lifecycle policy states that Adobe gives no security or quality fixes for third-party dependencies such as PHP, and that customers are responsible for watching the support status of the PHP versions they run. On a self-hosted store, PHP updates come from your host, your Linux distribution or whoever builds your PHP.

What about Magento 1?

Magento 1 follows different rules. Adobe's lifecycle policy covers only the 2.4 release lines, and Magento 1 era stores that are still maintained mostly run OpenMage LTS, which publishes its own PHP requirements.

Magento 1 and OpenMage PHP versions

3D rocket illustration above the call to find every exposed PHP server

Know your exposure

Find every PHP server you run

Patching the server you know about is the easy part. A vulnerability scan finds the forgotten staging site, the old microsite and the appliance with PHP inside, then tells you which ones are still exposed.

Find Every Exposed PHP Server Book a Free Consultation