Welcome to Threat Thursday, Galactic’s weekly threat intelligence roundup.

Every Thursday, we cover the cybersecurity stories that matter most for protecting organizations from emerging threats. Each item is broken down into what happened, what it could mean for your organization, and what to do about it.

Whether you’re overseeing risk management decisions, running security operations, or just trying to stay current, this update is designed to provide the information you need to keep yourself and your organization cyber safe.

This Week's Stories

1. Microsoft Patches an Actively-Exploited Outlook Web Access Zero-Day: CVE-2026-42897

On May 14, Microsoft confirmed that attackers were actively exploiting a flaw in Outlook Web Access (the browser version of Outlook used by organizations running Exchange Server on their own infrastructure). The flaw, CVE-2026-42897, is a cross-site scripting bug, which is a way to make a website (or, in this case, the OWA interface) run attacker-controlled code in the context of a victim’s session. The practical attack: a specially crafted email plus a particular interaction in OWA is enough for the attacker to reach into the victim’s mailbox, hijack the OWA session, and pivot from there. The flaw affects Exchange Server 2016, 2019, and Subscription Edition; the cloud-hosted Exchange Online service is not affected. Microsoft initially shipped a temporary mitigation through Exchange’s Emergency Mitigation Service, and the full May 2026 security update is now available. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the vulnerability to its Known Exploited Vulnerabilities catalog with a federal patch deadline of May 29.

Potential impact: On-premise Exchange is still used by many organizations that have not yet migrated to cloud-hosted email. A flaw that turns an inbound message into mailbox access is the kind of bug invoice-fraud and wire-redirect operations are built on, because a compromised finance or executive mailbox is the first move in those playbooks. The mitigation Microsoft auto-applied caused some short-term breakage in OWA (Print Calendar, inline-image rendering, OWA light), and installing the security update is what restores both safety and full OWA function. The pattern worth noting: the active-exploitation report came before the patch did, and the patch shipped within five days. Defenders who treat their patch window as "next maintenance cycle" lose ground every time this pattern repeats.

What to do: Affected organizations should confirm Exchange’s Emergency Mitigation Service applied the temporary fix (mitigation ID M2.1.x) between May 14 and 15, then install the May 2026 Exchange security update on every on-premises Exchange server before the May 29 federal deadline. Verify the OWA features the mitigation broke (Print Calendar, inline images in the reading pane, OWA light) are restored once the update is in place. Audit OWA access logs from May 13 forward for unusual activity.

Source: Microsoft Tech Community

2. Microsoft Issues a BitLocker Bypass Mitigation (Not a Patch) — CVE-2026-45585, “YellowKey”

On May 20, Microsoft acknowledged a vulnerability the researcher community has been calling "YellowKey" (CVE-2026-45585) and published a mitigation rather than a fix. The flaw lets an attacker with physical access to a Windows laptop bypass BitLocker, the built-in full-disk encryption that protects everything on the drive when the laptop is off. The attack involves planting specifically named files on a USB drive or directly in the small startup partition, then rebooting into the Windows Recovery Environment while holding the CTRL key. This lands the attacker in a command shell with access to the encrypted drive’s contents. The bug affects Windows 11 versions 24H2, 25H2, and 26H1, plus Windows Server 2025.

The researcher who reported it, going by "Chaotic Eclipse," released a working proof of concept publicly without coordinating with Microsoft first. This means attackers have the exact steps to run this attack on systems that have no patch to be installed.

Potential impact: Physical access sounds unlikely, but it is exactly the scenario BitLocker is supposed to defend against. Laptops get stolen, devices get left in hotel rooms and rental cars, and certain targeted scenarios (executive travel, M&A diligence, journalism) involve adversaries who can get briefly hands-on with a target device. A BitLocker bypass that works reliably against a fully patched laptop undermines the entire point of full-disk encryption. The deeper pattern is the gap between "Microsoft acknowledged it" and "Microsoft patched it": when a public proof of concept exists and the vendor’s answer is a manual mitigation, the burden of timing falls on the defender. Organizations that wait for a patch to be packaged up neatly are effectively choosing to remain exposed.

What to do: Administrators should identify Windows 11 24H2, 25H2, and 26H1 machines and Windows Server 2025 hosts that use BitLocker, then script the recovery-environment mitigation across the network (it requires modifying the WinRE image and re-establishing BitLocker trust). For laptops, the higher-value change is switching BitLocker from unlocking automatically at startup to requiring a short PIN before the drive opens. Automatic unlock is convenient, but it's exactly the path this attack uses; a startup PIN closes that door.

Source: Security Affairs

3. TeamPCP Steals 3,800 Internal GitHub Repositories Through a Malicious VS Code Extension

GitHub detected an intrusion on May 19 and disclosed it publicly on May 20. The attacker, a financially-motivated cybercrime group called TeamPCP (tracked as UNC6780 by Google Threat Intelligence), compromised a corporate device belonging to a GitHub developer by getting them to install a malicious extension for Visual Studio Code (the popular code editor used across the software industry). From that one compromised developer machine, the attacker exfiltrated roughly 3,800 internal GitHub repositories and posted them for sale on a cybercrime forum for $95,000. GitHub says it isolated the affected device, removed the malicious extension, and rotated high-impact credentials and cryptographic keys, and that no customer data or public infrastructure was accessed. Aikido Security pointed out that a completely separate VS Code extension called Nx Console (with 2.2 million installs) was briefly backdoored the day before the GitHub disclosure; the community caught it within eleven minutes, but plenty of machines auto-update inside that window. TeamPCP’s 2026 victim list now includes Trivy, Bitwarden CLI, Checkmarx KICS, TanStack, and GitHub itself.

Potential impact: The story isn’t really "GitHub had a bad day." It’s that a single VS Code extension on one developer laptop opened the door to 3,800 internal repositories at a company that is, by any reasonable measure, security-conscious. Editor extensions have full access to the developer’s machine: credentials, cloud keys, SSH keys, browser sessions, the works. Endpoint detection products generally do not look inside the editor, which means most organizations have no visibility into what extensions are running on developer endpoints or when those extensions last changed hands. TeamPCP has spent 2026 working through the developer-tooling supply chain methodically; the GitHub breach makes clear that even the largest names in that supply chain are at risk, which means downstream organizations that have their own internal developers should assume the same risk profile applies.

What to do: Organizations should treat developer endpoints as part of the production attack surface. Inventory the VS Code extensions installed across managed developer machines and flag anything recently published, low-install, or not on a maintained allowlist. Restrict auto-update for extensions on machines that hold long-lived publishing tokens or cloud credentials. Rotate any GitHub Personal Access Tokens, cloud keys, and SSH keys that lived on a developer device that touched an unvetted extension in the past 90 days. Add an extension inventory pass to the regular endpoint review cycle.

Source: Hackread

4. Cisco Catalyst SD-WAN Faces Sixth Zero-Day of 2026 — CVE-2026-20182, CVSS 10.0

On May 15, Cisco disclosed CVE-2026-20182, a maximum-severity (CVSS 10.0) authentication-bypass flaw in Cisco Catalyst SD-WAN Controller and SD-WAN Manager. The bug was already being actively exploited and used in attacks before Cisco announced this vulnerability. SD-WAN (software-defined wide area networking) is the technology many mid-sized organizations use to connect branch offices, and the controller is the management server that orchestrates the whole fabric. The flaw lets an unauthenticated attacker become an authenticated peer of the controller and then perform privileged operations. That gives persistent admin access to the controller and, by extension, to the network fabric it manages. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on May 16 with a federal patch deadline of May 17 (the shortest deadline CISA has issued in 2026). This is the sixth Cisco SD-WAN zero-day to be weaponized this year.

Potential impact: When the management plane of a network goes, the network goes with it. An attacker who controls the SD-WAN controller can read traffic between sites, reroute it, plant persistent footholds, or simply stay quiet and observe. The "sixth zero-day this year" line is an important detail. This is not an isolated bug, it’s a sustained pattern problem in a specific vendor’s product line, and organizations running this gear need to treat the management plane as actively-targeted infrastructure rather than as a set-and-forget appliance. The shortest-of-the-year CISA deadline is a useful tell: when the federal cybersecurity agency compresses a patch window to roughly one day, the working assumption is that opportunistic exploitation is already happening at scale.

What to do: Organizations running Catalyst SD-WAN Controller or SD-WAN Manager should apply the Cisco-published patch immediately. After patching, audit the administrative user’s SSH authorized-keys file on every controller for unexpected entries, and pull SSH login and configuration-change logs from May 10 forward looking for the same. Restrict controller management interfaces to known administrative networks. Treat any controller you can’t positively confirm clean as a candidate for forensic review rather than assuming clean.

Source: Cisco PSIRT advisory

5. A Max-Severity Flaw in ChromaDB Lets Anyone Run Code on the Server, With No Patch Yet: CVE-2026-45829

On May 19, Hadrian Security and BleepingComputer disclosed a maximum-severity flaw in ChromaDB, one of the most-used open-source databases for AI applications. ChromaDB is a "vector database", a kind of database designed to store the mathematical representations that large language model applications use to recall and retrieve documents. Many organizations use it as the back end for internal knowledge chatbots and other AI features. The flaw (CVE-2026-45829) affects the Python version of ChromaDB’s server (a separate Rust version is not affected) and lets an unauthenticated attacker with network access to the server run their own code on it. This could lead to a full server takeover. The root cause is two design failures that compound: the server trusts a value the client sends about which AI model to use, and it acts on that value before checking whether the client is authenticated. The bug has been present since version 1.0.0, was reported to ChromaDB in February, and remains unpatched as of version 1.5.8. There is no public evidence of active exploitation, but a working understanding of the bug is now in the open.

Potential impact: AI features have been quietly accumulating in organizations' environments for the better part of two years, often built by small teams to solve a specific problem and quietly turning into production infrastructure without anyone treating them that way. Additionally, most of this infrastructure has never been through a security review. A maximum-severity unauthenticated flaw in the dominant open-source vector database, with no patch yet and a known-public root cause, is the kind of bug that turns "we have some AI projects" into "we have unmanaged servers running attacker-supplied code." The broader pattern is that the trust model of AI infrastructure (let user input flow into model selection and execution) hasn’t had the same security scrutiny as the rest of the application stack. This is a major reminder that it needs to.

What to do: Affected organizations should identify ChromaDB deployments across managed environments. Docker containers, Kubernetes pods, dev and staging tenants, anything a developer stood up to support an AI feature. For each instance, confirm whether it runs the Python frontend (vulnerable) or the Rust frontend (not affected). Take any Python-frontend server that is reachable from the public internet off the public internet today, and gate the API port at the firewall to only the application servers that genuinely need it. Treat anything that was historically publicly reachable as a candidate for forensic review. Monitor the ChromaDB advisory channel for the eventual patched release.

Source: BleepingComputer

6. Verizon's 2026 Data Breach Report: Vulnerability Exploitation Is Now the Top Way Attackers Get In

On May 20, Verizon published the 2026 Data Breach Investigations Report (DBIR), the nineteenth edition of what is widely considered the most-cited breach analysis in cybersecurity. The headline finding broke a 19-year pattern: for the first time, vulnerability exploitation (attackers breaking in through unpatched software flaws) was the top initial access vector for breaches over the past year, overtaking compromised credentials. Vulnerability exploitation accounted for 31% of breaches in the dataset (up from 20% the year before), while credential abuse dropped from 22% to 13%. Just 26% of vulnerabilities in CISA's Known Exploited Vulnerabilities catalog (the catalog tracking flaws being actively used in attacks) were fully remediated by organizations in 2025, down from 38% the previous year, even as the number of critical flaws to patch grew by 50%. Verizon suggests AI is part of the explanation: attackers are using AI to find and exploit vulnerabilities faster than before, with the median threat actor using AI assistance across 15 documented techniques and some using as many as 40 or 50. Supply-chain breaches surged 60% year-over-year to make up 48% of all breaches; just 23% of third-party organizations fully remediated improperly secured MFA on cloud accounts. Ransomware was involved in 48% of breaches (up from 44%), but 69% of victims chose not to pay.

Potential impact: The DBIR is useful less as any single year's snapshot and more as a marker of the direction of travel. The direction this year is clear and uncomfortable. Attackers are exploiting more flaws, defenders are patching fewer of the ones that matter most, and the gap between disclosure and exploitation is closing. Three of the stories above (Exchange, Cisco SD-WAN, ChromaDB) are individual examples of exactly the pattern Verizon is measuring at scale. The supply-chain figures are the second uncomfortable part of the story. The average organization depends on third parties whose security hygiene, especially MFA on cloud accounts, lags well behind the standard the average internal security team holds itself to. The AI signal is the third. The data now supports what has been anecdotal for the past year, that attackers are using AI extensively across their workflow, and the result is a faster and broader cadence of vulnerability weaponization across the dataset.

What to do: Treat the DBIR as the dataset to benchmark your patch-cadence policy and supply-chain assumptions against, not just an interesting read. The 26% KEV remediation figure is the number to beat. Tighten SLAs on patching KEV-listed vulnerabilities regardless of internal severity scoring. Review third-party access and the MFA posture on every cloud service that holds sensitive data. Take an inventory of how AI tools are being used inside the organization — Verizon flagged shadow AI as the third most common non-malicious insider action this year, a fourfold increase from the year before.

Sources: Infosecurity Magazine & Verizon 2026 DBIR

The Through Line

Two themes hold this cycle together, and the Verizon DBIR landing on the same day as the ChromaDB disclosure is not a coincidence. It is the macro data backdrop for everything else above. The first theme is that "patch and walk away" no longer describes how every serious vulnerability gets resolved. Exchange got a real patch, on a real timeline, after active exploitation was already underway. YellowKey got a manual mitigation that needs to be scripted across a fleet. ChromaDB got "use the Rust frontend or take your server off the internet" as its operating advice, no patch at all, months after the bug was reported. Verizon's data makes the systemic version of this argument. Vulnerability exploitation is now the top initial access vector for the first time in 19 years, and the share of urgent flaws organizations actually patched in time dropped from 38% to 26% in a single year. The defender model that assumes a clean, packaged update is always on the way is going to keep getting outflanked. Building organizational muscle to apply mitigations, audit configurations, and tighten patch SLAs against the KEV catalog is now the basic patch-management job, not a special case.

The second theme is that developer machines and developer tooling are now the production attack surface, full stop. The TeamPCP-attributed GitHub breach is the cleanest demonstration of the year. One VS Code extension on one developer laptop, 3,800 internal repositories out the door. ChromaDB sits in the same category from a slightly different angle: AI infrastructure stood up by developers as part of an experiment ends up in the production environment without ever going through the security controls the rest of production lives behind. The DBIR backs this up too. Supply-chain breaches grew 60% year-over-year and now make up 48% of the dataset, and only 23% of third parties fully remediated improperly-secured MFA on cloud accounts. The implication is consistent. The developer endpoint, the editor, the package manager, the build runner, the vector database the AI team is using, and every cloud account at every third party that touches the business all belong inside the same security perimeter as the production servers themselves. Treating any of them as adjunct or low-risk is exactly the gap attackers are working into right now.

Make sure to check back here each week for another Threat Thursday update. See you then!