Regarding the PHP vulnerabilities disclosed on October 21, 2026 (CVE-2026-109618 and CVE-2026-109619), we have reviewed their impact on all of our Shopify apps: Japan Order CSV, Delete Me, Mockingbird, Mypage Blocks, and B2E, our employee sales app. None of these apps use PHP, so they are not affected by these vulnerabilities. Merchants using our apps do not need to take any action, such as updating or changing settings.

We continuously monitor published vulnerability information and will notify our users promptly if any impact is expected. If you have any questions about this matter, please contact the support desk for the app you use.

Definition

A processing technique in which a system or program repeatedly queries a target device, server, or job at regular intervals to check its status or retrieve data. Rather than waiting to be notified, the caller actively asks "is it done yet?" on its own schedule.

In practice, the key design parameters are the interval between requests, retry counts, timeouts, and the condition for giving up. Too short an interval increases load on the target system and consumes API quota; too long a one delays detection of state changes.

Background

There are two classic use cases.

  • Liveness and health checks: a monitoring component sends periodic requests to a server or endpoint and judges health from whether — and how — it responds.
  • Waiting for asynchronous work: when a job is handed to another system and the next step must not start until it finishes, the caller keeps asking for status until completion is detected.

The counterpart approach is event-driven design, where the side that changed state pushes a notification (a webhook, for example). Polling remains the practical choice when no push mechanism is available, when you need a safety net against missed notifications, or when a step must be confirmed complete before the workflow moves on.

Flagship's Involvement

In integration and batch designs we prefer event-driven mechanisms such as webhooks wherever they exist, and combine polling for two jobs: confirming a step is really complete before the workflow moves on, and covering for notifications that never arrive. When we implement it, the interval, maximum retries and timeout are made explicit, and the design stays within Shopify's API rate limits.

A concrete case: on a Shopify Plus project, refunds/create webhooks went missing for split payments combining 3-D Secure and gift cards. Working through it with Shopify Developer Support, the recommendation we adopted was a reconciliation job that periodically polls refund data instead of relying on webhook retries. Waiting for asynchronous work such as Bulk Operations to finish is the other classic polling situation. Our own corporate site detects newly published articles by polling the feed hourly rather than via webhooks — a deliberate choice, because a missed poll is trivial to recover from.