Cyber Roundup — Week of August 17th

Here are the main stories you missed last week.

1. GitLab: CVE-2026-19478 lets any unauthenticated attacker permanently delete or rewrite every public project on a self-hosted instance

The headline: GitLab disclosed CVE-2026-19478 on August 17, a critical code injection vulnerability in GitLab Community Edition and Enterprise Edition that allows any unauthenticated attacker to remotely modify or delete publicly accessible projects and rewrite their data. The flaw, which carries a CVSS score of 9.4, is exploitable via a GraphQL directive with no credentials, no user interaction, and no special configuration required. Affected versions span GitLab CE and EE 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4. Patches shipped in versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11. WatchTowr confirmed active exploitation within days of public disclosure.

What we’re actually watching: Deleting or rewriting a public GitLab project is not the attack. It is the visible part of a broader capability. An attacker who can modify project data can poison repositories, overwrite build scripts, replace release artifacts, and rewrite commit history, all without ever authenticating. This is not a data theft vulnerability. It is a software supply chain vulnerability dressed as a code injection flaw.

WatchTowr’s confirmation of active exploitation within days of disclosure follows the same timeline as GeoServer last week and TeamCity in July. The window between GitLab publishing a patch and attackers integrating the exploit into scanning tools is now measured in days, not weeks. Organizations running self-hosted GitLab CE or EE instances that have not applied this week’s patches should audit recent public project activity for unauthorized modifications and verify that release artifacts match expected signatures before the next deployment cycle.

The CISO question: For every self-hosted GitLab instance in your environment, have you applied the August 17 patches, reviewed recent audit logs for unauthenticated modification events in public repositories, and confirmed that build artifacts released since August 17 match expected signatures and were not produced from a tampered codebase?

2. Microsoft: CoSnitch turned Copilot’s persistent memory into a data exfiltration channel, and a critical Entra ID RCE shipped quietly on the same day

The headline: Varonis Threat Labs disclosed CoSnitch, tracked as CVE-2026-24301, on August 18, a Copilot Personal vulnerability that chains an undocumented URL parameter, Copilot’s built-in URL-fetching capability, and its persistent memory feature to silently exfiltrate data from linked accounts including Gmail and Google Drive after a single user click. Stolen data is disguised as routine outbound browsing traffic. A poisoned-memory variant can persist through password resets and device re-enrollment. Microsoft patched the flaw and found no evidence of pre-patch exploitation. Varonis discovered the vulnerability through meta-hacking, repeatedly asking Copilot why the attack was not possible until the model’s own explanations revealed the exact undocumented parameter needed. On the same day, Microsoft disclosed CVE-2026-69836, a critical maximum-severity remote code execution vulnerability in Entra ID, rated 10.0, before later correcting the exploited status to “not exploited in the wild” after The Hacker News contacted Microsoft for comment.

What we’re actually watching: CoSnitch is the second AI assistant data exfiltration technique disclosed this month, following GhostApproval in the week of July 6. The pattern is consistent: AI tools that hold OAuth connections to productivity platforms, with persistent memory or state, create exfiltration channels that look like normal application traffic. The Copilot case is particularly notable because Varonis extracted the exploit by interrogating the model itself. The AI’s own explanations of why the attack could not work revealed precisely how to make it work.

The Entra ID CVE-2026-69836 correction is the other story. Microsoft disclosed a maximum-severity Entra ID RCE as exploited, then quietly changed the exploited status to “not exploited” after press contact. Whether the original disclosure was an error or the correction was under-evidenced, the incident illustrates a problem that security teams face every Patch Tuesday: vendor exploitability assessments are unreliable in both directions. CybelAngel’s monitoring of dark web Telegram channels provides an independent signal on whether a newly disclosed vulnerability is being actively discussed and weaponized, separate from vendor characterizations.

The CISO question: For every AI assistant your organization has deployed with OAuth connections to productivity platforms, do you treat those tools as privileged insiders requiring access audits, and do you have monitoring that can detect when AI-mediated outbound traffic is carrying data exfiltrated from connected accounts rather than serving its intended function?

3. VMware: A China-nexus APT deployed Babuk ransomware through CVE-2026-59310 in vCenter while defenders were still reading the patch notes

The headline: Broadcom and Palo Alto Networks Unit 42 confirmed on August 17 that a suspected China-nexus advanced persistent threat actor exploited CVE-2026-59310, a CVSS 9.8 directory traversal vulnerability in VMware vCenter Server that enables unauthenticated arbitrary code execution, to deploy a Babuk-derived ransomware variant across victim environments. Broadcom patched CVE-2026-59310 in late July. Active exploitation targeting specifically vCenter Server infrastructure began within weeks of the patch, with Unit 42 attributing the campaign to a cluster they track as UNC5325 based on tooling and infrastructure overlaps with prior Chinese state-sponsored intrusions. Shadowserver tracks more than 4,200 internet-exposed vCenter Server instances globally.

What we’re actually watching: A China-nexus threat actor deploying ransomware through a vCenter vulnerability is not typical state-sponsored behavior. Nation-state actors with Chinese attribution have historically prioritized espionage and long-term persistence over destructive or financially motivated attacks. The use of Babuk-derived ransomware suggests either a deliberate disruption objective, a false-flag operation, or the involvement of criminal affiliates operating alongside state infrastructure, the same hybrid model documented in Lazarus Group’s collaboration with Play ransomware in 2024.

The vCenter attack surface is disproportionately dangerous because vCenter manages virtualization infrastructure rather than individual systems. One compromised vCenter instance provides administrative control over every virtual machine running on every host it manages. Organizations that treat vCenter as an internal management tool with limited exposure are frequently wrong: 4,200 instances are internet-reachable according to Shadowserver, and many more are accessible through compromised VPN or network-adjacent positions that UNC5325’s prior intrusion history demonstrates they consistently target.

The CISO question: For every vCenter Server deployment in your environment, have you applied the late-July patches for CVE-2026-59310, confirmed that your vCenter management interface is not internet-accessible, and reviewed virtual machine creation, deletion, and snapshot activity logs for signs of unauthorized access occurring before or after the patch was applied?

4. Unisoc: A two-stage exploit chain achieves full Android kernel access through a VoLTE video call with no fix available from the chipset maker

The headline: SSD Secure Disclosure published the second stage of a full Android kernel exploit chain on August 17 targeting devices running Unisoc modem firmware. The two-stage chain, with stage one disclosed in March 2026, achieves full kernel access on affected Android devices through a VoLTE video call, meaning the attack requires only that the target’s phone number is known and that the device accepts video calls over LTE. No user interaction is required beyond receiving the call. Unisoc has not issued a fix. The vulnerability affects Unisoc-chipset devices, which are widely deployed across budget Android handsets in emerging markets and some mid-range devices sold globally under multiple OEM brands.

What we’re actually watching: A zero-click full kernel exploit delivered through a phone call is the highest severity class of mobile vulnerability. It requires nothing from the target except a working phone number. The absence of a fix from the chipset maker is structurally the same problem as end-of-life router firmware: the vendor has no mechanism or incentive to patch, OEMs lack the engineering resources to develop independent fixes, and end users have no path to remediation short of replacing their device.

The Unisoc chipset is not found in premium enterprise devices, but it appears frequently in the personal phones of employees in regions where budget Android handsets are the primary device category. Organizations with BYOD policies that do not restrict device chipset or firmware version have no visibility into whether their employees’ personal devices are running Unisoc modems, and no remediation path if they are. The threat model here is not mass exploitation. It is targeted attack against specific individuals whose phone numbers are known and whose devices happen to run affected firmware.

The CISO question: For employees in your organization who use personal Android devices under a BYOD policy to access corporate email, messaging, or VPN, do you have visibility into device chipset and firmware, and do your mobile device management policies account for zero-click kernel exploits that cannot be remediated through software update?

5. Microsoft Power Pages: A global misconfiguration campaign exposed millions of records through a platform feature that defaults to public access

The headline: AppOmni researchers published findings this week documenting widespread data exposure across Microsoft Power Pages deployments, with millions of records exposed globally through misconfigured table permissions that default to allowing anonymous public access. The exposed data includes names, email addresses, phone numbers, home addresses, and in some cases partial financial information from organizations across healthcare, government, education, and financial services. This is not a CVE. There is no vulnerability in Power Pages itself. The exposure results from organizations deploying Power Pages with Microsoft’s default settings without understanding that those defaults make database tables publicly accessible to any unauthenticated user who queries the platform’s API.

What we’re actually watching: Default-open SaaS configurations are producing a category of exposure that sits outside the traditional vulnerability management framework. There is no CVE to patch. There is no vendor advisory to action. The platform is working exactly as designed. The organizations whose data is exposed are operating exactly as their administrators configured them. The misconfiguration is invisible to standard vulnerability scanning because there is nothing wrong with the software.

Power Pages is Microsoft’s low-code platform for building external-facing web portals. It is frequently deployed by non-security teams, including marketing departments, HR teams, and government agencies, to create customer-facing forms and portals that connect directly to Dataverse databases. The people deploying these portals typically do not have security backgrounds and do not understand that Microsoft’s default table permission settings allow public API access to every record in the connected tables. AppOmni has identified this pattern across organizations in the UK, US, and multiple other regions, with the UK government’s exposure receiving specific attention from NCSC.

The CISO question: Does your organization use Microsoft Power Pages, and if so, have you audited the table permissions on every deployed portal to confirm that Dataverse tables containing personal or sensitive data are not accessible to anonymous users through the platform’s default API, and do you have a process for reviewing SaaS platform deployments made by non-security teams before they go live?

The pattern across all five stories

Every incident this week reached systems that organizations had not thought to watch.

GitLab’s public repositories were reachable by anyone on the internet and audited by nobody. Copilot’s persistent memory held OAuth connections to productivity platforms and was treated as a feature, not an attack surface. vCenter sat above thousands of virtual machines and was reachable from the public internet on 4,200 instances. Unisoc modem firmware ran on employees’ personal phones under BYOD policies that never asked which chipset was inside. Power Pages portals were deployed by non-security teams against databases that defaulted to public access.

CybelAngel finds what is exposed across your external attack surface before someone with worse intentions finds it first.