:quality(75))
Welcome back to The ACCS Edit. Last week, two critical flaws in PHP had website owners around the world rushing to update their sites. For merchants on Adobe Commerce as a Cloud Service (ACCS), it was a different story: Adobe had already put protection in place across the platform. As one of the first agencies to put a site live on ACCS, we saw this first-hand with David Nieper, whose new site we launched on the platform at the end of September.
In this Edit, we'll look at what happened with PHP2Shell, why we don't think it'll be the last time security makes the headlines, and how Adobe Commerce as a Cloud Service looks after your security, both when something like this happens and day to day.
PHP2Shell: a sign of things to come
PHP is the programming language behind most of the web, including many ecommerce platforms. Last week, two flaws rated 9.2 out of 10 for severity were found in it, and together they became known as PHP2Shell. They could let an attacker run their own code on a site without logging in, and attacks began within minutes of the fixes being released.
We don't think it'll be the last. AI has transformed the cybersecurity landscape, making it worryingly quick to find flaws in older code, a phenomenon that has been coined the 'Vulnpocalypse'. One of the PHP2Shell flaws had sat unnoticed for more than ten years, and with PHP running around 70% of websites, a single flaw can affect a huge number of online stores at once.
How ACCS handled PHP2Shell
Adobe were aware of PHP2Shell before it was officially disclosed, and made protecting ACCS merchants a priority.
Their fix was a change to how PHP is set up across Adobe's cloud platform, which includes every ACCS site. Adobe switched off the PHP setting linked to the flaws and rolled the change out carefully, one server at a time, with no downtime or interruption to service.
For David Nieper, the fix was applied to their site automatically, as part of the service and at no extra cost. There was no emergency update for us to plan, test and put live, and nothing for their team to sign off.
For us, this shows exactly how responsibility works on ACCS. The PHP running underneath Adobe Commerce is part of the service, so when a flaw turns up at that level, it's Adobe's to fix.
How ACCS looks after your security day to day
That's why what comes as standard on ACCS matters. Adobe runs ACCS as a managed service, so security is looked after at every level, from Adobe Commerce itself down to the software and hosting it runs on.
Security patches are applied by Adobe. Fixes roll out across the platform in the background, so there's no ticket to raise, no waiting for a developer and no separate release to schedule.
Adobe has a 24/7 security team and early access to disclosures. As PHP2Shell showed, Adobe can move before a flaw is even public and protect every site on the platform at once.
Everything sits behind web application firewalls from leading CDNs. They filter out malicious traffic before it reaches the store.
PCI compliance is covered. The platform meets the PCI standard for card payments, which takes care of the infrastructure side of compliance.
Other updates can be tested first. New features and non-urgent updates are flagged in advance, with 30 days to test them before they reach the live site.
Less is spent on upkeep. With security and updates included in the service, there's no separate patching project to budget for, so more of the budget can go on improving the site.
What we took from it
For us, PHP2Shell shows the real value of Adobe Commerce as a Cloud Service. Adobe understands how quickly the cybersecurity landscape is evolving, and ACCS has been built with the security to keep pace as new threats appear. Fixes are in place before merchants need to think about them, at no extra cost, and that's a clear example of how well ACCS works in practice.
We'll keep sharing what we learn here in The ACCS Edit as more of our builds go live on the platform.
:quality(75))
:quality(75))
:quality(75))