← Incident database

nimoca-2026 · Disclosed 2026-10-06

nimoca: unauthorized access to the public usage-history service

nimoca reported leakage of 521 records through unauthorized service access. Unexpected emails were generated automatically by the service.

Cause unresolved / undisclosed

Outcome: Confirmed breach

Entry path and evidence

  • Reported fact

    Unauthorized public-service access was confirmed. The service, not the attacker, sent the emails.

    [s1]p.1 §2
  • Reported fact

    Affected data comprises 521 records with card numbers, birth dates, and email addresses; name and usage-history leakage is unconfirmed.

    [s1]p.1 §3 / p.2 §4

Timeline

  1. Access occurred around midnight–17:40. A customer report around 09:00 prompted investigation; the service stopped at 17:40. [s1]

  2. Impact and response disclosed. [s1]

Reported response

  • Reported fact

    The usage-history service was stopped; cause and scope remain under investigation.

    [s1]p.1 冒頭 / p.2 §6

Cause and mitigation hypotheses

These are editorial hypotheses, separate from established causes and reported responses. Supporting and challenging observations are checks to investigate, not collected evidence.

  1. Cause hypothesis 1 Unverified

    Abuse of the legitimate input and notification function is a candidate mechanism.

    Primary-source starting point

    The service sent unexpected emails to registered recipients in response to defined input.

    [s1]p.1 §2 概要

    Read assumptions, observations, and limits
    Required assumptions
    • The attacker reached the normal flow and it accepted input associated with another user.
    Observations that would support it
    • Preserved web and application logs link unauthorized activity to normal endpoints and insufficient ownership checks.
    Observations that would challenge it
    • Investigation establishes database access through another path, with email as separate subsequent activity.
    Assessment limits
    • Email proves the function ran, not an authorization flaw; other paths such as SQL injection remain possible.

    Related inspection rules

  2. Mitigation hypothesis 2 Unverified

    Checking ownership before lookup and notification, plus retrieval limits, could curb legitimate-function abuse.

    Primary-source starting point

    The disclosure describes unauthorized public-service access and automated emails containing registration data.

    [s1]p.1 §2 / p.2 §4

    Read assumptions, observations, and limits
    Required assumptions
    • Server-side ownership checks are available on lookup and notification paths.
    Observations that would support it
    • Two synthetic users in an isolated environment cannot trigger each other’s lookup or notification; retrieval limits work.
    Observations that would challenge it
    • Unauthenticated or cross-user input returns data, or bulk lookups and notifications remain unrestricted.
    Assessment limits
    • Server compromise and other paths remain possible despite these controls; the incident’s specific defect is undisclosed.

    Related inspection rules

Read this incident’s AI-ready guide ↗

Evidence relevant to prevention

Insufficient evidence

Inspect lookup authorization, input-driven recipients, retrieval limits, and logs.

Editorial assessment; not a determination of liability. [s1]

Unknowns and AI involvement

AI involvementUnknown

The reviewed disclosures do not establish attacker use of AI.

The specific mechanism is undisclosed; SQL injection and authorization defects are unestablished.

Sources

  1. [s1] ニモカ · Primary source

    nimoca利用履歴照会サービスへの不正アクセスによる情報漏えい ↗

    Published 2026-10-06 · Reviewed 2026-10-10