Three Sources, Three Descriptions of One Bank Breach. “AI Hacked Shinhan” Is the One Nobody Has Confirmed.

Three descriptions of the same bank breach are circulating. Korean outlets say an attacker slipped past identity verification on a loan-agent portal at Shinhan Bank and then looped through customer identifiers to pull records. One English-language outlet calls it a credential-stuffing attack run with advanced AI tools. Wire copy says AI may have been involved. Only the first description comes with a mechanism, and none of the AI claims has been confirmed by the bank or by regulators. This piece separates what is established from what is suspected, because the difference changes what a bank should fix.

What is confirmed

According to the Korea Herald (2 October 2026), Shinhan Bank confirmed a breach on Wednesday 30 September and disclosed the next day that about 25,000 customers were affected. The exposed data were names, phone numbers, annual income figures and calculated loan limits, plus 66 resident registration numbers and 97 CI records. CI, or connecting information, is the identifier Korean services use to link one person across platforms. CryptoBriefing, which published the same day, calls the 97 items ‘encrypted identifiers’ rather than CI records, so the label is not uniform across outlets.

Shinhan was not alone. The Korea Herald reports that KB Kookmin Bank disclosed on Friday 2 October that 119 customers had names, phone numbers, addresses and resident registration numbers exposed through an employee mobile support system. Hana Bank reported 89 customers affected through its ODS sales support system, with names, addresses, contact details, employer names and resident registration numbers involved. BNK Financial Group reported an incident involving 11 records belonging to outsourced employees, not customers. Hana said the affected system is separate from its internet and mobile banking and that customers’ financial transaction information was not leaked. KB said its customers’ banking transactions were unaffected. Shinhan said its general retail apps, including Shinhan Super SOL, were not affected, according to Herald Corp.

On the regulatory side, the Financial Supervisory Service began an emergency on-site inspection, a spokesperson confirmed to Yonhap, as relayed by Insurance Journal. The Financial Services Commission held an emergency meeting with the FSS, security officials and industry representatives on 2 October and ordered banks to check externally accessible systems and strengthen authentication and access controls, per the Korea Herald. The Korea Financial Security Institute is conducting an on-site investigation into the attack vector and whether Shinhan’s security systems worked as intended.

The numbers say this was a Shinhan story

Adding the three banks that reported customer counts gives 25,000 plus 119 plus 89, or 25,208 people. That total is our own sum of figures from the Korea Herald, and Shinhan’s is rounded (‘about 25,000’ in every source we read). Even so, Shinhan accounts for roughly 99.2% of the combined count. The 208 customers at KB Kookmin and Hana together are less than 1%. BNK’s 11 are outsourced employees and are left out of the sum.

The sensitivity profile is also lopsided. Of Shinhan’s roughly 25,000 affected customers, the two highest-risk identifiers appear in 66 and 97 records. If those were distinct people, which the sources do not say, that would be at most 163 customers, about 0.65% of the Shinhan total. The bulk of the exposure is names, phone numbers, income and loan limits. That is still useful to a fraudster crafting a convincing call about a loan, as NordVPN’s Korea country manager Sungho Hwang noted when he said the exposure of both personal and financial information makes this breach worrying and can fuel personalised scams. But it is a different harm from a leak of resident registration numbers at scale. The contrast also matters for the banks’ own reassurance: ‘no transaction data leaked’ is a statement about money movement, not about identity-fraud risk.

How the attack worked, as far as the sources say

Herald Corp describes the entry point as a security gap in the loan-agent service on Shinhan’s mobile website, a portal built for loan solicitation agents to track applications they submitted. The attacker reportedly got past standard authentication without completing the normal identity-verification process, then ‘repeatedly cycled through randomized customer identification numbers and other query values’ to retrieve customer records. The same report says the investigation is expected to examine whether the bank’s systems should have flagged repeated queries from one source or access from unusual IP addresses.

That is a recognisable pattern, and it is not credential stuffing. Credential stuffing, in the standard definition CryptoBriefing itself gives, tests username and password pairs leaked in earlier breaches against a new service at scale; it works because people reuse passwords, and it needs valid credentials to succeed. What the Korean reports describe is a different failure. First the authentication check is bypassed, so no valid login is needed. Then the attacker enumerates identifiers, trying values in sequence or at random and reading whatever the service returns for each. This second step is a broken access control problem: the service answers a query about a customer record without confirming that the requester is entitled to that record. (This is general security background, not something the reporting establishes about Shinhan’s code; OWASP’s Top 10 list ranks broken access control first in its 2021 edition.)

Why does the distinction matter? The fixes differ. Credential stuffing is countered with multi-factor authentication, breached-password screening and login rate limits. A bypass-plus-enumeration attack is countered by server-side authorisation checks on every record request, non-guessable identifiers, and monitoring for a single source making thousands of lookups. A bank that reads the headline as ‘AI credential stuffing’ and responds with stronger passwords would leave the actual door open. We take the Korean outlets’ description as the working one because it is the only version with a described mechanism, and we note that CryptoBriefing’s dates for the intrusion (early hours of 29 into 30 September) and its framing differ from the Korean reports.

Where the AI claim comes from

The AI claim has three layers, and they are not equally strong. First, Yonhap cited cybersecurity experts who said attackers probably used AI agents to scan for weaknesses and reach the loan-recruiter service, as relayed by Insurance Journal, which presents this as suspicion and not a confirmed finding. One of those quoted, Mun Chong-hyun, a director at the security firm Genians, said AI tools built for defence can be a ‘double-edged sword’ when misused. Second, the Korea Herald reports that security analysts found traces of ARTEX AI, described as an AI penetration-testing tool, on a server suspected of being linked to the attack, and states that neither the bank nor the financial authorities have officially confirmed whether the tool was used. ‘Suspected of being linked’ is two hedges in one phrase. Third, on 6 October, South Korea’s President Lee Jae Myung said there were signs AI models had been used in recent bank hacks, and the National Office of Investigation is examining them, according to a New York Times report summarised by Just Security. The item gave no detail on who was responsible.

Read together, these establish that officials are taking the possibility seriously. They do not establish that AI did anything. A tool trace on a server only shows that a tool was present on that server, not that it was used against Shinhan’s portal, and certainly not that it was what found the flaw. Herald Corp itself says the exact tools and methods will not be confirmed until investigators finish their work.

Why enumeration does not need AI

Cycling through randomised identifiers against an endpoint that does not check authorisation is something a twenty-line script can do. Scanners that probe for this pattern have existed for years. What AI could plausibly change is the first step, discovering that a peripheral service has a bypass at all, by reading traffic, guessing parameter names or generating test variants faster than a human tester. That is a speed claim, not a new-capability claim, and nobody has shown it happened here. If the flaw was an ordinary bypass, then the story is about a portal that was reachable from outside, with weak authorisation, and about monitoring that did not notice a long run of failed or unusual lookups, whoever or whatever wrote the script.

There is a fair counter-argument, and it should be stated plainly. Even if the bug is old, an attacker who can test thousands of services cheaply will find old bugs sooner, which shrinks the time defenders have to find them first. Mun’s point about misuse of defensive tools gestures at this. Under that reading, the AI label is not wrong about the trend even if it is unproven about this incident. The difficulty is that the label gets applied to incidents before the evidence exists, which makes it harder to judge when it is true.

What the peripheral-channel pattern suggests

Look at where each bank was hit: a loan-agent portal used by third-party solicitors at Shinhan, an employee mobile support system at KB Kookmin, a sales support system at Hana, and outsourced-employee data at BNK. None of the reports describes a breach of the core banking or consumer app. These are channels built for staff and partners, where authentication is often looser and the internal-facing assumption (‘only our agents use this’) quietly stops being true once the service sits on the internet.

• Inventory every service reachable from outside the network that was built for staff, agents or contractors, and confirm each enforces per-record authorisation on the server, not just a login screen.
• Replace sequential or guessable customer identifiers in those services with unpredictable ones, and rate-limit lookups per session and per source address.
• Alert on repeated lookups of many distinct records from one source, since Herald Corp notes this is exactly what investigators will ask whether the bank detected.
• Treat ‘no transaction data leaked’ and ‘no identity data leaked’ as separate claims in customer communications.

What the evidence does not establish

Nothing public confirms that AI was used at Shinhan, how the authentication bypass worked in technical terms, how many queries the attacker ran, how long the access lasted, or whether the 66 and 97 high-risk records overlap. The bank has said it cannot yet reasonably quantify the financial impact, per Insurance Journal. The outlets also disagree on the intrusion dates and on labels such as CI records. Those gaps will close only when the Korea Financial Security Institute and the FSS publish findings. Until then, the defensible summary is narrow: a peripheral portal failed to enforce who could see which record, about 25,000 people’s personal and financial details were exposed, and the AI explanation is a hypothesis. This analysis is current as of 6 October 2026.