What actually happened?

A person calling himself "Kris" (with a background in SEO, crypto, and online gambling) bought a company called Essential Plugin on Flippa on August 8, 2025. The company had developed 31 plugins. After the purchase, he planted a so-called "backdoor" in all of them. But he didn't do anything noticeable for about 8 months before the backdoor was activated in April 2026.

What did the hack do?

It gave the attacker total control over the website and everything on the server — what's called full remote code execution (RCE).

What actually happened was that the hack made it possible to inject hidden SEO spam into the website, all without the site owner noticing a thing. The attack was optimized to only show the spam to Googlebot, not to the person who owns the site. So nobody saw the "ads" the attack was serving.

What did it mean for site owners?

What "Kris" gained from this was exploiting the authenticity of other people's websites for his own benefit. He got Googlebot to boost his own affiliate links and similar content, which pushed him higher up in Google's search results without having to do anything more than let the hack work for him. Had this gone on for longer, the hacked websites would have risked losing their own ranking as Google flagged them as spam — without the owners having any idea why. WordPress permanently took down all 31 plugins once it was discovered, but the injected code in wp-config.php is still there and has to be cleaned out manually by a developer.

What is a supply chain attack?

This is a textbook supply chain attack, which in this case exploits WordPress's reliance on third-party plugins from many different developers.

This means that the hacker does not attack you, the user, directly, but rather something you rely on for your website to function – in this case, a plugin. The hacker takes control of the plugin and embeds malicious code within it, which is then smuggled in via a completely normal update. And because the update comes from a trusted source, it doesn’t raise any suspicion.

Is WordPress insecure?

This does not mean that WordPress is bad or that all WordPress sites get hacked. The core of WordPress itself is secure and receives regular security updates. With a knowledgeable developer, few plugins installed and good maintenance routines, it is perfectly possible to keep it secure. WordPress is simply more exposed to risks because it is such an extremely popular CMS; 43% of all websites are built using WordPress. So people often assume that WordPress is insecure when they hear it has been hacked. But in reality, it is the plugin market that is less secure.

How Statamic reduces the risk

I'd say no one can fully avoid being hit by a supply chain attack, but with Statamic you avoid that risk almost entirely:

• No need for multiple plugins. Most of the features you need are already built into Statamic.
• Statamic is developed by a single team that's very active.
• Flat-file architecture (no database) — that alone eliminates common attacks like SQL injection.
• Built on the modern and secure PHP framework Laravel.
• Much smaller attack surface and significantly lower risk of mass infections.

One marketplace, one package manager

Another important aspect is that customers can buy plugins from any number of different websites — like CodeCanyon, WordPress.org, and PluginsForWordPress — which makes the WordPress market extremely fragmented.

When you buy or download a WordPress plugin, you receive a .zip file. There is no version history or insight into what has changed over time. If, as a developer, I want to review the code, I must either unzip it and go through it manually or use AI to scan for vulnerabilities.

Unlike Statamic, which uses a platform where you purchase add-ons. When I install them – which, as the developer, only I can do – I do so via Composer, which is PHP’s own package manager. And as a bonus, I can also view the history of these plugins via the version history in Git. I can see exactly what has changed, when, and by whom.

That’s one of the reasons why I build with Statamic. WordPress still has its place for certain types of projects, but I want to be able to guarantee the security of what I deliver.

Want to read more about the hack?

Austin Ginder was the person who alerted WordPress.org that something was wrong. He has written a very detailed article about this incident, including which plugins were affected.

What does the gh auth switch actually do?

gh auth switch changes which GitHub user is active in the GitHub CLI tool. This affects:

• Which account gh commands use (e.g. gh pr create, gh issue list, gh repo clone)
• Which authentication method Git uses when you run git push or git pull over HTTPS – if you have run gh auth setup once

This does not affect:

• The Git configuration for my commits, i.e. user.name and user.email in this case.

There is a very simple solution to this, which is to specify which GitHub user should be associated with which project – in my case, which folder. I have two separate folders that divide my projects into personal and work projects. Here’s how to do it:

1# Go to your private project
2git config --local user.name "Lars Jönsson"
3git config --local user.email "crymeat@gmail.com"
4
5# and the same applies to your work project
6git config --local user.name "Lars Jönsson"
7git config --local user.email "info@noveris.se"

It wasn’t that difficult.

But there’s another solution I’ve decided to go with. Mainly because I like tinkering with Bash and the CLI in general. I’ve created a Bash script that changes everything at once.

 1#!/bin/bash
 2
 3case "$1" in
 4  "personal")
 5    git config --global user.name "Lars Jönsson"
 6    git config --global user.email "crymeat@gmail.com"
 7    echo "Switching to devpaps git account..."
 8
 9    # Make devpaps active GitHub CLI account
10    gh auth status | grep "devpaps" > /dev/null
11    if [ $? -eq 0 ]; then
12      gh auth switch -h github.com -u devpaps
13    else
14      echo "devpaps not logged in via gh. Logging in..."
15      gh auth login --hostname github.com
16    fi
17    ;;
18  "work")
19    git config --global user.name "Lars Jönsson"
20    git config --global user.email "info@noveris.se"
21    echo "Switching to Noveris git account..."
22
23    # Make noveris-hq active GitHub CLI account
24    gh auth status | grep "noveris-hq" > /dev/null
25    if [ $? -eq 0 ]; then
26      gh auth switch -h github.com -u noveris-hq
27    else
28      echo "noveris-hq not logged in via gh. Logging in..."
29      gh auth login --hostname github.com
30    fi
31    ;;
32  *)
33    echo "Usage: $0 {personal|work}"
34    exit 1
35    ;;
36esac
37
38# Show current Git user configuration
39echo -e "\nCurrent Git configuration:"
40echo "Name:  $(git config --global user.name)"
41echo "Email: $(git config --global user.email)"
42
43echo "Reloading shell to apply GitHub credentials..."
44exec $SHELL

What the script does is first set my name and email as my Git username, then it checks whether noveris-hq is authenticated with gh-cli; if so, my username in gh-cli is also changed to noveris-hq; if not, I have to log in via gh-cli.

To use this Bash script, all I need to do is type:

1noveris on  main +95 -93 [$!?] via  v22.20.0 via 🐘 v8.5.4 ❯ switchgh work
2Switching to Noveris git account...
3✓ Switched active account for github.com to noveris-hq
4
5Current Git configuration:
6Name:  Lars Jönsson
7Email: info@noveris.se
8Reloading shell to apply GitHub credentials...

Everything is handled automatically for me. I think this is really good. Plus, you feel a bit like a hacker when you get to type commands into the terminal, which is a bonus.

It might be a bit of overkill with my Bash script, but what does it matter in a hundred years time?

No database means fewer worries

The first thing that comes to mind is that with Statamic, you don't need a database. Everything is stored in files instead. That means fewer things that can go wrong, no database connections to worry about, and most importantly, no one can perform SQL injections. For my clients, that means easier hosting and better security.

Fewer plugins from the start

With WordPress, you get a lot for free, but you often need to install plugins just to get basic features working the way you want. It's worth noting that the range of plugins available for WordPress far exceeds that of Statamic. There are over 61,000 plugins for WordPress, whilst Statamic has around 430. Statamic comes with more built-in features, such as form management, search functionality, caching and image editing, to name just a few.

I build all websites with exactly the fields and features you need. No unnecessary settings to get confused by, and no steep learning curve here either.

Faster websites

Statamic websites are simply fast. The file-based architecture, together with built-in caching, means that pages load quickly. I don't need to install and configure cache plugins (WP Super Cache) as with WordPress, it comes baked in with Statamic.

Developer experience

As a developer, I am obviously biased here, but the fact is that Statamic is based on Laravel – one of the most respected PHP frameworks. This means that I can use everything I already know about Laravel to build customized solutions, such as adding an admin panel to manage a member database, for example. No plugins that need to be installed and that I have to figure out how they work, plus the code is written exactly as I write it in Statamic. It's simply less friction for me to work with as a developer.

Version control with Git is included, all content is stored as text files, so I can track changes and easily restore if something goes wrong.

Want to know more? We can book a short meeting, and I'll tell you more about how Statamic and Laravel can suit your business.

This is something I really appreciate about Linux, the vast majority of package updates require no reboot at all. You can keep working, shut down when it's convenient, and forget the update even happened. However, that doesn't mean reboots are completely passé - sometimes components close to the kernel are changed (e.g. a new kernel or an upgraded systemd library) and a reboot might be wise to keep everything running as stable as possible.

How do you know when a reboot is needed?

If you are running Fedora as distro, this is what you type in your terminal after running an update, sudo dnf update:

1sudo dnf needs-restarting -r

-r flag stands for reboothint. The program checks which processes are still running old versions of libraries or kernel modules and tells you whether a reboot is recommended. If you don't get any output, it means the system is happy - you can continue working. If instead you get a line like:

1Core libraries or services have been updated since boot. Reboot is required for the update to take effect.

...well, then it's at least worth considering restarting the computer, when you have the time and inclination. Rebooting with Linux is usually super fast.