Key takeaways

  • GMO GlobalSign's ID management and single sign-on service GMO Trust Login kept files containing customer data in the public storage area it used to serve logo images. Anyone could list the files and download them, with no signature or expiry on the links.
  • The files could be taken from November 2017 until September 15, 2026. Access logs, which only go back to June 2021, show third parties did take them.
  • Files covering 45,030 people at 2,492 companies were taken: names, email addresses, the apps each person was connected to, and attributes such as employee numbers and departments, plus billing contacts. No passwords, MFA data or payment data.
  • The problem was found by an outside researcher through the company's vulnerability disclosure program, not by its own checks. Its regular assessments and penetration tests covered applications and servers, but not the storage.
  • Each of the 2,492 customer companies has to deal with the leak too, including its own report to the privacy regulator.
  • GMO GlobalSign's disclosure is unusually thorough: it corrected its own earlier statements, explained the cause in plain terms and promised monthly progress reports. That is a sharp contrast with how its sister company handled the Onamae.com Desktop Cloud extortion.

What happened#

GMO Trust Login is a cloud service that companies use to manage employee accounts and give them single sign-on to other cloud apps. Administrators can register members, set custom attributes and set passwords for connected apps in bulk by uploading files.

When an administrator ran one of those bulk operations, the service created template files and error files, which contained the data being processed. These temporary files were saved to a storage area that the company had made public around November 14, 2017, to deal with the load of serving customers' logo images. The company's own contract information files were stored there too.

The public area allowed anyone to list its files, and the download links had no signature and no expiry. Anyone who found the area could see every file in it and take them.

On September 14, 2026, an outside security researcher reported the problem through GMO GlobalSign's vulnerability disclosure program. The company blocked access in stages between late that night and the afternoon of September 15. GMO Cybersecurity by Ierae then examined the access logs and confirmed that third parties had taken the files. GMO GlobalSign says they may have been taken for malicious purposes.

What was taken#

Source Companies People Data
Files from administrators' bulk operations 2,184 44,836 Email addresses, names, connected app names, custom attributes such as employee numbers and departments
Contract information files 217 194 Company ID, license count, usage, cancellation date; billing contact's name, address, phone number and email
Companies that could not be identified 91 Administrator accounts since deleted
Total 2,492 45,030

People are counted once per email address. Not included: passwords for Trust Login itself or for the apps it connects to, secret questions and answers, multi-factor authentication data, and payment data.

The figures rose from a provisional 2,007 companies and 37,747 people in the first report, after the company found that its first analysis had missed files and used the wrong criteria.

Timeline#

Date Event
Nov 14, 2017 (approx.) Storage changed to a public area for serving logos; customer files become retrievable
Jun 8, 2021 Earliest access logs; retrieval by third parties confirmed from here on
Sep 14, 2026, 17:48 Researcher's report through the vulnerability disclosure program
Sep 14-15 Access blocked in stages
Sep 16 First report; customers' administrators notified
Sep 20-Oct 23 Investigation by GMO Cybersecurity by Ierae
Oct 7 Second report; guidance on PPC reporting sent to customers
Oct 30 Third and final investigation report
Nov 12 (planned) Final report to the Personal Information Protection Commission

Why nobody noticed#

GMO GlobalSign's own explanation has three parts: customer files were saved by design to the public logo area; that area allowed listing, and links had no signature or expiry; and its regular security assessments and penetration tests covered applications and servers, but not the storage where files were kept. So for nearly nine years, no check it ran looked at the place where the problem was.

The disclosure#

Three things set GMO GlobalSign's notices apart from most Japanese breach notices:

  • It corrected itself. The third report opens with a list of what the first report got wrong: access was blocked over two days, not on the same day; retrieval was confirmed from 2021, not from 2017; the counts were too low.
  • It explained the cause plainly, including that its assessments never covered the storage.
  • It set out what it will do and when. Most measures are due by November 30, and it will publish monthly progress reports until they are done, including in months when nothing was completed, and an annual security report every December.

What it is changing#

  • Design: public files only through a dedicated delivery mechanism, limited to set file types.
  • Development: every feature that handles files must define the data type, storage location, access method, retention period and deletion method; code scanning on every change, with deadlines by severity; security tests on every release.
  • Checks: automated checks for files that should not be in public areas, continuous monitoring of storage settings (in place since October 2), and outside assessments twice a year covering web applications, the whole cloud environment and all internet-facing assets.
  • Retention: retention periods by data type with automatic deletion, and a common component for all file handling (by January 2027).

What we don't know yet#

  • How many files were taken in total, and how many different sources took them
  • Whether anything was taken before June 2021, when the logs begin
  • Whether the files from bulk password setting for connected apps ever contained the passwords being set. The company says passwords for connected services were not included
  • Whether the 2,492 customer companies have all been reached, given that 91 could not be identified

Our view#

Knowing what data is where is the foundation, and it is hard. Every security program says it should know what data it holds and where. In practice, inventories list databases and named systems. The files that leaked here were by-products: templates and error files created while processing an upload. They are exactly the kind of data that no inventory lists, saved wherever was convenient by the feature that made them. Rules on what may be stored where, for how long, and who may read it are necessary, but writing them is the easy part. Keeping every new feature inside them is the hard part, which is why GMO GlobalSign's fixes, a common file-handling component, mandatory design checks and automatic deletion, are about making the rules hard to break rather than restating them.

There were many chances to notice. These files were not created once. In all likelihood, a new one was created each time an administrator at one of thousands of companies ran a bulk operation, for nearly nine years, and none were deleted until September 2026. A logo area filling up with data files and error reports is a visible change, to anyone who looked. Retention limits would have kept the exposure small; a simple check of what file types sat in a public area would have caught it early. The company had access logs from 2021 that showed third parties taking files. As far as its notices show, they were only examined after the researcher's report.

Assessment scope is part of asset management. The storage was outside the scope of every assessment. That is the same lesson as with php2shell: you cannot test what you have not listed. Scoping tests by application and server leaves out storage, queues, logs and other places data ends up.

An identity provider holds a map of its customers. Even without passwords, these files show which employees use which apps at which companies, with employee numbers and departments. That is useful material for targeted phishing, and it is why customers of an SSO service should treat a leak like this seriously even when the notice says no credentials were included.

The disclosure deserves credit. A notice that corrects its own earlier mistakes and commits to monthly progress reports, even empty ones, is what we would like to see more often. It came from the same group, in the same weeks, as the Desktop Cloud case, and shows the group knows how to do this.

What this means for practitioners#

  • Inventory by-products, not just databases. Temporary files, exports, error reports, logs and backups are data too. List where each feature writes them.
  • Separate public from private by design. Serve public assets from a dedicated area or delivery service that accepts only set file types, and block public access everywhere else by default.
  • Turn off listing and sign links. A public area should never allow file listing, and downloads of anything else should use signed, short-lived links.
  • Delete automatically. Set retention periods for temporary and processed files and enforce them in the storage itself.
  • Scope assessments by data, not by system. Include storage, buckets and every internet-facing asset, and review cloud storage settings continuously.
  • Read your logs. Access logs that show unknown parties downloading files are only useful if someone looks.
  • If you use an SSO service, check whether your administrators ran bulk operations, and warn the employees listed about targeted phishing.

Japanese terms at a glance#

Japanese Reading Meaning
シングルサインオン shinguru sain on Single sign-on
公開領域 kōkai ryōiki Public area (of storage)
一括操作 ikkatsu sōsa Bulk operation
ひな形ファイル・エラーファイル hinagata fairu / erā fairu Template file / error file
設定の不備 settei no fubi Misconfiguration
脆弱性報告制度 zeijakusei hōkoku seido Vulnerability disclosure program
取得できる状態 shutoku dekiru jōtai Retrievable, exposed
アクセス記録 akusesu kiroku Access logs
確報 kakuhō Final report (to the regulator)
再発防止策 saihatsu bōshi saku Measures to prevent recurrence