Adobe Commerce Zero-Day and PSK Agent RAT: What to Do

CyberSecurityNews reports that attackers are exploiting a zero-day in Adobe Commerce to deploy a remote access trojan called PSK Agent, which lets them control the affected server remotely. If you run Adobe Commerce in production, this is a patching and compromise-checking job for this week, not a backlog item. A zero-day means exploitation started before a fix existed, so being current on last quarter's patches does not settle the question.

Other outlets have covered the same activity. Cyber Press describes Magento stores targeted with PSK Agent malware that evades antivirus detection, and GBHackers News ties a Magento vulnerability it calls StyleSmuggler to the same RAT. Separately, remio reports a CISA Known Exploited Vulnerabilities update that adds Adobe Commerce and Google Brotli flaws. Read each of those as a pointer, then go to Adobe's own security bulletin for the facts you will act on.

Key takeaways

• CyberSecurityNews reports an Adobe Commerce zero-day is being used to deploy the PSK Agent RAT and take remote control of servers.
• Patching closes the entry point. It does not remove a trojan that is already installed, so plan a compromise check as well.
• Confirm affected and fixed versions, and any interim mitigations, only against Adobe's official security bulletin.
• Self-hosted stores and stores on older patch levels need attention first. Ask your host what they have already done.
• Your own team can run the first 24 hours. Bring in a partner for forensics, rebuilds and anything touching payment data.
• Settle ownership, deadlines and an evidence trail now, so the next advisory costs hours rather than days.

What the reports about the PSK Agent RAT say

The headline claim is simple. A previously unpatched flaw in Adobe Commerce is being used to put a remote access trojan on commerce servers. Once a RAT is running, the attacker is no longer limited to the shop front. They can act as an operator on the machine, with whatever access the web server account and the surrounding network allow.

Cyber Press adds that the malware is described as evading antivirus detection. That matters for how you check. A clean scan from your endpoint tooling is a weak signal here, and you should not treat it as proof that nothing happened.

The GBHackers News headline names a vulnerability, StyleSmuggler, and links it to the same malware. Nicknames help journalists and do not help you. Your patch decision should rest on the identifier and fixed releases in Adobe's bulletin, not on whether a name rings a bell.

The CISA item from remio is a different kind of signal. Inclusion in the Known Exploited Vulnerabilities catalog usually means the flaw is being used in the wild, and that organizations with compliance obligations may face deadlines. Check the catalog entry itself for what it covers and what it asks of you.

Who needs to act on this Adobe Commerce vulnerability

Every team running Adobe Commerce or Magento should confirm its status, but the urgency is not equal. The deciding factors are who controls the servers and how quickly patches reach them.

One common blind spot is the agency-built store whose original team has moved on. Nobody gets the advisory email, and the server keeps running. If that describes one of your stores, finding the owner is the first task.

Another is the staging or demo server. It often runs the same code with weaker controls and sometimes holds a copy of production data. Put it in scope.

What to do in the first 24 hours

Keep this sequence short and boring. Speed comes from not debating the order.

1. Name one incident owner. They make the calls and keep the log of what was done and when.
2. Read Adobe's official security bulletin and note the affected versions, the fixed versions and any interim mitigation.
3. Inventory every Commerce instance you run, including staging, regional stores and anything a former agency built.
4. Compare each instance's version with the bulletin. Do not rely on memory or on a spreadsheet that was last updated months ago.
5. Apply the fix or mitigation on the most exposed production instance first, then the rest.
6. Snapshot the server and its logs before you change much else. If you later need forensics, you will want the evidence intact.
7. Start the compromise check described in the next section.
8. Tell your security contact, your host and whoever owns payment compliance that you are working on it.

If the fix cannot go in today because of a release freeze, a custom module that conflicts, or a long test cycle, say so and record the mitigation you used instead. A documented temporary control is better than a silent gap.

How to check whether a store was already compromised

With a reported zero-day, you have to assume the window ran before the patch did. So the question is not only whether you are patched, but whether anyone got in first.

This is a review, not a hunt for exploit details, and you do not need to know how the attack works to do it. You are looking for things that should not exist.

• Files in the web root or the code directories that your deployment process did not put there, or that changed outside a release.
• Admin accounts, API integrations or tokens nobody can explain.
• Scheduled jobs or cron entries you did not create.
• Outbound network connections from the web server to destinations your store has no reason to contact.
• Unusual processes running under the web server account, or unexpected load at odd hours.
• Changes to payment or checkout pages, since commerce attackers often care most about those.

Because Cyber Press describes the malware as evading antivirus, lean on comparisons rather than signatures. If your code is deployed from version control, compare what is on the server with what the repository says should be there. Differences are your leads.

If you find anything, stop treating this as a patching task. It is now an incident. Isolate the server, preserve evidence, rotate credentials and keys that the server could read, and involve your security team and, where the situation calls for it, a forensic specialist. Where payment data may be involved, loop in your payment compliance contact early.

If you find nothing, say what you checked and when. 'No evidence found in these checks on this date' is an honest finding. 'Not compromised' is not.

A rollout plan with owners

The technical steps are the easy part. Most delays come from nobody being sure who decides. This table is a starting point you can paste into a ticket.

Test the fix on staging first if you can, but do not let testing become the reason production waits days. Run the checkout, the admin login, your payment methods, search and any custom module that touches the areas the patch affects. A short, scripted smoke test beats a long manual one nobody finishes.

What not to do

A few instincts will feel productive and cause trouble.

• Do not rely on a news article for the fixed version number. Articles are summaries, and they age. Use the vendor bulletin.
• Do not treat a clean antivirus scan as an all-clear. The reporting says this malware is built to avoid detection.
• Do not patch and then delete suspicious files without taking a copy first. You lose the evidence you may need.
• Do not restart or rebuild everything before you snapshot. Same reason.
• Do not test whether the flaw is exploitable on your own production store. Verify versions and apply the fix instead.
• Do not announce to customers that data was or was not exposed before the review is finished. Premature statements in either direction create problems later.
• Do not ignore staging, regional or legacy stores because they get less traffic.

Where an implementation partner helps, and where your team can manage

Your team can handle the first pass. Reading the bulletin, taking inventory, applying a published patch on a standard setup, and running a smoke test are all within reach of a capable in-house or hosting team.

A partner earns their fee in the harder cases:

• Heavily customized stores where a patch collides with custom modules and nobody on staff knows the code.
• Suspected compromise, where forensic discipline and a clean rebuild matter more than speed.
• Large version gaps that need a proper upgrade, not a quick patch.
• Ongoing patch management, if your current process depends on one person remembering to check.

If you do not have a partner, or you are unhappy with the one you have, the Adobe Commerce partners page is a place to start comparing, and find-partners lets you narrow by need. When you brief someone, use the Adobe Commerce RFP template and add security specifics: patch service levels, who monitors advisories, how incidents are escalated and who pays for out-of-hours work.

Ask any candidate how fast they applied the last critical patch for a client and what they did about stores they could not patch at once. A plain answer tells you more than a certification list.

How to measure whether you are better prepared next time

This episode is a free stress test of your process. Use it.

Track how long it took from the advisory reaching you to a verified fix on every instance. Track how many instances you discovered you had that nobody had listed. Track how long the compromise review took and whether you trusted its result.

Then look for the gaps. Common ones are no single owner for advisories, no automated version reporting, deployments that cannot be compared with source control, and no tested way to rebuild a server from clean code. Fixing any one of these shortens the next response more than any amount of urgency during it.

Set a standing target for critical patches, such as a number of days from advisory to verified fix, and have the incident owner report against it. The target should be one you can meet, because a number nobody hits stops being a target.

The position here is straightforward. Zero-days in commerce platforms will keep coming, and you cannot prevent them. What you control is how quickly you learn about one, how reliably you can patch, and how well you can tell afterward whether anyone got in. Browse the blog for more practical guidance on running Adobe Commerce, and treat this week as the moment to fix the process, not just the server.

Sources

• CyberSecurityNews — Report that hackers are exploiting an Adobe Commerce zero-day to deploy the PSK Agent RAT and remotely control servers.
• Cyber Press — Coverage of Magento stores targeted with PSK Agent malware described as evading antivirus detection.
• GBHackers News — Coverage linking a critical Magento vulnerability named StyleSmuggler to the PSK Agent RAT.
• remio — Report of a CISA Known Exploited Vulnerabilities update adding Adobe Commerce and Google Brotli flaws.