Weekly Cybersecurity Intelligence Report: Cyber Threats and Breaches 05 Oct to 11 Oct 2026

Overview: Denmark’s Ministry of Research, Education and Digitalisation disclosed on 05 October 2026 that unauthorized parties used a small private Danish company’s lawful lookup access to the Central Person Register, known as CPR, to pull data on approximately 8.8 million people, including current residents, people who have emigrated and the deceased.

Impact: The CPR holds records on roughly 11 million people, so this incident reached about 4 in 5 of everyone in the register. Exposed fields included names, addresses, and CPR numbers, the identifier Danes use across nearly every government and financial interaction. The CPR administration notified Datatilsynet, the Danish data protection authority, on Sunday 04 October, and Datatilsynet published its own notice on 05 October. Records of people registered with name and address protection were not included in the unauthorized access.

Details: The unauthorized access ran for about 10 days in September 2026 before an employee of the register’s administration noticed a spike in automated queries on the evening of 02 October. The register has since blocked the company’s access, and Danish police have opened an investigation. Attackers made a very large volume of automated lookups through the company’s legitimate access channel to identify and harvest valid CPR numbers at scale, rather than exploiting a software flaw. Denmark’s government has not yet disclosed how the attackers reached the company’s own systems in the first place, which remains the open question in the investigation.

Remediation guidance: Rate-limit and anomaly-monitor any third-party integration that can perform bulk lookups against a sensitive national or customer database. Require re-authentication and step-up verification for high-volume query patterns from any single credentialed account. Audit every external party holding standing lookup rights to sensitive registers, and revoke access that is broader than the specific use case requires.

Overview: UK online retailer ASOS confirmed on 06 October 2026, in a filing to the London Stock Exchange, that attackers compromised a third-party platform the company uses for customer communications, after shoppers received an unauthorized app notification reading “ASOS HACKED.”

Impact: ASOS said names and contact details were possibly exposed through the compromised notification platform. The company stated it does not believe payment card information or account passwords were affected, and that its core website and app, along with day-to-day operations, were not disrupted. The exact number of affected customers has not been disclosed.

Details: ASOS’s later update to customers describes the entry point: an attacker impersonated a trusted contact of an ASOS employee, obtained that employee’s login credentials, and used the access to reach third-party platforms ASOS uses, including the mobile app notification system. A group calling itself Xuanye Group, on a Telegram channel created the same day, claimed it had “fully compromised” a Snowflake instance tied to ASOS. Neither ASOS nor Snowflake has confirmed any Snowflake compromise, and Group-IB reported finding no leaked data samples that support the claim. ASOS restricted access to the affected notification platforms and is working with external advisers and authorities, including the UK National Cyber Security Centre.

Remediation guidance: The entry point was a social-engineered employee credential, so phishing-resistant multi-factor authentication on every employee account that can reach a vendor console matters as much as MFA inside the vendor platform. Treat every third-party platform with push, email, or SMS send capability to customers as a brand-risk asset requiring its own access review, not just a marketing tool. Confirm which vendor platforms can message your customers directly, and verify each one enforces multi-factor authentication on every account with send privileges. Pre-stage a customer communication plan for a compromised-vendor scenario, since the notification itself was the first signal customers received.

Overview: South Korea’s National Office of Investigation announced on 06 October 2026 that it had opened a formal criminal investigation, assigning 28 officers across four teams, after seven financial institutions, including Shinhan Bank, KB Kookmin Bank, Hana Bank, BNK Busan Bank, Yegaram Savings Bank, Welcome Savings Bank, and Hyundai Capital, reported data exposures. The intrusions ran from late September to early October.

Impact: Reported figures put the confirmed exposure at roughly 66,000 individuals and 2,200 corporate records across the affected institutions as of 06 October, with Shinhan Bank’s share at 25,729 customers through a loan-agent inquiry service and Yegaram Savings Bank separately disclosing about 40,000. Woori Bank and NH NongHyup Bank were targeted but have not confirmed a data leak.

Details: The intrusions reached internal, employee-facing, and partner-facing systems rather than customer-facing banking services, and South Korea’s Financial Services Commission has identified 28 distinct IP addresses linked to the attempts. On 07 October, CrowdStrike published its analysis of the campaign, tracing the Shinhan and Yegaram intrusions to a single operator running ARTEX, an open-source, LLM-based penetration-testing agent built in China, and assessing with moderate confidence that the actor is Chinese-speaking and financially motivated, based on the tool and on Chinese-language prompts found on the attackers’ server. Genians’ security center had earlier flagged Chinese-language ARTEX console strings on a server tied to the Shinhan attack, and President Lee Jae-myung said on 06 October that signs had emerged that AI agents were used in at least some of the attacks. The ARTEX developer converted the project to closed source on 08 October. A Korea Financial Security Institute official told The Herald Business that attackers queried systems to extract data rather than attempting direct fund transfers.

Remediation guidance: Segment employee- and partner-facing systems from customer-facing infrastructure with the same rigor applied to the external perimeter, since this campaign succeeded entirely on the internal side. Rotate credentials and tighten monitoring on any loan-agent, mobile work-support, or sales-support tool that queries customer records, which is where each confirmed exposure originated. Validate that partner-facing and internal tooling cannot be reached or abused at the volume and speed an automated agent runs at; this campaign shows the speed is now real, with the full cycle from reconnaissance to data extraction compressed into hours per target.

Overview: The FBI and U.S. Secret Service issued a joint cybersecurity advisory on 06 October 2026 warning that an ongoing campaign dubbed FortiBleed has compromised more than 86,644 internet-facing Fortinet FortiGate firewalls and SSL VPN gateways across 194 countries.

Impact: The advisory states the attack chain has served as an initial access point sold to affiliates of the INC/Lynx and Payload ransomware operations. Attackers create new administrator accounts for persistence and, in some cases, delete or modify existing accounts, which has locked legitimate administrators out of their own devices.

Details: The campaign has run since June 2026 and relies entirely on reused and previously leaked credentials, credential stuffing, and password spraying rather than a new software vulnerability; the advisory does not cite any CVE. It came to light when the attackers exposed their own backend server, which made their tracking files and affiliate workflow visible to researchers. Because no single CVE or patch addresses the root cause, the agencies describe remediation as requiring credential resets, account audits and configuration review, not patching alone.

Remediation guidance: Restrict FortiGate administrative and VPN management interfaces to trusted hosts or a local-in policy, and remove internet-facing administration entirely where it is not operationally required. Terminate all active administrative and VPN sessions and reset every Fortinet credential, prioritizing internet-facing devices. Require phishing-resistant multi-factor authentication on all remote access and administrative accounts, and audit for unrecognized admin accounts or REST API keys.

Overview: Osaka Metropolitan University disclosed on 05 October 2026 that a suspected ransomware attack on its virtualization infrastructure, which began in the early hours of 02 October, had taken approximately 500 servers offline across all five campuses and potentially exposed data belonging to at least 130,000 current and former students, faculty, and staff.

Impact: The university cancelled in-person classes across all faculties through 08 October, with classes set to resume 09 October. Investigators said much of the university’s backup data was also encrypted in the attack, which complicates recovery beyond simply restoring from backup. Entrance exam and enrollment systems stayed up because they are hosted on external servers, and the electronic medical record system at the university hospital was unaffected. The university has not confirmed whether data was exfiltrated, only that it is investigating with outside specialists.

Details: The university has stopped short of formally confirming ransomware, describing the incident as a suspected ransomware attack while forensic work continues. Compromising the hypervisor layer encrypts every virtual machine at once, which is why 500 servers and the backup data fell together. The encryption of backup systems alongside production servers is a pattern consistent with attackers deliberately targeting backup infrastructure before deploying ransomware, to remove the recovery option before it can be used (MITRE ATT&CK T1490, Inhibit System Recovery).

Remediation guidance: Maintain at least one backup copy that is offline, immutable, or otherwise unreachable from the production network an attacker could compromise. Test backup restoration on a regular schedule rather than assuming backups are viable until the moment they are needed. Segment backup infrastructure management from general domain administration, since backup systems are frequently reachable through the same credentials as everything else.