EdTech Trends
How to Build an LMS Without Building Most of It
Most of an LMS is a solved problem you can rent. A buyer's view of when custom code is worth it, which standards keep you portable, and how to scope the part that is actually yours.
On October 21, 2026, the PHP project shipped emergency fixes for two critical flaws in PHP itself, now known as PHP2Shell. Every Magento and Adobe Commerce store runs on PHP, researchers have shown the attack working against the newest Magento release, and attack attempts were spotted before the fix was even public.
So the only question that matters this week is a simple one: is your store exposed right now? You don't need to read code to answer it. You need four answers from the people who run your store, and you can usually get them within the hour.
How to check if your store is exposed to PHP2Shell
Send these four questions to your hosting provider or development team, in writing, today.
1. Which PHP version is serving the store? Not "the latest" or "it's supported." The actual version number. Anyone with access to your server can read it in under a minute.
2. Is it a patched build, and has PHP been restarted since? The PHP project released fixed builds for its four supported branches, 8.2 through 8.5. Installing the update isn't enough on its own; PHP has to be restarted so the patched version is the one actually serving traffic. If the answer to question 1 is 8.1 or older, there is no official fix at all. More on that below.
3. Who patches PHP on our setup? Depending on how your store is hosted, that's your hosting provider, your agency, or your platform vendor. You want a name, not a shrug. If nobody can say who owns it, that's your first problem, and it won't be solved by this one patch.
4. Is Magento itself on the October security patch? Eight days before PHP2Shell, Adobe fixed a separate critical Magento flaw known as BlockStrap. It is a different hole in a different layer, and the PHP update does nothing for it. More on that below as well.
Ask the same questions about every environment, not just the live store. Staging sites, old subdomains, and that forgotten second store all run PHP, and they are the ones nobody remembers to patch.
How to read the answers: if all four come back with specifics, you're in good shape. If any of them comes back as "we're looking into it" or "should be fine," treat the store as exposed until someone gives you a version number and a date.
A word on the free online scanners that appeared this week. A scanner can only see what your server chooses to reveal, and many servers hide their PHP version. A clean or "unknown" result is not the same as a confirmation from whoever runs your server.
What PHP2Shell actually is
PHP is the engine underneath your store. Magento, its extensions, your checkout, your admin panel: all of it is code that PHP runs. PHP2Shell is a pair of bugs in that engine, rated 9.2 out of 10 for severity.
In plain terms, an attacker can send one specially crafted request to your store, with no login, and end up running their own code on your server. Security firm Sansec reports that researchers confirmed unauthenticated remote code execution against Magento 2.4.9, the latest release, along with ten other PHP applications. The same research describes a second effect: the server can leak fragments of its own memory back to the attacker, and that memory can hold passwords, session tokens, and API keys from other shoppers' and admins' requests.
Details leaked on October 20, a day before the planned disclosure. Sansec cites Cloudflare seeing the first attacks on the morning of October 21, hours before the official patch went out. A working exploit tool is now public, and Sansec expects mass exploitation.
Why updating Magento won't fix it
Most store owners have a mental model that goes: security problem, so apply the latest Magento patch. It doesn't work here.
The flaw lives below Magento, in the server software, and the attack can trigger before a single line of Magento code runs. So installing a Magento security patch does nothing against PHP2Shell, and neither does updating extensions. Security tools that live inside Magento don't see it either: Sansec states plainly that its own in-store protection product does not stop this attack. Even Magento's maintenance mode doesn't help, because PHP processes the malicious request before Magento checks whether the store is in maintenance.
The fix is a PHP update on every server your store runs on. That is usually your hosting provider's job, sometimes your agency's, and in a surprising number of contracts nobody's in particular.
The trap for stores on older Magento releases
This is where a lot of perfectly "supported" stores are about to discover they aren't. Here's what Adobe's own system requirements say each Magento release runs on:
- Magento 2.4.4 and 2.4.5 run only on PHP 8.1. No official fix exists for that combination.
- Magento 2.4.6 runs on PHP 8.1 or 8.2. It is still inside Adobe's support window, so it feels safe, but if your host set it up on 8.1, you are in the same position as above.
- Magento 2.4.7 and newer run on PHP versions that received fixes on October 21.
There's a catch in the obvious escape route for 2.4.6 stores. Moving from PHP 8.1 to 8.2 gets you the official fix today, but PHP 8.2 itself stops receiving security fixes on December 31, 2026. That's a perfectly good emergency move, and a poor plan. Treat it as buying ten weeks to schedule the Magento upgrade you'd need anyway.
When we take over an inherited Magento store, the PHP version is one of the first things we check, because it is so often older than the owner assumes. Hosting setups tend to stay frozen at whatever was installed on launch day. On 2.4.4 or 2.4.5, the realistic path is a backported PHP build from your hosting vendor as a stopgap, plus a Magento upgrade. We covered why older Magento versions quietly become a liability in our piece on Magento end of life; PHP2Shell is that argument with a deadline attached.
If the check fails: the next 48 hours
Get the PHP update scheduled with a date. Everything else on this list buys time. This is the fix.
Apply the Magento patch too. Adobe released the BlockStrap fix on October 13 for releases up to and including 2.4.9, and rated it as patch-within-30-days, a rating Sansec publicly disputes while saying it expects exploitation. You need both fixes, in both layers.
Turn on what your edge already offers. If your store sits behind Cloudflare, the company has deployed WAF rules for PHP2Shell on every plan, including the free one. Paid plans should check the rules are set to block, not just log. Cloudflare is explicit that this is an extra layer and not a replacement for patching, and it has already watched attackers rework their payloads to slip past the rules.
Understand the cost of stopgaps. Temporary server settings can reduce exposure while you wait. Some break things you care about, like product image uploads in the admin and, in some setups, parts of cart and checkout. Others let a single request eat all of the server's memory. Use them only with someone who will place a test order afterwards and remove them once the real fix is in.
If you were exposed, assume someone looked. Rotate the secrets that matter: admin passwords, payment gateway credentials, and API keys for your ERP, shipping, and marketing tools. Then have someone check for unfamiliar admin users and unexpected files on the server. Patching closes the door; it doesn't remove anyone who already walked in. A compromised server is exactly how checkout skimmers end up on Magento stores.
Two layers, two patches, two owners
PHP2Shell and BlockStrap arriving in the same fortnight makes a point that's easy to miss in a quiet month. Your store has at least two layers that break independently, the Magento application and the server it runs on, and in most setups each has a different person responsible for it.
Patching Magento is a known routine for most agencies. Patching the server often falls between the hosting provider and the development team, and owners only find out who was supposed to do it after something breaks. We made a similar point in why a patched Magento store can still get breached. If question 3 above didn't get a clear name, that is the real finding of this check, and your Magento support and maintenance arrangement should name both layers explicitly from now on.
Where Encomage fits
If you're unsure whether your store is exposed, or your current setup leaves PHP updates in a grey zone between host and developer, this is the kind of work we pick up at Encomage. It usually starts with a short infrastructure check, covering PHP version, Magento patch level, and who owns each layer, before any change touches production.
