Daily Digest

Over 450,000 current and former University of Nottingham students just had their personal data dumped online by a notorious hacking group. The breach exposed everything from names and addresses to passport numbers and financial details — and it’s part of a much larger global attack spree. If you’ve ever studied or worked at Nottingham, your data may already be circulating on the dark web. This isn’t just another university leak; it’s a stark warning that even top-tier institutions can fall victim to sophisticated cybercriminal campaigns.

**What exactly happened** The University of Nottingham confirmed this week that a cybercriminal group breached its student records system, accessing a “significant amount of data.” The attack was claimed by ShinyHunters, a well-known extortion gang, who posted a 40GB archive of stolen documents on their dark web leak site. The university has reported the incident to the UK’s Information Commissioner’s Office and Action Fraud. They’re now working with a third-party platform provider on a forensic investigation — but for the affected students, the damage is already done. **Who is affected and how** According to breach notification service Have I Been Pwned, the breach impacts 454,600 individuals — both current students and alumni. The stolen data includes full names, home addresses, IP addresses, phone numbers, dates of birth, and even sensitive details like ethnicities, disabilities, and passport numbers. Financial information was also compromised, including student finance data, billing records, credit card details, and payment histories. This level of exposure puts victims at serious risk of identity theft, phishing attacks, and financial fraud. **The real-world impact and consequences** For students and graduates, this isn’t just a privacy scare — it’s a long-term threat. With passport numbers and financial data in the hands of criminals, victims may face fraudulent loan applications, unauthorized transactions, or targeted social engineering attacks. The university’s reputation also takes a hit. As a top-20 UK institution and global top-100 university, this breach undermines trust in its data security practices. It also comes hot on the heels of a similar breach at the University of Oxford, suggesting a worrying trend in higher education. **Technical breakdown** ShinyHunters is exploiting Oracle PeopleSoft systems — enterprise software used by universities and large organizations for campus administration, HR, and finance. The gang claims to use a “gadget chain” of zero-day vulnerabilities combined with older, unpatched flaws to break in. Not all PeopleSoft instances are vulnerable, which suggests the attack’s success depends on specific configurations and security gaps. This isn’t a single exploit; it’s a sophisticated, multi-step attack chain that bypasses defenses. **What should be done — mitigation and recommendations** If you’re a Nottingham student or alum, change your passwords immediately, especially if you reuse them across accounts. Enable multi-factor authentication wherever possible. Monitor your financial accounts for suspicious activity and consider freezing your credit with major bureaus. For institutions: audit your Oracle PeopleSoft instances for known vulnerabilities and apply patches promptly. Implement network segmentation to limit exposure, and consider deploying intrusion detection systems tailored to enterprise software. **Why this matters in the bigger cybersecurity landscape** This breach is part of a wider ShinyHunters campaign targeting over 100 organizations globally via PeopleSoft vulnerabilities. It highlights how cybercriminals are weaponizing zero-days against legacy enterprise systems — and how no sector, including education, is safe. The ripple effect is clear: when one university falls, others become prime targets. The Nottingham breach should serve as a wake-up call for every institution relying on outdated or poorly configured enterprise software. The stakes have never been higher.

South Korea just dropped the hammer on Coupang—a record $409 million fine for a data breach that exposed 37 million customers. That’s nearly the entire adult population of the country. If you’ve shopped on this e-commerce giant, your personal data may have been leaked due to basic security failures. The breach wasn’t just big; it was preventable, and the regulator is sending a clear message: negligence has a price tag.

**What exactly happened** Coupang, the Amazon of South Korea, has been slapped with a historic 624.6 billion won ($409 million) fine by the Personal Information Protection Commission (PIPC). The penalty stems from a massive data breach that compromised the personal information of approximately 37.55 million customers. The breach occurred in late June but wasn’t discovered until mid-November. That’s a five-month gap where attackers had free rein over sensitive data. The company only warned customers when 33.7 million accounts were confirmed compromised. **Who is affected and how** Every Coupang customer is potentially at risk. The breach exposed names, contact details, and other personal data. For a company that employs 95,000 people and generates over $30 billion in annual revenue, the scale is staggering. Coupang has promised compensation—1.685 trillion won ($1.17 billion) in total—including single-use purchase vouchers worth 50,000 won ($34) per customer starting January 2026. But for 33 million affected users, that’s cold comfort when their data is already out there. **The real-world impact and consequences** The fine isn’t just about money. The PIPC found multiple violations: inadequate authentication key management, poor access controls, failure to properly destroy data, and even obstruction of the investigation. Coupang’s data protection officer was allegedly interfered with, raising serious governance red flags. The subsidiary Coupang Fulfillment Service was also fined 248 million won for unlawfully collecting and handling sensitive data. This isn’t a one-off mistake—it’s a systemic failure. **Technical breakdown** The root cause? Basic security hygiene failures. The PIPC specifically cited negligence in “authentication signature key management and access control.” In plain English: Coupang didn’t properly manage the digital keys that verify who can access data, and didn’t restrict who had entry. The primary suspect is a 43-year-old Chinese national who worked in Coupang’s IT department from 2022 to 2024. This insider threat accessed millions of accounts, though only 3,000 accounts had data retained. The suspect tried to destroy evidence by dumping a MacBook Air in a river—but police recovered it. Hard drives were also returned, but the damage was done. **What should be done — mitigation and recommendations** For Coupang: immediate overhaul of access controls, implement zero-trust architecture, and enforce strict authentication key rotation. Regular third-party audits are non-negotiable. For other companies: this is a wake-up call. Insider threats are often overlooked. Monitor employee access patterns, enforce least-privilege principles, and have incident response plans that catch breaches in days, not months. For affected customers: change passwords, enable multi-factor authentication, and watch for phishing attempts. The leaked data will fuel targeted scams for years. **Why this matters in the bigger cybersecurity landscape** This fine is the largest in South Korea’s history, signaling that regulators are done with slap-on-the-wrist penalties. It echoes the GDPR-era fines in Europe and sets a precedent for Asia. The breach also highlights a growing trend: insider attacks by former employees. With remote work and data mobility, companies must rethink how they protect data from their own people. Coupang’s case proves that even billion-dollar giants can fall to basic security lapses. The message is clear: data protection isn’t optional. It’s a business imperative—and the cost of failure just got a lot higher.

Dutch authorities have arrested two hosting company co-owners for running servers that fueled Russian cyberattacks and disinformation across the EU. The suspects, aged 57 and 39, are accused of violating sanctions by providing infrastructure to Stark Industries Solutions—a provider sanctioned for aiding Russian intelligence operations. If you’re in Europe, your data or services could have been caught in the crossfire of this digital proxy war. This isn’t just about two arrests. It’s a stark warning: the servers powering state-backed attacks often hide behind legitimate-looking businesses. The Dutch raid seized 800 machines, exposing a shadowy supply chain that enables everything from DDoS attacks to influence campaigns. For anyone online, this case reveals how cybercriminals exploit hosting loopholes—and why regulators are finally cracking down.

**What exactly happened** On May 18, the Dutch financial crime agency FIOD arrested two men—a 57-year-old from Amsterdam and a 39-year-old from The Hague—for operating hosting companies that supported Russian cyberattacks. Authorities seized 800 servers linked to Stark Industries Solutions, a provider that emerged just before Russia’s 2022 invasion of Ukraine. The arrests follow a 2025 KrebsOnSecurity investigation that exposed how these hosting firms took over Stark’s infrastructure after it was sanctioned by the EU. **Who is affected and how** The primary targets were European institutions, businesses, and critical infrastructure. Stark’s servers were used for massive DDoS attacks, proxy services, and disinformation campaigns—often traced to Russia-backed hacking groups like APT28 and Sandworm. But the ripple effects hit everyone: your online banking, government services, or even social media feeds could have been disrupted or manipulated using this very infrastructure. **The real-world impact and consequences** This isn’t a victimless crime. The DDoS attacks alone disrupted hospitals, airports, and energy grids across Europe. Influence operations sowed political chaos, amplifying fake news during elections. By seizing 800 servers, Dutch authorities have temporarily crippled a key node in Russia’s cyber arsenal. But the bigger win is setting a precedent: hosting providers can no longer claim ignorance when their services enable state-sponsored attacks. **Technical breakdown** Stark Industries operated like a digital ghost—spinning up servers in days, using shell companies, and routing traffic through multiple jurisdictions. The arrested duo’s firms provided “bulletproof” hosting, meaning they ignored abuse complaints and shielded malicious actors. Their infrastructure acted as a relay: attacks originated from Stark’s servers, bounced through compromised devices, and hit targets while hiding the true source. Think of it as a VPN for cyberwarfare, with the hosts as the gatekeepers. **What should be done — mitigation and recommendations** For businesses: audit your hosting providers for sanctions compliance. Use threat intelligence feeds to block IP ranges linked to known malicious hosts. For individuals: enable multi-factor authentication and monitor for unusual account activity—these attacks often steal credentials. For policymakers: this case proves the need for faster sanctions enforcement and cross-border cooperation. The EU must close loopholes that let providers like Stark operate in plain sight. **Why this matters in the bigger cybersecurity landscape** The Netherlands’ action signals a shift from reactive defense to proactive disruption. By targeting the enablers—not just the attackers—authorities are dismantling the supply chain of cybercrime. This case also highlights the growing role of private hosting firms in geopolitical conflicts. As Russia’s cyber units adapt, expect more arrests, more server seizures, and a global game of whack-a-mole. For now, the message is clear: if you host for hackers, you’re next.

The clock is ticking faster for federal agencies. CISA just dropped a new directive—BOD 26-04—that slashes patching deadlines for critical exploited flaws to as little as three days. If your agency runs a publicly exposed system with a known vulnerability, you now have a weekend to fix it. This isn't just another policy update. It's a seismic shift in how the government prioritizes security, replacing older directives from 2019 and 2021. The message is clear: if attackers are actively exploiting it, you patch it now. Every federal civilian agency is on the hook, and the ripple effects will hit the entire cybersecurity industry.

**What exactly happened** CISA announced Binding Operational Directive 26-04, a new mandate that forces Federal Civilian Executive Branch (FCEB) agencies to remediate high-risk vulnerabilities at breakneck speed. The shortest deadline? Just three days for flaws that are publicly exposed, listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, automatable for large-scale attacks, or give attackers total system control. This directive supersedes and revokes the older BOD 19-02 and BOD 22-01. It's not a tweak—it's a complete overhaul of the federal patching playbook. **Who is affected and how** The directive applies specifically to FCEB agencies and their information systems. That includes most government departments and agencies, but not military systems, Intelligence Community systems, or private contractors. However, the framework is expected to influence the broader cybersecurity industry as a patching priority signal. All on-premise federal systems, third-party hosted systems, and FedRAMP or non-FedRAMP cloud environments fall under the new rules. If you're a federal IT manager, your vulnerability management policies just got a major rewrite. **The real-world impact and consequences** The three-day deadline is the headline grabber, but the two-week timeline for less urgent flaws is equally significant. For vulnerabilities that can't be automated or only give partial control, agencies still have to move fast. This creates immense pressure on already stretched security teams. They must update asset inventories, automate KEV status reporting, and continuously monitor detailed asset metadata. The consequence of non-compliance? Increased risk of successful attacks on government systems that handle sensitive citizen data. **Technical breakdown—the "how" explained simply** CISA's prioritization hinges on four key factors. First, whether the asset is publicly exposed online—think web servers or public-facing APIs. Second, if the vulnerability appears in the KEV catalog, meaning attackers are actively using it. Third, whether exploitation can be automated for large-scale attacks, like a wormable flaw. Fourth, if exploitation gives attackers partial or total control of a system. Agencies must now use CVE and KEV data as the basis for all remediation decisions. Within 60 days, vulnerability management processes must be updated. Within 180 days, agencies must follow the new timelines and report detailed asset metadata continuously. **What should be done—mitigation and recommendations** For agencies bound by BOD 26-04, the first step is updating vulnerability management policies to align with the new timelines. Next, update asset inventories to ensure every system is tracked. Automate KEV status reporting to avoid manual delays. For private sector organizations, this directive is a warning shot. Even if you're not a federal agency, adopting similar rapid patching cycles for critical exploited vulnerabilities can dramatically reduce your attack surface. Start by identifying your publicly exposed assets and cross-referencing them with the KEV catalog. **Why this matters in the bigger cybersecurity landscape** This directive signals a fundamental shift in how the government treats vulnerability management. It moves from "patch when you can" to "patch when attackers strike." The three-day deadline is a recognition that adversaries move faster than ever, and slow patching is no longer acceptable. For the broader industry, this sets a new benchmark. Expect private sector regulators and insurance carriers to adopt similar timelines. The message is universal: in today's threat landscape, speed is security. If you're not patching critical exploited flaws within days, you're already behind.

Imagine booting up your Windows Server 2025 machine after a routine security update, only to be greeted by a BitLocker recovery screen demanding a 48-digit key. That’s exactly what happened to some IT admins after Microsoft’s April 2026 Patch Tuesday. This bug forced enterprise servers into recovery mode due to a specific group policy conflict. While it’s unlikely to hit your personal laptop, corporate IT teams managing sensitive data were suddenly locked out of their own systems. Microsoft has now fixed it, but the incident highlights how even security features can become a double-edged sword.

**What exactly happened** Microsoft quietly resolved a known issue that caused Windows Server 2025 devices to boot into BitLocker recovery mode after installing the April 2026 security update. The bug was acknowledged two months ago, and the fix arrived during this month’s Patch Tuesday via updates KB5094125 (Windows Server 2025) and KB5093998 (Windows 11 23H2). The problem stemmed from an “unrecommended BitLocker Group Policy configuration.” In plain terms, a specific set of settings triggered the recovery screen on the first restart after the update. Once the key was entered, subsequent reboots worked fine—unless the policy changed again. **Who is affected and how** This bug primarily hit enterprise environments running Windows Server 2025. Microsoft noted that personal devices running Windows 11 were unlikely to be impacted, as the problematic configurations are typically only deployed by corporate IT teams managing fleets of machines. For IT admins, this meant a sudden, unexpected interruption. Servers that should have booted silently instead demanded manual intervention—a 48-digit recovery key—before they could resume normal operations. In a data center, that’s not just an inconvenience; it’s a potential operational headache. **The real-world impact and consequences** While the recovery key only needed to be entered once, the disruption was significant. For organizations relying on automated server deployments or remote management, any manual step introduces risk and delay. If IT teams didn’t have the recovery key readily available, systems could remain offline longer than expected. The bigger consequence? Trust in Patch Tuesday updates took another hit. Admins already cautious about deploying updates immediately now have another reason to pause and test, especially on critical infrastructure. **Technical breakdown (explain the "how" simply)** BitLocker uses a Trusted Platform Module (TPM) to automatically unlock encrypted drives at boot. But if the TPM detects changes—like a new boot manager—it demands the recovery key to verify the system hasn’t been tampered with. In this case, the April update introduced a 2023-signed Windows Boot Manager. For systems with a specific group policy that included PCR7 (a TPM validation setting) and an incompatible Secure Boot configuration, this change looked like a hardware tampering event. The result? BitLocker triggered recovery mode, even though nothing was actually wrong. Microsoft’s fix prevents the 2023 Boot Manager from installing on devices with this incompatible policy, stopping the false alarm before it starts. **What should be done — mitigation and recommendations** For IT admins who can’t deploy this month’s updates immediately, Microsoft offers two workarounds. First, remove the problematic group policy configuration before installing earlier updates (KB5082063 and later). Second, apply a Known Issue Rollback (KIR) to block the automatic switch to the 2023 Boot Manager. If you’ve already been hit, check the System event log for Event ID 1032—that’s the telltale sign. Once you install the latest cumulative updates, the issue should be resolved without further action. **Why this matters in the bigger cybersecurity landscape** This isn’t an isolated incident. Microsoft has faced similar BitLocker recovery bugs in July 2024 and May 2025, suggesting a pattern where security updates themselves introduce operational risks. For organizations, this underscores the importance of testing updates in a staging environment before wide deployment. It also highlights a tension in modern security: features designed to protect data can sometimes lock out the very people who need access. As encryption becomes standard, ensuring these mechanisms work smoothly—especially during updates—is critical. Otherwise, the cure risks being worse than the disease.

A CISA contractor just did the unthinkable. They took a massive trove of agency secrets—including AWS GovCloud keys—and posted them on a public GitHub account. The account was ironically named “Private-CISA.” Lawmakers are now demanding answers as CISA scrambles to contain the damage and invalidate the leaked credentials. If you care about national security or government data, this story matters.

**What exactly happened** A CISA contractor with administrative access to the agency’s code development platform created a public GitHub profile called “Private-CISA.” Inside, they posted plaintext credentials to dozens of internal CISA systems. The commit logs show something even more alarming. The contractor deliberately disabled GitHub’s built-in protection against publishing sensitive credentials in public repos. This wasn’t an accident—it was a conscious choice. **Who is affected and how** The exposed secrets included AWS GovCloud keys, which are used for government cloud operations. That means any bad actor could have accessed sensitive government systems and data. Lawmakers in both houses of Congress are now demanding answers. Sen. Maggie Hassan sent a letter to CISA’s Acting Director Nick Andersen on May 19, pressing for details on how this happened and what’s being done. **The real-world impact and consequences** CISA claims “there is no indication that any sensitive data was compromised.” But experts who reviewed the now-defunct archive say it was originally created in November 2025. The repository showed a pattern consistent with an individual using it as a working scratchpad or synchronization mechanism. This wasn’t a sophisticated hack—it was a contractor using GitHub to sync files between work and home machines. **Technical breakdown** Truffle Security found that the repo gained some of its most sensitive secrets in late April 2026. The contractor had disabled GitHub’s secret scanning protection, which normally alerts users when credentials are exposed. This means the leak could have been active for months before discovery. The contractor essentially turned off the safety net that would have caught this mistake. **What should be done — mitigation and recommendations** CISA is still struggling to contain the breach and invalidate the leaked credentials. The agency needs to immediately revoke all exposed credentials and audit contractor access. Organizations should enforce strict policies against using personal GitHub accounts for work data. Automated scanning tools should be mandatory for all repositories, even those created by trusted contractors. **Why this matters in the bigger cybersecurity landscape** This incident highlights a fundamental weakness in government cybersecurity. Contractors with privileged access can bypass security controls with a few clicks. As one security expert noted, “I don’t know what technical controls you could put in place given that this is being done presumably outside of anything CISA managed or even had visibility on.” The lesson is clear: trust but verify isn’t enough when insiders can disable your safeguards.