Daily Digest

One click. That’s all it takes for a hacker to steal your GitHub tokens and access every private repository you own. A new VS Code zero-day exploit, released publicly by security researcher Ammar Askar, weaponizes a link to github.dev—Microsoft’s browser-based code editor—to install malicious extensions that swipe your OAuth tokens. No patch exists yet, and the risk is immediate for developers using VS Code or GitHub. If you click a crafted link, your code, secrets, and projects are exposed.

**What exactly happened** Security researcher Ammar Askar dropped exploit code for a VS Code zero-day that turns a simple link click into a full token heist. The flaw targets github.dev, a browser version of VS Code used to edit GitHub repos. By tricking users into clicking a malicious link, attackers can steal GitHub OAuth tokens—the keys to your private repositories. Microsoft hasn’t patched it, and no CVE ID has been assigned yet. **Who is affected and how** Any developer using VS Code or github.dev is at risk. The exploit works by running malicious JavaScript inside a sandboxed webview. It simulates keypresses in the main editor to install a rogue extension. That extension then grabs the OAuth token sent to github.dev when you sign in. The token isn’t scoped to just one repo—it grants full access to every repo you can see, including private ones. **The real-world impact and consequences** This isn’t a theoretical bug. Askar’s proof-of-concept shows attackers can enumerate all your private repositories via the GitHub API. For companies, that means leaked source code, stolen intellectual property, or compromised CI/CD pipelines. For individual developers, it’s a direct path to account takeover. The lack of a patch means every click on a suspicious link is a gamble. **Technical breakdown** The vulnerability lives in VS Code’s webview message-passing system. Normally, webviews are sandboxed to prevent code from escaping. But Askar found a way to bypass that sandbox. His exploit runs JavaScript inside a webview that mimics keyboard inputs. Those inputs trigger VS Code’s command palette to install an extension. Once installed, the extension intercepts the OAuth token POSTed to github.dev. The token is then used to query the GitHub API—no additional authentication needed. **What should be done — mitigation and recommendations** No patch exists, but you can protect yourself right now. Clear cookies and local site data for github.dev in your browser. Click the Settings icon in the URL bar, go to Cookies and site data, then Manage on-device site data. This forces github.dev to show a warning: “The extension ‘GitHub Repositories’ wants to sign in using GitHub.” That warning is your red flag. Don’t click through unless you’re sure the link is safe. **Why this matters in the bigger cybersecurity landscape** This disclosure follows a pattern of frustration with Microsoft’s security response. Askar chose full public disclosure after a prior bug report was silently fixed without credit. He’s not alone—another researcher, Nightmare Eclipse, has leaked multiple Microsoft zero-days this year over similar grievances. The trend signals a breakdown in trust between researchers and vendors. For developers, it’s a wake-up call: even trusted tools like VS Code can become attack vectors. Stay vigilant, clear your data, and question every link.

Acer just dropped a bombshell: two maximum-severity zero-day vulnerabilities are lurking in its Wave 7 mesh routers. If you own one, your home network might be an open book to attackers. These aren't your average bugs. One leaks your plaintext passwords to anyone who knows where to look. The other plants a permanent backdoor using a hardcoded encryption key. No patch exists yet—and that puts every Wave 7 user in the crosshairs right now.

**What exactly happened** Security researcher Gergo Pap uncovered two critical flaws in Acer's Wave 7 mesh routers, both carrying the dreaded "max severity" rating. Acer confirmed the findings in a Friday advisory, acknowledging that firmware version T7c_GBL_1.01.000055 and earlier are vulnerable. The first zero-day, CVE-2026-49200, is a broken access control issue. It lets unauthenticated attackers grab your login credentials—for both the web interface and Telnet—simply by accessing a log file that shouldn't be public. No password guessing required. The second, CVE-2026-49201, is even more insidious. A hardcoded AES encryption key inside the router's backup processing code allows attackers to decrypt, modify, and re-encrypt system backups. That means they can inject a persistent backdoor that survives reboots. **Who is affected and how** Anyone using an Acer Wave 7 mesh router with the affected firmware is at risk. That's potentially thousands of home and small office users who rely on these devices for their daily connectivity. Attackers don't need special access or insider knowledge. The credential leak vulnerability is accessible through the router's web interface without authentication. For the backdoor flaw, remote attackers with no privileges can exploit the hardcoded key to gain persistent control. **The real-world impact and consequences** Think about what's on your home network: work laptops, smart cameras, baby monitors, and personal devices. An attacker with router access can intercept traffic, launch man-in-the-middle attacks, or pivot to other devices. The credential leak is particularly dangerous because it exposes Telnet credentials. That opens the door to full command-line access, allowing attackers to change settings, install malware, or use your router as a botnet node. The backdoor vulnerability means even if you change your passwords, the attacker can still regain access. It's the digital equivalent of a locksmith giving a spare key to a stranger. **Technical breakdown explained simply** The first flaw works because the router's web server doesn't check who's asking for the log file. It's like leaving your diary on the front porch with your passwords written inside. The second flaw is more clever. The router uses a fixed encryption key to protect backup files. Once an attacker knows that key (it's hardcoded in the firmware), they can decrypt any backup, inject malicious code, re-encrypt it, and upload it back. The router trusts the backup because it's properly encrypted—just not by someone you'd want. **What should be done—mitigation and recommendations** Acer says a fix is coming by the end of June 2026. Until then, you're not defenseless. Disable remote management on your router immediately. If your firmware allows, restrict internet remote access to only trusted IP addresses. When the patch drops, update right away. Acer provides clear steps: connect to your router, navigate to the admin console, and check for firmware updates under System Management. Don't delay—this is one update you can't afford to skip. **Why this matters in the bigger cybersecurity landscape** These vulnerabilities highlight a persistent problem: consumer routers remain a weak link in home security. Manufacturers often prioritize features over security, and hardcoded keys are a recurring sin in IoT devices. The credential leak flaw is especially troubling because it's so easy to exploit. It reminds us that even "simple" misconfigurations can have catastrophic consequences. For Acer, this is a reputational test. How quickly they patch and how transparently they communicate will set the tone for their security credibility going forward.

Your phone rings. It’s your mom. But is it really her? Google just dropped a new Android feature that catches AI deepfake scam calls in real time—before you fall for that cloned voice. Called “fake call detection,” it silently checks if the caller is who they claim to be. If something’s off, you get an instant warning to hang up. This matters because impersonation scams cost victims nearly $3 billion in the U.S. alone last year. Anyone on Android 12 or later with Google’s Phone app is now protected by default.

**What exactly happened** Google rolled out “fake call detection” globally this month for Android 12 and newer devices, starting with Pixel phones. The feature is enabled by default and works automatically when both caller and recipient use the Phone by Google app. **How it works** When a contact calls, their device sends a silent, encrypted confirmation signal to your phone in real time. If that signal is missing—meaning the call might be spoofed—your device pings the contact’s actual phone to verify. If their real device says “I’m not making a call,” you get an on-screen warning to hang up immediately. This all happens behind the scenes, without any extra steps from you. **Who is affected and how** Anyone using Android 12 or later with Phone by Google, Contacts, and Google Messages (with RCS enabled) is covered. Scammers spoof both phone numbers and AI-cloned voices to impersonate your contacts. This feature catches both tricks at once. **The real-world impact** Impersonation scams are exploding. The FTC reported $2.95 billion in U.S. losses in 2024 alone. INTERPOL’s March 2026 assessment flagged impersonation fraud as a top global threat, contributing to over $440 billion in losses worldwide last year. **Technical breakdown made simple** The feature builds on the RCS open standard—the same tech behind modern messaging. When a call comes in, your device checks for a cryptographic handshake from the caller’s phone. No handshake? Your phone then asks the contact’s actual device if it’s placing a call. If both checks fail, you get the warning. **What you should do** If your phone runs Android 12 or later, you’re already covered if you use Phone by Google. If not, install it from the Play Store and set it as your default dialer. Make sure Google Messages has RCS enabled. No extra settings to toggle—it just works. **Why this matters in the bigger picture** This is a major shift. For years, caller ID was enough. Now, with AI voice cloning making deepfake calls indistinguishable from real ones, we need cryptographic trust baked into the call itself. Google’s move sets a new standard for mobile security. Expect other platforms to follow—or risk leaving users exposed to a $440 billion fraud machine.

Dutch authorities just dropped the hammer on two hosting company co-owners, seizing 800 servers and making arrests for allegedly fueling Russian cyberattacks. The suspects are accused of running infrastructure that helped Russia launch DDoS attacks, influence operations, and disinformation campaigns across the European Union. If you rely on online services in Europe, this is a wake-up call about how easily critical internet plumbing can be weaponized.

**What exactly happened** On May 18, the Dutch financial crime agency FIOD arrested a 57-year-old from Amsterdam and a 39-year-old from The Hague. They’re charged with violating sanctions law by providing economic resources to EU-sanctioned entities. Authorities also seized 800 servers linked to their hosting companies. The arrests stem from a 2025 investigation into Stark Industries Solutions, an internet service provider sanctioned by the EU for being a staging ground for Russian cyber mischief. **Who is affected and how** The suspects’ infrastructure was used to launch massive DDoS attacks against European targets. It also supplied proxy and anonymity services that Russian-backed hacking groups repeatedly exploited. Any organization or individual relying on European internet services could have been collateral damage. Think disrupted websites, stolen data, or manipulated public opinion through disinformation. **The real-world impact and consequences** This isn’t just about servers in a Dutch data center. It’s about how seemingly neutral hosting companies can become enablers of state-sponsored cyber warfare. The EU’s sanctions on Stark Industries were meant to choke off resources for Russian attacks. But these arrests show how easily sanctions can be circumvented when companies quietly take over sanctioned infrastructure. **Technical breakdown** Stark Industries materialized just two weeks before Russia invaded Ukraine. It quickly became a go-to source for DDoS attacks and proxy services. The arrested men’s companies assumed control of Stark’s technical infrastructure after it was sanctioned. This allowed Russian intelligence agencies to continue using the same IP addresses and server networks for attacks, essentially operating under new management. **What should be done** For businesses: audit your supply chain for any links to sanctioned or suspicious hosting providers. Use threat intelligence feeds to block known malicious IP ranges. For policymakers: this case highlights the need for faster, more aggressive enforcement of sanctions. Seizing servers and arresting enablers sends a clear message that hosting malicious infrastructure has real consequences. **Why this matters in the bigger cybersecurity landscape** This isn’t an isolated incident. It’s a pattern: sanctioned entities simply shift their operations to new providers who are either complicit or negligent. The Dutch action sets a precedent. It shows that countries are willing to physically dismantle the infrastructure enabling cyberattacks. Expect more such operations as governments get serious about disrupting the supply chain of state-sponsored hacking.

European police just dealt a massive blow to the criminal underworld of illegal streaming. In a coordinated sweep across 13 countries, they dismantled nine organized crime rings and arrested 29 suspects. This isn't just about free movies and sports. These pirate operations are a serious threat to your cybersecurity, exposing users to malware, spyware, and data theft. If you or someone you know uses an illegal streaming service, you're the real target.

**What exactly happened** Law enforcement agencies across Europe and the US just wrapped up "Operation KRATOS 2," a seven-month takedown of illegal streaming networks. The operation, coordinated by Bulgaria with Europol's support, resulted in the arrest of 29 suspects and the dismantling of nine organized crime groups. The scale is staggering. Investigators identified over 18,000 IP addresses and 4,370 domains linked to piracy. They flagged nearly 400,000 URLs for removal and took down more than 27,000 illegal streaming links. **Who is affected and how** More than 86 suspects have been identified, with 148 house searches conducted across 13 countries. The operation involved authorities from Belgium, Bulgaria, Croatia, France, Greece, Ireland, Italy, the Netherlands, Poland, Romania, Spain, the UK, and the US. The real victims? Everyday users. These pirate services don't just steal content—they steal your data. Europol warns that users face major cybersecurity risks, including malware infections, spyware, and data theft. **The real-world impact and consequences** This isn't a victimless crime. These criminal rings generate significant revenue from illegal streaming, funding other illicit activities. The operation has referred 59 cases to judicial authorities, with 72 more investigations ongoing. The takedown follows a pattern of escalating enforcement. Last summer's Operation KRATOS shut down a network with 22 million users. In January, Operation Switch Off seized three industrial-scale IPTV services. And in May, Italian authorities dismantled CINEMAGOAL, a platform providing illegal access to Netflix, Disney+, and Spotify. **Technical breakdown: the "how" explained simply** These criminal groups are sophisticated. Europol explains they deliberately separate customer-facing websites from the servers hosting illegal content. This allows them to operate across multiple jurisdictions, making detection and prosecution difficult. Rather than just taking down websites, investigators targeted the entire criminal ecosystem. This approach helped them gather intelligence on the organized crime groups operating behind the platforms and identify key suspects involved in management and technical operations. **What should be done — mitigation and recommendations** For users: Stop using illegal streaming services. The "free" content comes at a hidden cost—your personal data and device security. Stick to legitimate platforms. For businesses: Partner with law enforcement. Private sector cooperation was crucial in this operation, helping investigators pin down IP addresses and domains. For organizations: Educate employees and customers about the risks. Many people don't realize that pirate streaming services are a major vector for malware and data theft. **Why this matters in the bigger cybersecurity landscape** This operation signals a shift in enforcement strategy. Law enforcement is no longer just taking down websites—they're dismantling the entire criminal infrastructure. The coordinated international response shows that piracy is being treated as a serious organized crime threat, not just a copyright issue. The cybersecurity angle is critical. As these operations disrupt major pirate networks, users who relied on them may seek alternatives, potentially falling victim to even more dangerous malware-laden services. The message is clear: illegal streaming isn't just illegal—it's dangerous.

Microsoft just dropped a bombshell for developers who live in both the Windows and Linux worlds. At Build 2026, the company announced Coreutils for Windows — bringing beloved Linux commands like `ls`, `grep`, and `cat` natively to Windows, no WSL required. This isn't a toy or a half-baked port. It's a serious, Microsoft-maintained project based on the Rust-powered uutils framework. If you've ever cursed when your Linux script broke on Windows, this is your lifeline. Developers, DevOps engineers, and anyone juggling cross-platform workflows are the ones who stand to benefit most — and the risk? It's minimal, but watch out for command conflicts and missing POSIX features.

**What exactly happened** At its Build 2026 developer conference, Microsoft unveiled Coreutils for Windows — a native port of over 40 essential Linux command-line utilities. Think `ls`, `cp`, `mv`, `grep`, `find`, and `hostname`, all running directly on Windows without needing the Windows Subsystem for Linux (WSL). The project is built on the open-source uutils project, which rewrites GNU coreutils in Rust. Microsoft took that foundation, polished it, and packaged it as a single binary with NTFS hardlinks for each command. You can install it with a simple `winget install Microsoft.Coreutils` command. **Who is affected and how** This is aimed squarely at developers and IT pros who live in multi-platform environments. If you write scripts on Linux and run them on Windows, or vice versa, this removes a major friction point. No more rewriting `sed` commands or installing Cygwin just to get `grep` working. But there's a catch: many Linux commands conflict with existing Windows commands. For example, `ls` works in PowerShell but behaves differently. Microsoft provides a compatibility table, but you'll need to manage your PATH and alias settings carefully to avoid surprises. **The real-world impact and consequences** The biggest win is consistency. Developers can now write scripts that work across Linux, macOS, and Windows without modification. This reduces context switching and speeds up workflows. For teams using CI/CD pipelines, this means fewer "works on my machine" moments. However, not everything made the cut. Commands like `chmod`, `chown`, and `nohup` are absent because they rely on POSIX features Windows doesn't support. The `kill` and `timeout` commands are also missing due to differences in signal handling. This means some scripts will still need tweaks. **Technical breakdown — the "how" explained simply** Microsoft's approach is clever. Instead of shipping dozens of separate executables, they created a single `coreutils.exe` binary. When you install it, the setup creates NTFS hardlinks — think of them as shortcuts that act like the real file — for each command. So `ls.exe`, `cp.exe`, and `cat.exe` all point to the same binary. When you run `ls`, Windows loads `coreutils.exe`, which checks the command name and runs the appropriate utility. This keeps the package lean and makes updates easier. You can even see all the hardlinks with `fsutil hardlink list coreutils.exe`. **What should be done — mitigation and recommendations** First, install it via WinGet and test your scripts in a controlled environment. Check Microsoft's compatibility table to see which commands behave differently. For example, `cat` in Coreutils might handle line feeds differently than PowerShell's `Get-Content`. Second, watch your PATH order. If you have WSL installed, the Linux version of `ls` might take precedence. You can use `where ls` in Command Prompt to see which version runs first. Consider using the full path or aliases to avoid confusion. Finally, don't expect a 1:1 replacement. Missing commands like `chmod` mean you'll still need WSL or a Linux VM for some tasks. But for everyday scripting, this is a game-changer. **Why this matters in the bigger cybersecurity landscape** This move signals Microsoft's deepening commitment to cross-platform development. It's part of a broader strategy that includes WSL containers and native Linux tooling on Windows. For security teams, this means fewer workarounds and less shadow IT — developers won't need to install unsupported tools just to get their work done. But it also introduces new attack surface. A single binary with hardlinks could be a target for privilege escalation if not properly secured. Microsoft has a good track record with Rust-based projects (memory safety), but as with any new tool, keep it updated and monitor for vulnerabilities. In the end, this is a net positive for developer productivity — and that's a win for everyone.

A CISA contractor just did the unthinkable: they posted the agency's crown jewels on a public GitHub account. Plaintext credentials to dozens of internal systems, including AWS GovCloud keys, were left exposed for anyone to find. This isn't just a bureaucratic blunder. It's a wake-up call that insider threats can come from the people we trust most. If you rely on government agencies or cloud infrastructure, this leak puts you at risk too.

**What exactly happened** On May 18, KrebsOnSecurity revealed that a CISA contractor with administrative access had created a public GitHub profile called "Private-CISA." The repo contained plaintext credentials to dozens of internal systems, including AWS GovCloud keys. The contractor even disabled GitHub's built-in protection against publishing sensitive credentials. This wasn't an accident—it was a deliberate bypass of security controls. **Who is affected and how** CISA itself is the primary victim, but the ripple effects are massive. Any organization that shares sensitive data with CISA—from critical infrastructure operators to state governments—could be impacted. The exposed AWS GovCloud keys alone could allow an attacker to access classified government workloads. Think about that: a single contractor's GitHub repo could compromise national security. **The real-world impact and consequences** CISA claims "there is no indication that any sensitive data was compromised." But experts who reviewed the repo say it was created in November 2025 and gained its most sensitive secrets in late April 2026. That's months of potential exposure. The agency is still struggling to invalidate the leaked credentials and contain the breach. Lawmakers in both houses are demanding answers, with Sen. Maggie Hassan sending a pointed letter to CISA's Acting Director. **Technical breakdown** The contractor used the GitHub repo as a "working scratchpad" to sync files between work and home machines. They disabled GitHub's secret scanning, which normally flags and blocks credential commits. This is a classic case of shadow IT meeting insider threat. The contractor bypassed enterprise controls to make their workflow easier, exposing everything from API keys to database credentials in the process. **What should be done** CISA needs to immediately rotate all exposed credentials and audit every system accessed by the contractor. They should also review their GitHub security policies and enforce mandatory secret scanning. For other organizations: this is a stark reminder to implement data loss prevention (DLP) tools, monitor for unauthorized GitHub activity, and enforce strict policies against syncing work data to personal accounts. **Why this matters** This incident exposes a fundamental flaw in how even the most security-conscious agencies manage insider risk. A single trusted contractor, acting outside official channels, can bypass years of security investment. The bigger lesson? Technical controls mean nothing if employees can simply disable them. Until organizations address the human factor—through better training, monitoring, and accountability—these leaks will keep happening.

A 23-year-old Ottawa man named Jacob Butler, known online as "Dort," has been arrested for allegedly building and operating the Kimwolf botnet—a massive IoT army that enslaved millions of devices. This isn't just another hacker bust. Kimwolf powered record-breaking DDoS attacks, hit Department of Defense networks, and even targeted this very journalist with swatting and doxing campaigns. If you own a smart camera or digital photo frame, your device might have been a soldier in this cyber war without you knowing.

**What Exactly Happened** Canadian authorities arrested Jacob Butler on Wednesday, charging him with creating and running Kimwolf, one of the fastest-spreading IoT botnets in recent memory. The criminal complaint, unsealed in an Alaska district court, reveals a sophisticated operation that weaponized everyday smart devices. Butler faces charges in both Canada and the United States, including one count of aiding and abetting computer intrusion. He's currently in Canadian custody, awaiting an extradition hearing scheduled for early next week. **Who Is Affected and How** The victims are everywhere. Kimwolf specifically targeted devices that were traditionally "firewalled" from the internet—think digital photo frames, web cameras, and other IoT gadgets people rarely think to secure. These infected devices were then rented to other cybercriminals or forced into massive DDoS attacks. The damage wasn't just theoretical: the botnet hit Internet address ranges belonging to the Department of Defense, triggering an investigation by the DoD's Defense Criminal Investigative Service. **The Real-World Impact and Consequences** This botnet wasn't just about disruption—it was personal. Butler allegedly launched DDoS, doxing, and swatting campaigns against KrebsOnSecurity and a security researcher who publicly named him in February 2026. The consequences for Butler are severe. If extradited and convicted in the U.S., he faces up to 10 years in prison. However, the sentencing guidelines may account for his youth, lack of prior criminal history, and potential cooperation with investigators. **Technical Breakdown: How Kimwolf Worked** Kimwolf exploited a fundamental weakness in IoT security: devices that are "firewalled" by default but still vulnerable to compromise. These gadgets often ship with weak default passwords, unpatched firmware, or insecure network configurations. Once infected, each device became a remote-controlled attack drone. Butler could direct millions of these devices to flood targets with traffic, overwhelming servers and knocking entire networks offline. The botnet's speed of spread suggests automated scanning and exploitation of known vulnerabilities. **What Should Be Done — Mitigation and Recommendations** For individuals: change default passwords on all IoT devices immediately. Disable Universal Plug and Play (UPnP) on your router. Keep firmware updated. If you don't use a smart device regularly, unplug it. For organizations: segment IoT devices on separate network VLANs. Implement network monitoring for unusual traffic patterns. Consider DDoS protection services if you're a potential target. For law enforcement: this arrest shows cross-border cooperation works. Continued investment in cybercrime units and international extradition treaties remains critical. **Why This Matters in the Bigger Cybersecurity Landscape** Kimwolf represents a growing threat: weaponized IoT devices that are invisible to their owners. As smart homes and offices expand, the attack surface grows exponentially. This case also highlights the blurred line between cybercrime and personal vendettas. Butler didn't just attack random targets—he went after journalists and researchers who exposed him. That's a chilling reminder for anyone working in cybersecurity or journalism. The arrest sends a message, but the infrastructure remains. Millions of devices are still infected, waiting for their next command. The real work—cleaning up the botnet—has only just begun.

Imagine the irony: America’s top cybersecurity agency, CISA—the very organization tasked with protecting the nation’s digital infrastructure—just suffered one of the most jaw-dropping data leaks in recent government history. A contractor working for CISA left a public GitHub repository wide open, exposing highly privileged AWS GovCloud keys, plaintext passwords, and internal system blueprints. The leak wasn’t a sophisticated hack—it was a simple case of someone disabling GitHub’s default security settings. If you care about government data security, this is a wake-up call that hits close to home.

**What exactly happened** On May 15, security researcher Guillaume Valadon from GitGuardian flagged a public GitHub repository named “Private-CISA.” Despite its ironic name, this repo was anything but private. It contained a treasure trove of sensitive credentials, including keys to AWS GovCloud accounts—the cloud environment used exclusively by U.S. government agencies to handle classified data. The repository also held plaintext passwords, SSH keys, API tokens, and detailed documentation on how CISA builds, tests, and deploys its internal software. In short, it was a blueprint for attackers to infiltrate some of the most sensitive systems in the federal government. **Who is affected and how** The leak directly impacts CISA, the Department of Homeland Security (DHS), and any agency relying on CISA’s cybersecurity services. But the ripple effects extend far beyond. Threat actors could use these credentials to access GovCloud environments, steal classified data, or pivot to other federal networks. Worse, the repository’s commit logs revealed that the CISA contractor had disabled GitHub’s default secret-scanning protections. This means the exposure wasn’t a one-time mistake—it was a recurring pattern of poor security hygiene, with regular updates to the repo since November 2025. **The real-world impact and consequences** This isn’t just an embarrassing oops moment. It’s a catastrophic failure of operational security. The exposed credentials could allow attackers to: - Access AWS GovCloud resources, potentially compromising classified workloads. - Use SSH keys to move laterally within CISA’s internal network. - Exploit plaintext passwords to breach other government systems. Security experts, including former CISA official Brandon Caturegli, described this as “one of the most egregious government data leaks in recent history.” The leak undermines trust in CISA’s ability to secure its own house, let alone advise others. **Technical breakdown (the “how” explained simply)** GitHub has a built-in feature that blocks users from accidentally publishing secrets like SSH keys or passwords in public repos. The CISA contractor manually disabled this setting, essentially removing the safety net. Then, they used the public repo to sync files between a work laptop and a home computer—a classic shadow IT move that bypasses all security controls. The result? A publicly accessible archive of sensitive data, including CSV files with plaintext passwords, backup logs, and detailed infrastructure diagrams. GitGuardian’s automated scanning caught it, but the contractor ignored their alerts until KrebsOnSecurity got involved. **What should be done — mitigation and recommendations** First, CISA must immediately rotate all exposed credentials and revoke the affected AWS GovCloud keys. Second, they need to conduct a forensic audit to determine if any unauthorized access occurred. Third, the contractor’s access should be suspended pending a full investigation. For other organizations, this is a stark reminder to: - Never disable GitHub’s secret-scanning protections. - Use tools like GitGuardian or GitHub’s own secret scanning to monitor repos. - Enforce strict policies against syncing work files via public repositories. **Why this matters in the bigger cybersecurity landscape** This leak is a masterclass in how not to handle sensitive data. It shows that even the most security-conscious agencies can fall victim to basic human error. More importantly, it highlights the growing risk of cloud credential exposure—a problem that affects every organization, from startups to federal agencies. If CISA can’t protect its own secrets, what hope is there for the rest of us? The answer lies in learning from their mistakes: automate security checks, enforce strict policies, and never assume that “it won’t happen to us.” Because it already has.