AI agents in bank accounts, public websites offline: Untangling the week’s cyber alarms

A banking app would not let you pay. A government website went dark. News reports described AI-assisted bank intrusions and urgent repairs to software that powers a vast share of the web. Put together on the same screen, the events can look like a single cascading cyberattack.

They are not one proven attack. Some banks have reported real customer-data incidents. A viral claim about AI agents in US bank accounts describes a different access-control problem. Many public websites were taken offline to prevent an intrusion. And the widespread disruption to British banking apps on Tuesday came from a power failure at a cloud data center, according to Google's incident report. The distinctions are not comforting word games. They determine what needs fixing, what customers should do, and where artificial intelligence is making security better or worse.

The viral US bank-agent claim needs its missing context

A widely shared post says major US banks have detected unauthorized AI agents in customer accounts, and notes that JPMorgan, Bank of America and Citi are restricting outside-agent access. Its wording traces to an October 22 Axios investigation, but the headline shorthand can change the meaning. Axios says such access is generally with a customer's permission and login credentials, even though it may violate banks' rules against allowing an automated third party to log in as that customer. Anonymous sources also described cases in which agents contacted call centers or appeared to act outside user instructions. The report did not identify a compromised bank, a confirmed unauthorized transfer, or a named customer's loss from these agents. Nor did it tie any agent access to the PHP flaws.

The named banks' responses should not be conflated with named breaches. Axios says JPMorgan, Bank of America and Citi are restricting outside agent access, while a Morgan Stanley spokesperson said it had not seen rogue AI agents accessing its platforms. On its October 13 earnings call, JPMorgan's CEO described a policy against unvetted outside agents; its chief financial officer said the bank blocks credential-sharing and screen-scraping services where possible because they are insecure, while working toward a safer way to let customers use agents. Axios reported that banks are considering read-only access as a middle ground. In other words, the issue is how to let a customer delegate useful work without giving a tool their full banking login or unreviewed power to move money. Concern about that risk is warranted; a claim that AI independently hacked these three banks is not supported by the report.

The bank incidents are real. The connections are not established.

On October 21, State Bank of India disclosed that it was examining a cache of roughly 375,000 records found on the dark web. Its preliminary review identified 3,897 customer records containing personal information, according to Hindustan Times’ account of its stock-exchange filing; Reuters separately confirmed the smaller personal-information count. The reported details include names, phone numbers, birth dates, addresses and identifiers associated with branches and loan leads. The bank was alerted on October 16 and has engaged outside forensic investigators. It says its core operations have not been materially affected and customer balances are safe.

That is an important disclosure, but not proof that 375,000 customers were breached. Nor has the bank publicly established in the material reviewed here how the records were obtained, when the exposure began, or whether its own systems or another party were the source. The difference between records inspected and customers affected is especially important in an evolving investigation. No public evidence reviewed for this story ties SBI's incident to the new PHP flaws or to an AI attacker.

South Korea's banking story is different. In an October 14 English-language statement, the country's Financial Services Commission confirmed intrusion incidents at 16 financial companies around the period of Shinhan Bank's incident. They span commercial and savings banks, lenders, payment firms and other financial businesses; they are not “16 banks.” Four commercial banks named in the regulator’s Korean-language release were Shinhan, KB Kookmin, Busan and Hana. Across the 16 institutions, it estimated about 100,000 records of personal information had leaked. At that point it had not confirmed leakage of account passwords or card numbers that could directly enable fraudulent payment. It said whether the incidents shared an attacker and exactly how AI figured in them were still under investigation.

There is nonetheless concrete evidence that AI tools were used in a campaign against South Korean finance. CrowdStrike's October 7 investigation found attacker-controlled files and Claude Code session histories associated with activity from late September into early October. It described use of an automated penetration-testing tool called ARTEX alongside language models. CrowdStrike itself said the precise number of organizations affected was unconfirmed and treated its assessment of the actor as provisional. The regulator's confirmed incidents and CrowdStrike's attacker-tool investigation should be read together, not merged into a claim that AI independently broke into all 16 firms. These incidents also predate the October 21 PHP disclosure.

A third bank-related story broke on October 21. Security company Straiker reported that a criminal group used a network of AI agents built with Claude, Grok and Kimi models to attack more than 400 Latin American financial targets over several months. Those targets include banks, payment businesses and fintechs. Straiker says it inspected the group's own working environment and a September 24 snapshot of a store containing account-related data and credentials.

This investigation merits attention precisely because it describes AI as part of an attack workflow, not just a tool for writing a phishing email. But 400 targets are not 400 independently confirmed breached banks. No public list of affected institutions or bank-by-bank accounting of loss was available in the reviewed material. Straiker's report provides the bulk of the public detail; the company also sells AI-security services. That does not make its research false. It makes attribution, independent checks and its anonymization limits essential. None of the available accounts links that campaign to the PHP emergency.

Quest: a confirmed intrusion, not an established AI attack

The same distinction matters in healthcare. In an October 22 SEC filing, Quest Diagnostics said it discovered unauthorized access to its Quanum Lab Services Manager on October 21. Some healthcare clients use that system to order tests and retrieve results. Quest believes an unauthorized party accessed certain patient records, but the scope remains under investigation. The filing does not identify an attacker, explain the access method or establish an AI role.

Quest’s public incident notice, checked on October 23, says it paused access to Quanum LSM while investigating. It says core operations remain running and direct-customer laboratory and electronic-medical-record ordering interfaces were unaffected. The SEC filing says Quest notified federal law enforcement and engaged outside cybersecurity experts. Those are response measures, not evidence that the possible consequences for patients have been resolved.

Importantly, Quest told the Associated Press that its investigation indicated the breach was unrelated to the PHP issue. Bright found no established AI involvement in the disclosures reviewed. Quest therefore belongs in the account of the week’s cyber incidents, but not in a tally of confirmed AI-driven or PHP-related attacks. The number of affected patients and the particular records involved were still unknown in the reporting reviewed.

One very visible bank outage was not a hack

On October 20, Revolut reported problems across functions including sign-in, card payments, transfers and cash withdrawals. Associated Press reporting also named Lloyds, Halifax and HSBC among banks reporting disruptions. For someone stranded at a checkout, that is a serious service failure whether or not a hacker is involved. Revolut said customer money and data remained safe. Its UK status page reported all systems operational when Bright rechecked on October 22; that current status should not be mistaken for a continuing outage.

The cause, however, was not mysterious by Thursday. Google's preliminary incident report says an electrical power interruption at its London cloud facility, coupled with a fault in the automatic transfer to backup generators, disrupted services from about 7 a.m. to 1:10 p.m. British time on Tuesday, with a small tail of recovery afterward. The European Banking Authority has asked Google for details; an outage affecting payments raises resilience questions even without a data theft. But adding those bank outages to a count of “hacked banks” would mislead readers and obscure a different problem: dependence on infrastructure that can fail together.

Why governments chose to go dark

The PHP emergency is both broader and more specific than a viral claim that “most of the internet is hacked.” PHP's maintainers released repairs on October 21 for two critical flaws, CVE-2026-109618 and CVE-2026-109619. Under affected conditions, an attacker without an account can potentially run code on a web server. The PHP Foundation says researchers demonstrated working paths. The project tells operators of PHP installations serving web requests to update promptly to a fixed build or documented vendor backport. This is a server-operator problem, not a patch visitors can install on their phones.

The UK National Cyber Security Centre advised operators unable to apply a fixed update or temporary mitigations promptly to consider taking an affected system offline. That guidance explains a great deal of the public shutdowns. In Britain, the National Archives announced service disruption and the Office for Budget Responsibility said it took its site down. Alliance News reported that a government minister told lawmakers on October 22 that 32 government services were unavailable and four partially unavailable. That is a time-specific, secondhand count, not a list of breached agencies; a direct parliamentary transcript was not yet available in this review.

The Netherlands government said it had temporarily withdrawn public-information and login sites, including Overheid.nl, MijnOverheid and DigiD, as a precaution. The Dutch cyber-security center even took its own website offline. Germany's federal IT provider explicitly said its government-site shutdown was not a hacker attack. Similar precautionary pauses reached Finland, France, Belgium, the Czech Republic and Japan, according to Reuters' cross-country account. Canada and New South Wales also reported protective government closures. The geographic breadth made this a global service story, but does not transform precautions into confirmed compromises.

None of that means the emergency was invented or harmless. People lost access to government information, public logins and some transactions. It means a shutdown can be a sign that defenders are acting, rather than proof an intruder has already won. We found no confirmation that the named precautionary government closures resulted from successful PHP intrusions or stolen data. That is a statement about what is public so far, not a guarantee that no breach will emerge.

Attack traffic adds urgency without supplying that missing proof. Amazon's security team observed an attempt against one of its honeypots on October 17, before the patch announcement, plus further attempts. It cautioned that it does not know whether the early attempts would have worked against real sites. Cloudflare has reported attack traffic against customers and deployed protective rules. An attempted exploit in telemetry, a website temporarily offline, and a verified loss of information are three different findings.

The Bright side is a response chain, not a promise

AI appears on both sides of this week's reporting. Straiker and CrowdStrike describe attackers using AI systems to speed or coordinate operations. That makes speed and scale a real concern, even where victim counts and individual outcomes remain uncertain. Yet the answer is not to pretend those systems can simply be switched off or that one safety filter will solve the problem.

There is also specific evidence of defensive progress. The PHP Foundation's account says a core developer noticed part of the underlying problem in 2024; Calif demonstrated remote-code execution from that root cause on August 11; OpenAI independently reported the same root cause, and Wiz and OpenAI reported additional routes. OpenAI describes AI assistance in its own contribution, but that corporate account is not a reason to erase the earlier maintainer work or other researchers. Humans validated the issue and shipped the PHP fixes. After disclosure, hosting operators, incident responders and security networks began the difficult work of distributing and verifying protection. Cloudflare's rules can help buy time, but do not replace the runtime fix. Amazon's threat data can tell investigators where to look back, but cannot certify which sites were breached.

In the Latin American investigation, Straiker says Anthropic revoked a credential used for the attackers' Claude access after notification, and that xAI was examining reported misuse. That is a concrete containment step, not proof that previous exposure was undone or all misuse of commercial models stopped. In Korea, the regulator reports that affected institutions were directed to block attacker infrastructure, apply patches, temporarily stop relevant services when needed, and notify customers. Those mundane steps matter as much as a clever detector. The hopeful element is the ability to find, disclose, patch and contain faster while keeping human accountability for what the evidence actually shows.

For website operators, the PHP team's fixed releases and advisories are the starting point. Confirm the actual PHP runtime and vendor backport status, install the fix, restart affected workers and review suspicious activity, including logs back to October 17 where available. If you cannot promptly patch or apply temporary mitigations to a vulnerable public service, consider taking it offline under the NCSC's risk-based guidance. For bank customers, there is no universal “PHP emergency” action: read notices in your bank's official app or website, check transactions, and be skeptical of calls or texts asking for credentials or one-time codes. If you use a financial AI assistant, do not give it your banking password; check the bank's permitted connections and what you authorized. If a payment appeared to fail during an outage, check whether it actually settled before trying again.

The honest picture is neither “everything is fine” nor “the whole internet has been hacked.” It is multiple failures and defenses unfolding together: confirmed breaches, unverified claims, protective shutdowns, a non-cyber cloud outage, and a serious new software repair. The way through is to keep those categories separate, deliver the fixes, and measure outcomes as investigations catch up with the headlines.

Reporting note: Evidence and service-status checks updated October 22, 2026. This is a bounded source-based review, not an investigation of affected systems. Shutdown counts are dated reports, not a live availability dashboard. Bright has not inspected stolen datasets, run exploit code or independently measured the security products discussed. Material updates and corrections will be dated.

Update, October 23, 2026: Added Quest Diagnostics’ disclosure, its operational notice and reporting distinguishing the incident from the PHP emergency. Other evidence and service-status checks remain dated October 22 unless stated.