Code Creation LabsCode Creation Labs
BlogShopify app security in October 2026: where things stand, and what we do so your store is not the one that has to ask

Shopify app security in October 2026: where things stand, and what we do so your store is not the one that has to ask

October 23, 2026

October 2026 has been the busiest month for Shopify app security that we can remember. Three things happened at once: a wave of app hijacks that sent shoppers to fake checkouts, a critical vulnerability in PHP, and a call to action from Shopify to every app developer. We published a statement on each incident as it happened. This is the overview: what happened, what Shopify now expects from apps like ours, where every Workflow app stands against that list, and what we do so you do not have to ask.

What happened this month

The checkout hijack campaign (10 to 20 October). Starting on 10 October, an unauthorized party changed the configuration of several well-known apps so that the storefront code those apps render sent some shoppers to a fake checkout page that collected card details. Hulk Product Options, Selleasy and Swym Wishlist Plus confirmed incidents between 10 and 18 October. In the days after, further apps were removed from the App Store, among them Boost AI Search & Filter, Privy, Consentmo and 17TRACK; not all of their vendors have said why. Shopify's own platform and checkout were not breached, and the vendors involved have removed the scripts. Our statement from 23 October, with the reasons none of our apps can be used this way: Shopify checkout hijack: our apps are not affected.

PHP2Shell (21 October). PHP shipped fixes for two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Exploitation attempts were seen in the wild before and after the disclosure, and a public exploit exists. The researchers who found it reported on 22 October that mass exploitation is less likely than feared on the first day, but every PHP server still needs the patch. Our statement: PHP2Shell: our apps are not affected. None of our apps contain PHP.

Node.js (21 October). The same day, Node.js published a security release for all supported lines, among them CVE-2026-111497 in the Brotli decompressor. Our apps run on Node.js 22, so this one concerned us. Every app was rebuilt on the patched release, 22.23.4, and has been running it in production since that week. Nothing was required on the merchant side.

Shopify's call to action (20 October). In Securing your app, together, Shopify asked every app developer to act within the week: run the new security check in Shopify's AI Toolkit, move to expiring access tokens, run vulnerability scanners against every endpoint, treat all rendered data as untrusted, review API traffic in the Dev Dashboard, turn on two-step authentication for every account that touches the app, remove access nobody needs any more, and keep the emergency contact current. Shopify also announced that expiring access tokens become mandatory for every public app on 1 January 2027, that IP restrictions for API keys are coming, and that the security requirements of the App Store and the boundaries for storefront app code will be tightened.

Shopify's app security checks (15 October). The security check itself is documented at App security checks. It is a command in the Shopify CLI that inspects an app's source code for 37 named issues, each with a stable ID and its own documentation page: 25 rated high (among them routes without authentication, database queries not scoped to a store, app proxy requests without signature verification, committed secrets, credentials reaching logs or the browser, cross-site scripting, server-side request forgery and SQL injection), 10 rated medium (missing CSRF protection, disabled expiring access tokens, missing privacy webhooks, open redirects, reachable vulnerable dependencies) and 2 rated low. Part of it is a deterministic scan, part is a review handed to a coding agent, and Shopify recommends rerunning it on every release.

Where the Workflow apps stand

This covers Workflow Trigger Extensions, Workflow Webhooks, Workflow Transactional Email, Workflow Functions, Workflow Suite, Workflow Forms and Workflow Documents, point by point against Shopify's list.

  • Not involved in the hijack campaign, and not usable for it. Four of the apps run nothing in your storefront at all. Two add a web pixel inside Shopify's sandbox, which cannot read or change the page. Workflow Forms renders your form through a fixed script we ship, and every text in it passes an allow-list that admits no script, style or event handler. The details per app are in the statement.
  • No PHP, and no other runtime we do not use. Every app is TypeScript on Node.js with PostgreSQL and Redis, on Google Cloud in the European Union (Belgium). When an advisory concerns PHP, WordPress, Java or .NET, it cannot affect our apps.
  • Expiring access tokens: already in place in all seven apps. Shopify will require them from every public app on 1 January 2027. Our apps already work with short-lived access tokens and a refresh token, so a token that leaked would stop working by itself. The tokens are additionally encrypted per record under keys in Google Cloud KMS and are never written to logs.
  • Rendered data is treated as untrusted. Texts you enter in Workflow Forms are rendered through an allow-list, HTML in Workflow Transactional Email is sanitised before it reaches a recipient, and the code you write yourself in Workflow Functions, custom triggers and Workflow Suite runs in an isolated sandbox on separate infrastructure that never sees our credentials or your Shopify access token.
  • Every endpoint is verified. Pages inside the Shopify admin are authenticated with Shopify session tokens, webhooks and Flow callbacks by Shopify's HMAC signature, storefront requests through Shopify's signed app proxy. Every record belongs to one store, and every query is scoped to the store that was authenticated. On 18 October we reviewed every route and data path of every app once more and fixed what we found the same day.
  • Accounts and access. Production is reached by named people through individual Google Cloud IAM accounts. There is no support console, internal tool or script runner with a public address, so our configuration cannot be changed from the internet, which is exactly how the hijacked apps were changed. Credentials live in Google Secret Manager, not in code, images or the build pipeline.

How we keep it that way

  • Shopify's own security checks, on every app. We ran Shopify's app security checks, the deterministic scan and the agent review, against all seven apps. The checks cover the issues behind this month's incidents and the ones Shopify's call to action names: unauthenticated routes, data not scoped to a store, unverified webhooks and app proxy requests, committed secrets, leaked credentials, unsafe HTML and disabled expiring tokens. No open issues, and the check runs again with every release as Shopify recommends.
  • Patches twice a day. Every app is rebuilt and redeployed twice a day, so operating system, Node.js and library patches reach production within hours instead of with the next feature release. When Node.js published a security release on 21 October, our images were rebuilt on the patched release that week.
  • Every change is scanned before it can ship. Each app's pipeline runs static application security testing, secret detection, dependency vulnerability scanning and container image scanning on every commit. Our release bar is zero known vulnerabilities in dependencies and in the image.
  • Automated penetration tests. Scheduled scans with OWASP ZAP, Nuclei and schema-based fuzzing run against every app's endpoints. A high or critical finding fails the pipeline and alerts us.
  • A security regression suite before sensitive releases. Authentication matrix, cross-store access, request forgery, webhook signatures and outbound request guards are tested as code and must report zero vulnerable before any release that touches authentication, sessions or data access.
  • Keys, backups, nodes. Encryption keys rotate automatically every 90 days. Databases are encrypted with customer-managed keys and backed up daily with point-in-time recovery, inside the EU. The managed Kubernetes platform keeps the nodes patched on a release channel, and every node runs as a Shielded VM with secure boot.
  • Monitoring, in the open and on our own infrastructure. Our status page used to be hosted by a third-party status service. It now runs on our own infrastructure in the EU, next to the apps and help centers: fewer outside tools that hold data about you and your visits, and one dependency less. All seven apps are on it at status.codecreationlabs.cloud: live state and 90-day uptime per app, checked every minute from outside our clusters, planned maintenance announced ahead, the current security advisories at the top, and email subscriptions for incidents. Errors alert us, and operational logs never contain tokens, secrets or customer data.

Where to find this later

Security at Code Creation Labs describes all of this in one place and carries the table of advisories we have been asked about, with the date, whether our apps are affected and a link to the statement. Each app's help center has its own security page with the same table, and every privacy policy links to it. The help centers of Workflow Trigger Extensions, Workflow Transactional Email and Workflow Webhooks, and the status page, are available in 12 languages: English, German, French, Spanish, Italian, Dutch, Portuguese, Brazilian Portuguese, Danish, Japanese, Simplified Chinese and Traditional Chinese.

If you have a security questionnaire to complete, or an advisory you would like us to check against our apps, write to support@codecreationlabs.com. We answer those with priority.