Marketing Tools Are Japan's New Breach Surface: Website Builders, Campaign Tools and Email Services

Key takeaways

• In October 2026, attackers broke into several marketing tools used by Japanese companies: the no-code website builder Studio, the B2B marketing platform ferret One, the SNS campaign tool OWNLY, and a string of email delivery services.
• Each holds data that companies collect for marketing: form submissions, mailing lists, campaign entries. Some also hold keys to other services. Studio stored its customers' API keys and Google Sheets credentials.
• The problem is not new. In 2020, Rakuten found that a cloud sales management system had been misconfigured for nearly five years, leaving up to 1.49 million records reachable from outside. In 2025, attackers stole data from hundreds of companies' Salesforce instances, not through Salesforce itself but through apps connected to it, such as the sales chat tool Salesloft Drift.
• In our view, these are the shadow SaaS of marketing departments: bought quickly, often outside IT's review, and rarely included in data inventories. Each is a vendor whose breach becomes the customer's breach under Japan's privacy law.
• The usual controls have gaps here. When data moves from one cloud service to another through a connected app, it never passes through the company network, so DLP and CASB do not see it. Single sign-on helps, but staff can still sign up with a local password. In our view, that leaves rules, enforced where the tools allow, and checks at contract time.
• Practitioners should inventory marketing tools, set retention for form and campaign data, check sharing and guest settings, and treat integration keys stored in these tools as credentials.

A month of marketing tool breaches#

Tool	What it does	What happened	Whose data
Studio	No-code website builder	Attackers exploited a vulnerability to reach its cloud environment and read the key that decrypted stored data	Form submissions on customers' websites, plus customers' API keys and Google Sheets credentials. Customers disclosing include the Digital Agency (up to 13,323 submissions), Luup and Raksul
ferret One (Basic)	B2B marketing platform for websites and lead generation	A flaw in an internal admin function let an attacker create an account there on October 14; found on October 26	Customers' login email addresses; six accounts logged into without authorization
OWNLY (SmartShare)	SNS campaign tool for prize draws and coupons	A flaw in its file upload function; monitoring caught it on October 16, but an alert setting delayed the developers	X and LINE user names and IDs of people who entered Mos Burger campaigns
Email delivery services	Newsletters, alerts and notices	Attackers reached the vendors' own access into the environments they run for each customer	Mailing lists: a cumulative 51.63 million records at Yumil Link alone

Customers are now publishing their own notices. Money Forward, the fintech company, said on October 26 that submissions to the inquiry forms of group companies' websites built on Studio may have leaked, including 4,150 from its recruiting site. Its main services were not affected, and it has moved the forms to another system. Mos Burger has been affected twice in a week through two different vendors: OWNLY for its campaigns, and Value Design, the platform behind its prepaid Mos Card.

The older problem: settings that left data open#

Not every exposure needs an attacker to break in. In December 2020, Rakuten, Rakuten Card and Rakuten Edy said a cloud-based sales management system they used had been set up so that data could be reached from outside. An outside security expert had flagged it in November. Up to 1.49 million records were exposed, including store and corporate contact details, business loan applications and service applications, some going back to January 2016. Rakuten found that 614 records had actually been accessed.

Similar cases followed. In January 2021, Japan's National center of Incident readiness and Strategy for Cybersecurity (NISC) warned critical infrastructure operators that misconfigured access settings in Salesforce products could expose data. In May 2021, the Personal Information Protection Commission (PPC) said leaks had been reported since late 2020 from guest user settings on sites that take member registrations or bookings, and asked companies to check who owned records created before a July 2020 change.

The issue has not gone away. In January 2026, Google's Mandiant released a tool, AuraInspector, after finding that many incidents in Salesforce's customer-facing Experience Cloud came from administrators' settings rather than sophisticated attacks: overly broad guest permissions, self-registration left on, and record lists visible without logging in.

The newer route: apps connected to the CRM#

Since 2025, attackers have found a way around both the CRM and its settings: the apps connected to it. Marketing and sales tools are commonly linked to a company's Salesforce through OAuth tokens or "connected apps", which let them read and write CRM data without anyone logging in.

• A fake app, approved by phone. In June 2025, Google's Threat Intelligence Group described a group it calls UNC6040 that phoned employees posing as IT support and talked them into approving a modified version of Salesforce's Data Loader as a connected app. The attackers then exported the data, and in some cases demanded money months later.
• Stolen tokens from a sales chat tool. In August 2025, attackers used OAuth tokens stolen from Salesloft Drift, an AI chat and sales tool, to export data from customers' Salesforce instances for about ten days. Google said they searched the stolen data for credentials, such as cloud access keys and passwords, and advised every Drift customer to treat all tokens connected to it as compromised. Google, Cloudflare and Zscaler were among those that disclosed impact. Salesforce and Salesloft revoked the tokens and removed the app.
• And again. In November 2025, Salesforce revoked tokens for apps made by the customer success platform Gainsight, which said it had itself been reached with tokens stolen in the Drift breach. The attackers claimed to have reached more than 200 Salesforce instances.

Salesforce has said none of these involved a flaw in its platform. We have not found Japanese companies disclosing breaches from these campaigns, but the tools involved are sold in Japan, and the pattern is the same as in this month's cases: the weak point was a third-party tool that held a key to customer data.

Why marketing tools#

In our view, four things make these tools a growing part of the attack surface:

• Who buys them. Marketing teams pick website builders, form tools, campaign tools and email services to move fast, often on a credit card, sometimes without IT or security review. They may never appear in the IT asset list.
• What they hold. Inquiry forms, recruiting forms, prize draw entries, mailing lists and webinar sign-ups are all personal data. Studio's case shows they can also hold API keys and tokens for a company's CMS, spreadsheets and other services, which are credentials in everything but name.
• How long they keep it. The Digital Agency's leaked submissions dated from 2021 to early 2023. Form and campaign data tends to stay in the tool long after anyone needs it.
• Who builds them. Many are run by smaller vendors that grow fast and add features such as file uploads, public pages and guest access, each of which needs careful design. OWNLY's entry point was a file upload function; ferret One's was an internal admin function.

The two failure modes, a vendor's flaw and a customer's setting, look different but end in the same place. Under Japan's privacy law, a company that hands personal data to a contractor must supervise it (Article 25), and a breach at the vendor is usually the customer's breach to report and notify. That is why each Studio customer has had to decide whether to report, and why Studio arranged joint reports with the PPC.

Where the usual controls stop#

Companies that have invested in data protection usually rely on three controls. In our view, connected apps get around the first two, and the third has a gap of its own.

• DLP (data loss prevention) inspects data as it leaves a device or passes through the company's network. When a marketing tool reads CRM data through an OAuth connection, the data goes directly from one cloud to another. It never touches an employee's PC or the company proxy, so DLP has nothing to inspect.
• CASB (cloud access security broker) sees how employees use cloud services, inline or through those services' APIs. Some products can list the apps connected to Salesforce or Microsoft 365. But a connection approved once keeps working in the background, and inline monitoring of employees' traffic does not see the traffic between the two services.
• Single sign-on (SSO) is the most effective of the three. If every tool is reached through the company's identity provider, IT knows which tools exist, can require multi-factor authentication, and can cut access when someone leaves. But many SaaS tools also let anyone sign up with an email address and a local password, and a marketing team can do exactly that without IT knowing.

That leaves rules: a policy that marketing and other departments use SaaS only through SSO, that local accounts are not allowed, and that connecting an app to the CRM or other core systems needs approval. Where a tool can enforce SSO-only login or restrict who may approve connected apps, turn it on, so the rule does not depend on everyone remembering it.

And it leaves contracts. The time to ask a vendor how it protects your data is before you sign, not after its breach notice. In our view, a short checklist at purchase does more than any tool afterward: whether the service supports SSO and can disable local logins, MFA and IP restrictions on the admin side, what OAuth permissions its integrations request, how long it keeps data and how you can delete it, how its own staff access your environment, and how fast it will notify you, including whether it supports joint reports to the privacy regulator.

One thing OWNLY got right#

OWNLY's campaigns collected no names, addresses, phone numbers or email addresses, only the X or LINE handles needed to run a draw. That limited what could leak. The trade-off is that SmartShare has no way to contact the people affected, so it has published its notice in place of individual notices, and asks entrants to check whether they took part. In our view, that is a reasonable trade: for a prize draw, collecting less is worth more than being able to send an apology.

What this means for practitioners#

• Find the tools. Check single sign-on logs, expense claims and corporate card statements for SaaS subscriptions, not only the IT asset list. Ask marketing, HR and PR which form, campaign and email tools they use.
• Make SSO the rule. Require SSO for every SaaS tool that supports it, prohibit local accounts, and turn on SSO-only login where the tool allows it.
• Check at contract time. Add a short security checklist to SaaS purchasing, including for tools bought by marketing: SSO, MFA, IP restrictions, OAuth permissions, retention and deletion, vendor staff access, and breach notification.
• Record what each holds. For every tool: what personal data, how many records, how far back, and which keys or tokens to other services are stored in it.
• Set retention. Delete form submissions, campaign entries and old mailing lists on a schedule. Export what you need into systems you control.
• Check sharing and guest settings regularly, especially in CRM and customer portals. Salesforce's own Health Check and tools such as AuraInspector can help.
• Lock down the admin side. Turn on multi-factor authentication and IP restrictions for every marketing tool's admin screen, as OWNLY has now asked its customers to do.
• Treat integration keys as credentials. Rotate API keys, webhooks and spreadsheet connections when a tool is breached, and avoid giving a marketing tool broader access than it needs.
• Review connected apps in your CRM. List the apps and OAuth tokens connected to Salesforce or similar systems, remove the ones you no longer use, limit what each can read, and restrict who can approve new ones. Train staff that IT support will not ask them to approve an app by phone.
• Keep secrets out of CRM records. Passwords and access keys pasted into support cases or notes were what the Drift attackers were looking for.
• Close tools when campaigns end. A finished campaign's tool still holds its entries.
• Put marketing tools in your incident plan: who on your side decides, and how you will work with the vendor on joint reporting and notices.

Japanese terms at a glance#

Japanese	Reading	Meaning
お問い合わせフォーム	otoiawase fōmu	Inquiry form
ノーコード	nō kōdo	No-code
キャンペーンツール	kyanpēn tsūru	Campaign tool
設定不備	settei fubi	Misconfiguration
ゲストユーザー	gesuto yūzā	Guest user
委託先の監督	itakusaki no kantoku	Supervision of contractors
本人通知の代替措置	honnin tsūchi no daitai sochi	Substitute for individual notice