Sony So-net and plala Breach: 2.58 Million Records, 54,401 Mailbox Passwords, and the Parts Nobody Has Explained

2026-10-29 · Security Engineering · By Hassan Nazir

Sony Network Communications disclosed on October 27, 2026 that attackers got into the So-net and plala member database, exposing about 2.58 million records and 54,401 email passwords. Here is what is confirmed, what is missing, and what I would change in my own systems after reading it.

On October 27, 2026, Sony Network Communications told customers of its So-net and plala internet services that an attacker had gotten into the member database. The headline number is about 2.58 million customer records. The detail that caught my eye is smaller and uglier: 54,401 mailbox passwords were exposed too, and Sony had to force-reset them.

I do not run a Japanese ISP, but I run systems that hold user records and mailboxes, so I read this the way I read every disclosure: what is actually confirmed, what is missing, and what would I change on Monday. Short version: the count is the least interesting part of this incident.

One note on sourcing before we start. Sony's own notice is the primary source, but I could not open it directly in my tooling, so everything below about its contents comes from three secondary write-ups that agree with each other on the numbers: CyberInsider, Cybersecuritynews, and a SmartScope analysis that cites Sony's notice and FAQ. If you need the exact wording, go to the primary page linked in the sources.

What Sony Has Said

Pulling the overlapping facts from those write-ups:

Unauthorized access happened on October 19, 2026.
Sony found it on October 23, shut down the affected server, and blocked traffic from the source.
On October 24, the investigation confirmed that personal data had actually leaked.
Sony reported the incident to Japan's Personal Information Protection Commission.
On October 27, it reset the exposed mailbox passwords and published the notice.
Sony says it had not seen follow-on harm as of October 27, but warned that the data could fuel suspicious emails, texts, and calls.

That is a four day gap between intrusion and detection, and a three day gap between detection and public notice. Neither is shocking by industry standards. Both are long enough for an attacker to do a lot.

The Numbers, Laid Out

Item	Count
So-net records	2,141,986
plala (S Course) records	443,495
Combined	2,585,481
Mailbox passwords exposed	54,401
Bank account records exposed	16

Two caveats on that table. First, these are records, not a verified count of unique people. One person can hold several records. Second, the combined figure is simple addition of the two service counts. One analyst noted that the official announcements do not state the total directly, and the "2.58 million" headline comes from adding them up.

The affected group is not just current customers. About 272,215 former So-net members and 21,130 former plala members, people who canceled from March 2026 onward, are in there. Members who finished cancelling by the end of February 2026 are reported as excluded.

The 54,401 mailbox passwords break down across four services, per CyberInsider: 24,655 on Mail Service (G), 17,672 on A-Box additional mailboxes, 7,005 on So-net VAIO Mail, and 5,069 on PostPet Mail. These belong to people already in the affected population, so they are not extra customers.

What Was in the Records

Per the write-ups, the member data included names, phone numbers, email addresses, user IDs, dates of birth, gender, and internet connection IDs. Sony says main membership account passwords and credit card data were not part of it, and that it does not store bank PINs.

Sixteen bank account records were exposed with bank name, branch, account type, account number, and holder name. Sixteen is tiny next to 2.5 million, and it is the one that scares me most. Account numbers plus a real name, a phone number, and a date of birth is the exact kit a fraudster needs to sound convincing on a call.

Reports also mention seven password reset notification documents. Those passwords were already reset.

The Part That Matters: Why Were Mailbox Passwords Readable?

Here is the question I keep coming back to. Sony says it does not know yet how the attacker got in, and it has not said how those 54,401 mailbox passwords were stored. CyberInsider says this explicitly.

That matters because the story splits in two depending on the answer:

Passwords were hashed properly with a slow, salted algorithm. Then "exposed" means an attacker has hashes and has to crack them. Forced reset is a sensible precaution.
Passwords were stored reversibly or hashed weakly. Then "exposed" means usable credentials, and the reset is damage control after the fact.

Sony chose to force-reset, which fits either story. The notice language I can see does not tell us which one we are in. I will not guess, and neither should you. If Sony publishes a final report, this is the first thing I will look for.

Why do I care so much about mailboxes specifically? Because a mailbox is not just a mailbox. It is the recovery address for a pile of other accounts. Whoever reads it can trigger password resets on banking, shopping, and social accounts, and the reset emails arrive right where the attacker is sitting. A leaked mailbox password is often a master key with a delay on it.

What Is Still Unknown

Question	Status
How the attacker got in	Not disclosed, investigation ongoing
Who is responsible	Not named in the coverage I read
How mailbox passwords were stored	Not disclosed
Whether data is being sold or published	Not stated in the coverage I read
Any link to other Sony incidents	Sony reportedly says no link to the separate MOVEit-related issue at Sony Interactive Entertainment

That last row comes from one source (Cybersecuritynews), so treat it as unverified until you read Sony's page. PlayStation Network accounts are reported as unaffected.

The coverage is also thin in a specific way: almost every article is a rewrite of Sony's notice. I found no independent forensic detail, no leak-site claim, and no technical analysis. That is normal for the first 48 hours, but it means you should not read agreement between articles as independent confirmation. Four outlets repeating one statement is still one statement.

What This Looks Like From the Engineering Side

I want to be careful here, because the cause is unknown and I am not going to invent one. But the shape of the timeline tells us a few things regardless of the entry point.

Detection took four days. The intrusion was on the 19th and found on the 23rd. For a database of millions of members, that suggests either no alerting on bulk reads, or alerting that nobody acted on until something else tipped them off. I do not know which. In my own systems, the check I trust most is boring: alert when any single account or service reads far more rows than it normally does. It is cheap and it catches the "attacker pulling the whole table" pattern no matter how they got in.

The blast radius included former customers. People who left in March 2026 or later were still in the database. Keeping cancelled users around is common, sometimes for legal reasons, sometimes because nobody wrote the cleanup job. But every old record is liability with no revenue attached. If you cannot name the reason a field is kept, you are storing risk for free.

Mailbox credentials lived next to member data. The exposed passwords came from four different mail products. When several legacy products share a backend or a credential store, one break exposes all of them. I have seen this pattern in my own work: a newer system gets hardened and the old products attached to it quietly keep the old habits.

Account numbers were in the same database as everything else. Sixteen records is small, but it means banking details sat within reach of a path that reached member profiles. The usual fix is separation: sensitive fields in their own store, behind their own access path, with their own logging.

What I Would Do If I Were a So-net or plala Customer

Sony says to set a new mailbox password through the official My Page portal, going to the site directly instead of through any link in an email. That is correct, and I would add a few things:

Change the password anywhere you reused it. If your So-net mailbox password matched another account, that account is the real problem now.
Change the recovery email and phone on important accounts if they point at the affected mailbox, or at least review recent login activity there.
Treat any message that quotes your name, phone, or birth date as suspicious, even if it sounds specific. The attacker may have exactly those fields.
If you gave Sony a bank account, watch statements and call your bank about alerts. Do not wait for a letter.
Turn on two factor authentication on the accounts tied to that mailbox, using an app or hardware key where possible.

What I Would Do If I Run a System Like This

This is the checklist I am taking from the incident. None of it needs a root cause to be worth doing.

Inventory every place credentials for user mailboxes or logins are stored, and write down the hash algorithm for each. If you cannot answer "how are these stored" in one minute, you have found your first task.
Add bulk read alerting on member and mailbox tables. Thresholds per service account, not global.
Set a retention rule for cancelled users and actually run it. Pick a number of days, document the legal reason, delete or anonymize after that.
Separate financial fields from profile data, with their own access path and audit log.
Rehearse the forced reset. Sony reset 54,401 mailbox passwords on the day of disclosure. Can you reset a few million on a bad day without taking your login service down?
Write the customer notice early. A template with the fields people care about (what data, what counts, what to do, where the official page is) saves hours when you are tired.

For item 1, here is a small sketch of the audit I mean. It is not Sony specific, just a way to find weak storage in your own user tables before someone else does:

HEX_LENGTHS = {32: "unsalted_md5_like", 40: "unsalted_sha1_like", 64: "unsalted_sha256_like"}
GOOD_PREFIXES = {
    "bcrypt": ("2a", "2b", "2y"),
    "argon2": ("argon2",),
    "scrypt": ("scrypt",),
    "pbkdf2": ("pbkdf2",),
}

def classify(stored: str) -> str:
    # Rough classifier for how a stored credential looks. Run it against a
    # sample of your own data in a safe environment.
    body = stored.lstrip(chr(36))
    for name, prefixes in GOOD_PREFIXES.items():
        if body.startswith(prefixes):
            return name
    is_hex = all(c in "0123456789abcdefABCDEF" for c in stored)
    if is_hex and len(stored) in HEX_LENGTHS:
        return HEX_LENGTHS[len(stored)]
    return "unknown_or_plaintext"

def summarize(rows):
    counts = {}
    for stored in rows:
        label = classify(stored)
        counts[label] = counts.get(label, 0) + 1
    return counts

If the output shows anything under "unsalted" or "unknownorplaintext", that is your migration backlog.

Tip: do the audit on a copy, and keep the output to counts only. You want the percentage of weak entries, not a list of them.

My Take

Three things.

First, wait for the storage answer before judging Sony. Everything about how bad this is hinges on how those mailbox passwords were stored, and Sony has not said. Forced resets are the right move either way. But "we reset them" is a response, not an explanation.

Second, the small numbers deserve the most attention. The 2.58 million figure will drive headlines. The 16 bank records and 54,401 mailbox passwords are what turn this from an annoying leak into account takeover and fraud material.

Third, this is a retention and segmentation story as much as a security story. Former customers, legacy mail products, and financial fields all lived within reach of one intrusion. You can have good perimeter controls and still lose because of what you kept and where you put it.

Key Takeaways

Sony Network Communications disclosed on October 27, 2026 that its So-net and plala member database was accessed on October 19, exposing about 2,585,481 records, plus 54,401 mailbox passwords and 16 bank account records.
The entry method, the attacker, and how mailbox passwords were stored are all not yet disclosed.
Former customers who cancelled from March 2026 onward are included, which is a retention lesson for everyone.
Customers should reset mailbox passwords via the official portal, fix reused passwords, and watch for targeted phishing and bank fraud.
Teams should audit credential storage, add bulk read alerts, enforce retention for cancelled users, and separate financial data.
Most coverage restates Sony's single notice, so treat agreement between articles as one source, not several.