PHP Commerce: Moving Off Shared Hosting

Familiar is not the same as safe. Protecting customers now takes wholesale change, not patches — especially where personal data (PII), card data (PCI) or health data (PHI) is involved. The October 2026 checkout hijack ran through apps merchants had trusted for years. Shopify and Google have been raising these requirements since 2022. Most of the deadlines have passed; what remains is enforcement — delisting, blocked installs and lost ad eligibility.

Who this is for: merchants, agencies and app developers running WordPress and WooCommerce, Magento or Adobe Commerce, or PHP-backed Shopify apps — loyalty, upsell, product options, wishlists — on shared or single-VM hosting.

The question it answers: what to move, where to, and in what order, so that one breached plugin, one compromised vendor or one runtime flaw cannot reach every customer on the server.

The PHP runtime itself is covered in the companion article: patch for php2shell (CVE-2026-109618 and CVE-2026-109619) and keep the Cloudflare WAF rules in Block — Entitlement Security → php2shell. This article is about the architecture around it. For the owner and legal view of the same deadlines — what goes dark, and who carries the liability — see the Risk & Liability Brief: The 2026 Client-Side Cliff.

Vocabulary

The requirements are not new

October 2026: delistings and the checkout hijack

About 126 apps were pulled from the Shopify App Store between October 14 and 18, 89 of them on October 15. Most of that number is versioning, not attack: API 2025-10 stopped being accessible on October 16, and delistings are routine — LetsMetrix counted 512 between September 22 and October 21, about 17 a day. Shopify has published no count and named no apps.

Only a few are tied to the hijack. Between October 10 and 20, attackers changed vendor-side settings so that shoppers clicking Checkout were sent to a lookalike payment page. Shopify's own checkout was not breached. The code came from vendors' configuration APIs and internal tools, not from the app files Shopify hosts — which is the risk of a third-party server holding store access.

Rebuy's account is the identity half of the same lesson. Nothing in the runtime failed: an email address on the company's domain was treated as proof of being staff, and staff accounts carried standing access to stores. Its remediation — privileges only for a named group, multi-factor authentication for every merchant, a third-party penetration test of the authentication services — is the permissions model this article argues for: identity verified at the server, never inferred from what the caller typed, and access granted per task rather than held by default.

The same mistake is not unique to apps. Identity providers and the software built on them have shipped it too:

The rule all three break is the same: an email address is a contact detail, not an identity. Identify a user by the identity provider's immutable subject — the OpenID Connect sub with its issuer, in Entra the object ID with the tenant ID — require a verified email before linking any account, restrict which tenants may sign in, and grant elevated access only to a named group. MFA is necessary and, as nOAuth shows, not sufficient.

Why /auth/me claims and extras refuse the impostor

In the CRM Sync model, nothing an app does is decided from the email address. Every request is resolved through /auth/me, which reads five things in a fixed order, and each one is a row someone had to be granted rather than a fact inferred from what the caller typed:

Platform administration sits outside this path entirely: a separate root credential and revocable tenant-scoped tokens, never a user account with an elevated flag.

Closed on 22 October 2026. Writing this section surfaced the same mistake in CRM Sync's own code, and it is fixed in production. An email-only match now attaches a login to an existing subject only when the inbox is proven — the provider verified the address, a Shopify one-time-code login, or an invitation link — and an unverified login is refused rather than attached. A typed email on a public form writes nothing until a single-use link mailed to that address is clicked, and every unconfirmed submission gets the same reply, so the form cannot reveal whether an address has an account. Rewards enrolment takes identity only from a session. Four static checks in the release gate fail if any of this regresses. The full claims-and-extras model is in Entitlement Security → claims and extras.

Merchant checks: find these apps among those installed, delisted ones included; review app embeds and custom JavaScript fields for scripts nobody added; run a test checkout in a private window and confirm it lands on Shopify's checkout domain; read Shopify's notice for your store's exposure window. Shoppers who paid by Shop Pay or PayPal were generally not exposed; shoppers who typed a card number during a window were.

Remove every client-side redirect to another domain

The hijack worked because a script in the shopper's browser could send them somewhere else. Any script that can do that today is a hijack waiting for a compromised vendor — legitimate ones included: market redirectors, affiliate rewriters, "faster checkout" buttons, leftovers from a previous storefront.

Then hold it: a destination allow list for every server redirect; a Content Security Policy with script-src limited to an inventoried list and form-action limited to the store's own origins and checkout; a payment-page script inventory with change alerts (PCI DSS 6.4.3, 11.6.1); and a private-window test checkout on every release.

What is being replaced

Desktop publish: how MAMP and WAMP sites reach production

MAMP and WAMP are desktop bundles — Mac or Windows + Apache + MySQL (or MariaDB)

• PHP — for running WordPress or Magento on a laptop. The SQL database inside is an ordinary

MySQL server. The risk is not the laptop; it is how the site usually gets published from it:

WooCommerce and Magento make the dump worse. A store's database is not just content:

• WooCommerce keeps orders and customers in its own tables (the HPOS wc_orders tables on current versions, or wp_posts and wp_postmeta on older ones), payment gateway settings — including gateway secret keys — in wp_options, and REST API keys in woocommerce_api_keys, where the consumer secret is stored as written. A dump carries all of it.
• Magento stores database credentials and its encryption key (crypt/key) in app/etc/env.php, and encrypts sensitive configuration in core_config_data with that key. Copy the dump and env.php together — which a desktop publish usually does — and the encrypted values can be decrypted. It also holds customer password hashes, orders, carts and integration tokens, and needs OpenSearch beside MySQL, which brings a second service and its own credentials onto the VM.

What replaces it:

1. The desktop stays a sandbox, with seed or synthetic data — never a copy of production customers. Anonymise anything realistic first.
2. Publish code, not databases. Code travels through Git and a built container image; nobody uploads a .sql file to production.
3. Schema changes are migrations or versions, applied in the image — WP-CLI and WooCommerce's own updater, Magento's declarative schema (db_schema.xml) with bin/magento setup:upgrade in production mode — or recorded by the data platform, not hand-run SQL.
4. The production database has its own roles, made in its own ceremony: no root, a user per service, no public port, TLS required.
5. Desktop-to-production access goes through Cloudflare Access or a tunnel — never an open MySQL port or FTP.
6. Dumps are encrypted, expire, and live outside the web root, deleted after the restore they were made for.

Where Magento's database actually runs: MAMP, a VM, Docker or Azure

Magento does not come with a database. It is a PHP application that connects to a MySQL or MariaDB server, and where that server runs depends on how the store is set up. MAMP and WAMP are only one of those places, and the weakest one for Magento.

Moving the database to its own VM is a step, not the finish. It stops a neighbour's site from reaching your tables. It does not stop your own PHP from reading every table, because Magento connects as one database user with rights to all of them. The rules about who may read which customer's rows still have to live somewhere: in a row-level gate in front of the data, or in Xano, as the migration path below describes.

Docker with the database: the setup that matches production

The same images run on a laptop, in staging and in production. The database is a container (or a managed service in production) that nothing outside the private network can reach.

# compose.yaml: Magento 2.4.8 locally, shaped like production. Check Adobe's system
# requirements for your exact version; these follow 2.4.8.
services:
  web:                      # nginx: the only service with a published port
    image: nginx:1.28
    ports: ["127.0.0.1:8080:80"]       # localhost only; production sits behind Cloudflare
    depends_on: [php]
  php:                      # your own image: PHP-FPM 8.3 or 8.4, Magento code baked in
    build: .                  # its app/etc/env.php reads these; Magento does not read them by itself
    environment:
      DB_HOST: db
      DB_NAME: magento
      DB_USER: magento_app            # not root
    secrets: [db_app_password]         # read from a file at runtime, never in the image
    depends_on: [db, search, cache]
  db:
    image: mariadb:11.4
    environment:
      MARIADB_DATABASE: magento
      MARIADB_USER: magento_app
      MARIADB_PASSWORD_FILE: /run/secrets/db_app_password
      MARIADB_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
    secrets: [db_app_password, db_root_password]
    volumes: [dbdata:/var/lib/mysql]
    # no "ports:" — only containers on this network can reach the database
  search:
    image: opensearchproject/opensearch:2.19.1
    environment: { discovery.type: single-node, DISABLE_SECURITY_PLUGIN: "true" }   # local only
  cache:
    image: valkey/valkey:8
secrets:
  db_app_password:  { file: ./secrets/db_app_password }    # git-ignored
  db_root_password: { file: ./secrets/db_root_password }
volumes: { dbdata: {} }

What the file shows, in plain terms:

• Only the web server has a door. The database, search and cache have no published port, so nothing outside the containers' private network can reach them. On a laptop the web port binds to 127.0.0.1, not to the café's Wi-Fi.
• Magento connects as its own user, not root. The root password exists only for the database container's own setup, and the application never sees it.
• Passwords are files, mounted at runtime. They are not in the image, the Git history or env.php in the repository.
• The data lives in a named volume, not in the image. Rebuilding the image does not touch the data, and the data never travels inside the image.
• Search security is off only because this is local. In production, OpenSearch runs with its security plugin on, or as a managed service.

In production, the same php image runs in a container platform, and the db container is usually replaced by a managed database. Nothing else in the file changes shape: the application still reaches the database by name, with its own user, over a private network.

On Azure: the database, Blob Storage and the containers

A note on Blob Storage and Magento. Magento's built-in remote storage supports Amazon S3, not Azure Blob. On Azure you either add a remote-storage adapter extension for Blob, or mount Blob into the container with BlobFuse2 or Blob NFS. Either way:

• Blob holds files, never the database. Images, invoices and exports go there. The MySQL data stays in the database service.
• The container is private. Public access is turned off on the storage account. Shoppers get images through the CDN, not from a public container URL.
• Dumps go in a different storage account from media. A media account has to be readable by the CDN; a backup account should be readable by almost no one.
• Invoices and exports with customer data get the same treatment as dumps: private, short-lived links, and a deletion rule.

The order to do it in: Docker locally first, so every developer runs the same stack; then the managed database with private access; then Key Vault for the secrets; then Blob for media and backups. Each step removes one shared-box risk without waiting for the next. The permission rules, who may read which customer's rows, are the step none of these replace.

The migration path: MySQL on a VM to Postgres in Xano

Moving identity and customer data off WordPress's MySQL and into Xano's Postgres is a one-time migration, done once and carefully — not a recurring export. Xano provides the Postgres, containers and schema versioning; the rules on each endpoint are yours to write.

1. Inventory and decide what moves. List the tables (wp_users, wp_usermeta, WooCommerce orders and customers, plugin tables). Identity goes to Xano's users table and user_claims; profile and consent to user_extras; orders stay with Shopify if the store is moving there; products go to Shopify or the PIM. Anything nobody can name an owner for does not move.
2. Do not carry password hashes. WordPress hashes belong to WordPress. Customers sign in again through a magic link or a provider login, which creates a claim keyed by the provider's immutable subject — the step that stops email-match impostors.
3. Export table by table, minimised. One CSV per table with only the columns that move (SELECT … INTO OUTFILE, or mysqldump --tab), taken from a read-only copy, on an encrypted disk, never to the web root.
4. Create typed tables in Xano first, then load: Xano's CSV import for small tables, or a rule-checked endpoint (or Xano's bulk record functions) for large ones, so every row is validated and each field lands in the table that owns it. Schema versioning records who changed what and can roll back.
5. Reconcile. Compare row counts and a digest of each exported file against what Xano holds, and record the result in the ledger: which file, which digest, which rows were refused.
6. Cut over behind the sidecar. WordPress stops reading its own users table; the /auth/me sidecar answers who the caller is from Xano. The MySQL database goes read-only, then is retired after a full billing cycle.
7. Close the old doors. Delete every dump and CSV, drop the old database users, and rotate every key that ever sat in wp_options or wp-config.php — in a key ceremony, on a patched machine, one environment at a time.

WooCommerce and Magento: what lives where, and where it goes.

Platform-specific steps:

• WooCommerce: revoke every REST API key and webhook, then rotate the gateway keys at Stripe, PayPal or the other provider — the copies in wp_options and every dump are now old.
• Magento: rotate the encryption key with bin/magento encryption:key:change (2.4.7 and later re-encrypt stored values) before the final cutover, then rotate payment and integration credentials at each provider. Keep the old env.php off every disk once the database is retired.
• Both: the PIM, DAM and import plugins attached to the store hold their own keys — Cloudinary, Akeneo, feed services. Rotate those too, as the CSV section describes.

After the move, the same rule from the CSV section holds: data reaches Postgres only through an endpoint that authenticates the caller and checks the row, never as a file loaded into the database.

Not just WordPress: PIMs, DAMs and the CSVs that feed PHP

The exposure in this article is not limited to the storefront. Product information (PIM) and digital asset (DAM) systems either run on PHP themselves or hand their data to PHP through plugins and CSV imports. Wherever data lands in PHP, it inherits the shared-VM risks above.

What the main systems are built on. Self-hosted open-source tools are mostly PHP on MySQL; enterprise SaaS mostly is not. The SaaS rows are drawn from public job postings and vendor documentation, not published architecture, so treat them as indicative.

SaaS without PHP still reaches PHP. Cloudinary has no PHP in its platform, but its PHP SDK, WordPress plugin and Magento extension do — and they run on the merchant's server. To sign uploads, they keep the Cloudinary API secret where PHP can read it: wp_options, env.php or a .env file. A php2shell-style flaw on a shared VM reads that secret, and with it an attacker can upload, replace or delete every image in the account — swapping product images, or planting files on the brand's own media domain. The same is true of every PIM connector, feed plugin and DAM sync module installed into WooCommerce or Magento.

CSV and spreadsheet imports are a door into PHP

Even when the PIM is not PHP, the data often reaches the store as a CSV or spreadsheet loaded by a PHP importer — a WooCommerce or Magento import, a PIM connector, a nightly cron job. Each import is code reading a file someone else wrote:

What replaces it. The same pattern as the rest of this article: the file is checked before anything PHP-shaped touches it.

1. Parse at the edge, not on the VM. A Worker receives the file, validates every row against a typed schema, and writes through the platform's API (Shopify GraphQL, the Merchant API) — the PHP importer is retired, not patched.
2. Field ownership. Each source may write only the fields it owns. A catalog file never writes consent; an ERP file never writes reviews. Rows that try are refused and recorded.
3. No fetching from rows. Image URLs are fetched only from allow-listed hosts, outside the network, and stored in object storage (R2 or the DAM), never the web root.
4. Sign the file. The sender's digest and identity travel with the file, and each import writes a ledger row — so "which file set this price on 1 March?" is a query, as the AI Trust Framework Requirements asks.
5. Until the importer is retired: PhpSpreadsheet on a fixed release (2.2.1 or later for CVE-2024-45048, and the 1.9.4 / 2.1.3 / 2.3.2 / 3.4.0 lines for CVE-2024-47873), Pimcore and its data importer on their fixed releases, uploads outside the web root with PHP execution disabled there, and every DAM or PIM secret rotated when the site leaves the shared VM.
6. Escape exports. Prefix any cell that begins with =, +, - or @ before a CSV leaves the system.

Three ways to load a product file: Matrixify, a bare database, and Xano with rules

The same product.csv can reach a catalog three ways. What differs is who checks it, and what a bad row can reach.

• Matrixify is a hosted Shopify app. It reads the spreadsheet on its own servers and writes through the Shopify Admin API under the scopes the store granted it.
• A bare database load is the file loaded straight into MySQL or Postgres — LOAD DATA INFILE, COPY, a phpMyAdmin import, or a PHP script reading product.csv from an upload or FTP folder.
• Xano with rule-based permissions puts Postgres behind API endpoints. Nothing connects to the database directly; every write goes through an endpoint that authenticates the caller, checks typed inputs, and applies RuBAC rules before a row changes.

How the Xano side is hardened:

1. No direct database access in production — no public Postgres port, and any direct database connector off or read-only.
2. Authentication on every endpoint, with identity resolved server-side by /auth/me, never taken from a field in the file.
3. Typed inputs. Each endpoint declares the fields and types it accepts; anything else is dropped before the query.
4. Rules before writes. A precondition checks tenant, role and field ownership for every row, and filters every query by the caller's tenant — the API-level equivalent of row-level security.
5. Separate keys per job and environment. An import key can write products for one tenant; it cannot read customers or touch another workspace.
6. Sensitive fields encrypted with a key made for that deployment, so even a full export reveals ciphertext.

Choosing. Matrixify is a sound tool for a one-off migration on Shopify — remove it, or cut its scopes, when the job ends, and strip columns you do not mean to change. A bare database load should not exist in production. For a recurring feed from a PIM, ERP or supplier, the rules belong in front of the database, where every row is checked and every refusal is evidence.

The options, and what each one isolates

Order of moves: static first, for every page that needs no login. EmDash next, where editors need a live CMS. WordPress or Magento in Docker last, only for what cannot yet leave PHP.

EmDash was announced by Cloudflare on April 1, 2026 as a v0.1.0 developer preview — MIT licensed, TypeScript on Astro, no WordPress code. Content imports from a WXR export or the EmDash Exporter plugin; themes must be ported. It has no commerce, so WooCommerce stays in Docker or the store moves to Shopify. Pilot it on a blog subdomain first. Cloudflare: EmDash

The static path has run in production for years — Jekyll and GitHub Pages since 2008, 11ty since 2017, Decap since 2016 as Netlify CMS. GitHub Pages' terms forbid running an online business or e-commerce site on it, so a store built with Jekyll or 11ty is hosted on Cloudflare.

One machine, isolated: a private VM with Cloudflare and Xano, versus shared hosting

WordPress does not need a cluster to be isolated. One private VM — WordPress in its own container, reachable only through a Cloudflare Tunnel, behind the Cloudflare WAF, with identity and data on Xano — closes the gaps that shared and entry-level managed hosting leave open. The difference is not the WAF itself; it is whether the WAF can be the only way in.

What this means. Cloudflare's WAF can be engaged securely only when it is the sole path to the origin. On a private VM that is a property of the network — no inbound port exists. On shared hosting it is a hope: the WAF filters the traffic that comes through Cloudflare, and nothing stops traffic that goes to the server's address directly. Managed hosts like WP Engine close much of that gap with their own Cloudflare-powered edge, but the rules, keys and data model stay theirs, and the site's identity still lives in a WordPress users table.

RuBAC by design: claims, extras, configuration and EdDSA keys

Rule-based access control is only as strong as the facts the rules read. In this architecture each fact comes from a place the WordPress container cannot write, so a compromised plugin can render a page but cannot change who the caller is, what they consented to, or what the rules say.

One request, in order:

1. Cloudflare WAF and Access filter the request at the edge.
2. The Worker verifies the token's Ed25519 signature against the published key id. A retired, unknown or altered token stops here.
3. /auth/me returns claims and extras for that subject — the server's answer, attached by the sidecar, never the browser's.
4. The configuration's rules decide: this subject, this tenant, these fields, this action. The default is deny; anything not written as allowed is refused, and the refusal is recorded.
5. Xano's endpoint precondition applies the same rule at the data layer and filters by tenant before Postgres runs the query.
6. WordPress renders the result. It never held a key, a password table or a rule.

"By design" means the rules exist before the first request, not after the first incident: the default is deny, every input comes from a system the theme cannot write, and every decision is signed and logged. Moving from a shared VM to one isolated VM is the infrastructure step; RuBAC is what makes the move hold when a plugin is compromised anyway.

Sources: Hostinger technology (CloudLinux LVE); WP Engine Global Edge Security; Cloudflare Tunnel. Plan features change; check your host's current documentation.

The safer customer option: let Shopify hold the customer and the card

For a store that wants to keep its WordPress or Webflow site, the most effective PII and PCI reduction is to stop holding the data at all. Shopify's Storefront Web Components put products, prices and a cart on any page with a few lines of HTML, and the Buy now button sends the shopper to checkout on Shopify. Shopify's own WordPress plugin — built by Shopify, not by WordPress — does the same from the WordPress Editor: products are managed in Shopify and placed on WordPress pages and posts.

The components are plain HTML elements plus one script, so they are not tied to a CMS. The same block works in a Webflow embed, a WordPress theme or block, an Astro or EmDash component, an 11ty template, and an AEM component or Edge Delivery block — anything that renders HTML and can load a script. Try them in Shopify's playground.

A working example. crm-base.webflow.io is a Webflow site with no commerce code of its own. When a shopper adds a product to the cart, a CRM Sync embed mounts Shopify's <shopify-store> and <shopify-cart>, and checkout lands on the Shopify store at www.crm-sync.dev. The Webflow site never sees a card number or keeps a customer record; the Shopify store holds both.

The same theme renders the same everywhere. The design is the Webflow export plus one embed block, with no framework code in it, so the same theme renders the same on WordPress, AEM, 11ty, Shopify, Next, Astro, Nuxt, Svelte and Drupal — with the forms and the data-binding security intact. The security does not live in the theme, so it does not change when the host does: forms still post to the Worker and hold a typed email until the inbox confirms, /auth/me still decides who the caller is, permissions are still granted rows checked on every request, and the cart and checkout are still Shopify's. None of those hosts ever holds a customer record, a consent record or a card.

The structured data carries over too. The JSON-LD for collections and their joins, the llms.txt answer engines read, and the LLM weighting are generated by the Worker from the records, not by the theme. Each AEO taxonomy item carries a weight — the summed predicted value of that channel's consented members, an aggregate and never a per-person score — and the JSON-LD and agent surfaces rank by it. Move the theme to another host and what an answer engine reads, and how it is ranked, stays the same.

Stakeholder teams review the model

The modeling is intentional, and it is reviewable. Because the collections, joins, weights and permissions are records rather than theme code, the people accountable for them can read and adjust them without a developer redeploying a site: subject-matter experts and QA review the content, developers own the schema and joins behind the release gate, and revenue stakeholders adjust the context — the taxonomy, channels and weights that decide what is ranked. Mandate permissions are adjusted the same way: an agent's mandate can be tested and revoked from the console, and the roles are separate by design — the role that tests a mandate before a release depends on it cannot revoke it. Each change is a recorded row, so every adjustment can be checked after the fact.

Signed in as the author on www.crm-sync.dev. The name in the navigation comes from /auth/me — the claims and extras for that subject, read on the server, not stored by the theme — and the views listed are exactly the roles that subject was granted. Access is by invitation; someone holding only Revenue BA sees campaigns, Smart Bidding and BigQuery analytics and nothing else. QA / Compliance reviews and signs off, Content & Strategy defines events and audiences, Agent Permissions holds the mandates, and Shape Author edits the data shapes in a Webflow collection with no git and no CLI. The WordPress and Astro/EmDash paths are in File System Agnostic Publishing, and the AEM path in Shopify / Google Integration on an AEM Scaffold.

The crm-base design in Webflow at three breakpoints. The structure is a navigation component, the page content and a footer component — design only. The CART link in the navigation opens Shopify's cart; the products, cart and checkout come from Shopify, not from Webflow.

What it does not remove. The page that holds the Buy now button is still a page you serve, and the October 2026 hijack worked by changing what happened before checkout. The rules above still apply to it: no client-side redirects to other domains, a Content Security Policy that lists every script, an inventory of the scripts on any page that links to checkout, and a private-window test checkout on every release. WordPress still runs PHP for the content site, so the runtime patches still matter. Only the public Storefront token belongs in the page — never an Admin API token. Shopify's plugin page does not say where customer and order records live; confirm that before describing the plugin to customers as keeping them off WordPress.

Setup, including the Webflow-to-WordPress and EmDash/Astro paths, is in File System Agnostic Publishing → the Web Components block.

Secure forms on any front end

A form is the other place PII enters, and the platform's own form storage — Webflow submissions, a WordPress form plugin's table, a Liquid contact form — puts that PII next to everything else the platform runs. CRM Sync forms send the data to the Worker instead, and the form itself is only HTML:

<form data-crm-form="newsletter" data-crm-submit="worker">
  <input type="email" name="email" required>
  <label><input type="checkbox" required> I accept the Terms of Use and Privacy Policy</label>
  <button type="submit">Submit</button>
</form>
<script src="https://crm-sync.dev/embed/forms.js" defer></script>

The crm-base newsletter form in Webflow. The design stays in the Designer; the two custom attributes hand the submission to the Worker.

Because the contract is two attributes and one script, the same form works wherever HTML renders:

What makes it secure.

• The platform never stores it. The script intercepts the submit before the platform's own handler runs and posts to the Worker, so the address is not written to Webflow, WordPress or Shopify form storage.
• A typed email proves nothing. Without a session, the Worker records nothing and mails a single-use, 48-hour confirmation link; the permission is written — with its date, time and the exact wording shown — only when the inbox answers. A signed-in shopper's session proves the address, so theirs is recorded immediately.
• The reply never reveals an account. Every unconfirmed submission gets the same answer, whether or not the address already has an account.
• Abuse is capped. 60 submissions an hour per IP, three confirmation mails a day per address.

The demo, on our own data. This is the live run from 22 October 2026, submitted from no session with the author's own address (masked here):

POST https://crm-sync.dev/forms/newsletter
{"email":"y•••••••••••@gmail.com","page":"/verify-email-is-not-identity","locale":"en"}

{"ok":true,"form":"newsletter","form_id":"newsletter_en_2026-10-22T12:02:22.862Z_f767c744",
 "locale":"en","status":"confirmation_sent",
 "why":"check your inbox — the request is recorded once the address confirms it"}

No user ID, no "created" flag, and no consent row until the link in the inbox is clicked. The form_id is the join key: the same value is written to the reconcile log, the GA4 signal event and the response, and it survives confirmation, so the held entry and the recorded one join on it.

Email-only plugin forms and fee-based middleware. Most CRM and plugin forms capture an email address and nothing else — no consent wording, no time, no session — and store it in the vendor's own database, often a PHP application outside the merchant's control. Fee-based middleware then copies it onward, charging per task or per record. Moving that audience to Google is not a file transfer: Google's EEA consent rules require ad_user_data and ad_personalization consent for the people in it, and an address with no consent event behind it has nothing to show. Migrate with the consent, not just the address — export what consent evidence exists, send the same single-use confirmation to everyone whose record has none, and connect the confirmed audience to Google's APIs directly from the Worker, which also ends the per-record middleware fee.

What it does not cover. If the script is blocked — an ad blocker, a strict CSP that omits it — the platform's own handler takes the submit, and the address lands in the platform's form storage after all. Remove the platform's own destination where the platform allows it, list crm-sync.dev in the CSP, and test the form with the script blocked.

Packaging the form. The HTML contract above is what ships today. Because the form is a contract — a slug, its fields, its consent wording — it can travel in other shapes:

Shopify plugins become Rust Shopify Functions

Shopify recommends Rust for public apps, large carts and complex logic, because it compiles directly to WebAssembly and stays inside the instruction-count limits; JavaScript is for prototypes. Functions decide; they do not store. Points, history and consent stay in the ledger, behind /auth/me.

Identity, data and AI tasks

1. Identity. A sidecar resolves every request through Xano /auth/me with the caller's JWE token and forwards the actor in a signed internal header. PHP never parses tokens and never trusts a user_id sent in a form.
2. Data. Postgres row-level security filters every read and write by tenant and actor, so a plugin bug or SQL injection returns only the caller's own rows. MySQL has no RLS; WooCommerce and Magento data either moves or sits behind filtered views.
3. AI tasks. Each automated job runs in a Tool Runner loop with a scoped tenant key and only the tools that task needs — the runner exists in PHP too. The full model — Cloudflare binds, Xano grants, Rust checks — is in Entitlement Security → AI task binding.

AI data binding with provisional permissions. A task binding says which tools an agent may call. The data it may touch is bound the same way — by permissions that expire, and by gates on where the subject is, who they share with and what device they used:

The plugin in the middle: data ownership from Shopify to CRM, service, fraud, consent and Google pLTV

A typical store sends one customer's data through several systems, each connected by a plugin:

• Marketing and CRM: Klaviyo, Salesforce
• Customer service: Gorgias, Sprinklr
• Consent management (CMP): OneTrust
• Fraud: Signifyd, Stripe Radar
• Advertising and predicted lifetime value (pLTV): Google Customer Match, enhanced conversions and BigQuery

The gap is the plugin in the middle. It holds the access tokens for both sides, and nothing it does leaves a record the merchant controls. The merchant is the controller under GDPR and CCPA, but the evidence of what was sent, with what consent, and whether it was erased sits with the processors.

Where ownership breaks:

Every hop is also a place code can be injected. Each connector runs third-party code where PII and card data change hands: a checkout script, a webhook receiver, an import job, a helpdesk widget. A distrusted certificate authority (the emSign case) makes it easier to impersonate any of those endpoints, but the injection itself happens in whatever code runs at the handoff. That is why each hop needs a verified sender and a declared shape, not just TLS.

The fix: one service bus with timestamp-verified records, linked to the user ID

The plugins can keep doing the transport. They stop being the only place the evidence lives. Every transfer, in either direction, also writes one record to a service bus the merchant owns, keyed to the merchant's own user ID.

Shopify ─┐                                  ┌─ Klaviyo / Salesforce
Gorgias ─┤                                  ├─ Gorgias / Sprinklr
OneTrust ┼─→ Worker gate ─→ service bus ─→──┼─ Signifyd / Stripe Radar
Signifyd ┤   (verify, shape, consent)  │    └─ Google (Customer Match, BigQuery pLTV)
Stripe ──┘                             └─→ Xano: user ID spine, permissions, erasure fan-out

1. One user ID spine the merchant owns. Xano, behind Cloudflare, holds a pseudonymous ID for each customer. Every vendor's ID (Shopify customer, Klaviyo profile, Salesforce contact, Gorgias customer, OneTrust identifier, Stripe customer) is linked to it. The bus carries the spine ID, never the email address.
2. Verify the sender at the gate. Webhooks are checked by their HMAC or signature (Shopify, Stripe and Signifyd sign theirs; for any vendor that doesn't, use a per-vendor secret URL behind Cloudflare Access) before anything is read, then parsed into a declared shape by the Rust gate. Unknown fields and oversized bodies are refused.
3. Consent travels with the record. The gate reads the consent state at the moment of the transfer (CMP receipt plus Shopify signal) and writes it into the record. Google receives only what was actually granted, never a value inferred from something else.
4. Purpose is part of the record. Fraud and service records are tagged with their purpose (fraud_prevention, support) and can't be routed to marketing or advertising destinations. Card numbers and ID documents are redacted from service messages before the record is stored.
5. Every record is timestamped, chained and signed. Clocks differ between clouds, so a timestamp alone doesn't prove order. Each record carries:

   {
     "seq": 18422,
     "prev": "sha256:9f2c…",
     "subject": "usr_7f3c…",
     "event": "fraud.decision",
     "source": "signifyd",
     "destination": "shopify.order",
     "purpose": "fraud_prevention",
     "consent": { "analytics_storage": "granted", "ad_user_data": "denied", "ad_personalization": "denied" },
     "observed_at": "2026-10-24T14:02:09Z",
     "received_at": "2026-10-24T14:02:11Z",
     "kid": "bus-2026-10",
     "sig": "ed25519:…"
   }

• observed_at is when the source says it happened; received_at is the gate's own clock. A large gap between them is flagged.
• seq and prev (the hash of the previous record) fix the order and make a deleted or edited record visible, whichever cloud's clock was right.
• sig is an Ed25519 signature from a key the merchant holds, so the record can be checked anywhere: in BigQuery, by an auditor, or after leaving a vendor.
• Where a record may be needed as legal evidence, also anchor batches with a trusted timestamp (RFC 3161) from a time-stamping authority.
• Erasure fans out from the spine. One request finds every linked vendor ID and sends each vendor its deletion call. Each confirmation is written back to the bus as its own signed record.
• Analytics only read. BigQuery and the pLTV model read the bus to score customers. They never decide access; permission stays in Xano.

What the merchant can then answer, for any user ID, from records it owns: what was sent to which vendor and when; under which consent and purpose; which vendor decisions (fraud, refunds, service actions) changed the order; and whether every copy was erased.

Status. Built today: consent records with device provenance, Shopify webhook HMAC checks in constant time, consent and erasure events in a hash chain ordered by seq and prev_hash and signed with Ed25519, and erasure fan-out to Shopify, Klaviyo, Salesforce, Adobe, Google Customer Match, the pLTV score and any agent mandates, with the Google instruction written to the chain. Not built yet, and pinned as failing tests in the CRM Sync test harness: erasure to helpdesk, fraud and CMP vendors (Gorgias, Sprinklr, Signifyd, OneTrust), purpose tags that keep fraud and support data out of ad destinations, received_at with clock-skew flags, the Rust shape gate, and one table linking every vendor ID to the user spine.

Google audiences and conversions with Vertex AI, and where LoRA fits: scoping private channel data

The service bus decides what each channel's data may be used for before any of it reaches Google or a model. Three Google uses are in play, and one AI technique that is often confused with them:

• Conversions: order values sent to Google Ads (enhanced conversions, or Data Manager) so bidding learns which clicks led to sales.
• Audiences: hashed contacts sent to Customer Match, so ads reach or exclude known customers.
• Predicted lifetime value (pLTV): a model scores each customer's likely future spend, and the score is sent as the conversion value instead of the first order's total. BigQuery ML trains it in place; Vertex AI is Google's platform for training and serving larger models when a client's Google team wants more than BigQuery ML.
• LoRA (Low-Rank Adaptation): a small add-on trained beside a language model that changes how it writes (tone, format, classification), not what it knows. It is not a targeting or scoring tool.

Scope by channel. Each record on the bus carries its purpose, and the purpose decides the destinations:

Two rules sit under the table. Personal data never goes into model weights, because an erasure request can't reach inside a trained model. And Google receives conversions, audiences and pLTV scores, never the vectors or the documents behind Ask-the-Docs; those stay in Cloudflare.

The flow:

service bus (purpose + consent on every record)
  ├─ conversions ─→ consent gate (ad_user_data) ─→ Google Ads / Data Manager
  ├─ audiences ───→ consent gate (both signals) ─→ hashed contacts ─→ Customer Match
  ├─ pLTV ────────→ pseudonymous features ─→ BigQuery ML  (or Vertex AI, client's Google team)
  │                  score ─→ Xano / Worker ─→ sent as the conversion value
  └─ LoRA ────────→ redacted, de-identified pairs ─→ one adapter per client and channel
                     facts stay in Cloudflare Vectorize (RAG), so erasure still works

Where Vertex AI fits. It is an add-on, not a dependency. Training or serving a model in Vertex needs the client's own Google Cloud project, which their Google or analytics team owns and an agency usually can't reach. So the core runs without it: BigQuery ML trains pLTV where the data already sits. Vertex is handed over to the client's Google team with three things named: the permission it needs, the team that grants it, and what it unlocks (larger models, scheduled retraining, online scoring). Either way, the features arrive under a pseudonymous ID, and the score comes back to Xano, which decides whether it may be used.

How LoRA scales without widening access. Scaling here means more small adapters, not one bigger shared model:

• One adapter per client and channel, owned by that client as their asset. A support-tone adapter for one brand is never loaded for another.
• Behaviour only. Tone, format, routing and classification. Prices, stock, policy and legal text stay in RAG, where they can be updated and erased.
• Trained on de-identified pairs only. Names, emails, phone numbers, order numbers and card data are removed first, and the pairs need their own legal basis, because training is a separate purpose from answering.
• Recorded on the bus like any other transfer: which dataset (by hash), which purpose, who approved it, which base model, and when. An adapter with no record isn't loaded.
• Hosted where the data may go. Workers AI accepts your own LoRA adapters on supported base models (check current limits on rank, size and count), and Vertex AI tunes adapters inside the client's Google project. Korean data uses a Korean-hosted model.
• Climbed to only on evidence. Retrieval first; an adapter is trained when an evaluation set shows retrieval finding the right passage but the answer still coming out wrong.

Status. Built today: the consent-gated export of pseudonymous IDs to BigQuery, carrying the four Consent Mode signals; a BigQuery ML pLTV model (boosted tree, first-week features predicting 90-day revenue) whose scores come back to the Worker; pLTV used as the audience value when a score exists; and all retrieval vectors in Cloudflare. Not built: Vertex AI training or serving, any LoRA adapter, the purpose tags that route records by scope (a failing test in the harness), the Korean release-consent check before an identifier upload, and requiring the purchase session's consent record before any upload.

Google Merchant API: rebuild loyalty, reviews and comparison in one pass

The Google feed integration is being rebuilt regardless. The Content API for Shopping shut down on 18 August 2026; Merchant API became generally available as v1 in July 2025, its v1beta versions were discontinued on February 28, 2026, new features ship only there, and conversion sources move from content/v2.1 to conversions/v1. Connect loyalty, reviews and price comparison directly in the same conversion, rather than through a plugin that can be delisted.

Conversions at no ad spend. Merchant Center conversion sources report conversions from free listings — the organic surfaces where reviews, loyalty member prices and price comparisons appear — as well as from ads. They only match exactly when each event carries three things, captured at the moment it happens:

That is what turns an AI answer into an attributable sale: the assistant finds the candidate, and the session, device and key decide the transaction. CRM Sync writes all three today for a signed-in submission. A submission confirmed by email deliberately drops the typing browser's GA identifiers — carrying them would bind a stranger's browser to the person who clicked the link — so it keeps the device and the key but not the session. Conversions sent without all three are estimates.

A verified-purchase review or a member price shown to Google is a claim about a real order and a real member. CRM Sync records that claim as a signed mandate anyone can check offline in a browser — verify a mandate · verified transactions.

Supply chain: every new ecosystem is a new door

Moving off PHP brings in Python for AI gateways, npm for Workers and Rust crates for Shopify Functions. On March 24, 2026, LiteLLM 1.82.7 and 1.82.8 were published to PyPI with a credential stealer — one through a .pth file that runs on every Python start — taking SSH keys, cloud and Kubernetes credentials, .env files and TLS private keys (BleepingComputer). A second poisoned release, 1.107.0, followed on October 21 — Entitlement Security → LiteLLM.

CRM Sync's desktop build imports the published crate audits of Mozilla, Google, the Bytecode Alliance, ISRG, Embark and Zcash — 102 crates fully audited, 357 recorded as a starting baseline — and fails CI on any crate version no audit covers. Wildcard trust is avoided on purpose: a hijacked publisher would pass it.

Signed records: SBOMs, firmware and signing keys

Every incident in this article ends with the same question from the board, the insurer and the regulator: were we affected, and can you prove it? A business that has to answer by meeting finds out in weeks. One that keeps signed records answers by query in minutes. Three records do the work:

• A software bill of materials (SBOM) is the ingredient list for each release: every package, runtime and certificate bundle, with its version. When a flaw is announced, the SBOM says which releases contain it.
• A signed firmware or build image is the sealed box. Its hash is certified when it is uploaded, so a distributor, a device or an auditor can check that what they received is exactly what was built.
• A signing key is the seal itself. Its private half stays on the server. Its public half is published, so anyone can check a receipt, a mandate or a certificate without asking the issuer.

CRM Sync publishes all three. Anyone can check a mandate offline in a browser on the verify plane, against the public keys at /.well-known/jwks.json. The app's own SBOM is public, and firmware images go to the firmware vault. The vault gives each image its own encryption, an upload certificate, grant-gated downloads, and a hash-chained ledger of every grant, denial and download.

Business summary: the verify plane and the firmware vault

The need. After a breach, three groups ask for proof, not reassurance. Customers and partners want to know a receipt or permission is genuine. Distributors and device owners want to know a firmware image is the one that was built. Regulators and insurers want to know who had access while the flaw was open. Under the EU Cyber Resilience Act, those answers are due in 24 hours (early warning), 72 hours (notification) and 14 days (final report) from 11 September

1. A business that answers from email threads and storage links misses those deadlines.

What it replaces: a signed installer behind a link, a support inbox for "is this genuine?", and an incident report assembled by hand. What it does not replace: patching. The records prove what happened; the fixes in the timeline below still have to be applied.

Firmware identity: the part-number gap

Signed records assume you can say what a record is about. For firmware, that is harder than it looks. A buyer orders by manufacturer part number (MPN). Firmware is tied to the device by technical identifiers instead, and there is no standard link between the two. The mapping usually lives in the manufacturer's internal systems.

Where each identifier lives today:

The gap. The authoritative MPN ↔ firmware version ↔ firmware hash mapping sits inside the manufacturer's ERP and PLM systems. The public, cryptographic artifacts — capsules, SUIT manifests, CoRIM, platform certificates — speak in GUIDs and model strings that do not map cleanly to orderable part numbers. A distributor, an integrator or a buyer validating devices has no signed way to answer: this MPN, at this revision, should be running exactly these firmware hashes.

That is a catalog and identity-resolution problem as much as a security one, and signed records close it:

• A signed registry row that binds MPN, revision, firmware version, full SHA-256 and the linked SBOM, verifiable offline against a published key. The firmware vault already signs product, version, digest and SBOM in each upload certificate; carrying the MPN and revision on that row is what closes the gap for a buyer.
• An as-of read: "which firmware should this MPN have been running on 1 March?" is a question about history, answered from the ledger.
• Actor identity: who certified the mapping — the manufacturer, a programming distributor, an integrator — is provenance.

A trusted third-party issuer, eMudhra-style, could plausibly publish such mappings. The eMudhra incident is also the caution: the issuer's own keys must come from a sound random source, and the mapping must stay verifiable when the issuer is distrusted — which is why records should be signed with keys you can retire and republish, not only chained to a public CA.

See it working: the Protected Firmware Asset Management and Download Service vaults each image under its own key, certifies every upload, grants every download, and records each event in a hash-chained ledger — with SBOMs linked per image and certificates that verify against a public JWKS. The requirements behind it are in the AI Trust Framework Requirements.

The breaches, on one timeline

Details and sources are in Entitlement Security and in reporting on eMudhra by The Hacker News and Help Net Security.

What eMudhra teaches about signing keys

Who eMudhra is. eMudhra is an Indian digital-trust company. Its main lines of business:

• India's largest licensed certifying authority. Under India's IT Act it issues Digital Signature Certificates, which people and companies use to sign official filings: income tax, GST returns, company filings and government e-tenders. This is the core of the business.
• eSign. An online signing service built on Aadhaar, India's national digital identity.
• emSign, its publicly trusted CA brand. Its roots sit in the Chrome, Mozilla, Apple and Microsoft trust stores, so it can issue TLS and code-signing certificates that browsers accept worldwide. This is the part the incident hit, and one of the few Indian-owned roots in those programs. What failed was emSign's key generation, not its software or its algorithm: the 30 April 2025 ceremony for eight intermediates under emSign ECC Root CA - G3 produced computable keys. The emSign root key itself was not reported as weak.
• Trust software for others. Certificate-authority and authentication products for governments, banks and enterprises, in India and abroad.
• A listed company, public in India since 2022 and expanding into the Middle East, Africa, Southeast Asia and the US.

eMudhra says TLS is about 1% of its revenue, and its shares fell about 20% after the disclosure. Both numbers make the same point. A small, rarely run ceremony got little scrutiny, yet the failure hit the company's whole product, because what it sells is trust. India's Digital Signature Certificates run under India's own CA licensing rather than the browser root programs, so as far as has been reported they are not directly affected.

The keys were not stolen. They were computable. The ceremony used certified hardware security modules and still produced weak keys. A key is only as strong as the randomness it was made from, and an audited process is not a substitute for checking the output. Four properties keep a signing key's failure small:

Two of the eight distrusted intermediates issued code-signing certificates. Software and firmware signed under them lost their proof of origin with the chain. A vendor has to re-sign, and every customer has to trust the new signature. Images held in the firmware vault also carry their own upload certificate: the image's full SHA-256, its version and its SBOM, signed with an Ed25519 key that CRM Sync publishes. That certificate does not depend on any public CA, so a CA incident does not void it. Anyone can still check an image on the verify plane. It is a second, independent record, not a replacement for the vendor's own code signing.

LiteLLM is the reason signing keys never sit in an application environment. Both poisoned releases searched for signing keys and .env files. A key held as a platform secret and used only by the signing service is not on the disk the payload reads.

Signing keys you control: Xano encryption, AI binding and Cloudflare EdDSA

Every trusted CA can vouch for every domain. Certificate issuance is concentrated. In July 2024 W3Techs counted Let's Encrypt at about 64% of certificates on the top websites, GlobalSign about 24%, Sectigo 6%, GoDaddy 4% and DigiCert 2% (W3Techs, via Wikipedia). eMudhra is not in that top five, yet browsers trusted its intermediates exactly as much as the largest CA. A trust store is flat: the smallest root in it can issue a certificate for your domain. You can't choose which CAs other people's software trusts, so the keys that matter most should not depend on a public CA at all.

The stack splits the work so that a public CA secures only the connection, and everything that proves identity, authority or origin uses keys you hold:

Why the work is split this way. Xano's security library generates RSA keys and elliptic curve keys on the NIST curves (P-256, P-384, P-521), and its JWS example signs with HS256, a shared secret. Ed25519 signing therefore stays in the Cloudflare Worker, and Xano does what it does best:

• encrypting rows and fields
• sealing the session as a JWE
• applying row-level rules before data leaves the database

Each side holds keys the other never sees:

• A leaked Xano encryption key does not let anyone sign a mandate.
• A leaked Worker key does not decrypt a customer row.

What this means after eMudhra:

1. Fix trust first: update pip, certifi, uv, Node and base images, as in Python and Docker after eMudhra. This repairs the one layer that depends on a CA.
2. Narrow which CAs may issue for your domains. A DNS CAA record names the CAs allowed to issue for a domain, and Certificate Transparency monitoring alerts you to any certificate issued anyway. Neither stops a browser from trusting a bad CA, but together they shrink and expose the window. Instructions are in CAA records.
3. Leave your own keys alone unless they were exposed. Xano encryption keys and Worker Ed25519 keys were never issued under emSign, so eMudhra gives no reason to rotate them. Rotate on their own schedule, or after an exposure like LiteLLM, through the key ceremony.
4. Keep agents on mandates, not keys. An agent that holds only a signed mandate has nothing a CA failure or a stolen environment can turn into new authority. See AI binding.

Sources: Xano security functions; W3Techs SSL certificate authority usage.

Layered encryption with Rust and WebAssembly: security additions shaped for AI callers

Why AI callers change the shape of the problem. An agent's requests are well formed, fast and plentiful. A prompt injection doesn't arrive as obviously malformed input. It arrives as a valid-looking tool call with an attacker's arguments: a different order id, a larger refund, a field the form never had. No single control catches all of that, so each layer below answers one question and refuses on its own. None of them tries to judge intent.

Encryption answers who can read a value, a signature answers who wrote it and whether it changed, and the Rust shape check answers whether this request is one the system ever declared. Encoding (Base64) answers none of these: it only gets bytes through a text channel.

What the Rust layer looks like. The allowed calls are a closed list. Serde refuses any tool or field that isn't on it, and the mandate's limits are checked against typed values rather than strings:

#[derive(serde::Deserialize)]
#[serde(tag = "tool", deny_unknown_fields)]
enum AgentCall {
    ReadOrder   { order_id: u64 },
    RefundOrder { order_id: u64, amount_cents: u32 },
}

fn admit(body: &[u8], mandate: &Mandate) -> Result<AgentCall, Refusal> {
    if body.len() > 16 * 1024 { return Err(Refusal::TooLarge); }
    let call: AgentCall = serde_json::from_slice(body).map_err(|_| Refusal::Shape)?;
    match &call {
        AgentCall::RefundOrder { amount_cents, .. } if *amount_cents > mandate.max_refund_cents =>
            Err(Refusal::OverMandate),
        _ => Ok(call),
    }
}

The call is refused rather than repaired. A prompt-injected "refund 500 dollars" against a 50-dollar mandate fails at the type and limit check, before any database or model sees it.

Why Rust and WebAssembly for this layer:

• The enum is the allow-list. A tool that isn't declared can't be represented, so there is no "unknown action" branch to forget.
• Bytes and text stay apart. Ciphertext and keys are Vec<u8>, and text is a String that must be valid UTF-8. Ciphertext can't slip into a text field, and a key can't land in a log as if it were a message.
• The Wasm sandbox has no filesystem and no network. The check sees only the bytes it is handed, so even a bug in it can't reach a secret.
• One check, many surfaces. The same crate compiles for the Worker, Shopify Functions, the desktop build and the browser. Every front end applies the same rule, not a copy of it.
• Dependencies are reviewed. cargo vet stops an unaudited crate version, which is the LiteLLM-style poisoned release, before it ships.

What it doesn't do. Rust prevents memory errors and undeclared shapes, not wrong business rules. A badly chosen mandate limit is still enforced exactly as written. Wasm also adds bundle size and start-up time to the Worker, so keep the checking crate small.

One encryption detail to get right. The example in Xano's documentation uses AES-256-CBC. CBC hides a value but doesn't detect tampering. Where a stored value must not be altered, use an authenticated mode such as AES-GCM, which WebCrypto in the Worker provides, or sign the value as well. Either way, never reuse a nonce or IV with the same key, and keep keys in Xano environment variables or Worker secrets, never beside the data.

These layers sit on the hops in Identity, data and AI tasks, and the binding model behind layers 3 and 4 is in Entitlement Security → AI task binding.

Use-after-free in business terms: where Rust, garbage collection, Cloudflare, Xano and TLS each fit

The analogy. A hotel checks a guest out but doesn't cancel their key card. The room is cleaned and given to a new guest. The old card still opens the door, and the old guest walks in on the new guest's belongings, or leaves something behind for them.

In software, the room is a piece of memory and the key card is a pointer to it. The program releases the room, keeps the card, and a later step uses the card anyway. An attacker who knows this can arrange for their own data to be in the room when the old card is used, and the program ends up doing what the attacker wants.

Why it matters to a business. It is one of the most common ways browsers and older server software get taken over. Many emergency browser updates and a long line of PHP security patches come from it. It is not a configuration mistake a team made. It is built into code written in older languages (C, C++ and the PHP engine itself), and the only fixes are to patch it or move away from it.

Who handles it at each layer. Each part of the stack does a different job, and none stands in for another.

The decision it leads to.

• If you keep WordPress, WooCommerce or Magento: the PHP engine underneath is C, so use-after-free bugs will keep appearing in it. A Rust gate in front, on Cloudflare, turns most hostile requests away before they reach PHP, using code that can't have this bug. Xano permissions then limit what any request that gets through can see. The next section sets this up.
• On the storefront (Webflow, or theme parcels): page scripts are already safe from it, because JavaScript manages its own memory. What you control is how much outside code runs: fewer embeds, pinned scripts with Subresource Integrity, and a strict Content Security Policy. Keep browsers updated.
• What to tell a board: this is a defect in old code, not something to configure away. Shrink how much of that code faces the internet: Rust at the entrance, garbage-collected code on the page, and permission checks on every record. Most of these patches then become routine maintenance instead of an emergency.

When the break meets an integration platform: Celigo, MuleSoft and Boomi

A use-after-free is how an attacker gets in. It gives them no new permissions: it hands them the permissions the broken program already had. So how much they take depends on what that program, and everything connected to it, can reach. Integration platforms are where that reach usually grows.

Celigo, MuleSoft and Boomi reach an on-premises or self-hosted database through an agent or connector that holds a database login: Boomi's Atom, MuleSoft's Database Connector, Celigo's on-premise agent. That login can usually run any query its database user is allowed to. A "daily sync" can therefore just as easily be a daily full copy of the database into another company's cloud.

Where the break happens, and what the attacker inherits:

The point is the combination. A use-after-free is a defect in C and C++ code that no setting removes. A broad login and a daily full copy turn one memory bug at one hop into the whole customer base, at every place the copy lives.

The fixes split the same way.

• Make a break less likely: a Rust gate in front of PHP, PHP and MySQL kept patched, and no open database port.
• Make a break smaller, without dropping the integration platform:
• A scoped login. Read-only, on views that expose only the columns the job needs, never the base tables.
• Changes, not copies. Change data capture or an outbox table, so only changed rows move, each with its timestamp and consent state.
• Push from the source. The source writes to a signed event bus and the platform subscribes, the service-bus pattern in The plugin in the middle.
• A gate between the agent and the data. A tunnel to an endpoint that checks consent and scope, not an open database port.
• Retention on the platform side. Short log retention, and payload logging turned off for personal data.

With those in place, a use-after-free at any one hop yields only what that hop was allowed to see.

How RuBAC with Xano entitlements sits on top of memory safety

Rule-based access control (RuBAC) and memory safety answer different questions. Memory safety asks: does the program do only what its code says? RuBAC asks: should this request be allowed at all? Each layer in the table assumes the one beneath it holds.

Layers 5 to 8 run on top of layers 1 to 3. A rule is code. If a use-after-free breaks the process that evaluates the rule, the attacker runs as that process and can skip the rule. So where a rule runs matters more than how it is written:

The design rule: keep the code that might break (C, C++, PHP and third-party plugins) in a different memory space from the code that decides access (Xano rules, a Rust gate, a Worker), and give the breakable side the narrowest entitlement it needs. A memory bug at the bottom of the stack then can't rewrite the rules at the top. It can only ask them questions, and they still answer per request.

The short definition is in the Vocabulary under Use-after-free (UAF).

If you have to keep Magento, WooCommerce or WordPress: reinforce in place with Rust and parcels

Not every team can migrate this year. Contracts, extensions, staff skills and budget can keep a PHP store where it is. The store can still reach AI-grade security without a rewrite. You don't make PHP safe for agents; you stop agents and untrusted input from reaching PHP directly, and you move the parts that matter out of it one module at a time.

The shape: PHP stays the origin for what it already does well, such as the catalogue pages, the theme and existing extensions. Everything around it is reinforced:

Shopper or agent
  → Cloudflare: WAF, Access, Turnstile
  → Worker: Rust shape gate (Wasm), mandate check, rate limits
      ├─ unchanged routes → PHP origin over a Cloudflare Tunnel (no open inbound port)
      └─ parcel routes    → Xano: identity, rows, entitlements, encryption
  ← the PHP theme renders the page; parcels inside it fetch live data from the Worker

Layer 1. Put a Rust gate in front of the PHP routes agents and attackers use

The gate is a Worker route with a Rust crate compiled to WebAssembly. It parses each request into the shapes the store declares, under a size cap, and refuses everything else before PHP parses a byte. It doesn't change the PHP code.

An agent never calls PHP with a store credential. It calls the Worker with a signed mandate, the gate admits a declared call, and the Worker makes the PHP or Xano call on its behalf. That is the layered model above applied to an estate you keep.

Layer 2. Replace plugins with parcels in the theme

A parcel is one self-contained module dropped into existing theme code. It has four parts, one per layer of the stack, and none of them lives inside PHP:

PHP renders a placeholder and nothing else. It never holds the API key, never stores the data and never decides who may see it. A vulnerable plugin can't leak what PHP never had.

petite-vue or HTMX:

• petite-vue (about 6 KB) for values that react in the browser: a points balance, a live price or stock count, a configurator, consent preferences.
• HTMX (about 14 KB) for lists and forms the server renders: order history, reviews, a support form. The Worker returns an HTML fragment and HTMX swaps it in.

One parcel, three PHP themes. The same loyalty balance in WordPress, Magento and on a Webflow page:

<?php // WordPress or WooCommerce theme: template part, or a hook such as woocommerce_after_add_to_cart_form ?>
<div class="crm-parcel points" data-parcel="points" v-scope="Points()" @vue:mounted="load()">
  <span class="points__value">{{ balance }}</span> points
</div>

<?php // Magento: app/design/frontend/<Vendor>/<theme>/Magento_Catalog/templates/product/points.phtml ?>
<div class="crm-parcel points" data-parcel="points" v-scope="Points()" @vue:mounted="load()">
  <span class="points__value">{{ balance }}</span> points
</div>

<!-- The same markup in a Webflow embed, plus one shared behavior script -->
<script type="module">
  // a self-hosted, pinned copy of petite-vue on your Worker, loaded with Subresource Integrity
  import { createApp } from "https://your-worker.example/vendor/petite-vue.es.js";
  createApp({
    Points: () => ({
      balance: "–",
      async load() {
        const r = await fetch("https://your-worker.example/parcels/points", { credentials: "include" });
        this.balance = r.ok ? (await r.json()).balance : "–";
      },
    }),
  }).mount();
</script>

An HTMX parcel needs no script of its own beyond HTMX. The Worker returns the rendered list, and only for the signed-in customer:

<section class="crm-parcel orders" hx-get="https://your-worker.example/parcels/orders"
         hx-trigger="load" hx-swap="innerHTML">Loading your orders…</section>

Parcels that replace common plugins:

Two security details for parcels

• Content Security Policy. petite-vue evaluates its template expressions with new Function, so it needs 'unsafe-eval' in the page's CSP. Keep its expressions to bound data, never to text a user wrote. Where a page must run under a strict CSP, use HTMX with htmx.config.allowEval = false and no hx-on handlers, or put the parcel in a Web Component with its own policy.
• Credentials and origin. A parcel calls the Worker with the customer's session cookie, set HttpOnly, Secure and SameSite. The Worker allows only the store's own origins in CORS. Keys stay in Worker secrets and Xano environment variables, never in the theme, and never in wp_options or core_config_data.

Rollout order

1. Gate first. Put the Worker and Rust gate in front of the API routes, and move admin paths behind Access. Nothing in PHP changes.
2. Close the origin. Serve PHP through a Cloudflare Tunnel so nothing can bypass the WAF and the gate.
3. Parcel the plugin with the most data. That's usually loyalty, reviews or forms. Ship it as a parcel, turn off the plugin, and export, check and delete its tables.
4. Repeat, one plugin at a time. Each parcel removes a PHP attack surface and a store of customer data.
5. Decide later. Once the data lives in Xano and the behavior lives in parcels, PHP renders pages and little else. Replacing it then is a theme change, not a data migration.

Status: the forms.js parcel, the /forms/<type> Worker route and the <crm-*> Web Components are built. The Rust gate crate, a shared parcel loader and the parcels other than forms are a pattern, not built.

CAA records: name the CAs that may issue for your domain

What a CAA record is. A CAA (Certification Authority Authorization) record is a DNS record that lists the certificate authorities allowed to issue certificates for your domain. Every publicly trusted CA must check it before issuing. With no CAA record, any CA in any trust store may issue for you. That includes emSign, the eMudhra brand whose eight intermediate keys were exposed. A CAA record that doesn't list emSign (emsign.com) tells every CA that follows the rules not to issue for you under it.

What it does and doesn't do:

• It does stop a careful CA from issuing for your domain when the CA isn't on your list.
• It doesn't stop a browser trusting a certificate that was issued anyway. A CA whose keys are computable, as eMudhra's were, can skip the check. Certificate Transparency monitoring covers that gap: every trusted certificate is logged publicly, so an unexpected one shows up.
• It doesn't touch email. CAA governs certificates only, so MX, SPF, DKIM and DMARC are unaffected.

One record at the apex covers every subdomain unless a subdomain has CAA records of its own. That includes subdomains pointed at other platforms, such as Shopify, so list every CA that any of your hosts uses before you add the first record. Otherwise the next renewal fails and the site goes down.

Step 1. Find out which CAs issue for you today

You don't need anyone's access for this, because certificates are public:

# Every certificate issued for the domain and its subdomains, from the public CT logs
open "https://crt.sh/?q=%25.example.com"

# The certificate each host is serving right now
for h in example.com www.example.com account.example.com; do
  printf '%-24s ' "$h"
  echo | openssl s_client -connect "$h:443" -servername "$h" 2>/dev/null \
    | openssl x509 -noout -issuer
done

# Any CAA records already published
dig +short CAA example.com

On crm-sync.dev this showed three hosts and two CAs:

Hosts you don't run yourself, such as Shopify customer accounts or a SaaS custom domain, are the ones people forget. Leaving out their CA breaks the next renewal.

Step 2. Choose the records

Use the CA's CAA identifier, not its brand name:

Add each CA twice: issue for ordinary names, and issuewild for wildcards such as *.example.com. Once any issuewild record exists, a CA that isn't listed there can't issue wildcards even if it's listed under issue. For crm-sync.dev the records were:

SSL.com is included because Cloudflare may fall back to it when renewing a proxied host.

On Cloudflare, once the zone has any CAA record, Cloudflare automatically publishes CAA records for every CA its Universal SSL uses. They don't appear in the dashboard list, but they do appear in DNS. After the records above, crm-sync.dev also published comodoca.com (Sectigo) and digicert.com. That's expected, and it's what keeps Cloudflare's own renewals working.

Recommended: an iodef record (0 iodef "mailto:security@example.com") asks CAs to report refused requests to that address. Not every CA does. Use a mailbox that receives mail, and type the value with nothing before mailto:. crm-sync.dev added 0 iodef "mailto:team@crm-sync.dev" on 24 October 2026.

Step 3a. Add them in the Cloudflare dashboard

1. Open DNS → Records for the domain.
2. Click + Add record.
3. Set Type to CAA and Name to @.
4. Set Flags to 0.
5. Set Tag:
6. Only allow specific hostnames for issue
7. Only allow wildcards for issuewild
8. Send violation reports to URL for iodef. The form's summary still says the value "can issue certificates"; for this tag it only sets where reports go
9. Enter the CA domain name, for example letsencrypt.org.
10. Click Save. Repeat for each row.

Add the CAs your hosts are using right now first. A gap of a few minutes doesn't matter, but if the first record names only one CA, every other CA is refused until the rest are in.

Step 3b. Or add them with a scoped token

The key-ceremony rule applies: the person makes the credential, and it never enters an AI session or a file.

1. Create the token: My Profile → API Tokens → Create Token → Custom token.
2. Permissions: Zone → DNS → Edit.
3. Zone Resources: Include → Specific zone → your domain.
4. Expiration: 7 days.
5. Check the summary before creating it. It must read <your domain>, DNS: Edit with an end date. If it says All zones across all accounts or No expiration, go back and fix it. A token like that can rewrite the DNS of every domain you own, for good.
6. Run this in your own terminal. The token is read without being shown and is cleared at the end:

   read -s "CF_TOKEN?Paste token: "; echo        # zsh; in bash: read -rsp "Paste token: " CF_TOKEN
   ZONE_ID=<zone id from the domain's Overview page>
   DOMAIN=example.com
   for v in 'issue pki.goog' 'issue letsencrypt.org' 'issue ssl.com' \
            'issuewild pki.goog' 'issuewild letsencrypt.org'; do
     set -- ${=v}                                    # bash: set -- $v
     printf '%-10s %-16s ' "$1" "$2"
     curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
       -H "Authorization: Bearer $CF_TOKEN" -H "Content-Type: application/json" \
       --data "{\"type\":\"CAA\",\"name\":\"$DOMAIN\",\"data\":{\"flags\":0,\"tag\":\"$1\",\"value\":\"$2\"}}" \
       | grep -o '"success":[a-z]*'
   done
   unset CF_TOKEN

Every line should end in "success":true. A record that already exists returns false, and you can ignore it.

1. Delete the token straight away: API Tokens → ⋯ → Delete.

Step 4. Verify

# The records, from the authoritative nameserver and from a public resolver
dig +short CAA example.com @$(dig +short NS example.com | head -1)
dig +short CAA example.com @1.1.1.1

# Every host still serves a valid certificate
for h in example.com www.example.com account.example.com; do
  curl -s -o /dev/null -w "$h %{http_code}\n" -A "Mozilla/5.0" -H "Accept: text/html" "https://$h/"
done

A 2xx or 3xx on every host means nothing broke. The real test is the next renewal: note each certificate's expiry date and check again after it. Some Shopify hosts return 406 to a bare curl with no Accept header, which is not an outage.

Step 5. Keep it current

• Before adding a custom domain for a new service, find out which CA it uses and add that CA first.
• Watch the CT logs for your domain. Cloudflare's Certificate Transparency Monitoring (SSL/TLS → Edge Certificates) emails you when a certificate is issued for it. crt.sh is the manual check.
• Record the change in the key and certificate ledger with the date and who made it, like any other trust decision.

Step 6. Test it red, then green

Verifying by eye once is not the same as knowing it stays right. Write the expected CAA down as a test before you add the records, run it and watch it fail (red), then add the records until it passes (green). Keep the test and run it on a schedule or in CI. It then fails the day a record is deleted, a new host starts using a CA you didn't list, or a value is mistyped.

The script below needs Node 18 or later and nothing else. Set DOMAIN, HOSTS and EXPECTED to your own values. It reads CAA over DNS-over-HTTPS and the certificate each host actually serves, and checks one against the other:

// caa-check.mjs: node caa-check.mjs   (exit 0 = all green)
import tls from "node:tls";

const DOMAIN = "example.com";
const HOSTS = ["example.com", "www.example.com"];
const EXPECTED = ["pki.goog", "letsencrypt.org", "ssl.com", "comodoca.com", "digicert.com"];
const ISSUERS = [[/google trust/i, "pki.goog"], [/let's encrypt|isrg/i, "letsencrypt.org"],
  [/ssl corp/i, "ssl.com"], [/sectigo|comodo/i, "comodoca.com"], [/digicert/i, "digicert.com"],
  [/emudhra|emsign/i, "emsign.com"]];

const res = await fetch(`https://cloudflare-dns.com/dns-query?name=${DOMAIN}&type=CAA`,
  { headers: { accept: "application/dns-json" } }).then((r) => r.json());
const caa = (res.Answer || []).filter((a) => a.type === 257).map((a) => {
  const [, flags, tag, value] = a.data.match(/^(\d+)\s+(\w+)\s+"(.*)"$/) || [];
  return { flags: +flags, tag, value, ca: (value || "").split(";")[0].trim() };
});
const of = (tag) => caa.filter((r) => r.tag === tag);
const issuerOf = (host) => new Promise((ok, fail) => {
  const s = tls.connect({ host, port: 443, servername: host }, () => {
    ok(s.getPeerCertificate(true)); s.end();
  }).on("error", fail);
});

const results = [];
const check = (name, pass, detail) => results.push({ name, pass, detail });

check("CAA exists", caa.length > 0, `${caa.length} records`);
check("issue lists exactly the expected CAs",
  EXPECTED.every((c) => of("issue").some((r) => r.ca === c)) && of("issue").every((r) => EXPECTED.includes(r.ca)),
  of("issue").map((r) => r.ca).join(", ") || "none");
check("issuewild restricts wildcards", of("issuewild").length > 0, of("issuewild").map((r) => r.ca).join(", ") || "none");
check("iodef is a valid URL", of("iodef").some((r) => /^(mailto:\S+@\S+|https?:\/\/\S+)$/.test(r.value)),
  of("iodef").map((r) => JSON.stringify(r.value)).join(", ") || "none");
for (const host of HOSTS) {
  const cert = await issuerOf(host);
  const ca = (ISSUERS.find(([re]) => re.test(cert.issuer.O)) || [])[1] || "unknown";
  check(`${host} certificate is from a permitted CA`, of("issue").some((r) => r.ca === ca), `${cert.issuer.O} (${ca})`);
  let c = cert, chain = [];
  while (c && !chain.includes(c.fingerprint256)) { chain.push(c.fingerprint256); if (/emudhra|emsign/i.test(c.issuer.O)) chain.emsign = true; c = c.issuerCertificate; }
  check(`${host} chain has no emSign`, !chain.emsign, `${chain.length} certificates`);
}

for (const r of results) console.log(`${r.pass ? "GREEN" : "RED  "}  ${r.name} — ${r.detail}`);
process.exit(results.every((r) => r.pass) ? 0 : 1);

On a domain with no CAA yet, every line is red. After Steps 2 and 3, every line should be green. The iodef line is the one that catches the easiest mistake: the dashboard field accepts a leading space, and " mailto:…" is not a URL, so a CA that follows RFC 8659 ignores the record and reports nothing.

What the CRM Sync harness checks for crm-sync.dev. The same checks run in the CRM Sync test harness alongside the custody checks they support. Green means the control is built and holding; red means a known gap, kept failing on purpose until it is built:

The red rows match the gaps in The plugin in the middle.

Sources: RFC 8659 — DNS CAA Resource Record; Cloudflare — CAA records; crt.sh Certificate Transparency search.

The number 4, and what row-level controls still protect

What an elliptic-curve key is. An elliptic curve is a fixed, published mathematical curve, with a fixed starting point on it, G. "Multiplying" a point by a number means stepping along the curve that many times by a special rule. The rule is easy to run forwards: given a number, finding the point is fast. It is effectively impossible to run backwards: given only the point, there is no shortcut to the number. That one-way step is the whole key pair:

• the private key is the number
• the public key is the point it lands on

Elliptic-curve keys are much shorter than RSA keys of the same strength, which is why certificates, phones and Ed25519 signatures use them.

eMudhra's keys were elliptic-curve keys, not RSA. An elliptic-curve private key is a single number, d. The public key is that number multiplied by a fixed, published starting point G: public key = d × G. Picked at random from roughly 2^256 possibilities, d cannot be worked back from the public key.

**For one of eMudhra's keys, d was 4.** Anyone could compute 1×G, 2×G, 3×G and 4×G and match the published key on the fourth try. A researcher recovered all eight keys from the public certificates in under a second, so all of them were tiny. openssl rand -hex 32 draws d from the full 2^256 range. Size was never eMudhra's problem; the randomness was missing.

Why elliptic curves? The business reason. Elliptic-curve keys give the same security as RSA for far less size and work:

Smaller and faster means less bandwidth, quicker page loads, longer battery life and lighter servers, on every handshake and every signature.

• A certificate authority, eMudhra included, builds an elliptic-curve hierarchy for the usual reasons. eMudhra has not, as far as we have seen, stated its own.
• Customers want lighter, faster HTTPS.
• Browsers and TLS 1.3 already favour elliptic curves.
• A new elliptic-curve root keeps the CA in browser root programs for the next decade as RSA roots age.
• Everything it issues and revokes gets cheaper.
• Nostr chose Bitcoin's own curve (secp256k1) and signatures (BIP-340).
• Tested libraries, hardware signers and wallets already existed, and the same key sits beside Lightning payments.
• A 32-byte public key is short enough to be the handle and to fit in a QR code.
• Relays verify every post, so small, fast signatures keep a network nobody owns cheap to run.
• A phone makes a key instantly, with no sign-up server.

The curve was not the mistake. Weak randomness breaks RSA just as surely:

• Debian, 2008: an OpenSSL bug left only about 32,000 possible keys on Debian systems.
• "Mining your Ps and Qs", 2012: researchers found thousands of internet devices whose RSA keys shared primes, which made them computable.

Elliptic curves are slightly less forgiving of carelessness, though. ECDSA leaks the key if a single signature's random number is weak, which is why newer systems prefer EdDSA. The next cost is shared by both: a large quantum computer would break elliptic curves and RSA alike. The post-quantum replacements (ML-DSA for signatures, ML-KEM for key exchange) have much larger keys and signatures, so the size advantage that drove these choices will shrink in the migration.

RSA, elliptic curve and EdDSA — what each one is. RSA and elliptic curve are two kinds of key. EdDSA is not a third kind: it is a way of signing with an elliptic-curve key.

Nostr uses a third elliptic-curve signature, Schnorr (BIP-340). It is a close relative of EdDSA that also mixes fresh randomness into the one-time number.

In one line each:

• RSA: big keys built on prime numbers. Well understood and widely supported, but heavy.
• Elliptic curve: small keys built on a curve. The same strength, much lighter.
• EdDSA: a modern way to sign with an elliptic-curve key that removes the most common way to lose it.

None of them survives a key made without real randomness — eMudhra's failure, and Debian's RSA failure in 2008 — and a large quantum computer would break all three. The post-quantum replacement for signatures is ML-DSA.

Which layer broke. A certificate authority's key does not encrypt anything of yours. It vouches for other people's certificates. Whoever held eMudhra's keys could issue a "valid" certificate for any domain — a Xano instance, a store, pypi.org — and every client that still trusted emSign would accept it.

What still holds if a connection is intercepted. Nothing at the row level fixes a broken CA — updating trust stores does. But row-level design decides how much an intercepted connection can give away:

• Sealed identity. The session token is encrypted (JWE), and only the data plane decrypts it. Someone reading the traffic cannot read or alter the claims inside. They can replay the whole token, which is why logout writes it to a denylist checked on every read, and why sessions are short.
• Row-level authorization. Every read and write takes the caller's identity from the decrypted token on the server — the /auth/me claims and extras — never from a user id the browser sends. A captured session exposes one person's rows, not the table.
• Field-level encryption. A field encrypted with a key the application holds stays ciphertext even when its row is read.
• The exception is a master key. An admin key or a data-plane API key that crosses an intercepted connection has no row limit. That is a layer 1 or layer 6 key in the key layers: rotate it through the ceremony, from a patched machine.

EdDSA vs. token gating — proof is not permission. Two ideas get blurred together:

A signed token used as a gate is still a bearer credential: whoever holds it, gets in. So signing is never the whole answer. The gate adds:

• a short expiry
• revocation checked on every read
• an audience, so a token minted for one service is refused by another
• spending caps and scopes on agent mandates
• server-side role checks on each row

Signing makes a token trustworthy. Gating decides what that trust is worth. The same split runs through web3 "token gating", where holding an NFT opens a door: the chain proves the token is genuine, not that the wallet holding it is the person it was meant for.

Why EdDSA, after eMudhra. eMudhra's chain used ECDSA, the older elliptic-curve signature scheme. ECDSA needs a fresh random number for every signature. Reuse one, or let it be guessable, and the private key can be computed from two signatures — a well-known failure. EdDSA derives that number from the key and the message, so a weak random source at signing time cannot leak the key.

EdDSA would not have saved eMudhra. Their failure was in making the key, and every scheme needs real randomness at key generation. That is why CRM Sync's Ed25519 keys come from the platform's cryptographic random source inside the Worker, never from a hand-run script.

Nostr: when the key is the identity

Nostr, the messaging protocol Jack Dorsey championed and funded, uses the same kind of key as eMudhra — elliptic curve — but makes the opposite choice: the key is the identity and the permission at once.

• The account is a key pair on secp256k1, Bitcoin's curve, with Schnorr signatures.
• The public key (npub…) is the handle. The private key (nsec…) is the password, the account and the signature, all at once.
• Every post is a signed event. Relays — the servers — check the signature and pass the event on. No server issues the identity or can take it away.
• The optional NIP-05 name (name@domain) is only a file on a website that points a name at the key.

What Nostr shows about everything above.

• Same kind of key, opposite outcome: Nostr is randomized where eMudhra was not. Both use elliptic-curve keys — a private key that is a single number — though not the same curve.
• Key creation. Each Nostr app makes its key on the user's device, normally from the operating system's cryptographic random source, so the number is one of roughly 2^256 — not 4.
• Signing. Nostr's Schnorr signatures (BIP-340) build each signature's one-time number from the key, the message and fresh random bytes. A weak random source at signing time therefore cannot leak the key — the ECDSA failure that eMudhra's chain is exposed to.
• The limits. The protocol cannot check how a key was made. There is no ceremony and no authority, so a badly written app could still produce a weak key, and nothing in the network would notice.
• Scale, not kind. A weak Nostr key exposes one person. A weak CA key exposes every site that CA can vouch for. eMudhra's central ceremony was supposed to be the careful one, and it failed once, for everyone.

The lesson is the same for both: the type of key was never the problem. What matters is whether the private key came from real randomness, and whether anyone checked.

• Pasting an nsec into apps is the key-ceremony problem. Every app it is pasted into — including AI tools and browser extensions — can take the identity for good. Nostr's answer is a remote signer (NIP-46, a "bunker"): the key stays in one place, and apps ask it to sign. That is the ceremony's rule — the thing that holds the key is not the thing that asks for its use.
• Proof is not permission — unless you choose to merge them. Nostr merges them on purpose, and gains censorship resistance and independence from any platform. The price is a leaked key that cannot be revoked and no row-level limit on what it can do. Commerce cannot pay that price: a stolen customer or admin key has to be stoppable today. So CRM Sync keeps the signature as proof and leaves the decision to a server that can say no.
• eMudhra touches Nostr only at the edges. Post signatures do not depend on certificate authorities, so a forged certificate cannot forge a post. But relays are reached over secure WebSockets and NIP-05 names are fetched over HTTPS. An intercepted connection could fake a name or hide posts — it could not sign as you.

Details are from the Nostr specifications (NIP-01, NIP-05, NIP-19, NIP-46) — see the NIPs repository.

Which custody model fits an agent? Participant-held keys (Nostr) and edge-held keys (CRM Sync) are compared side by side — identity versus authority, rotation after a compromise, and enterprise controls — in Key Custody: Two Ways to Give an Agent a Key.

Non-random keys were never safe — AI only shortens the window

Would eMudhra's keys have been fine before AI? No. A private key of 4 is found by trying 1, 2, 3, 4 — a pocket calculator, not a model. The keys were breakable from the ceremony on 30 April

1. Every well-known weak-key failure was weak the moment it was made, and humans found each

one:

What AI changes is the window, not the maths.

• Searching is cheap now. Scanning every certificate in the public CA database or the Certificate Transparency logs for weak keys was always possible. It is now cheap, quick and automated, for researchers and attackers alike. AI-assisted tools are already credited with finding flaws such as php2shell.
• Mistakes no longer sit quietly. eMudhra's keys sat for about 18 months before anyone looked. Today, expect a mistake like that to be found in days, possibly by someone who will not report it.

So checking has to happen when a key is made, not years later:

• generate from a cryptographic random source
• lint the certificates
• test new keys against known-weak patterns
• monitor Certificate Transparency for your domains
• record key fingerprints, so a duplicate or reused key stands out

Security levels, in one table. Strength is counted in bits of security: 128 bits means an attacker needs about 2^128 tries, far beyond any computer that exists. Different key types reach that level at different sizes.

Nostr's security level, plainly.

• On paper it matches CRM Sync's signing: about 128 bits, on a curve that has protected Bitcoin for years.
• In practice, the weak points are operational, not mathematical:
• each app must use a proper random source, and nothing in the protocol checks
• there is no rotation or revocation, so one leaked nsec is permanent
• pasting the key into apps exposes it — the remote signer (NIP-46) exists for that reason
• Message privacy depends on which version an app uses. Nostr's older direct-message encryption (NIP-04) is deprecated for known weaknesses and replaced by NIP-44. Apps still on the old scheme protect less than the signatures suggest.
• The shared limit: a large quantum computer would break Nostr's keys, eMudhra's and CRM Sync's signing keys alike.

The level a key could have is set by its type. The level it does have is set by how it was made and how it is kept. eMudhra had the right type and none of the second.

One architecture under any front end, whatever the platform plan

The controls in this article do not belong to WordPress, Shopify, AEM or a static site generator. They sit in two layers the front end calls:

• Cloudflare at the edge: certificates, the WAF, Access, and Workers for forms, sign-in, signing and consent.
• Xano as the data plane: identity, rows, entitlements and encryption.

The front end renders pages and calls the edge. It never holds a key and never stores a customer row.

Browser ──TLS──▶ Front end (WordPress · Shopify theme · AEM · static 11ty/Astro/Jekyll)
                   │  renders pages; holds no secrets, stores no customer rows
                   ▼
               Cloudflare edge ── certificates (auto-renewed) · WAF · Access · rate limits
                   │  Worker: forms held until confirmed · /auth/me · signing · consent
                   ▼  (secrets live here, set by the key ceremony)
               Xano data plane ── sealed identity · row-level authorization · field encryption
                                  · entitlements · hash-chained records

Why the plan or fee does not matter. Shopify Basic or Plus, WordPress.com or self-hosted, an AEM licence or a free GitHub Pages site — the protection is the same, because none of it runs on the front end's plan:

• the key ceremony and key layers apply to secrets the front end never sees
• forms are held until the inbox confirms, at the edge
• identity is sealed and rows are authorized in the data plane
• certificates renew at the edge

A platform upgrade buys features, not these controls. Changing platform does not lose them either. The front end can be replaced, and the same edge and data plane carry over unchanged, along with their records.

What still depends on the front end:

• Its own runtime must be patched. php2shell on a WordPress origin is still the host's to fix, and the edge only buys time.
• Its theme must not leak. No client-side redirects to other domains, and no keys in theme code.

The working example — one theme, one form, one sign-in across platforms — is in the safer customer option and secure forms on any front end.

The key ceremony: a person makes the key, the AI never sees it

eMudhra shows what goes wrong when keys are made badly. LiteLLM shows where good keys leak: terminal output, shell history, the clipboard, .env files and chat transcripts. Today those are also exactly what an AI coding assistant reads. A key ceremony is the routine that keeps a secret out of all of them.

The rule is simple: a person runs the step that creates the secret, and the AI only prepares, checks and records. The secret goes from the generator straight into the secrets store, through a pipe or a prompt. It is never printed, never pasted into a chat, and never written into a command line.

Directions — OpenSSL and Wrangler, interactive. Run these from the Worker's folder.

Before you start: patch the machine the ceremony runs on. wrangler secret put sends the new key to Cloudflare over HTTPS, and Wrangler runs on Node. If that machine's Node still trusts the eMudhra chains, a fresh key could travel over an intercepted connection. Use Node 22.23.4, 24.22.1 or 26.12.1 or later. If Python is on the machine, follow Python and Docker after eMudhra first.

1. Open your own terminal window, not the AI's. If you work in an AI coding tool, do not run ceremony commands through it. That includes shortcuts that run a command inside the session, because their output becomes part of the conversation.

1. Generate and store in one step, so the value is never displayed:

   openssl rand -hex 32 | npx wrangler secret put ADMIN_KEY --config wrangler.toml --env=""

Wrangler reads the value from the pipe. Nothing is echoed, and the shell history holds the command but no secret.

How big is it? rand -hex 32 means 32 random bytes: 256 bits, written as 64 hexadecimal characters (0–9, a–f). That is 2^256 possible keys, a number 78 digits long. Guessing at a trillion tries a second would take far longer than the age of the universe.

Why it is safer than eMudhra's keys. eMudhra's keys were not short. They were made badly. A wrap-and-unwrap step in the ceremony produced keys with so little real randomness that they could be worked out from the public certificates in under a second. Length is only worth anything if every bit is random. openssl rand takes its bytes straight from the operating system's cryptographic random source, with no extra step between the source and the key. The scale is different too. This secret guards one Worker, nobody else trusts it, and replacing it is one command. A CA key is trusted by every browser, and replacing it took four browser vendors and a root removal.

1. For a secret someone else issued (an OAuth client secret, a payment-provider key), use the interactive prompt:

   npx wrangler secret put GOOGLE_CLIENT_SECRET --config wrangler.toml --env=""

Run the command first. Then copy the secret from the provider's dashboard and paste it at the "Enter a secret value" prompt. Done in the other order, copying the command overwrites the secret on the clipboard, and the command text is stored as the secret.

1. When one secret must go to two systems — say a Xano environment variable and the Worker — write it to a file only you can read, and feed both from that file:

   ( umask 077; openssl rand -hex 32 | tr -d '\n' > ~/.crm-ingest-key )
   npx wrangler secret put INGEST_KEY --config wrangler.toml --env="" < ~/.crm-ingest-key
   pbcopy < ~/.crm-ingest-key     # paste into Xano, then clear the clipboard:
   pbcopy < /dev/null

1. Check by fingerprint, never by value. The AI can be shown a fingerprint: the first eight characters of a hash, which say nothing usable about a 256-bit key.

   shasum -a 256 ~/.crm-ingest-key | cut -c1-8
   npx wrangler secret list --config wrangler.toml --env=""   # names only, never values

Then check behaviour. The old key is refused, and the new key works. Any check refers to the file ($(cat ~/.crm-ingest-key)) and never repeats the value, so the AI's command and output both stay clean.

1. Record it, then delete the file. File the record: who ran it, which secret, when, the fingerprint and the check result. Then delete any file you made.

Signing keys are not made this way at all. The Ed25519 keys behind mandates and receipts are generated by WebCrypto inside the Worker. Rotation is a server action. The private half never exists on a laptop, and only the public half is ever published. OpenSSL and Wrangler are for shared secrets: admin keys, webhook secrets, API keys from other providers.

You manage the keys you hold — create, rotate, revoke — and the rest of the plane from one console: Configuration System. Every change lands in the audit ledger. The full ceremony, with roles and the record format, is in Rotate a Key in Three Steps and the Key Management Lifecycle.

Dev, Stage and Prod: a separate ceremony for each, least privilege everywhere

A key that works in two environments is one leak away from both. Each environment gets its own keys, made in its own ceremony, and no value is ever copied from one to another. The fingerprints prove it: if Stage and Prod show the same eight characters, something was copied. The full Dev → Stage → Prod workflow, with roles for consulting teams and stakeholders, is in the Key Management Lifecycle.

Passing --env explicitly matters. With more than one environment defined, a bare Wrangler command falls back to the top level, which is right only by accident.

Least privilege: each person, machine and test gets the smallest key that does its job.

• Production secrets are set on-premises only. The Cloudflare API token that can write Prod secrets belongs to the key holder. It is scoped to the one account and the Worker permissions it needs, and it can be locked to the company network's addresses with Cloudflare's client-IP filter on API tokens. Admin paths sit behind Cloudflare Access with a device check. A token copied off the network does not work.
• Supply-chain tests never see a secret. Dependency scans, crate audits and the static test harness run on every pull request, so they treat every change as untrusted. CRM Sync's pipeline shows the pattern:
• the job token can only read the repository
• actions are pinned to commit hashes, not movable tags
• installs run with --ignore-scripts
• the contract tests touch only public and fail-closed paths, so they are safe on pull requests from outside forks

The one credential the test job holds is a single-repository, read-only token for a private test dependency.

• Deploy is a separate job with separate rules. It runs only on a merge to main, never on a pull request, and it goes through the same deploy guard and test gate as a deploy from a laptop. Worker secrets are not stored in CI at all. They are set by the ceremony, so a poisoned dependency in CI has nothing to steal.
• Reviewers approve; they do not hold keys. Design, content and compliance roles sign off on what ships. Only the release engineer, whose role carries the release permission, promotes it. The agency or consulting team gets a rotatable key, never the root key and never the command line.

Trust setup: decide once, per environment, what each system will believe. Most of the breaches on the timeline were failures of trust, not of encryption. Write the trust list down and keep it under version control:

The configurator (Configuration System) shows which environment you are in and which keys you hold. Environment rules, the key-handoff matrix and the RACI are in the Key Management Lifecycle.

Key layers: what each key protects

Not every key is equal. Each layer protects something different, is held by someone different, and costs something different to replace. Knowing which layer a key belongs to tells you who may hold it and what to do the day it leaks.

A correction we found in our own setup. The vault and the encrypted configuration fields are meant to have their own master secret, ENVELOPE_MASTER_KEY. When it is not set, the code falls back to JWT_SECRET — and in CRM Sync's production it is not set. So one secret is doing two layers' jobs:

• it signs sessions (layer 4)
• it is the root of the encryption keys for vaulted firmware and tenant configuration

Rotating JWT_SECRET today would not only sign everyone out; it would also leave every vaulted image and encrypted configuration field unreadable until they are re-wrapped. That is exactly the "one key spanning layers" problem instruction 2 below warns about.

The fix is a planned migration, not a one-line change:

1. Create ENVELOPE_MASTER_KEY through the ceremony.
2. Re-wrap every existing envelope under it.
3. Only then leave JWT_SECRET to sessions alone.

Setting the new secret without step 2 would lock the existing data at once, because the code would immediately start deriving keys from it. Until the migration is done, treat JWT_SECRET as a layer 1 key.

Instructions — run the layers in this order:

1. List every key you have and give it a layer. If you cannot say which layer a key protects, it is probably layer 1 by accident. An "all-access" token used for convenience is the common case.
2. Split anything that spans layers. One key doing root work and tenant work means a tenant leak becomes a platform leak.
3. Give each layer its own holder. Agencies and contractors get layer 2 or 3, never layer 1. Reviewers and AI assistants get none.
4. Give each layer its own environment copy. Dev, Stage and Prod never share a value at any layer.
5. Set a rotation date per layer — the root on staff change and at least yearly, the others every 90 days and on any incident — and record each rotation by fingerprint.

Without Cloudflare

The ceremony does not need Cloudflare. Wrangler is only Cloudflare's way into its secrets store, and the rule is the same everywhere: create the secret with OpenSSL and send it straight into the store, through a pipe or a file only you can read.

Check each command against the provider's current documentation before relying on it.

Shared hosting is the exception. cPanel-style PHP hosting usually has no secrets store at all. Keys end up in wp-config.php or a .env inside the web root, readable by anything that runs there — including a php2shell exploit. You cannot run a proper ceremony on it. Move secrets outside the web root with chmod 600 today, and plan the move off it.

The other Cloudflare pieces in this article have equivalents:

To use the Cloudflare route instead, the free plan is enough to start:

1. Sign up at dash.cloudflare.com/sign-up. Workers are on the free plan and run on a workers.dev address, so you do not need a domain.
2. Install Wrangler in your project: npm install --save-dev wrangler. Use Node 24.22.1 or later, which rejects the eMudhra chains.
3. Sign in from your own terminal: npx wrangler login. This opens the browser and stores a login token on the machine. On a shared machine, run npx wrangler logout after the ceremony. For production, prefer an API token scoped to the one account, locked to your network's addresses.
4. Run the ceremony above, one environment at a time.

To manage the keys you hold in CRM Sync — create, rotate, revoke — open the Configuration System.

TLS automation: replacing a certificate is a renewal, not a project

Browsers received the eMudhra block automatically. Much other software did not:

• Go binaries, which need a rebuild with a fixed Go
• anything using Python's certifi bundle
• the curl that ships with macOS
• older cloudflared
• origin servers running their own mutual TLS
• containers with a baked-in trust store

Two habits close that gap:

• Let the platform issue and renew certificates. On Cloudflare, edge certificates are issued and renewed automatically. A certificate that chains to a distrusted root is replaced by the next renewal, not by a ticket. A site that buys and installs certificates by hand has until 27 October to get off the emSign hierarchy.
• Treat the trust store as a dependency, and list it in the SBOM. certifi, webpki-roots, the Node and Go versions and the container base image all decide which roots a program trusts. When they are listed, "who still trusts the bad root" is a search across releases.

Python and Docker after eMudhra: what to do this week

Python is the slowest runtime to recover from eMudhra, for a structural reason: pip carries its own copy of certifi and always trusts it, on top of the operating system's list. There is no setting to turn it off, and --cert, PIP_CERT and REQUESTS_CA_BUNDLE only add certificates. A fully patched operating system still leaves an old pip trusting the bad chain. The risk is an intercepted connection serving a fake PyPI, and the only fix is a new pip.

Versions are from the Python packaging announcement on discuss.python.org.

Upgrade pip from the pinned wheel, not with a bare pip install -U pip. An unpatched pip fetching its own replacement is exactly the connection an attacker would intercept. The announcement gives a pip install command naming the 26.2.2 wheel by its SHA-256 hash, so a substituted file is refused. Then upgrade certifi and uv. This is the hash-pinned install from the supply-chain table, doing the job it exists for.

Every virtual environment, not just the system Python. Each venv has its own pip. A new venv still gets the old bundled pip from ensurepip until CPython ships its fix (GH-159910). So upgrade pip right after creating any venv, and in CI after every python -m venv.

Docker: a patched host does not patch an image. The certificates are baked in at build time.

• Official python images: the maintainers rebuilt them on 21 October (docker-library/python #1142), with the expedited 3.13.17, 3.14.9 and 3.15.1 releases. The 3.11 and 3.12 images keep an older pip, because upstream does not change pip in those security releases. Add the pinned-wheel pip upgrade to your Dockerfile, or move to 3.13 or later.
• Rebuild without the cache, so the new base and certificates are actually used: docker build --pull --no-cache. A cached layer quietly keeps the old trust store.
• Node and Go images on Debian also need ca-certificates updated inside the image, so curl, wget and git stop trusting the chain.
• List the trust store in the SBOM (pip, certifi, ca-certificates, base-image digest), so "which images still trust emSign" is a search, not an audit.

And the LiteLLM root cause shows why the key ceremony keeps the AI out. On 22 October LiteLLM disclosed how 1.107.0 was published:

• The tokens were in logs. An internet-exposed internal LiteLLM deployment held GitHub CLI OAuth tokens. LiteLLM says an AI coding tool's response bodies can carry the user's GitHub CLI token, and those bodies were logged.
• The attacker used them to publish. With three developers' tokens, including one with workflow rights and an organisation owner's token used to switch off branch protection, the attacker pushed the release through a lookalike repository. It was signed and published like a real release.
• The stolen cloud keys were used within hours. Stolen AWS credentials were being tested about four and a half hours later.
• Release rights had just been widened. LiteLLM had temporarily expanded them for two engineers two days earlier.

Every link in that chain is covered in this article:

• AI traffic carries secrets, so gateway logs must not store request and response bodies.
• Developer tokens should be scoped to one repository and to read access unless a release needs more.
• Owner tokens should not sit on everyday machines.
• Release rights widened "temporarily" need an end date, like any other key.

The order: fix trust first, then rotate keys

New keys do not fix eMudhra. The two problems sit at different layers:

A forged pypi.org is accepted before any of your keys is involved, so rotating them cannot stop it. The order:

1. Fix trust first. Update Node, pip (from the hash-pinned wheel), certifi and uv on every machine and in every venv, and rebuild images. This is the eMudhra fix.
2. Then ask whether anything leaked while you were exposed. If a pip install, a wrangler secret put or a deploy ran over an untrusted network while the old trust was in place, a secret could have crossed an intercepted connection. Rotate those secrets with the ceremony, from the patched machine.
3. If nothing points to exposure, rotate on the normal schedule. eMudhra alone does not require new keys.

The ceremony is the clean-up and the habit, not the cure. Run on an unpatched machine, it would send fresh keys over the same untrusted connection it is meant to protect.

Clean up after exposure: rebuild, don't purge

A package downloaded through an intercepted connection has the right name and the right version, and nothing on disk records that its download was faked. So you cannot find the bad ones by looking, and uninstalling packages one at a time does not work. Rebuild instead, from hashes recorded before the exposure.

1. Fix pip first, as above: 26.2.2 from the hash-pinned wheel, then certifi and uv, on a network you trust. A new Python alone does not fix existing environments, because every venv keeps its own pip.
2. Delete each virtual environment and recreate it from a lockfile with hashes: pip install --require-hashes -r requirements.txt, or uv sync from a uv.lock. Every package is checked against its recorded hash, and a substituted file is refused. No lockfile yet? Generate one with the patched pip, then rebuild from it.
3. Clear every cache a tampered file could hide in, or the rebuild reuses it:
4. pip: pip cache purge
5. uv: uv cache clean
6. Docker: docker build --pull --no-cache
7. any shared wheelhouse or internal package mirror
8. Rotate secrets only where there is a reason. A malicious package runs code while it installs, so removing it afterwards does not undo what it read. If installs ran over an untrusted network while the old pip was in place, rotate what those environments could reach, using the ceremony and the patched machine. If every install ran on networks you trust, rebuilding is enough. No attack has been reported.
9. Scan what you rebuilt against published advisories: pip-audit, or osv-scanner across lockfiles and images. A scanner finds known-bad versions, not swapped files. Steps 2 and 3 handle swapped files.
10. Re-certify what you ship. Upload each rebuilt image to the firmware vault: it gets a new digest, a new certificate and a new SBOM link. The vault's ledger then lists who downloaded the earlier image and when, which is the list a customer notice or a Cyber Resilience Act report needs. Partners confirm the new image on the verify plane.

The exception is LiteLLM 1.107.0. That release was malicious, not merely exposed. Anywhere it was installed:

• treat the environment as compromised
• do not start Python there to clean up, because starting Python re-runs the payload
• rebuild from 1.106.2 pinned by digest
• rotate everything that environment could reach

Does cargo vet help? For Rust, yes, but at a different layer from eMudhra:

• Against an intercepted download: Cargo already checks every crate against the checksum in the committed Cargo.lock. A Rust build from a lockfile was protected the way a hash-pinned pip install is. Keep the lockfile committed and build with --locked.
• Against a poisoned release — the LiteLLM kind, published by a stolen account: this is what cargo vet is for. CI fails on any crate version that no trusted, published audit covers, so a hijacked new release is stopped before anyone has reported it. Neither checksums nor scanners can do that, because the bad release is "genuine" when it ships.
• For eMudhra itself: Rust programs that use webpki-roots need its fixed release and a rebuild. cargo update -p webpki-roots, then cargo vet asks for that new version to be audited or certified before it ships. That is the review step working as intended.

Python has no direct equivalent of cargo vet yet. The nearest substitutes:

• hash-pinned lockfiles
• a delay before adopting new versions
• review of each dependency change in the pull request

That is the Python row of the supply-chain table above.

AI binding: the agent proves its permission on every call

An AI agent in this architecture acts under a signed mandate: who may act, on what, up to what amount, and until when. The mandate is checked against the published key on every call, so:

• an agent holding a mandate signed by a retired key is refused
• a mandate altered after signing fails verification
• a stolen environment yields keys that have already rotated

Bound tasks and TLS hops are covered in Identity, data and AI tasks. Signing is what lets a third party — an auditor, a partner platform, Google — check that work without trusting us.

Records on a timeline that scales out

Every grant, check, firmware download and consent change is appended to a hash-chained ledger. The ten requirements that ledger meets, the rotation calendar, and how erasure requests are handled without breaking the chain are in the AI Trust Framework Requirements. Each entry locks in the one before it, so history can be visibly broken but never quietly edited. The ledger is not one long chain. Each tenant and each stream is its own thread: firmware for one product, mandates for one agent, consent for one store.

• Threads do not wait on each other. A new store or product line adds a thread, not contention on a shared one, so the record scales horizontally.
• Order within a thread is set by a sequence number, not a clock. Two simultaneous writes cannot be mistaken for tampering.

On a breach day, the incident dates in the table above are laid over those threads. "Everything signed by key X between 30 April 2025 and 17 October 2026" or "every image served with an SBOM listing certifi older than the fix" becomes a filter, not an investigation. To see one session's thread across consent, identity, purchases and engagement, open See a session's story on the verify plane.

The benefit, control by control

What signed records do not do. An SBOM does not patch anything. A signature proves who sealed a file, not that the file is safe. A ledger shows that history was broken; it does not prevent the break. Developer machines and CI runners — where Node, Wrangler and Python run — still need the runtime updates in the timeline. More background: What Is an SBOM? Who Uses This? Everyone. and Firmware, SBOM & the Cyber Resilience Act.

Its role in AI-first resilience: for QA and growth marketing teams

AI agents and answer engines now act on a store's behalf and decide what customers see. A journey that quietly breaks — a consent banner, a checkout step, a tracking tag, a product feed — costs sales before anyone notices. The verify plane gives the two teams who catch those breaks the same signed record to work from.

QA and testing teams

AEO and tracking growth marketing teams

See a session's story on the verify plane →

No silver bullet: rotate, randomise, look forward

No single control in this article would have stopped every incident in it. TLS did not stop the checkout hijack. MFA did not stop nOAuth. A WAF does not stop a poisoned package, and a package audit does not stop an unverified sign-up. What holds is layers that change faster than an attacker can map them — so the defence has to move on a schedule, and be tested in ways the attacker cannot predict.

Build to the standard that is coming, not the one being enforced today. Every requirement in the table at the top of this article was announced years before it was enforced, and the merchants hurt worst in October 2026 were the ones still meeting the old version. The ones already on the calendar: the Content API for Shopping shut down on 18 August 2026; EU AI Act transparency obligations apply from 2 August 2026; the EU Cyber Resilience Act's reporting obligations began on 11 September 2026, with full obligations from 11 December 2027; GS1 Sunrise 2027 moves retail point of sale to 2D barcodes. Each date, with its source, is in The Compliance Calendar.

What it costs

What this does not claim. It is not a certification and not legal advice. Delisting counts come from public trackers, not Shopify. "Unconfirmed" means exactly that. Prices are deliberately absent: they vary by provider, region and traffic.

What to do next

Ordered by exposure — card data first.

1. Payment pages. Inventory every script, remove every client-side redirect, set the CSP, run a private-window test checkout. Owner: store owner with the developer.
2. Delisted and hijack-listed apps. Remove or replace; revoke their Shopify scopes after cutover. Owner: store owner.
3. PHP runtime. Patch for php2shell and keep the WAF rules in Block. Owner: hosting or DevOps.
4. Origin. Cloudflare in front, Full (strict), Access on every admin path, tunnel, inbound ports closed. Owner: DevOps.
5. Containers. One pinned image per app, secrets injected at runtime. Owner: developer.
6. Identity and data. /auth/me sidecar; a database role per service; RLS or filtered views; personal fields encrypted with a key generated for this deployment. Owner: developer with compliance.
7. Checkout logic. Scripts and checkout.liquid patterns rebuilt as Rust Shopify Functions. Owner: Shopify developer.
8. Google. Merchant API migration with loyalty, reviews, comparison and conversions in the same pass. Owner: marketing operations with the developer.
9. Content. Static publish first, EmDash pilot second. Owner: content lead.
10. Records. Keep an SBOM for every release, move firmware and build images from storage links into the firmware vault, and give partners and auditors the verify plane instead of a support inbox. Owner: developer with compliance.
11. Decommission the shared VM after the tunnel has carried production traffic for a full billing cycle. Owner: DevOps.

Evidence basis: public vendor, platform and standards documentation linked inline, read on 22 October 2026. Not a certification.