Iwai Cosmo and Trade Works Breach: Admin Flaw, 4,975 Leaked, 5 Trades

On 14 October 2026 an attacker got into the internet trading system that Trade Works runs for Iwai Cosmo Securities. Names and email addresses of 4,975 customers were exposed, and orders were placed in 7 accounts, 5 of which executed. Customer passkeys and multi factor login were not bypassed. Firms that outsource trading platforms should audit vendor admin access now.

This post sets out what the two companies have said across five official documents, where their descriptions of the cause differ, what the attack did and did not touch, and what any broker, fintech or platform vendor can check this week. Neither company has published the exact misconfiguration or the attacker's method, and we do not guess at either. Iwai Cosmo says it held back details at first so that the same method could not be copied while fixes were rolled out.

What happened

Iwai Cosmo Securities (岩井コスモ証券) is an Osaka based securities broker and a subsidiary of Iwai Cosmo Holdings, which is listed on the Tokyo Stock Exchange Prime market under code 8707. Its online brokerage brand is called Cosmo Netre (コスモ・ネットレ). Iwai Cosmo outsources the operation and maintenance of its internet trading system to Trade Works Co., Ltd. (株式会社トレードワークス), a Tokyo based developer of trading systems listed on the TSE Standard market under code 3997. Trade Works also provides systems to other financial institutions.

On Wednesday 14 October 2026, according to both companies, an unauthorized third party accessed the trading system that Trade Works provides to Iwai Cosmo. Iwai Cosmo says it detected the access, contacted Trade Works straight away and put emergency access restrictions in place. Trade Works says it cut off the access the same day, and that no further intrusion or unauthorized trading has happened since.

The incident had two parts:

1. Exposure of customer data. Names, email addresses and other fields for part of Iwai Cosmo's online customer base were exposed. The first count, published on 16 October, was 4,611 customers. The second report, on 20 October, raised it to 4,975 after the companies re-examined communication records as well as access records.
2. Unauthorized trades. On the same day, orders that customers did not intend were placed in 7 accounts, and 5 of those accounts saw the orders execute. Iwai Cosmo contacted the affected customers on 14 October and restored the accounts to their pre-trade state. It says customers bore no cost. This part was not made public until 20 October.

Trade Works said on 16 October that it would bear the full cost of losses and response. On 23 October it put the expected loss at about 50 million yen, to be booked as an extraordinary loss in the fourth quarter of its financial year ending December 2026, and said it expects its cyber insurance to apply.

Timeline

No published document gives times of day for the intrusion, detection or containment. The times below are the ones that appear in the sources.

What is still unknown

• Which admin function was exposed, what it was for, and how long it had been reachable from outside.
• How the attacker found it, and what exactly Iwai Cosmo means by a brute force attack in this case: what was being guessed, and against which interface.
• Whether the orders were placed through the same admin function or through a separate attack on the order management system. The two companies describe this differently (see the next section).
• The full list of exposed data fields beyond "name, email address and others".
• What other financial institutions use the same Trade Works system, and what "necessary measures" Trade Works took at each.
• Whether the attacker kept any copy of the data, and whether any of it has appeared anywhere.

Where the broker's and the contractor's accounts differ

The two companies agree on the date, the counts and the outcome. They describe the cause and the path to the trades in noticeably different words. That matters for anyone reading these notices to decide what to fix in their own environment, so we set the wording side by side. Each line is a summary in our own words of the cited document.

Three points stand out.

Misconfiguration or vulnerability? Trade Works consistently calls the cause a configuration flaw in an admin function, and on 23 Oct explains it as exposure: the function was reachable from outside when it should have been reachable only from a limited environment. Iwai Cosmo uses the word vulnerability (脆弱性) and, on 21 October, adds brute force. These are not necessarily contradictory. An admin function that should not have been reachable is a vulnerability in the plain sense, and a brute force attempt could have been how the attacker got past whatever protected that function. But neither company says that, so the honest reading is that the broker and the contractor are describing the same event with different emphasis, and the public does not yet have a single technical account.

One path or two? Iwai Cosmo's 20 October report describes the trades as the result of an attack on the order management system that "also occurred" on 14 October, which reads like a second target. Trade Works' 23 October release says the attacker used the abused admin function to make the trades. If Trade Works' wording is the accurate one, a single exposed admin function could both read customer data and place orders. That is the more serious design lesson, and it is the one we focus on below, while noting that the companies have not reconciled the two descriptions.

Leaked or viewable? Iwai Cosmo's later wording, that data was viewable by the attacker until the connection was cut, is narrower than "leaked". Trade Works still says "may have leaked". Both companies notified the affected customers individually, and for customers the advice is the same either way.

Who is affected

The 4,975 count is a count of customers (名), not of records.

Technical details

This incident has no CVE, no affected software version, no published indicator of compromise and no published hash, IP address or domain. Neither company has released attacker infrastructure, and the Japanese advisories we checked contain none. What the primary sources do publish is the list of systems involved, the data scope, the controls in place and the remediation steps. We set those out here so defenders can map them onto their own platforms.

Systems named in the disclosures

Data in scope

Customer authentication in place

The notable fact about this incident is that the customer login path held. According to Trade Works, customer logins were protected by layered authentication including multi factor authentication and passkeys, and unauthorized logins through the normal route were prevented. Iwai Cosmo says on 21 October that passkey authentication was not broken, that multi factor authentication is mandatory at login, and that login security had already been strengthened.

A news analysis by Innovatopia reports that Iwai Cosmo made multi factor authentication mandatory at login on 28 September 2025, with a choice of passkey, phone number or authenticator app, and that the authentication platform used is Trade Works' own product. The same analysis says Iwai Cosmo began phasing in mandatory passkey authentication at login and withdrawal from 27 September 2026. We could not fetch Iwai Cosmo's original notices for those two dates, so treat them as reported rather than confirmed.

Remediation steps, as published

What the published remediation tells defenders

Read together, the remediation list describes the gap fairly clearly even without the details. The fixes are network reachability (the function can no longer be used from outside, and connection sources are restricted), session hygiene (unauthorized connections were invalidated), detection (login anomalies now trigger immediate alerts) and process (security reporting criteria are being reviewed). Each of these maps to a control that any team running an admin plane can check. Trade Works' review of its "reporting criteria and information sharing" also suggests that the escalation of security events, internally or to the client, is part of what is being changed, though the company does not say what the old criteria were.

Brute force, in plain terms

Iwai Cosmo uses the term 総当たり攻撃, which translates as brute force or exhaustive guessing. In general, a brute force attack means trying many values, such as passwords, tokens or identifiers, until one works. It succeeds where an interface accepts unlimited attempts without lockout, throttling or alerting. The companies have not said what was guessed. If it was a credential on an admin function, the relevant control is the same one the JSDA guideline already requires on the customer side: automatic account lockout after repeated failed authentication, plus notification. The difference is that customer-facing lockout rules do not always extend to operator and maintenance interfaces.

The context: Japan's securities account takeover wave

This incident lands at the end of a long run of unauthorized trading in Japanese online brokerage accounts. The FSA publishes monthly provisional figures reported by securities firms. Its statistics file dated 9 October 2026 shows the following.

The FSA notes that these are provisional, that the sale and purchase totals are the sum of unauthorized trading in affected accounts and do not equal customer losses, and that the typical pattern was an attacker selling holdings in a stolen account and using the proceeds to buy small cap stocks. Those attacks started with stolen login credentials from phishing sites and malware.

Iwai Cosmo says in its 21 October report that, according to the FSA's monthly figures, it had seen no such cases since May 2025. The FSA's file does not list firms by name, so we could not check that from the FSA data itself.

In response to the 2025 wave, the JSDA revised its guideline for preventing unauthorized access in internet trading on 15 October 2025. Among the standards, as we read the published PDF:

• Phishing resistant multi factor authentication, such as passkeys or PKI based authentication, implemented and made the default for login, withdrawal and changes to the withdrawal bank account.
• Notifications to customers for logins, trades, withdrawals and withdrawal account changes they did not make.
• Automatic account lockout after repeated failed authentication.
• Masking of important customer information, and notification when it is changed.
• Login behaviour analysis and retention of login and trading data useful for later investigation, such as location, device, source IP address and source port.
• A footnote reminding firms that where there are several login paths, they must check that a weakness in one trading tool does not affect the others.

The guideline also has a set of standards for outsourced contractors that predates this revision, added after a 2021 case in which a member firm's contractor employee accessed accounts and withdrew funds. The standards require the outsourcing firm to:

1. Monitor regularly whether outsourced work is being done properly.
2. Confirm that measures are in place so that customer information, including login IDs and passwords, cannot leak through unauthorized access to the contractor.
3. Build a way to monitor and trace the contractor's access restrictions on customer data and how they operate.
4. Manage data transfers between the contractor's development environment and the production environment holding customer data.
5. Manage the access rights given to the contractor properly, for example by preventing reuse.
6. Report information security risk at the contractor to senior management.
7. Where work is subcontracted further, confirm that the contractor supervises its subcontractors.

The Iwai Cosmo incident sits squarely in the gap between those two parts of the guideline. The customer facing controls that the 2025 revision focused on did their job. The incident went through the operator side, which the outsourcing standards cover in more general terms.

Why strong customer login did not stop it

A trading platform has at least two front doors. One is the customer login: the web and app sign in, now protected by passkeys and multi factor authentication at most Japanese brokers. The other is the set of interfaces that operators, support staff and maintenance contractors use to run the platform. Those interfaces often have far more power than any customer: they can read many accounts at once, correct records and, on some platforms, enter or amend orders on a customer's behalf for legitimate operational reasons.

Passkeys protect the first door. They do nothing for the second unless the operator side is held to the same standard. Trade Works' own description is that the customer route was protected and the attacker came in through an admin function instead. Its 23 October explanation adds the key detail: the function was supposed to be usable only from a restricted environment, and a configuration flaw made it usable from outside.

That pattern is common across industries. Admin consoles, back office tools, support dashboards and maintenance APIs are frequently protected by network location ("only reachable from the operations network") rather than by strong authentication of their own. When the network boundary slips, through a firewall rule, a load balancer route, a new deployment or a cloud security group, the function is suddenly on the internet with whatever weaker protection was considered acceptable inside.

If Trade Works' wording is right that the same function was used to place trades, the second lesson is about privilege design. A function that can read customer details should not, by itself, be able to place orders. Order entry by operators is a high risk action that normally warrants separate authorization, a second person, strict logging and real time alerting.

What to do now

If you are an Iwai Cosmo customer

1. Read the individual notice if you received one, by email or in the notice area after login. Check your account history for any trades you do not recognise.
2. Expect phishing. Both companies warn of calls and emails that pretend to be Iwai Cosmo. Do not use links in emails or SMS messages to log in; use a saved bookmark or the official app, as the JSDA guideline also advises.
3. Set up passkey authentication if you have not, and make sure multi factor authentication is on. Iwai Cosmo asks all customers to do this.
4. Call the customer consultation office on 0120-405-546 (weekdays 9:00 to 17:00) if you are unsure about any contact or trade.

If you run a brokerage or fintech on an outsourced platform

Work through these with your platform vendor this week. Each is phrased as a question you can put in writing and expect a written answer to.

1. List every admin and maintenance interface. Ask the vendor for the full list of operator, support and maintenance interfaces on the platform you use, with the network locations each should be reachable from, and evidence of the current rules.
2. Test reachability from outside. From a network outside both your own and the vendor's (a cloud instance you control is fine), check that each admin hostname and path is not reachable. Do this only against systems you own or have written permission to test.
3. Separate read and act. Ask which interfaces can place, amend or cancel orders, or move funds, and what extra authorization those actions need beyond logging in.
4. Check lockout and alerting on operator logins. Ask whether operator interfaces lock out after repeated failures, and who is alerted.
5. Confirm logging that you can see. The JSDA standards ask outsourcing firms to be able to monitor and trace the contractor's access to customer data. Ask for read access to admin access logs, or a regular export, with source IP, user, action and record identifiers.
6. Ask about other tenants. If the vendor serves other financial institutions from the same code base, ask what was checked after this incident and get the answer in writing.
7. Rehearse an operator side incident. Most broker playbooks after 2025 focus on customer account takeover. Add a scenario where the attacker comes in through the vendor, and decide who can freeze order entry from operator paths.

If you build or run a trading platform or any admin plane

The steps below use common tools. Run them only against your own systems.

Find listening admin services on a host:

# Linux: list listening TCP sockets with the owning process
sudo ss -tlnp

# Show which addresses each service binds to; 0.0.0.0 or :: means all interfaces
sudo ss -tlnp | awk '{print $4, $6}' | sort -u

Check that an admin path is not reachable from outside:

# Run from a machine outside your corporate and vendor networks.
# Expect a connection failure or 403/404, never a login page or 200.
curl -s -o /dev/null -w "%{http_code}\n" --max-time 10 https://trading.example.com/admin/
curl -s -o /dev/null -w "%{http_code}\n" --max-time 10 https://ops.example.com/

Look for cloud firewall rules open to the whole internet:

# AWS: security groups with an ingress rule from 0.0.0.0/0
aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query "SecurityGroups[].{id:GroupId,name:GroupName}" --output table

# Google Cloud: firewall rules that allow any source
gcloud compute firewall-rules list \
  --filter="sourceRanges:0.0.0.0/0 AND direction=INGRESS" \
  --format="table(name,network,allowed[].map().firewall_rule().list())"

# Azure: NSG rules that allow inbound from any address
az network nsg list --query "[].name" -o tsv | while read nsg; do
  az network nsg rule list --nsg-name "$nsg" -g YOUR_RG \
    --query "[?direction=='Inbound' && access=='Allow' && (sourceAddressPrefix=='*' || sourceAddressPrefix=='Internet')].{nsg:'$nsg',rule:name,port:destinationPortRange}" -o table
done

Find Kubernetes ingresses and services that expose admin paths:

# Ingress rules with "admin", "ops", "manage" or "internal" in host or path
kubectl get ingress -A -o json | jq -r '
  .items[] | .metadata.namespace as $ns | .metadata.name as $n |
  .spec.rules[]? | .host as $h | .http.paths[]? |
  select((($h // "") + .path) | test("admin|ops|manage|internal"; "i")) |
  "\($ns)/\($n) \($h)\(.path)"'

# Services of type LoadBalancer or NodePort, which are often reachable from outside
kubectl get svc -A --field-selector spec.type=LoadBalancer
kubectl get svc -A --field-selector spec.type=NodePort

Restrict an admin location at the reverse proxy:

# nginx: allow the admin path only from the operations network and VPN
location /admin/ {
    allow 10.20.0.0/16;      # operations network
    allow 10.99.0.0/24;      # operator VPN
    deny  all;
    proxy_pass http://admin_backend;
}

Network restriction alone is the control that failed in this incident, so treat it as one layer. The admin application should also require its own phishing resistant authentication for every operator, independent of network location.

Spot guessing against an admin login in web logs:

# Count failed (401/403) requests per source IP to admin paths in a combined log
awk '$7 ~ /\/admin|\/ops|\/manage/ && ($9==401 || $9==403) {print $1}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

# Requests per minute to admin paths, to see bursts
awk '$7 ~ /\/admin/ {print substr($4,2,17)}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

Find orders that did not come from a customer channel:

The exact schema will differ, but most order tables record a channel, source or operator identifier. A query like this, run daily, surfaces orders entered from operator paths so a second person can review them.

-- Orders in the last 24 hours entered by an operator or system path, not by a customer session
SELECT order_id, account_id, created_at, channel, operator_id, source_ip
FROM orders
WHERE created_at >= now() - interval '24 hours'
  AND channel NOT IN ('web_customer', 'app_customer', 'api_customer')
ORDER BY created_at DESC;

-- Accounts with orders from more than one source IP in a short window
SELECT account_id, count(DISTINCT source_ip) AS ips, min(created_at), max(created_at)
FROM orders
WHERE created_at >= now() - interval '1 hour'
GROUP BY account_id
HAVING count(DISTINCT source_ip) > 2;

Admin planes of outsourced trading platforms: a control set

The table below collects the controls that the published remediation and the JSDA standards point to. It is a checklist for any firm running or buying a platform with an operator side, not an assessment of either company.

Why the count rose from 4,611 to 4,975

Iwai Cosmo's second report says the 364 extra customers were found when the investigators looked again at access records and also at communication records, and that this was not a new intrusion. That is a useful, specific lesson. Application access logs often show which pages or endpoints were called but not which records came back in each response. Network or communication logs can fill that gap, but only if they are retained and can be matched to sessions.

Three practical points follow for any team:

1. Log what was returned, not only what was requested. For admin functions that list or search customers, log the record identifiers returned, or at least the query parameters and the result count.
2. Keep communication logs long enough to scope an incident. The JSDA guideline already asks for retention of source IP and port, location and device data for later verification on the customer side. Apply the same thinking to operator traffic.
3. Publish counts as "at least" until scoping is complete. Revising a number upward is common and nothing to hide, but customers and regulators find it easier when the first notice says the count may grow.

What changed since the first reports

• The count went up. 4,611 customers on 16 October, 4,975 on 20 October.
• Unauthorized trades became public. The first reports from both companies covered only data. On 20 October Iwai Cosmo disclosed orders in 7 accounts and executions in 5, which it had already reversed on 14 October.
• The cause became more specific. Trade Works moved from "a settings deficiency in some admin functions" on 16 October to "a function that should only be used from a restricted environment was usable from outside" on 23 October.
• Brute force entered the picture. Iwai Cosmo's 21 October report is the first to mention a brute force attack. Trade Works has not used that term.
• The wording on data narrowed. Iwai Cosmo's 21 October report describes the data as viewable by the attacker, rather than leaked.
• A cost appeared. Trade Works estimated a loss of about 50 million yen on 23 October.
• MFA messaging. Iwai Cosmo now stresses that passkeys were not broken and asks customers who have not done so to set up passkeys and multi factor authentication.

Open questions

• Will either company publish a joint technical summary that reconciles "misconfiguration" with "vulnerability and brute force", and one path with two?
• Was the exposed function used by Trade Works staff, by Iwai Cosmo staff, or by both?
• How long was it reachable from outside before 14 October?
• What did Trade Works' detection see first: the guessing, the data access or the orders?
• Which other financial institutions run on the same system, and will they publish anything?
• Will the FSA's next monthly figures include these 5 or 7 trades? They were caused by an operator path rather than a customer account takeover, so it is not clear how they will be counted.
• Will regulators issue any guidance on operator side controls for outsourced trading systems?

What would have helped

None of what follows is a judgement on either company. Both detected the attack the same day, cut it off, reversed the trades and reported publicly. The question for everyone else is what makes the same class of event less likely, or smaller, on their own platforms.

Practices any team can use

• Treat the admin plane as an internet facing product, even if it is not supposed to be. Give it its own threat model, its own authentication and its own testing schedule.
• Make exposure a test, not an assumption. After every network, ingress or load balancer change, run an automated check from outside that admin hostnames and paths do not answer. Fail the change if they do.
• Require phishing resistant MFA for operators, not only for customers. Passkeys or hardware security keys bound to a named person, through a separate identity provider from the one customers use.
• Lock out and alert on repeated failures on every interface that accepts a credential or token, including maintenance APIs.
• Split read and act. No single admin function should both list customer details and place orders. Put order entry behind a second permission and a second person.
• Alert on operator orders in real time. Any order that did not come from a customer session should page someone.
• Log for scoping. Record which records each admin session saw, and keep communication logs that can be joined to sessions.
• Write outsourcing questions down. Use the JSDA outsourcing standards as a checklist with your vendor, and ask for evidence rather than a yes.
• Rehearse the vendor path. Run a tabletop where the attacker comes in through the contractor, and decide in advance who can freeze operator order entry.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists, in two modes: an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems. Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, with a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) supplies hardened drop in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses.

To be plain about the limits: this incident, as described by both companies, was a configuration and access control problem in a vendor run system, not a flaw in an open source package. Where these capabilities help is in the rest of the platform: the web frameworks, libraries and base images that admin consoles and trading front ends are built from. Keeping those on patched, signed components and rebuilding quickly when an advisory lands removes one class of admin plane weakness, so the configuration review can focus on the rest.

Where Safeguard fits

Honest scope first: Safeguard would not have prevented this incident, and nothing in Safeguard's scanning would have flagged that a particular admin function on a vendor's network was reachable from outside. That is a deployment and network configuration question, and it needs the reachability checks above.

What Safeguard does cover, at GA:

• Dependency and image scanning of the repositories and container images that make up an admin plane: safeguard scan --dir . for a repository, safeguard scan --image <name> for an image and safeguard scan --sbom <file> for an SBOM a vendor hands you, with JSON results under ./output. For a firm buying a platform, asking the vendor for an SBOM and scanning it gives you your own view of the components inside.
• Component search across projects: the platform shows which projects contain a given component and version, so when an advisory lands for a framework your admin console uses, you can see every place it ships.
• Vulnerability matching and reachability analysis to rank the vulnerable code paths your application actually calls.
• Policies and gates evaluated in the platform, so a build with a known exploited vulnerability in an internet facing component can be blocked or held for approval.
• Vendor and questionnaire tracking in the compliance suite, where the outsourcing questions in this post can be sent, answered and kept as evidence.
• Autonomous remediation with tested fix pull requests, off by default.
• The Safeguard CLI assistant, which can edit code and configuration and run commands only with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to add an IP allowlist to an nginx admin location or to write the reachability check as a CI step, and approve each change.

Safeguard's first party dynamic testing (DAST), which performs safe, scoped testing against verified targets, is still maturing and should be treated as early access; it is not a substitute for the external reachability checks described above.

Common mistakes and troubleshooting

• "Our customers use passkeys, so we are covered." Passkeys protect customer login. This incident went around it through an operator function.
• Relying on network location alone for admin access. Trade Works' own explanation is that a function meant for a restricted environment was usable from outside. Add strong operator authentication as a second layer.
• Testing reachability from inside. A curl from the office or the VPN will reach the admin page and tell you nothing. Test from a network you do not normally trust.
• Forgetting non HTTP paths. Admin functions can also be exposed over database ports, message queues, SSH or vendor specific protocols. Include them in the inventory.
• Lockout on customers but not operators. Check every authentication point, including service accounts and maintenance APIs.
• One permission for everything. If the same admin role can read customer data and place orders, an exposure of that role is a trading incident, not only a data incident.
• Logs that only show the URL. When you need to know which customers a session saw, a list of requested URLs may not be enough. Log record identifiers.
• Asking vendors yes or no questions. "Are your admin interfaces protected?" gets a yes. "Send the list of admin interfaces, their allowed sources and last week's external reachability test output" gets evidence.
• Assuming another tenant's incident cannot be yours. If your vendor serves several firms from one code base, ask what was checked on your instance.

FAQ

What happened at Iwai Cosmo Securities?

On 14 October 2026 an unauthorized third party accessed the internet trading system that Trade Works operates for Iwai Cosmo. Names, email addresses and other details of 4,975 customers were exposed, and orders customers did not intend were placed in 7 accounts, with 5 executing. The trades were reversed the same day at no cost to customers.

Were customer passkeys or multi factor authentication broken?

No. Both companies say the customer login path was not bypassed. Iwai Cosmo says passkey authentication was not broken. Trade Works says the attacker abused a misconfigured admin function rather than the customer login.

What was the root cause?

Trade Works says a settings flaw in part of its system's admin functions meant that a function intended for use only from a restricted environment could be used from outside. Iwai Cosmo describes a third party exploiting a system vulnerability with a brute force attack. Neither has published the specific function or method.

How do the broker's and the contractor's explanations differ?

Trade Works calls it a configuration flaw and says the attacker used the exposed admin function to place the trades. Iwai Cosmo calls it a vulnerability exploited by brute force, and describes the trades as an attack on the order management system. The broker also later described the data as viewable by the attacker rather than leaked. The companies have not published a single reconciled account.

What customer data was exposed?

Name, email address and other fields that have not been itemised. Iwai Cosmo says trading PINs were not included and that passwords needed for trading are masked and could not be seen. Trade Works says it has not confirmed that any customer passwords were obtained.

Why did the number go up from 4,611 to 4,975?

The companies re-examined communication records as well as access records and found 364 more customers whose data had been exposed during the same intrusion. They say it was not a new incident.

Did customers lose money?

According to both companies, no. The accounts with unintended trades were restored to their pre-trade state on 14 October, and Trade Works says no unauthorized outflow of customer funds was confirmed. Trade Works expects a loss of about 50 million yen, which it says it will bear.

Are other brokers that use Trade Works affected?

Trade Works says it inspected the systems it provides to other financial institutions, took necessary measures and found no similar event. It has not named those institutions.

I am an Iwai Cosmo customer. What should I do?

Check your notices and trade history, ignore emails or calls that claim to be from Iwai Cosmo unless you can verify them, log in only from a bookmark or the official app, and set up passkeys and multi factor authentication if you have not. The customer consultation office is on 0120-405-546.

Would Safeguard have prevented this?

No. This was a configuration and access control issue in a vendor operated system. Safeguard helps with the components and images an admin plane is built from, with vendor SBOM review and with tracking vendor questionnaires, but it would not have detected that a specific admin function was reachable from outside.

Fix it without waiting for upstream

This incident had no CVE and no upstream package fix, so the section below applies to the open source components and container images that trading front ends and admin consoles are built from, not to the configuration flaw itself. When an advisory does land for one of those components, these are the ways to close the gap quickly.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Iwai Cosmo, Trade Works or their systems. Each is a real Safeguard session, and each intro says how the same flow would apply to an admin plane or a trading front end.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For an admin console, you would run /scan . in its repository, then ask the assistant to add an IP allowlist to the nginx admin location and a CI step that checks the admin path is unreachable from outside, approving each edit and command as it runs.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. A platform team could pick the folder holding its ingress and security group definitions, ask for every rule open to the whole internet to be listed and tightened, and approve or deny each file change itself.

Click through it at your own pace, or open it full screen.

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. If an advisory lands late at night for a framework your admin console uses, the on call engineer could approve the rebuild from a phone, and deny anything that touches production network rules until a second person has looked.

Click through it at your own pace, or open it full screen.

To try it on your own services, download Safeguard and follow the CLI docs. For more on third party risk, read our post on the IDCF Cloud ransomware incident and third party risk. For other breaches in Japan this month, see the Japan breach wave involving Yamato, Nikkei and FANCL, and for the wider month, October 2026 security incidents and what would have helped.

Quick check

Sources

• Iwai Cosmo Securities: Report on personal information leak and unauthorized trading due to unauthorized access (21 Oct 2026, Japanese)
• Iwai Cosmo Securities: Leak of customer information due to unauthorized access to an outsourced contractor, 2nd report (20 Oct 2026, Japanese)
• Iwai Cosmo Securities: 2nd report, corporate site (20 Oct 2026, Japanese)
• Iwai Cosmo Securities: 1st report, corporate site (16 Oct 2026, Japanese)
• Iwai Cosmo Holdings: Timely disclosure on the leak at Iwai Cosmo Securities (16 Oct 2026, Japanese, PDF)
• Trade Works: Notice of unauthorized access to a system we provide (16 Oct 2026, Japanese, PDF)
• Trade Works: Progress of disclosed matter, unauthorized access to a system we provide (23 Oct 2026, Japanese, PDF)
• Trade Works: Corporate site and IR news list (Japanese)
• Japan Securities Dealers Association: Revision of the guideline on preventing unauthorized access in internet trading (15 Oct 2025, Japanese, PDF)
• Financial Services Agency: Beware of unauthorized access and trading on internet trading services (Japanese)
• Financial Services Agency: Unauthorized access and trading statistics through September 2026 (9 Oct 2026, Japanese, PDF)
• Impress Internet Watch: Iwai Cosmo Securities, 4,975 people's data leaked and 7 unauthorized trades (21 Oct 2026, Japanese)
• Innovatopia: Unauthorized orders at Iwai Cosmo despite mandatory MFA; settings flaw in contractor's admin function (Japanese)
• Money Post (Fisco): Trade Works shares fall after disclosure of unauthorized access (16 Oct 2026, Japanese)
• Hakky Handbook: Cyberattack on Iwai Cosmo Securities, unintended trades executed (Japanese)
• OWASP Authentication Cheat Sheet
• OWASP Credential Stuffing Prevention Cheat Sheet
• CISA: Implementing phishing resistant MFA (fact sheet, PDF)

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.