Serious Linux kernel vulnerability: is your PrestaShop store at risk?

If you've read about a serious Linux kernel vulnerability and you run a PrestaShop store, chances are it affects you: almost every store runs on Linux. This flaw doesn't let anyone walk into your store directly from the internet, but anyone who has already managed to run something on your server can take over the whole machine. What you need to do today depends on where your store lives: on shared hosting, you ask your provider; on your own server, you update and reboot.

The warning that put it back in the headlines came on 28 October, when the US cybersecurity agency, CISA, added the Fragnesia flaw to its list of vulnerabilities already being used in real attacks.

What has happened with the Linux kernel?

The kernel is the core of Linux: the part in charge of everything else running on the server. Several serious flaws have come out one after another this year, which is why you keep seeing headlines: Copy Fail, Dirty Frag, Fragnesia, GhostLock, Vghost. Since May, CISA has added eight kernel flaws to that list.

You don't need to learn the names. Those five share the one thing that really matters to you: they are local flaws.

Can someone get into my PrestaShop store through this flaw?

Not on its own. Microsoft explains it when talking about Copy Fail: the attacker needs to already have a foot on the machine. And Red Hat says the same about Fragnesia: it takes local access to the system.

Think of your server as an office building. These flaws don't open the street door. But anyone already inside, even in a broom cupboard, gets the keys to the entire building.

And how does someone end up in that cupboard? By fairly ordinary routes:

• A module with a security hole that lets someone run code on your server.
• Another website on your own account, like that old WordPress nobody updates.
• Another customer's website, if you're on shared hosting. CloudLinux, whose system many hosting providers use, warns that a malicious customer could reach other accounts on the same machine.
• A flaw in PHP, such as PHP2Shell.

That last one isn't theory. In its Fragnesia entry, CISA warns that this flaw can be chained with PHP2Shell to plant a back door and run commands with full control of the server. CISA hasn't given details of those attacks and what we've read doesn't mention online stores, so there's no reason to panic, but there is every reason to close both.

Why isn't updating the server enough?

Because a new kernel does nothing until the server starts up with it. Ubuntu, AlmaLinux and Canada's cyber security centre all say so: update and reboot. A server can have the fix installed for weeks and still be running on the old kernel.

The other way is live patching: tools like KernelCare, which apply the fix to the running kernel, without rebooting. On shared hosting every reboot takes all its customers offline, so "we haven't rebooted" isn't a bad sign if they tell you it's live patched.

What do I need to do, depending on where my store is?

If you're on shared hosting

You log in to a panel, like cPanel or Plesk, and you don't manage the server. The kernel is your provider's job; yours is to ask. Copy and send this:

A good answer comes with data: a version, a date, the name of the tool. If all they say is "we're up to date", ask again for the version. If they haven't cleared it up within a couple of days, it's a good time to think about moving.

If you have a VPS or a dedicated server

This one falls to you or whoever looks after it: install the security updates and reboot. Pick a quiet hour for sales, because the store goes down for a few minutes, and when it's back check that you can buy.

Then compare the version that's running with the one in your system's advisory: Ubuntu, Debian, AlmaLinux or Red Hat. Each system numbers things its own way: always look at yours.

If your store runs in a container

Docker and the like, and also some cheap VPSs that are really containers. They share the kernel of the machine hosting them, so updating from the inside changes nothing. The fix comes from whoever runs that machine: if that's your provider, send them the message above.

What to do today, in order

1. Find out which case you're in: shared, your own server or a container. If you don't know, ask your hosting provider.
2. Make a full backup, files and database, and keep it off the server.
3. Send the message to your hosting provider, or update and reboot if the server is yours.
4. Close the ways in: PHP with the PHP2Shell fix, modules up to date, and out with what you no longer use, whether modules or old websites on your account. Which PHP each version supports is in which PHP version PrestaShop needs.
5. Look for signs that someone is already in, like a strange window when you visit your store or files you don't recognise.

Updating closes the door, but it doesn't throw out anyone already inside. Microsoft warns that protective measures may not undo what an attacker has already done.

If something smells off, start with what a store hacked with ClickFix looks like, and don't delete anything until someone has checked it: those files tell you how they got in.

For your technical team

Running kernel: uname -r against the installed one (rpm -q kernel, dpkg -l 'linux-image*'). Fixes arrive by backport with no visible version change: what counts is the package revision, not the kernel.org number.

Revisions with the Fragnesia fix (CVE-2026-46300): Ubuntu 26.04 7.0.0-22.22, 24.04 6.8.0-124.124, 22.04 5.15.0-181.191; AlmaLinux 8 4.18.0-553.124.3.el8_10, 9 5.14.0-611.54.5.el9_7, 10 6.12.0-124.56.3.el10_1. Each CVE has its own: install the latest for your branch.

Not yet closed on every branch: Vghost (CVE-2026-74580). As of 4 November, Ubuntu lists it as fixed on 26.04 and 22.04 and in progress on 24.04. Red Hat places it mainly on virtualization hosts and it requires access to /dev/vhost-*: until it's fixed, don't expose that to containers or untrusted users.