Magento 1 and OpenMage LTS
Magento 1 PHP version: original Magento 1 and OpenMage
Adobe's current lifecycle table lists Magento 2.4 releases alone, so the PHP answer for a Magento 1 store now comes from OpenMage LTS, the community project that carries the codebase on. Its current release, 20.19.0, accepts PHP 8.1 to 8.5. Stores on original Magento 1 or an old OpenMage release may be running PHP that no longer gets fixes.
Last reviewed against OpenMage's documentation and releases, Adobe's lifecycle policy and php.net.
Requirements table
Which PHP each Magento 1 era release accepts
The PHP ranges below are the ones each OpenMage release declares in its composer.json. OpenMage's requirements page adds that 8.4 and 8.5 are supported but may produce warnings in the logs.
| Release | Published | PHP accepted | Status |
|---|---|---|---|
| OpenMage 20.19.0 | 26 October 2026 | 8.1 to 8.5 | Newest stable release; carries every security fix published that day |
| OpenMage 20.18.2 | 26 October 2026 | 8.1 to 8.5 | Security-only patch on 20.18.0; three advisories are fixed in 20.19.0 only |
| OpenMage 20.16.0 | 1 November 2025 | 8.1 to 8.5 | First release to accept PHP 8.5; superseded |
| OpenMage 20.14.0 | 20 June 2025 | 8.1 to 8.4 | Raised the minimum to PHP 8.1; superseded |
| OpenMage 20.13.0 | 28 February 2025 | 7.4 to 8.4 | Last release to accept PHP 7.4 and 8.0; superseded |
| OpenMage 19.x | Last release 19.5.3, 27 February 2024 | 7.4 to 8.2 (19.5.3) | OpenMage names 20.x as its maintained line; 19.4.x patches ran until 4 April 2025 |
| OpenMage 21.0.0-beta3 | 26 October 2026 | 8.2 to 8.5 | Pre-release of the next major version |
| Original Magento 1 | Not listed | Check what your server actually runs | Absent from Adobe's current lifecycle table, whose oldest line is 2.4.4 |
What the ranges mean for PHP2Shell: on OpenMage 20.x, the fixed releases you can use are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The bottom of the range, PHP 8.1, reached end of life on 31 December 2025 and got no fixed release from the PHP project.
Sources: OpenMage system requirements; OpenMage supported versions; OpenMage release notes and the composer.json at each release tag; Adobe lifecycle policy. The hub compares every platform this site covers: PHP version requirements.
First, which one is it?
Original Magento 1 or OpenMage: telling them apart
The two look much alike in the admin, and both are often just called "Magento 1". Their PHP options are very different, though, so confirm which one the store runs before planning anything.
Look at the admin footer
Log in to the admin and scroll to the bottom of any page. OpenMage 20.x prints "OpenMage" followed by its release number, such as 20.19.0, and later 19.x releases do the same. A footer reading "Magento ver." with a 1.x number points to original Magento 1 code, or to a very early OpenMage 19.4 release that kept the old wording.
Do not trust "1.9.4.5" on its own
OpenMage 20.19.0 still returns 1.9.4.5 from
Mage::getVersion(), so an extension or
report quoting that number does not settle the question. The
OpenMage release comes from
Mage::getOpenMageVersion(), or, on a
Composer install, from the openmage/magento-lts
package.
Source: the admin footer template and app/Mage.php
in the
OpenMage repository,
at the v20.19.0, v19.4.23 and v19.4.0 tags.
Card-handling shops
Why an old Magento 1 stack is a payments problem
If a store has not been updated for years, its PHP may not have been either. When that store also takes payments, four facts from the past week sit on top of each other.
The server behind the checkout
PHP2Shell can let an attacker with no account run code on a web server. On a shop, that server assembles the pages customers pay on, so whoever controls it can alter what those pages collect and where they send it.
Old PHP branches get little or nothing
The PHP project released no PHP2Shell fix for 8.1 or older. It published minimal source-only backports for 7.4, 8.0 and 8.1, and none for 7.3 or anything earlier.
The application has its own fixes
OpenMage 20.18.2 and 20.19.0, both out on 26 October 2026, fix a long list of security issues in the shop software itself, one rated critical. A shop running original Magento 1 code gets none of them.
The official guidance is plain
CISA wants PHP systems taken offline when they cannot be updated immediately or run 8.1 or older. The NCSC's alert points the same way when updates and mitigations cannot be applied in time.
CISA also added both PHP2Shell vulnerabilities to its Known Exploited Vulnerabilities catalogue on 26 October 2026. The full background is on PHP2Shell explained, and the OpenMage fixes are listed in its 20.19.0 release notes.
The realistic routes
Stay on the codebase, or leave it
There are two ways to end up on PHP the PHP project still fixes. Neither is quick, which is why the stopgap in the third box comes first.
Route 1
OpenMage 20.x on PHP 8.3 or 8.4
The smaller change for most stores, because the data, theme and admin stay familiar. PHP 8.3 has the fewest caveats today: fixed in 8.3.36, supported by the PHP project until 31 December 2027, and outside the 8.4 and 8.5 range where OpenMage warns of logged warnings. 8.2 is fixed too but ends on 31 December 2026, and the OpenMage 21 pre-release already requires 8.2 or later.
Expect work on extensions. OpenMage says 20.x carries changes that may not be fully backward compatible with Magento 1.9.4.x, unlike the mostly compatible 19.x line.
Route 2
Replatform
Moving to a different shop platform is the bigger project, and the store's PHP then follows that platform's rules. For Magento 2, Adobe documents a Data Migration Tool with modes for settings, bulk data and the changes made since the last run, such as new orders; themes and custom code need rebuilding.
PHP requirements for some other platforms are on Magento 2, PrestaShop and WooCommerce. This site does not recommend one platform over another.
Meanwhile
Cover the gap this week
- Ask whoever supplies your PHP whether the build you run has the PHP2Shell fixes backported, and get the answer in writing. Backported fixes for older branches have come from some Linux distributions and long-term support vendors.
- If not, restrict who can reach the shop, or close it until it is fixed.
- Apply the PHP project's interim settings as a partial measure only.
Sources: OpenMage documentation (Magento 1 compatibility); Adobe Data Migration Tool; php.net supported versions. For retired PHP branches, PHP end of life sets out the options.
Step by step
Moving a Magento 1 store onto OpenMage 20.x and a fixed PHP
Do all of this on a copy, never on the live shop. The order matters: the application changes first, on the old PHP, so that each problem you meet has one cause.
-
1. Take stock of what the store runs
Note the version in the admin footer, the PHP version the site reports (how to find it), the theme, and every extension, including the ones a developer added by hand years ago.
-
2. Build a staging copy
Copy the files and the database to a separate server or account that the public cannot reach. Mask customer details in the copy where you can, and switch payment methods to their test mode if they have one.
-
3. Move the copy to OpenMage 20.19.0
OpenMage documents installation with Composer and with Git on its installing page. 20.19.0 needs PHP 8.1 or later. If the copy runs PHP 7.4 or 8.0, one way to keep causes apart is a stop at 20.13.0, the last release that accepts those branches, before the PHP change; only the copy should ever run it. Fix whatever the extensions break before you move on.
-
4. Prepare PHP 8.3 with the right extensions
OpenMage 20.19.0 declares ctype, curl, dom, ftp, gd, hash, iconv, intl, json, libxml, mbstring, mysqli, pdo_mysql, posix, simplexml, soap, spl and zlib. Its requirements page also names MySQL 5.6 or later (8.0 or later recommended) or MariaDB, and the patch command at 2.7 or later. Install the fixed release, 8.3.36 or later.
-
5. Switch the copy and test the money path
Move the copy to the new PHP, then place orders with each payment method, run a refund, send the order emails and let the cron jobs run. On a Composer install,
composer prohibits php 8.3names any package that refuses the branch. Read the logs for warnings. -
6. Repeat on the live store in a quiet hour
Take a fresh backup, put the shop into maintenance, apply the same changes in the same order, and keep the old server or configuration ready to bring back if the checkout fails.
For the server side of the PHP change, from control panels to Linux packages, see how to update PHP.
Picking the OpenMage release
20.19.0, 20.18.2 or 21?
OpenMage published three releases on 26 October 2026, and they serve different stores.
Under OpenMage's maintenance policy, 20.x keeps receiving patch releases until two years after 21.x is released, so a move to 20.x now is not a dead end.
- 20.19.0 is the release to aim for. It holds every security fix OpenMage published that day, plus feature work held over from earlier.
- 20.18.2 is a security-only patch for stores already on 20.18.0 that are not ready for new features. It leaves out three advisories whose fixes needed behaviour or database changes; those are in 20.19.0 only.
- 21.0.0-beta3 is a pre-release. It carries the same fixes, but it is still a beta, and it needs PHP 8.2 or later.
Confirm it worked
Check the application and the PHP, separately
Two things changed, so prove both. A store that shows the right OpenMage release but still serves pages from an old PHP worker is no safer than before.
The OpenMage release
The admin footer should read "OpenMage 20.19.0" (or 20.18.2). On a Composer install, these confirm the package version and that the PHP on this server meets every installed package's needs:
composer show openmage/magento-lts
composer check-platform-reqs --no-devThe PHP that serves the shop
- Read the version the website reports, not just
php -v, and make sure it is at least the fixed release on that branch: other ways to read it. - Check the PHP binary that the store's cron jobs call, which can differ from the web server's.
- Restart every PHP worker so none keeps the old build in memory: restart and confirm.
- If the store ran unfixed PHP on the internet, look for signs that someone got in before you closed the door: what to look for.
Quick answers
Magento 1 and OpenMage PHP questions
What PHP version does Magento 1 need today?
For a store kept on the Magento 1 codebase today, the working answer comes from OpenMage LTS. Its current 20.x releases need PHP 8.1 or later and run on branches up to 8.5; OpenMage cautions that warnings can appear on 8.4 and 8.5.
The PHP project left 8.1 itself without a fix, so in practice aim for 8.3 or 8.4 at their fixed releases: 8.3.36 or 8.4.27 or later.
Is Magento 1 still supported?
Not by Adobe's current lifecycle policy, which lists only the Magento 2.4 release lines. The Magento 1 codebase is carried forward by OpenMage LTS, an unofficial community project whose 20.x line is maintained. OpenMage's older 19.4.x releases were patched until 4 April 2025 and no later.
Does OpenMage work with PHP 8.4 and 8.5?
Yes. OpenMage's requirements page lists both as supported, with the caveat that some warnings may be shown or logged. The composer.json for 20.19.0 accepts every branch from 8.1 up to, but not including, 8.6.
My Magento 1 store runs PHP 7. Is it exposed to PHP2Shell?
Yes. The PHP project says the flaws affect every PHP installation that serves web requests, and it released no fix for any branch older than 8.2. A minimal source-only backport exists for 7.4; for 7.3 and older the PHP project published nothing at all.
Ask whoever supplies your PHP whether their build carries a backported fix. If not, the safer course is to restrict access to the shop while you move it.
Is OpenMage the same as Magento 1?
It is a continuation of it, not a copy, and OpenMage calls itself unofficial and run by its community. Its 19.x releases stayed mostly backward compatible with Magento 1.9.4.x; its 20.x releases include changes that may not be fully compatible, so extensions written for original Magento 1 need testing.
Can I move from Magento 1 to Magento 2 instead?
Yes. Adobe documents a Data Migration Tool that copies settings, store data and later incremental changes from a Magento 1 database into Magento 2. Themes, extensions and custom code are separate developer work, and the new store then follows Magento 2's PHP rules.
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.