Arara's second report puts its email service breach at about 77 million addresses on 97 customer servers
Arara Inc. says in its second report, dated 2 November 2026, that about 77 million email addresses on 97 customer servers were taken or may have been, and up to about 7.13 million suspicious emails went out from its own sender address. It names no actor and no way in; counts are under review.
By Parminder Kumar Sharma · LinkedIn · · 21 min read
Three counts, no total: about 77 million, 3,386,187 and up to 7.13 million
Arara Inc., a Japanese company, runs a bulk email delivery service that its PDF writes in katakana as アララメッセージ; this site writes it "Arara Message" (this site's translation). Its first report, dated 29 October 2026, gave one figure: about 3.01 million email addresses, from one shared environment. Its second report, dated 2 November 2026, gives three counts for three categories and says they are not added together, because "the same email address may be duplicated between categories" (this site's translation). The largest, about 77 million email addresses on 97 servers in customer companies' own environments, is about 25.6 times the first report's figure (derived: 77,000,000 / 3,010,000). It is not that figure grown. It counts a place the first report did not cover. For the first environment itself, the second report revises about 3.01 million to 3,386,187 addresses with duplicates removed, about 12.5 per cent more (derived: 3,386,187 / 3,010,000, from a rounded first figure).
What that does not establish. About 77 million is a count of addresses, not of people: Arara says it "does not show the number of end users" because one person may hold several addresses. It includes addresses that "may have been taken", which Arara says it judged "from the amount of records read". It is a figure for 1 November that Arara says is under review, with a third report to follow. The PDF names no actor, no first way in, no software flaw by name, and nobody who lost money.
Arara sells the service and wrote this notice about itself, so every figure below is its own account unless a customer's notice is named. By its own estimate it supplies up to about 380 companies. TKC Corporation, one of its customers, and the City of Osaka, a customer of TKC, published their own notices; the later sections read what each adds.
What the second report changes
The report opens with a table of what moved since the first. It is reproduced here in this site's translation, row by row. The first report's column is as the second quotes it.
Main changes from the first report, as the second report's own table gives them (Arara Inc., 2 November 2026; this site's translation).
| Item | First report, 29 October | Second report, 2 November |
|---|---|---|
| Where leakage was confirmed | "1 system (shared environment)" | The shared environment, plus customer companies' environments (97 servers) |
| What was taken | Email addresses | Email addresses, and member information such as name, which differs by customer company |
| Count | "about 3.01 million email addresses" | Per category, under review (next section) |
| Cause | "web server vulnerability" | "web server vulnerability and problems in the system environment" |
| Suspicious emails | A general caution | The content of suspicious emails sent from the service, up to about 7.13 million, and a caution |
| The service | That server cut from the network | All service provision stopped on 31 October |
The cause changed, and still names nothing. The first report said a third party had exploited a web server vulnerability. The second says that "in addition to that vulnerability, problems in the system environment were also involved in the occurrence" (this site's translation). It does not name the vulnerability, the product it sits in or a CVE number, and it does not say what the “system environment” problems were or how they combined. For the first environment it says the third party "logged in to the admin screen of that environment without authorisation and took the data out by abusing the data output function and similar" (this site's translation). How the third party got a login for that admin screen is not stated, and the PDF does not say whether the web server vulnerability supplied it.
The three categories, and the note that stops them being added
Section 2 of the report is a table of three categories, with the dates each occurred and was identified, the target, the main information and the count as of 1 November. Its note under the table is the sentence the rest of this briefing depends on: "Because the same email address may be duplicated between categories, the counts are not totalled" (this site's translation).
The three categories in Arara's section 2 table (Arara Inc., 2 November 2026; this site's translation). Dates are as printed, 2026, and the PDF states no time zone.
| Category | Occurred, identified | Target | Main information and count |
|---|---|---|---|
| (1) Unauthorised access via the service | 28 to 31 Oct; identified 31 Oct | Customer companies' environments: 97 servers, up to about 380 companies (current estimate) | Email addresses and member information; about 77 million (under review) |
| (2) The first report's environment (shared environment) | 27 to 28 Oct; identified 28 Oct | 61 customer companies | Email addresses and attribute information; 3,386,187 (duplicates removed) |
| (3) The service misused to send suspicious emails | 28 to 30 Oct; identified 28 and 30 Oct | Two environments | Email addresses; up to about 7.13 million emails (total for the two environments) |
Two more points come from the same pages. First, "may have been taken" is not a statement of loss: the note says it is "judged from the amount of records read". The 77 million therefore mixes addresses Arara says were taken with addresses it infers may have been, and the report does not split the two. Second, the 61 companies in category 2 and the up to about 380 in category 1 are separate estimates: the report does not say how many companies are in both, and calls the 380 a current estimate under review.
One actor, as Arara reads it. The report says the whole series is "seen as being by the third party who carried out the earlier unauthorised access", judged "from the commonality of the attack source and similar" (this site's translation). That is an assessment with a basis the PDF does not describe. It is not an identification: no group, person or country is named, and this briefing attributes the intrusion to no one. On how it began, the report says "the start time and route of the intrusion are still being investigated" (this site's translation).
What was in the data. For category 1 the report lists "email addresses, the items the contracting company registered with the service (name, sex, date of birth, telephone number, member number, address and so on, which differ by contracting company) and records such as delivery destinations" (this site's translation). For category 2 it adds customer data including names and company names, up to 411,827 items, registered by five of the contracting companies. Appendix 2 sets out what the service records and what this affected:
What the service records and what this affected, from Arara's appendix 2 (Arara Inc., 2 November 2026; this site's translation). Column (1) is access via the service, column (2) the first report's environment.
| Type of information | What it is | (1) Via the service | (2) First environment |
|---|---|---|---|
| Member information (address book) | Email address, plus the name, sex, date of birth, telephone number, member number and address the customer registered; items differ by customer | About 97 servers | 5 companies |
| Credentials for using the service | Credentials customers use for API connections and similar (API keys and so on) | Marked as use suspended | Marked not applicable |
| Customer staff details | Names and email addresses of staff who use the admin screen | Being confirmed | Being confirmed |
The credentials row is easy to over read. The cell for category 1 reads 利用停止中, which this site translates as use suspended; whether that means the keys were taken or only that the service that uses them is stopped is not said. Arara says it will ask customers, when the service restarts, to reset their admin passwords and credentials, "API keys and so on". One item is stated flatly: Arara says its service "holds no credit card numbers at all" (this site's translation).
The timeline, as the PDF's own table gives it
Appendix 1 lists the main events. It prints no time zone; Arara is a Japanese company and this site assumes Japan time, which the PDF does not say. Two entries are marked in the PDF as found only after the first report, and are flagged here. The last column gives the category from the section 2 table.
Appendix 1 of Arara's second report, main events (Arara Inc., 2 November 2026; this site's translation). All 2026; times as printed.
| Date and time | What the table says | Category |
|---|---|---|
| 27 Oct 08:36 | Access seen as reconnaissance by a third party (found after the first report) | none |
| 28 Oct about 03:59 | Misuse of the service begins: suspicious emails sent | (3) |
| 28 Oct 07:00 | External access to that environment stopped | (3) |
| 28 Oct about 08:47 | Suspicious emails start in another environment (found after the first report) | (3) |
| 28 Oct 11:09 to 15:43 | Unauthorised login to the shared environment's admin screen, and data taken | (2) |
| 28 Oct 16:31 | Shared environment stopped as an emergency | (2) |
| 29 Oct 01:36 to 30 Oct 02:22 | Data taken via the service | (1) |
| 29 Oct | First report published; preliminary report to the Personal Information Protection Commission | none |
| 30 Oct 13:08 | Sending of suspicious emails recognised; that environment's traffic blocked at 13:26; no sends after 13:32 | (3) |
| 31 Oct morning | Taking via the service recognised | (1) |
| 31 Oct from 12:58 | Accounts and keys used improperly invalidated, and each server's traffic blocked, in turn | (1) |
| 31 Oct 19:53 | Stopping of the whole service completed | none |
Five spans follow from those entries. Each is derived by this site, from the printed times and nothing else:
Spans derived by this site from appendix 1 (Arara Inc., 2 November 2026). The PDF states no time zone.
| Span | From, to | Length (derived) |
|---|---|---|
| First recorded misuse to the service fully stopped | 28 Oct 03:59 to 31 Oct 19:53 | 3 days 15 hours 54 minutes |
| First recorded access to the service fully stopped | 27 Oct 08:36 to 31 Oct 19:53 | 4 days 11 hours 17 minutes |
| Taking via the service, as listed | 29 Oct 01:36 to 30 Oct 02:22 | 1 day 46 minutes |
| Misuse in the second environment, to the block | 28 Oct 08:47 to 30 Oct 13:26 | 2 days 4 hours 39 minutes |
| Suspicious emails, first start to last send | 28 Oct 03:59 to 30 Oct 13:32 | 2 days 9 hours 33 minutes |
What the timeline shows. The second environment's misuse began at about 08:47 on 28 October, 1 hour 47 minutes after the first environment's external access was stopped at 07:00 (derived), and Arara recognised it on 30 October, so mail went on from the service for about two more days. The block was recorded at 13:26 and the last send at 13:32, six minutes later; the PDF does not explain the gap. The take-out via the service began at 01:36 on 29 October, the day of the first report, and ended at 02:22 on 30 October; the PDF gives no hour for the first report, so it cannot be said whether the taking was still running when the first report was published. What the first report said, one system and about 3.01 million addresses, was written before Arara recognised the take-out via the service (31 October morning).
A small inconsistency in what the PDF says. The body says the third party logged in to the first environment's admin screen "from 27 to 28 October", while the timeline lists 27 October only as access seen as reconnaissance and puts the login and data take-out at 11:09 to 15:43 on 28 October (4 hours 34 minutes, derived). The PDF does not say whether any login happened on the 27th.
What each customer's notice adds, and what it cannot
Arara's report defines two layers. A "contracting company" is "a company that has adopted the service directly"; an "end user" is an individual who finally uses it (this site's translation). Two notices from further down the chain were saved: TKC Corporation's third report (printed date 4 November 2026) and the City of Osaka's notice (printed date 13 November 2026).
What each saved page says about counts and dates. Sources: Arara Inc. 2 November 2026, TKC Corporation 4 November 2026, City of Osaka 13 November 2026 (this site's translation), The Record 13 November 2026 (secondary).
| Source and date | Count and dates it gives | What it says it does not yet know |
|---|---|---|
| Arara Inc., 2 Nov | About 77 million addresses (category 1); 3,386,187 (category 2); up to about 7.13 million emails (category 3) | Counts under review; third report to follow; each contracting company to be told individually whether it is covered |
| TKC Corporation, 4 Nov (third report) | Up to 2,230,812 email addresses of customers who use TKC's systems, from Arara's service; only addresses, not mail text, My Number or application information to municipalities | Which customers' addresses leaked: investigation continues. TKC's own services cannot send mail while Arara's service is suspended; it is moving to another mail platform |
| City of Osaka, 13 Nov | 1,078,713 addresses of users of the City's online administrative system, who received mail from it between 1 July and 31 October 2026 | Cannot say whether any one address is covered; notice to affected people is under consideration; has asked TKC for a detailed report |
| The Record, 13 Nov (secondary) | More than 1 million Osaka addresses; 77 million from nearly 400 customers | Not applicable: it repeats the figures; see the differences section |
Each notice can say only what the layer above tells it. TKC says that "which customers' email addresses leaked, investigation is continuing" (this site's translation). The City says it identified its affected addresses "on the basis of information that the external service's provider gave to the system provider, classified and cross-checked by the system provider", and that it "cannot answer enquiries about whether an individual email address is covered" (this site's translation). So the people at the end of the chain are told that a count exists, and are asked to check their own inbox history; the yes or no for a given address sits with the platform.
Three smaller points. The City's notice does not print Arara's name: it speaks of an external mail delivery service and its provider. TKC's notice names Arara Message, and The Record names Arara. The City's count is large partly because of one mailing: it says a notice mail sent on 16 September 2026 to every registered user "made the count very large" (this site's translation). And neither notice says how its count maps onto Arara's categories. If the City's 1,078,713 sits inside TKC's 2,230,812, which neither notice says, it would be 48.4 per cent of it (derived: 1,078,713 / 2,230,812).
Who counts as a customer. Arara's estimate of up to about 380 companies is a count of contracting companies. A municipality that buys a system from one of them, as the City does from TKC, is one step further out, and nothing in the PDF says the 380 includes such organisations or their users. That is this site's reading of the layers, not a statement in any saved page. The dates show the lag: Arara's report is dated 2 November, TKC's third report 4 November (2 days later, derived) and the City's notice 13 November (11 days after Arara's, 9 after TKC's, derived).
The suspicious emails: what the PDF prints, and what a mail team does with it
Section 5 describes emails posing as credit card companies, sent through the service itself. The PDF prints a sender address and two subject lines; it prints no link, no domain, no message text and no message headers. The address is defanged here (the dot in brackets). The subject lines are quoted in Japanese because a mail team needs the exact strings to search for; the English is this site's translation.
The suspicious emails, as Arara's section 5 table prints them (Arara Inc., 2 November 2026; this site's translation). The sender address is defanged by this site.
| Field | As printed | This site's translation or note |
|---|---|---|
| Sender address | news@arara[.]com | Arara's own domain, sent from its service (the PDF says they were sent from the service) |
| Subject 1 | 利用内容確認のご依頼 | Request to confirm usage details |
| Subject 2 | ご利用明細確認のご依頼 | Request to confirm usage statement |
| Subjects, others | 等 | The PDF adds etc.: further subjects may exist and are not printed |
| Number | 最大約713万通 | Up to about 7.13 million emails, total for two environments |
| Window | 10月28日から30日 | 28 to 30 October; last send 30 October 13:32 |
| Recipients | 第三者が外部から持ち込んだメールアドレス | Email addresses that the third party brought in from outside |
| Other personal data | 本件の不正送信自体に伴うメールアドレス以外の流出は確認されておりません | No leak other than email addresses, arising from the sending itself, confirmed |
What the recipients line says. The PDF says the recipients were addresses the third party supplied from outside. It does not say they were the stolen addresses, and it does not say they were not. The 7.13 million is a count of emails, not of people: how many distinct recipients, how many were delivered, opened or clicked, and whether anyone lost money are not stated. Arara's advice to a recipient who followed the link and entered card details, to contact the card issuer promptly, implies that card details were the aim, but the PDF does not describe the page behind the link.
What a mail team does with it (this site's suggestion). Search mail gateway and mailbox logs for 28 to 30 October for that sender and those two subjects, with the Japanese strings as printed, and count what reached your users. Keep one copy with full headers of anything found before it is deleted, since the PDF gives no headers to compare against. Check web proxy logs for clicks from those messages. Do not rely on a sender block alone: the address is Arara's own, so a block also stops genuine Arara mail if you receive any.
An inference, labelled as one. Mail sent through the provider's real service under the provider's own address is the case that domain based checks such as SPF and DKIM are least able to catch, because the message really did come from that infrastructure. The PDF says nothing about whether such checks passed and does not mention them. This site offers the point as reasoning, not as a finding.
Where the sources differ
The Record's report of 13 November is a secondary. It is dated by its page data, 19:53 UTC on 13 November 2026. It matches the PDF on the headline figure and differs on the points below; the article follows the PDF.
Differences between Arara's PDF (2 November 2026; this site's translation) and The Record's 13 November 2026 report.
| Point | Arara's PDF | The Record |
|---|---|---|
| When | A report dated 2 November; accesses 27 to 31 October | "The company said a November 2 cyberattack exposed 77 million email addresses from nearly 400 customers, including TKC, gaming giant Sega and others." It dates the attack to 2 November |
| Number of customers | Up to about 380, a current estimate under review; no customer is named | Nearly 400, and names TKC and a games company; the PDF names neither |
| The 77 million | About 77 million, under review, addresses not people, including addresses that may have been taken | States 77 million without those qualifiers |
| Who the emails posed as | Credit card companies | Credit card companies and financial institutions, in the wording: "pretending to be credit card companies and financial institutions" |
| Osaka | Not mentioned | More than 1 million; the City's own notice says 1,078,713 |
The Record also carries a wider account of Japanese incidents and an official's views about the tools attackers use. None of the saved Arara, TKC or Osaka pages ties any tool or actor to this incident, and this briefing does not either.
What Arara states, and what it does not
What the PDF states and what it leaves out (Arara Inc., 2 November 2026; this site's translation).
| Point | Stated by Arara | Not stated |
|---|---|---|
| Cause | A web server vulnerability and problems in the system environment | Which vulnerability or product, any CVE, what the environment problems were, how they combine |
| First way in | Start time and route still under investigation | Any route at all |
| Credentials | Accounts and keys used improperly were invalidated from 31 Oct 12:58 | Whose they were, how they were obtained, whether customers' or Arara's own |
| Who | Seen as the same third party, from a shared attack source and similar | Any identity, group, motive or link to other incidents |
| Customer count | Up to about 380 companies, current estimate; 61 in the first environment | Which companies; how many are in both; downstream organisations |
| What happened to the data | Taking confirmed (or possible, judged from the amount read) | Whether it was published, sold, used or demanded for payment: the PDF has no word on it |
| The emails | Sender, two subjects, up to about 7.13 million, 28 to 30 Oct, recipients supplied from outside | How many recipients, delivery, clicks, any loss, the page behind the link |
| Restart | Undecided; after the route is identified, credentials fully changed and safety confirmed | A date |
| Cost | Effect on its results under review | Any cost, fine or customer loss |
| Authorities | Preliminary reports to the Personal Information Protection Commission and JIPDEC and a police report, all on 29 Oct; new matters and an interim report planned for 2 Nov | Whether the planned 2 Nov reports were made: the PDF is dated the same day |
Arara has also said it will "contact all contracting companies promptly after this report is published", telling each "individually" whether its environment is covered and what was taken (this site's translation). It describes its next steps as working with outside specialists on the route, start and scope, a full change of credentials, rebuilding the system and stronger monitoring.
What to do, in order
Take this with you
Checklist (items 1 to 3 are Arara's; the rest are this site's suggestions)
- Arara's advice, recipients: be wary of emails, texts, calls and post that claim to come from Arara or its customers; do not open links in contacts you do not recognise, enter IDs, passwords or card details, or open attachments.
- Arara's advice, recipients: if you received mail from news@arara[.]com with those subjects between 28 and 30 October, do not open the link and delete it; if you entered card details, contact your card issuer promptly. Arara says it never emails to ask for passwords or card details.
- Arara's stated plan, customers: Arara will contact every contracting company, and will ask them to reset admin passwords and credentials such as API keys when the service restarts.
- This site's suggestion, customers of Arara: ask Arara in writing whether your environment is covered, which category, how many addresses, and which fields (name, date of birth, telephone number, member number, address) were in it.
- This site's suggestion, customers of any bulk mailing provider: list the fields each provider holds for you and remove those it does not need. The PDF shows a provider holding names, dates of birth, telephone numbers and addresses that customers had registered.
- This site's suggestion: write breach notice timing and per customer counts into the contract, and plan how you will publish a number your provider may revise. Arara's own figure moved from one report to the next because a new category was found.
- This site's suggestion: search your mail logs for 28 to 30 October for the printed sender and subjects, keep a copy with headers of anything found, and tell affected users what Arara advises.
- This site's suggestion: rotate admin passwords and API keys for any provider that was breached, and anywhere the same secret was reused, without waiting for a restart.
- This site's suggestion: assume that someone with a provider's access can send as the provider, and perhaps as you. The PDF reports mail sent under Arara's own address and does not say whether customers' domains were used. Ask your provider which senders and keys it can use for you.
- This site's suggestion, recipients: do not open links in unexpected card statement emails, even when the sender address looks trusted. Go to your card issuer's site or app by your own route.
- This site's suggestion, organisations that buy a system built on a mail provider: ask your supplier which providers send mail for you, so you know the chain before a notice has to cross it.
The question Arara's report leaves open
Arara says it will tell each contracting company whether it is covered and what was taken, and the City of Osaka says it cannot tell any resident whether their own address is among its 1,078,713: between the platform's list and a person's inbox, who will say yes or no, and with which number?
Key facts
Sources
- PrimarySecond report on unauthorised access to its Arara Message mail delivery service and the service suspension, 2 November 2026, in Japanese: the counts, categories, timeline, suspicious email table and advice. Saved by the lead at about 22:00 UTC on 13 November 2026Arara Inc.accessed 2026-11-13
- PrimaryNotice on information leakage at its mail delivery contractor (third report), 4 November 2026, in Japanese: up to 2,230,812 addresses of its customers, which customers still unknown. Saved by the lead on 13 or 14 November 2026TKC Corporationaccessed 2026-11-14
- PrimaryICT strategy office notice, 13 November 2026, in Japanese: 1,078,713 addresses of users of the City's online administrative system, how they were identified, what the City cannot say. Saved by the lead on 13 or 14 November 2026City of Osakaaccessed 2026-11-14
- Reported byCity of Osaka warns of data breach impacting 1 million as Japan reels from dozens of cyber incidents, 13 November 2026 (page data 19:53 UTC): a secondary, used for the places where it differs from the PDFThe Record from Recorded Future Newsaccessed 2026-11-14


