Shelly Store UK, an independent reseller of Shelly smart home kit, has warned shoppers that malicious code found on its web shop may have exposed their payment cards. It is a familiar pattern, and a reminder that even the smallest UK web shops are worth a skimming crew’s time.
What happened
Shelly Store UK, an authorised reseller of Shelly smart home equipment, has begun contacting customers about a possible theft of payment data. According to the company’s notice, as reported by The Register on 30 October 2026, the retailer acted after a warning from its payment provider, Stripe. Its own investigation then turned up what it described as unauthorised software on both its website and its server.
The notice, as reported by The Register, says the firm cannot tell whether customer data was actually accessed or copied. Even so, it is writing to everyone who ordered during a window it has not defined. Payment card details, names, billing addresses and contact details may be at risk. The company says it has removed the malicious code, tightened access controls, applied security updates, put ongoing monitoring in place and reported the matter to the Information Commissioner’s Office (ICO).
One customer told The Register they had placed a single order with the shop on 12 October. A £221.28 transaction appeared on their card, dated 26 October and made in Australia, and they had already opened a dispute with their card provider a few hours before the breach email landed on 27 October. That account is unverified and does not prove the card was taken from this shop, but the timing is uncomfortable.
Shelly Group, the manufacturer, has distanced itself from the reseller. A Shelly spokesperson told The Register the shop is “not part of, owned by, or directly affiliated with Shelly Group”. The manufacturer says it does not run the site. Shelly Store UK did not respond to The Register’s questions, and at the time of writing I could find no incident notice on the shop’s own website or independent reporting beyond The Register’s exclusive.
The technical picture
The company has not said how the attackers got in, what the code did or how long it was live. Its notice says the rogue software sat on the server as well as the website, and the data it lists as at risk is what a shopper types into a checkout: payment card details, name, billing address and contact details. That profile fits the pattern the industry calls e-skimming, or Magecart-style attacks, in which an intruder plants code that copies payment details as they are entered and quietly sends them elsewhere.
The company has not said which e-commerce platform its shop runs on. Whatever the stack, the attack surface for a small online retailer typically includes the core software, every plugin and theme, the hosting account and the administrator logins. An attacker who can write to the server can alter the payment form customers see, even when a reputable provider handles the card processing.
It is telling that Stripe spotted the problem first. Processors look for clusters of fraud tracing back to a common merchant. When the merchant learns of an incident from its processor rather than its own monitoring, the skimmer has often been running long enough for stolen cards to be used.
Why it matters for UK organisations
Skimming on small web shops rarely makes headlines, which is why it persists. Thousands of UK businesses trade through self-managed WordPress or similar sites, maintained by one developer or an agency on an occasional basis, with nobody watching for changes to checkout pages.
Under UK GDPR, the ICO expects a reportable breach to be notified within 72 hours, and its guidance stresses that the clock runs from discovery rather than from the date the breach began. Where the risk to individuals is high, customers must also be told without undue delay. Its notice indicates Shelly Store UK has reported to the ICO and is telling customers, though the number affected and the exposure window remain unknown.
Card scheme rules add a second layer. PCI DSS v4.x includes two requirements, 6.4.3 and 11.6.1, aimed squarely at this threat: the first requires merchants to authorise and check the integrity of every script on a payment page, and the second requires a mechanism to detect unauthorised changes to those pages and their security headers. The PCI Security Standards Council warned in its March 2025 guidance that scripts executing in shoppers’ browsers have become “a significant target” for criminals. Small merchants often assume a hosted payment provider takes them out of scope. It reduces the burden, but the pages leading to the payment step still need protecting.
Expert view
When we test small e-commerce sites, the weaknesses that let skimmers in are rarely exotic. Outdated plugins, administrator accounts without multi-factor authentication, shared hosting credentials reused across sites and file permissions that let the web application rewrite its own code are the usual suspects.
In my experience, the bigger gap is detection. Most small retailers have no file integrity monitoring and no baseline of what the checkout should look like, so injected JavaScript can sit undisturbed for weeks. The fact that, on the company’s own account, the processor raised the alarm here suggests the store may have had no mechanism of its own to notice the change.
Where a business says it cannot tell whether data was taken, and a skimmer may have sat on the checkout, the sensible working assumption is that every card entered while it was live is compromised. Customers should act on that basis.
What to do now
If you have bought from Shelly Store UK recently:
- Call your card issuer, explain the merchant has reported a possible compromise and ask about a replacement card.
- Check statements for small or overseas transactions, often used to test stolen cards.
- Treat any call, text or email asking for card details, security codes or one-time passcodes as suspicious, even if it quotes your order.
- Change your shop password and any reused elsewhere.
If you run an online shop, prioritise the following:
- Patch everything (Cyber Essentials: security update management). Keep the platform, plugins and themes current; remove anything unused.
- Lock down admin access (user access control). Enforce multi-factor authentication on CMS, hosting and SFTP accounts, and review who holds administrator rights.
- Harden the server (secure configuration). Stop the web application writing to its own code directories and disable unneeded services.
- Watch the checkout. Deploy file integrity monitoring and a Content Security Policy, and keep an inventory of approved payment page scripts to meet PCI DSS 6.4.3 and 11.6.1.
- Prepare to report. Keep an incident log and know the ICO’s 72-hour expectation before you need it.
Bottom line
Shelly Store UK says it has done the basic things right after the fact: it cleaned up, notified customers and told the ICO. The harder lesson is that it learned of the intrusion from its payment provider, and by then at least one customer says their card was already being abused. For small UK retailers, a hosted payment service is not a substitute for knowing exactly what code runs on your own checkout.
Sources
- The Register: UK Shelly reseller warns payment data stolen after malware found on website
- LavX News: Shelly Store UK warns customers of payment breach after malware found on site
- elhacker.NET: Revendedor británico de Shelly alerta sobre robo de datos bancarios
- ICO: 72 hours – how to respond to a personal data breach
- PCI Security Standards Council: Payment Page Security and Preventing E-Skimming
