Shopify security before BFCM: 3 incidents to check

If your Shopify store runs third-party apps, the one thing to do before Black Friday is audit your app embeds. The rest of this post explains why.

In the span of about a week, three separate security incidents hit the ecosystem: a checkout hijack spread through Shopify apps, a critical PHP vulnerability, and a certificate authority whose private keys could be guessed. Over the past few days I've walked several merchants through what happened and what to check. These are the same answers, written down.

The Shopify checkout hijack

Attackers put malicious code into the settings of several Shopify apps, and that code sent shoppers on real stores to fake checkout pages that captured their card details. Shopify's own checkout was not breached. The fake pages ran on outside domains.

Developer Roman Zipp caught it on October 10, when a keyboard store's Checkout button sent him to a lookalike page on an unfamiliar domain. The fake page took his details, then forwarded him to the real checkout, so the order would have gone through normally.

Here's how it worked, per Zipp's analysis:

1. A legitimate app script loaded on the storefront from Shopify's CDN.
2. That script fetched the store's app configuration from the vendor's servers.
3. The configuration had a custom JavaScript field, and someone had placed redirect code in it.
4. When a shopper clicked Checkout, the code sent them to the fake page. It set a flag so it only fired once per browser session.

That last detail matters. A store owner who tests checkout twice in the same browser will see a clean result the second time. And because the malicious code lived in data the app fetched at runtime, searching your theme files won't find it.

The apps named so far are Hulk Product Options, Selleasy and Swym Wishlist Plus. HulkApps and Selleasy have both confirmed incidents. The Swym connection comes from one developer's analysis, and Swym hasn't commented publicly. Qikify had a similar incident in July, and all three app listings were unavailable on the App Store as of October 16.

What isn't known yet: how the attackers got in. Selleasy says someone gained unauthorized access to an internal tool. HulkApps calls it an exploit. Neither has published a full root cause, and Shopify hasn't said how many stores were affected.

Where the risk is, and where it isn't

The exposure sits with apps that run code on your storefront through theme app extensions, the app blocks and app embeds you manage in the theme editor. Code loaded this way has global access to the page, so it can rewrite or intercept any button on it, including Checkout.

Three things lined up for this attack to work:

1. The app used a theme app extension, so its code ran on every storefront page.
2. The app let someone store arbitrary JavaScript in its settings, which it then loaded and ran.
3. The attacker got access to change those settings.

Remove any one of those and this attack doesn't happen.

Apps that work inside Shopify's newer extension surfaces are a different story. Checkout extensions, customer account extensions and post-purchase extensions run in a sandbox Shopify controls:

• They have no access to the page itself, so they can't take over another app's button or redirect checkout.
• Shopify's documentation says checkout extensions can't access sensitive payment information.

So when you're deciding which apps to audit first, start with anything in your theme editor.

How to audit your store

This takes under an hour for most stores, and you don't need a developer for the first four steps.

1. List your app embeds. In the theme editor, open the App embeds panel. Write down every embed that's switched on. Those are your audit list.
2. Check for custom code fields. For each app on that list, open its settings and look for anything labeled custom JavaScript, custom HTML or custom code. Make sure you recognize everything in those fields. If you don't, paste it into an AI model like Claude and ask whether it redirects anywhere, takes over buttons or sends data to an outside domain.
3. Remove apps you don't use. Every installed app is surface area. Some apps leave code behind after you uninstall them, so check your theme afterward.
4. Test checkout in a fresh private window. Add a product, click the plain Checkout button and watch the address bar. Checkout should stay on your store's domain. Close the window and repeat, because this attack only fired once per session. Test on a phone and from your cart drawer too.
5. Lock down access. Turn on two-step authentication for every staff account, review your collaborators, and change passwords on your app vendor accounts.

If you find a redirect, screenshot it with the address bar visible before you change anything. Then turn off the app, and contact the vendor, Shopify Support and your payment processor.

Questions to ask your app vendors

Shopify handles PCI compliance for its checkout, but your customers' trust is still yours, so the apps you install are your responsibility to vet. The merchants I've talked to this week are doing the right thing: meeting with each vendor that touches their site before BFCM. These are the questions worth asking:

• Do you load code on our storefront? If so, through which surface: a theme app extension, an app embed, or a sandboxed checkout or account extension?
• Can anyone add custom JavaScript or HTML through your app? Who can change it: us, your support team, or an internal tool?
• How do you protect internal tools that can change our settings? Ask about two-factor authentication, and whether they require hardware security keys.
• Do you run PHP anywhere, and are you patched? See the next section.
• Do you have published security practices? A SOC 2 report is strong evidence, but at minimum a vendor should be able to show written policies they actually follow.
• How would you tell us about an incident? Look for a status page you can subscribe to.

A vendor who can't answer these clearly is worth a closer look.

PHP2Shell: why it matters even on Shopify

On October 21, PHP shipped emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both let an attacker run code on a server without logging in. CISA told organizations to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 immediately.

This one was unusual. Details leaked on October 20, the day before the patch. Sansec reports that Cloudflare saw attacks that morning, hours before the fix shipped, and that every PHP version from 5.4 on is affected. Some site operators took their sites offline until they could patch.

Your Shopify store doesn't run PHP, so you might think this doesn't concern you. But WordPress runs on PHP, and so do plenty of marketing sites, blogs, landing pages and app backends. If any of your vendors run PHP, an attacker who gets onto their servers could reach whatever data they hold about your store and your customers. That's why it's on the vendor question list above.

If you run a WordPress site alongside your store, ask your host whether the October 21 release is applied.

The certificate keys anyone could guess

On October 17, an independent researcher reported that eight intermediate certificates from eMudhra, an India-based certificate authority, had private keys that anyone could work out. Mozilla confirmed it and recovered the keys on its own within hours.

The keys weren't stolen. They were generated badly. A private key for this kind of certificate should be a random number with more than a hundred digits. Each of these keys was a whole number under 256, and one of them was literally the number 4. Anyone could compute them from the public certificates in under a second. eMudhra attributes it to a flaw in a key-generation ceremony in April 2025 that produced a second, weak set of keys, which were then used by mistake.

Certificates are what put the padlock in your browser's address bar. Anyone holding these keys could create certificates that browsers would accept for any website, then sit invisibly between a shopper and a site, reading or changing what passes between them. This is called a man-in-the-middle attack.

The response was fast. Chrome blocked the six website certificates within two hours of the report, and Firefox blocked them the same evening. Chrome found no website certificates issued from them in public Certificate Transparency logs before its block, so none could have been trusted by default in Chrome. eMudhra revoked the certificates on October 18, and Apple and Microsoft blocked them within days. Mozilla and Chrome are also removing trust in eMudhra's entire ECC root, and Chrome expects that change to reach its stable release on October 27.

For most merchants, there's nothing to do here. Browsers handle it. If you or your vendors run servers, make sure their certificate trust stores are up to date.

What we did at Cleverific

Cleverific wasn't affected by any of the three incidents. We still ran through our security and engineering processes for each one:

• Checkout hijack. Our app has no theme app extension and no setting that runs custom code on your storefront. Our checkout, customer account and post-purchase extensions all run in Shopify's sandbox. We audited our systems and access controls anyway.
• PHP2Shell. Our systems run on Ruby, Node, Go and Rust, with no PHP. We checked with our vendors to confirm each one either doesn't use PHP or has mitigated the vulnerabilities.
• eMudhra certificates. We don't use certificates from eMudhra. We updated our base images and language runtimes so our systems no longer trust the affected certificates.

Access to our internal tools and data has required hardware security keys since we started, and we're SOC 2 Type 2 audited by a third party. Our status page has the full notice, and you can subscribe there for updates.

Sources

• Roman Zipp: Shopify shops hit with ongoing Checkout Hijack attack
• WitsCode: Shopify Phishing Attack: Fake Checkout Hijack and What to Check
• Shopify.dev: Checkout UI extensions
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Sansec: PHP2Shell
• Mozilla Bugzilla 2083449: eMudhra private key compromise of intermediate certificates
• The Hacker News: Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software