Malicious code served to storefronts through OC Quantity Breaks & Limit

Incident date: 11 September 2026
Last updated: 18 September 2026
Status: Contained. Independent investigation in progress.

Summary

On 11 September 2026, an unauthorised third party gained access to our infrastructure and inserted malicious JavaScript into the Custom JS field of campaigns in OC Quantity Breaks & Limit. On affected stores, the script intercepted shoppers who clicked through to checkout, read their cart contents, and sent them to a fraudulent checkout page hosted outside Shopify.
The code was capable of being served for 8 hours 31 minutes. We removed it and secured the affected systems on 11 September.

We are sorry.
This was not something we saw coming, and learning that our own app had been used against the shoppers our merchants serve was hard to take. We are fixing it as fast as we can, and doing everything we can to limit the impact on your store and your customers.
On behalf of everyone at Orichi, we apologise to every merchant affected by this.
We also intend to come out of this with a stronger system. The weaknesses this exposed are being closed, and the section below sets out exactly what is changing and by when.

Stores

Our review of affected stores is being carried out together with third party company, the independent security firm conducting our incident response and penetration testing. We are not publishing a store count until that review is complete, because a number we later have to correct is worse than no number.
We will contact every affected merchant directly with the exact exposure window for their store as soon as the review concludes. Until you hear from us, please treat the general window above as the period to check against. If you want us to check your store ahead of that, leave us your information here and we will prioritise it.
https://forms.gle/TbeE6mxPcRK3cmxb9

App availability

OC Quantity Breaks & Limit is currently delisted from the Shopify App Store. We have engaged third party company to carry out an independent incident response investigation and a full vulnerability assessment and penetration test of our infrastructure and the app. The app will remain delisted until those reports are complete, shared with Shopify, and every finding addressed. We will publish the outcome here.

Shoppers

The script ran in the shopper's browser and did not produce a matching server-side record in Shopify, so an exact count of affected shoppers cannot be established from Shopify's data. Based on our own server and CDN logs, the affected script was served 4,182 times across 1,937 storefront sessions. We are publishing that figure as the upper bound of potential exposure rather than a count of shoppers who actually entered details.

Data that may have been exposed

• Cart contents, read through Shopify's /cart.js endpoint
• The storefront URL the shopper was on, including any query parameters

Data that was not affected

• Shopify admin credentials and sessions. Our investigation found no unauthorised logins to merchant accounts, and the attack path we identified did not require one.
• Order, customer and payment records held inside Shopify
• Cookies and browser storage
• Payment details entered on the legitimate Shopify checkout, which the script bypassed rather than read

Timeline

All times UTC+7.

What happened

How the attacker got in

Our application exposed an internal endpoint, getShopInformation, which returned the access token (this token has permission to create/delete/edit discount campaigns). That endpoint did not require authentication. Knowing a store's domain was sufficient to retrieve its token.
Separately, our internal support administration tool allowed a session to be established for an arbitrary store domain. The attacker used this to impersonate merchant stores without ever touching a merchant's Shopify account. All requests were routed through Tor, and the exit node addresses carry no attribution value. We cannot identify who was responsible.

How the code reached storefronts

OC Quantity Breaks & Limit lets merchants attach custom JavaScript to a campaign through a Custom JS field. That JavaScript is stored with the campaign and served to the storefront when the campaign renders.
Using the tokens obtained above, the attacker called our campaign API to create a campaign titled ORICHI127 BATCH 260911 and wrote the payload into its Custom JS field. Our theme app extension then served that payload to storefronts as designed.

What the script did

The payload registered click and submit listeners on the window in the capture phase. For each event it inspected the originating element's link target, form action, name, id and visible text, and matched them against a pattern for the word "checkout". Events that did not match passed through untouched.
On a match it cancelled Shopify's own checkout navigation, requested the cart through /cart.js, base64-encoded the cart and storefront context into a URL parameter and sent the browser to a fraudulent checkout page at a domain resembling a misspelling of shopify.com.
It did not run on Shopify's checkout itself. Shopify's checkout is served from a separate domain where third-party scripts do not load, which is why the payload intercepted shoppers before they reached it rather than operating inside it.

Technical details

Published so that merchants and their developers can search their own systems and verify our findings independently.

Indicators of compromise

What the payload could read and transmit

The table below is derived from the payload source, not inferred from logs. The payload contains no API call capable of reaching the items marked as not accessed.

Cart data transmitted included product and variant identifiers, titles, quantities, unit and line prices, image URLs, subtotal, total and currency.

Two points we want to state rather than leave you to discover.

• The redirect target used http:// rather than https://. The encoded cart data travelled over an unencrypted connection for at least the first request.

• The payload transmitted the full storefront URL the shopper was on. If any of your storefront URLs carry personal data in query parameters, that data was transmitted with it.

What we did immediately

Immediate removal: The affected script was isolated and permanently deleted from our CDN servers within 85 minutes of the first merchant report.

Full codebase audit: We reviewed our entire source code, servers, and database. The malicious code has been removed and the entry points used in the attack have been closed. An independent incident response investigation and penetration test by third party company is underway, and we will publish the results.

Infrastructure security: We revoked all existing deployment keys, enforced 2FA across all dev accounts, and set up automated file-integrity monitoring that alerts us within minutes when storefront-facing files change outside a deploy.

Placed a legal hold on the relevant logs and records so they are preserved for the ongoing investigation

Reported the incident to Shopify and provided our findings

What we are changing

Each item below has a date. We will update this table as items ship, and we expect to be held to it.

We will post progress against this table here at 30 and 90 days, whether or not every item is complete.

What you should do

Now, before we contact you

• Check whether any shopper reached checkout on your store during the window above. If none did, your shoppers were not exposed regardless of what our review finds

When we contact you

• Every merchant will hear from us once the review with Shopify concludes, whether or not their store was affected
• Affected merchants will receive the exact exposure window for their store, and log extracts on request

Get an update on your store

You do not have to wait for our general notification. Both options below go to the same engineering team handling this incident.

Have us check your store

Leave your store URL and email. Our developers will check your store against our records, tell you whether an affected campaign was live and when, and email you our findings. You will also be added to the notification list for every update on this incident.
https://forms.gle/TbeE6mxPcRK3cmxb9

Talk to us directly

If you would rather go through it with someone, book a call. Useful if you are deciding what to tell your own customers, or if you need log extracts and technical detail for your records.

Requests from merchants with checkout traffic during the exposure window are handled first.

Questions we have been asked

Was my Shopify account compromised?

No. Our investigation found no unauthorised logins to merchant accounts, and the attack path we identified did not require one. The compromise was contained within our infrastructure.

Did the attacker read data stored in Shopify?

No. The script read cart contents in the shopper's browser through a public storefront endpoint. It did not access order history, customer records or stored payment data.

Is the app safe to use now?

The malicious code is removed, the entry point is closed, and the monitoring described above is in place. We will not tell you the app can never be compromised again, because no one can honestly say that about any software. What we can say is what we now detect, how fast, and how quickly we will tell you.

Why did you publish this rather than handle it quietly?

Shoppers may have had card details taken. Merchants cannot warn them without knowing the window. A private resolution would have served us and not you.

If anything here is unclear, or you need detail we have not published, write to me directly.

Alex
Co-founder, OC Quantity Breaks Order Limit

Updated on: 18/09/2026