10 Things I Learned at Meet Magento Germany (incl. PHP Vulnerability Disclosure)

Last week I was at Meet Magento Germany. I came home with a full notebook, a tired body and one very unusual memory: a security disclosure for PHP itself landed the evening before the conference, while most of us were at the pre-party.

Here are ten things I learned that week. Some are about people, some are about patching, and one is a promise.

1. Meeting the people you only read on LinkedIn or GitHub is awesome

For years I've known a lot of this community as avatars: a commit on GitHub, a post on LinkedIn, a name in an issue thread. Shaking their hands is something else. You stop reading what people do and start hearing why they do it.

Credits to the organizer of Meet Magento DE. Although the event is located in Mainz, Germany, everybody is talking in English. Everyone can just have open conversations - joining each other conversations. Stating the rules about pacman (if I recall it correctly) I think it's genius. It made everybody understand to be open and openup, ensuring that everybody is welcomed. Alot of respect to everyone, this is by far the most enjoyable event I have ever been for a long time.

As for me, it's also something I have never imagine, to be able to speak in such an event.

2. Disaster struck the day before, and everybody still had a great time

Nobody look panicked, pre-party was lit. People knew what to check, who to call and what to roll out, and the next morning the conference went on as planned, with enthusiasm and very good conversations. That's what a mature community looks like: not one that never gets hit, but one that knows how to respond when it does.

3. PHP showed us how vulnerable we all are

Two critical vulnerabilities in the PHP interpreter itself, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. They allow remote code execution without logging in, they affect every PHP version from 5.4 to 8.5, and details leaked before the planned disclosure date. The fixes (8.5.12, 8.4.27, 8.3.36 and 8.2.35) arrived in a hurry on 21 October. PHP runs a huge part of the web, so a hole in the language is a hole in everything built on top of it: every framework, every CMS, every shop.

The press already has a name for this month: Black October. PHP wasn't alone. In a few weeks we got:

• PHP2Shell: two unauthenticated remote code execution bugs in PHP itself (21 October).
• Node2Shell: remote code execution through Brotli decompression in Node.js, CVE-2026-111497 (21 October). Bun had the same problem.
• Magento and Mage-OS: Adobe's APSB26-153, an unauthenticated remote code execution scored CVSS 10 (13 October).
• Next.js: version 16.4.1 fixed remote code execution through image handling and React Server Components (14 October).
• LiteLLM: a supply-chain attack shipped a backdoored release to PyPI and Docker (21 October).
• eMudhra: intermediate certificate authority keys were compromised.

I think we'll see this more often in the coming years, not less. The PHP flaws were found with the help of AI. Most of this code was written by humans alone, long before anyone reviewed code together with AI. Now researchers and attackers both have tools that read code at scale, and the old bugs in that human-only code are going to surface faster than they ever did.

4. Customers would rather go offline than take the risk

I've never seen this before. When the news broke, merchants asked for their shops to go into maintenance mode until a fix was in place. They'd rather lose a day of sales than stay up and gamble.

Not long ago the answer was always: keep it up at any cost, downtime is the enemy. Now the enemy is a breach, the GDPR notification that follows it, and the customer trust that leaves with it. Merchants do that maths themselves today, and they do it fast.

Part of it was FOMO, turned around. When everyone around you goes offline, staying online starts to feel like the risky choice. Customers watched government sites, broadcasters and hospitals go dark one after another, and they were afraid too. Nobody wanted to be the one shop still open when the attackers came looking.

And for the first time, customers were writing PHP configuration suggestions to me. They knew exactly which PHP version their own VM was running and whether it was patched yet. Security stopped being something they leave to us and became something they follow themselves. They checked this themself and know we have vPatch (similar like what Cloudflare) used to help mitigate the situation. Yet again don't rely 100% on vPatch and WAF when the real fix is around, just fix it.

5. Moving every shop to Mage-OS 3.6.0 and PHP 8.4 was just in time

A few weeks ago I decided to move every shop we run to Mage-OS 3.6.0 on PHP 8.4. Mage-OS 3.6.0 already carried the fix for October's critical Magento template-engine bug, so production was done by 20 October. One day later, PHP 8.4.27 came out (I wrote about why we moved everyone to Mage-OS earlier).

Because every shop was on the same platform and the same PHP line, the patch was one job, not thirteen. The official Docker images weren't published yet, so we built them ourselves from the official recipe, checked the php.net source against its checksum and signature, and rolled the new version out to every shop on 21 October. One image, one rollout, one test plan. Being on the same version everywhere is boring right up until the night it saves you.

6. The sites that went down told us they run PHP

Some of the sites taken offline that day gave away what they run underneath, just by going down. In the Netherlands that included DigiD, MijnOverheid and the website of the Tweede Kamer, the Dutch parliament. So now we all know: governments spend millions on PHP sites too.

Even the website of the Dutch NCSC, the national agency that is supposed to inform everyone about vulnerabilities like this one, went offline, with a notice saying it had been taken down as a precaution because of the PHP vulnerabilities.

And php.net, the home of the language itself, answered with a gateway timeout while the whole world was trying to read the advisory and download the fix.

That's not a criticism of PHP, or of the NCSC. Offline as a precaution is not the same as hacked; it's exactly the choice from point 4. It's a reminder that boring technology carries the world, and that its patches deserve the same urgency as a zero-day in your own code.

7. Listening to everyone led me to something worth disclosing

Talking and listening to so many people opened up new ideas. One conversation sent me digging somewhere I hadn't looked before, and I found something interesting, which I have disclosed to the Mage-OS and Sansec.

I can't tell much yet. It has to do with a module leak that could be used as a way in. I'll write about it in a separate post later this week, so stay tuned.

8. Small companies defend on cost, big companies on people and process

For smaller companies, security is a budget question. That's why so many still run WordPress on a shared cPanel box with Apache, or a shop that hasn't seen an update in two years. Not because they don't care, but because every update costs money they don't have.

If you run a small business in the Netherlands, there is help with that budget. The NCSC's Mijn Cyberweerbare Zaak subsidy pays 50% of the cost of measures such as a password manager, two-factor authentication, patch management, tested backups or awareness training, up to €1,250 per business. It is open to freelancers and companies with up to 50 employees and €10 million turnover, until 30 November 2026, first come, first served.

For bigger companies the money is there. Their weak spots are people and process - policies. Every employee's laptop, phone, mailbox and access rights is a door that needs securing, and one leaked credential is enough: a key committed to a repository, a password reused by a contractor, a phishing mail opened on a phone. Attackers don't need a zero-day when they already have a login.

And when the fix is ready, it still has to go through a lengthy deployment and approval process: a ticket, three sign-offs, next Tuesday's change window. The attacker doesn't wait for the change board.

That's what MDR, XDR and EDR are for: managed, extended and endpoint detection and response. Software on every laptop, phone and server that watches what happens and raises the alarm, often with a team behind it watching around the clock. It's why you see CrowdStrike on the Mercedes and SentinelOne on the Aston Martin every race weekend in Formula 1. Protecting people and process is big business, and it sells to big companies.

And it goes deep. Amazon caught a North Korean operative working as a remote systems administrator because his keystrokes took more than 110 milliseconds to reach Seattle, where a worker in the US would show well under 100. The laptop was in Arizona; the person typing was not. Amazon says it has stopped more than 1,800 such attempts since April 2024.

Impressive, and a little uncomfortable. To measure how long every keystroke takes, you have to watch every keystroke. Somewhere between protecting the company and watching the employee there is a line on privacy, and in Europe, under GDPR, that line is not optional. The bigger the company, the harder it gets to defend against its own accounts without treating every employee as a suspect.

9. The badges didn't keep anyone online, and attackers come in from the side

NIS2, SOC 2, GDPR, ISO 27001. The certifications are expensive, and they matter: they prove you have a process. But they don't patch your PHP. Organisations with every shiny badge on their website still went offline that week.

And look at where the most expensive attacks of the last two years actually came in. Rarely through the core system the certificate describes. Almost always through something around it: a supplier, a helpdesk, an employee.

• bol.com (August 2026): attackers got into two order-processing systems at its logistics partner CEVA Logistics, not at bol itself. Names, addresses, phone numbers and order details of bol and De Bijenkorf customers ended up for sale on the dark web.
• Intermarché (October 2026): the refrigeration in around 150 French stores was hacked through Danfoss cooling controllers, many of them legacy units that no longer get security updates. Fridges and freezers were pushed into nonstop defrost, and the stores had to throw away their fresh and frozen food. The system was run by the supplier, not by the retailer.
• Marks & Spencer (April 2025): attackers impersonated an employee and talked the outsourced IT helpdesk into resetting credentials. The ransomware that followed shut down online orders for weeks.
• Odido (February 2026): attackers posed as the IT department and got employees to approve a login to the customer system. Records of up to six million customers were exposed.
• Qantas, Allianz Life and others (2025): employees were tricked into handing over access to cloud CRM systems connected to Salesforce. Qantas alone lost nearly six million customer records.

None of these was a missing patch in the main application. The certificate covered the castle; the attackers came in through the delivery entrance, the cold storage and the phone at the helpdesk.

Not even a government with every obligation in the book is spared. In August 2026 the ransomware group Rhysida spent a week inside the networks of two Berlin Senate departments, urban development and mobility, before anyone shut them down. Berlin refused the ransom of 30 bitcoin, roughly two million euros, and in September 1.4 million files appeared on the dark web.

Look at what was in them: payroll lists, bank details and scans of employees' ID documents. That is how one breach feeds the next. As the Chaos Computer Club put it, the more you know about a person, the better you can impersonate them. Today's leak is tomorrow's convincing call to the helpdesk.

Compliance tells you what to do. It can't make a new vulnerability wait for your next audit, and it can't stop a tired employee from approving one login too many. What counts is how well you know every system, supplier and person that can reach your data, and how fast you can act when one of them fails.

10. I'll be sharing more of the why

Most importantly: the conference reminded me that people don't just want to know what we built, they want to know why. So I'll be writing more about the engineering and architecture decisions behind StoreFrame. Why every shop runs the same stack, why we build our own images, why we moved to Mage-OS, and what we got wrong along the way.

Thank you to everyone at Meet Magento Germany for the conversations, and to the organisers for keeping it a great event on a very long night.

There is so much more from the event worth writing about and publishing. Right now it's just a matter of finding the time and energy to turn it all into good articles. Stay tuned.