PSK Agent Malware Targets Magento Stores: What to Do

Cyber Press reports that attackers are going after Magento stores with a malware family it calls PSK Agent, and that the malware evades antivirus detection. If you run Adobe Commerce, the practical meaning is simple: a clean antivirus scan on your servers no longer tells you the store is clean, so your checks need to look at code, access and behaviour as well.

The headline does not tell you whether your store is exposed, and this post does not pretend to. It tells you where to look and how to organise the work.

Key takeaways

• Cyber Press reports PSK Agent malware aimed at Magento stores that evades antivirus detection, so scanning alone is not proof of a clean store.
• Start with the basics: patch level, admin accounts, third-party extensions and the scripts on your checkout pages.
• File integrity monitoring and outbound request review catch what signature-based scanning can miss.
• Confirm fixed versions only in Adobe's official security bulletins.
• Write the incident plan before you need it, including who can take checkout offline.
• Handle routine hygiene in house; use a partner for forensics, big version gaps and heavily customised builds.

What did Cyber Press report about PSK Agent malware?

The report, as titled by Cyber Press, says hackers are targeting Magento stores with PSK Agent malware that evades antivirus detection. That is the part worth anchoring on. The two claims that matter to an operator are that Magento storefronts are the target and that standard antivirus tooling may not flag the malware.

Beyond that, treat the details as something to read in the original article and in Adobe's own security guidance. A news summary is not a technical advisory. It will not tell you your exact exposure, and you should not build your remediation plan from a headline.

It also helps to see this as one item in a steady stream. Security Affairs has covered a separate Magento campaign it describes as infecting 953 online stores across five domains, and remio has covered a CISA Known Exploited Vulnerabilities update that includes an Adobe Commerce flaw. Different stories, same message: Magento and Adobe Commerce stores are a regular target, and attackers keep an eye on them.

Why does 'evades antivirus' change how you check a store?

Many teams treat a server-side malware scan as the finish line. The scan comes back clean, the ticket closes, everyone moves on. If malware is built to avoid detection, that habit gives false comfort.

Think of it this way. Antivirus mostly asks, does this file look like something we already know is bad? Malware that evades it is, by definition, something the scanner does not recognise. So you need checks that ask different questions:

• Does the code on the server match what we deployed? That is file integrity monitoring.
• Who has admin access, and did anyone log in who should not have?
• What scripts load on the checkout page, and did that list change?
• What is the server talking to on the network, and is any of it unexpected?

None of those depend on a signature. They depend on knowing what normal looks like for your store, which is the real work. A team with a deployment pipeline, version control and a known list of extensions has a big advantage here, because any difference from the known state stands out.

Who should act first?

Not every Adobe Commerce team has the same exposure. Order your attention by risk rather than by who shouts loudest.

If your store sits in the first three rows, act this week. If you are in the last two, a short review is still worth the afternoon.

What should an Adobe Commerce team do this week?

Here is a sequence that fits in a normal working week and does not need a project budget.

1. Confirm your version and patch level. Open Adobe's official security bulletins for your release line and compare. Do not take fixed version numbers from news coverage or from this post.
2. Audit admin users. Remove accounts for people who have left, agencies you no longer use and test users. Make sure two-factor is on for every remaining account.
3. Inventory extensions. Write down each one, who owns it, and when it was last updated by its vendor. Anything abandoned is a candidate for removal or replacement.
4. Compare deployed code to your repository. If you deploy from version control, a diff between production and the repository is one of the most useful checks you can run. Unexpected differences deserve an explanation.
5. Review checkout page scripts. Open the checkout in a browser, list every script that loads, and check each one is something you put there on purpose.
6. Check logs for odd admin activity. Look for logins at strange hours, from unfamiliar locations, or new users you did not create.
7. Rotate secrets if anything looks off. Admin passwords, API keys and integration tokens are the usual list.

None of this requires knowing anything about PSK Agent specifically. That is the point. Good hygiene covers a family of threats, and you do not need to wait for a named malware report to do it.

How do you test and verify the store after changes?

Patching without verifying is how teams end up believing they are safe. Treat verification as its own step with its own owner.

Apply patches and upgrades in a staging environment that mirrors production, then run through the checks that matter to revenue: add to cart, guest and logged-in checkout, payment authorisation, order confirmation emails, and admin order management. A security fix that quietly breaks a payment method is a bad trade, and it happens more often when the store carries custom code.

A simple rollout checklist helps keep owners clear:

Keep a rollback path ready. If the production smoke test fails, you want to be able to step back quickly rather than debug on a live checkout.

What if you find something suspicious?

This is the part nobody wants to plan, and the part where a written plan pays off most.

First, preserve evidence. Before anyone cleans files or restores from backup, take copies of the affected code, logs and database state. Cleaning too fast destroys the trail you need to understand how the attacker got in, and if you just remove the visible piece, they may come back through the same route.

Second, contain. Decide ahead of time who can take checkout offline, switch to a maintenance page, or disable a payment method. If there is credible evidence that checkout pages were tampered with, speed matters more than comfort.

Third, tell the right people. Your payment provider or acquirer will have its own requirements, and depending on where your customers are, there may be legal duties around notification. Involve your legal or compliance contact early. Do not wait until the technical picture is perfect.

Fourth, fix the cause, not only the symptom. That usually means patching, removing the entry route, rotating every credential that could have been exposed, and rebuilding from a known good state instead of hand-editing infected files.

A forensic investigation is a specialist job. If you suspect an active compromise, this is the moment to bring in outside help rather than learn on the job.

How do you measure whether you are safer?

Security metrics can turn into theatre, so keep them few and tied to things you can actually count.

• Patch lag. The time between Adobe publishing a fix for your release line and that fix reaching production. Track it per release and watch the trend.
• Admin account hygiene. The share of admin accounts that are named, active and protected by two-factor. The target is all of them.
• Unexplained file changes. The number of production file differences you could not trace to a deployment. The target is zero, and any non-zero number needs an owner.
• Checkout script count. The number of third-party scripts on checkout, against an approved list.
• Time to contain. In a drill, how long it takes from someone raising a concern to checkout being safely paused.

You do not need exact industry benchmarks for these. What you want is your own baseline and a direction of travel. If patch lag is shrinking and unexplained changes are at zero, you are in better shape than you were last quarter.

Where does an implementation partner help, and what should you avoid?

A lot of this a competent in-house team can do alone. Patching a current release, cleaning up admin users, pruning extensions and setting up a file diff are routine. If you have developers who already deploy to the store, keep this work with them.

A partner earns their fee in a few specific situations:

• Suspected active compromise. Forensics, containment and clean rebuilds are specialist work.
• Large version gaps. If you are many releases behind with custom code on top, an upgrade is a project, not a patch. A partner who has done it before saves real time.
• Heavy customisation. The more bespoke the build, the harder it is to know what is safe to change.
• No internal Commerce engineering. If the store is run by marketing with an agency on call, you need someone accountable for security, in writing.

If you are looking for that help, the Adobe Commerce partners page and the Adobe Commerce top partners list are a sensible starting point, and the Adobe Commerce RFP template will help you write down scope, response times and who is accountable when something goes wrong. Ask candidates how they handle incident response, patch cadence and access to your production environment, and ask for specifics rather than reassurance.

And a few things not to do:

• Do not rely on one antivirus scan as evidence you are clean.
• Do not wipe and restore before saving evidence. You lose the story of how it happened.
• Do not copy fixed version numbers from articles. Check Adobe's bulletins.
• Do not leave old agency and contractor accounts active because removing them feels awkward.
• Do not patch production first. Staging, then a quiet window, then production.
• Do not wait for a perfect report on PSK Agent before doing hygiene work that helps regardless.

One last point on position. Headlines like this one are a decent trigger for a quarterly review, and a poor basis for panic. The stores that come out of these stories well are the ones that already know their version, their extensions, their admins and their checkout scripts. If you cannot answer those four questions today, that is the finding, whatever the malware is called.

Sources

• Cyber Press — Original report of PSK Agent malware targeting Magento stores and evading antivirus detection.
• Security Affairs — Related coverage of a separate Magento campaign reported as infecting 953 online stores across five domains.
• remio — Related coverage of a CISA Known Exploited Vulnerabilities update that includes an Adobe Commerce flaw.