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, and we break each one down into what happened, what it could mean for your organization, and what to do about it.
The pattern this week is speed. Flaws are being weaponized within days, sometimes hours, of becoming public, and severity scores are being rewritten upward only after the attacks start. Rapid7 put numbers to it last week: high and critical vulnerabilities disclosed last quarter doubled from a year earlier, and their researchers are not subtle about what that means for the monthly patch cycle. What matters is what's being exploited, and what of yours is exposed to it.
This Week's Cycle
1. VMware vCenter Exploited Five Days After the Patch: CVE-2026-59310
Broadcom disclosed a critical flaw in VMware vCenter, the console that manages a company’s virtual servers, on July 29 and shipped a patch with no workaround. Five days later, attackers were exploiting it. CVE-2026-59310 (CVSS 9.8) sits in vCenter’s built-in Syslog server, a part meant only to collect logs, and lets an unauthenticated attacker run commands as root, the highest level of control. Incident responders at QUIRSO traced a single campaign that reached 361 systems across 47 countries, tied with moderate confidence to a suspected China-nexus group. On at least one victim the intruders installed backdoors, then dropped Babuk-derived ransomware on the VMware ESXi hosts, which the researchers read less as a payday than as a smokescreen: the encryption wiped the ESXi logs and destroyed the evidence of what they had done.
Potential impact: vCenter sits above everything it manages, so root access to it is effectively root access to every virtual machine in the environment. That is why it drew a nation-state-grade actor within a week of a public patch. The ransomware makes recovery harder in a specific way: because the logs were encrypted, defenders lose the forensic trail they would normally use to scope the breach, and patching afterward does nothing to remove backdoors already planted.
What to do: Patch vCenter to the fixed build immediately, as there is no workaround. Treat any internet-reachable vCenter that was unpatched between July 29 and your update as potentially compromised, and hunt for unfamiliar root cron jobs, new administrator accounts, and reverse SSH connections rather than trusting that the patch closed the door. Keep vCenter off the public internet, and confirm you hold offline backups of both the vCenter appliance and the ESXi datastores.
Source: The Hacker News
2. A macOS Flaw Grants Root With No Password, Rescored After Attacks Began: CVE-2026-65400
A flaw in macOS Screen Sharing, the remote-control feature built into every Mac, is being used to take over machines that expose it to the internet. CVE-2026-65400 lets an attacker on the network reach Screen Sharing, which listens on port 5900, and connect with no password at all, then gain root. The Dutch national cyber agency reported active attacks in which intruders did exactly that and installed software that quietly hijacks the Mac to mine Monero cryptocurrency. Apple patched it out-of-band on August 6, but the sequence is the week’s theme in miniature: CISA first scored the bug a middling 7.1, then raised it to a critical 9.8 on August 14 once the real attacks showed it needs no credentials and can be automated.
Potential impact: The practical trap is that this happens before any login, so a strong password does nothing, and changing the password afterward does not lock the attacker out. Any Mac with Screen Sharing on and port 5900 reachable from outside is exposed, a setup that is common when remote support was enabled once and forgotten. Cryptomining is the visible payload today, but the same root access could just as easily be turned to data theft tomorrow.
What to do: Update affected Macs to the fixed versions (macOS Tahoe 26.6.1, Sequoia 15.7.9, or Sonoma 14.8.9). If you cannot patch right away, turn Screen Sharing off and block port 5900 at the firewall. Because the score was revised upward only after exploitation began, treat this as a reminder to prioritize by what is being attacked, not by the number a bug carried on day one.
Source: Help Net Security
3. CISA Gave Just Three Days to Patch the Ray AI Framework: CVE-2025-62593
CISA gave federal agencies only three days to fix a flaw in Ray, the open-source framework many companies use to run large AI and machine-learning jobs across clusters of machines. CVE-2025-62593 lets an attacker execute code on a developer’s Ray instance simply by getting them to open a malicious web page in Firefox or Safari, using a trick called DNS rebinding to slip past the browser’s protections. It was first disclosed in late 2025, but CISA added it to its Known Exploited Vulnerabilities list on August 17 after confirming real attacks, with an unusually short deadline. Ray runs inside organizations like Amazon, Apple, and OpenAI, and unpatched instances are already being pulled into a campaign that turns GPU servers into a cryptocurrency-mining botnet.
Potential impact: The uncomfortable part is that the developer does not have to do anything unusual to be hit; browsing the web while Ray runs locally is enough. AI tooling has spread into many environments faster than security has followed, often installed by data teams outside the normal IT process, which means these systems can be exposed without anyone tracking them. A three-day federal deadline on a flaw from last year is CISA saying the exposure now outweighs the age of the bug.
What to do: Find every place Ray is installed, including developer laptops, build servers, container images, and cloud compute, and upgrade to version 2.52.0 or later. Where you cannot patch at once, keep Ray’s dashboard and API off untrusted networks and behind a proxy or VPN. More broadly, take an inventory of the AI and machine-learning tools running in your environment, since you cannot protect infrastructure you do not know is there.
Source: The Register
4. AI and Industrial Tools Attacked Within Hours of Disclosure: MLflow and FUXA
Two more open-source tools came under attack almost the moment their flaws were named. In MLflow, a widely used platform for managing AI models, CVE-2026-64849 (CVSS 9.3) is a server-side request forgery bug, meaning an attacker can trick the MLflow server into making requests on their behalf. Researchers at watchTowr saw it exploited within hours of the CVE being assigned, used to reach cloud metadata services and steal the credentials that unlock the rest of a cloud account. Separately, FUXA, an open-source tool for monitoring industrial and building systems, has a flaw (CVE-2026-25895, CVSS 9.5) that lets an unauthenticated attacker write files to the server and run code; VulnCheck reports it is already being scanned for.
Potential impact: The MLflow bug is dangerous out of proportion to its obscurity because stolen cloud credentials rarely stay contained to one server; they become the key to the wider cloud account. The FUXA flaw matters most for clients with operational technology, the systems that run physical equipment, where a compromised controller has real-world consequences. Both landed on the same pattern as everything else this week: exposure plus a public CVE equals exploitation, measured in hours.
What to do: Update MLflow to a fixed release (3.15.0 or later) and rotate any cloud credentials an exposed instance could have reached, since credential theft is the whole point of the attack. For FUXA, restrict it to trusted networks and apply the vendor’s guidance. As a rule, treat AI and operational-technology software the way you already treat internet-facing servers: patched, off the open internet, and inventoried.
Source: The Hacker News
5. GitLab Rushed an Emergency Fix After an Exploit Appeared in Minutes: CVE-2026-19478
GitLab, the platform many teams use to store and manage their source code, shipped an emergency fix on August 17, outside its normal schedule, for a flaw serious enough to break that schedule. CVE-2026-19478 (CVSS 9.4) let an unauthenticated attacker, with no account and no clicks from a victim, modify or delete public projects and user data on self-managed GitLab servers by sending a crafted request to its API. The speed is the point: the security firm watchTowr said it reproduced a working exploit within minutes of the fix being published, which is exactly how attackers turn a patch announcement into a roadmap. Only organizations that run their own GitLab are affected; the hosted GitLab.com service was already patched.
Potential impact: Source code repositories are high-value in two directions. Losing them can halt development, and tampering with them can poison everything built from that code downstream, a supply-chain risk. Because the flaw needs no login, any self-managed GitLab reachable from the internet is a target, and the window to act is short by design. One gap worth checking: the fixes cover the 18.11 and 19.x branches, while older 18.2 through 18.10 installs sit in the affected range without a direct patch.
What to do: Upgrade self-managed GitLab to a fixed version (19.2.4, 19.1.6, 19.0.8, or 18.11.11) now. Confirm whether your instance exposes its API to the internet and put it behind a proxy or restrict access while you patch. If you are on an older branch the patch does not cover, plan an upgrade path rather than assuming you are out of range.
Source: Cybersecurity Dive
6. Rapid7: The Space Between a Patch and an Exploit Has Collapsed
Tying the week together, Rapid7 released its Q2 2026 Quarterly Threat Landscape Report, and the numbers reframe the problem. High-severity disclosures exploded from 4,268 to 8,539 year over year, while the count of newly exploited vulnerabilities stayed roughly flat, rising only about 8 percent. The implication is that attackers are getting more selective, not more prolific. 62% of newly exploited vulnerabilities were flaws that could be exploited over a network without authentication or user interaction, the kind an attacker can automate at scale. Beek's read on what that means for defenders is direct: "We're drowning in a deluge of disclosures, and the gap between a patch existing and an exploit being weaponized has collapsed to near zero. Security teams are chasing ghosts if they think they're 'secure' just by closing tickets based on CVSS scores."
Potential impact: This is the context behind every other item above. When exploitation is measured in hours and days, a monthly patch cadence and a habit of triaging by severity score leave a standing gap that attackers automate straight through. The practical shift is from patching everything eventually to finding what is both exposed and being exploited, and fixing that first.
What to do: Prioritize remediation by real-world exploitation and exposure, not by CVSS score alone. The most useful public signal is CISA’s Known Exploited Vulnerabilities list: anything on it that you also run should jump the queue. Pair that with an honest inventory of what of yours is reachable from the internet, because exposure plus a known exploit is the combination that gets you hit.
Source: SecurityWeek
The Big Picture
Rapid7's numbers confirm this week wasn't a fluke. The speed is structural, and patching faster across the board is a race no team wins. What works is a narrower question: which of your systems are reachable from the internet, and which of those show up on the list of what's being exploited right now. Start there and work outward.
CISA's Known Exploited Vulnerabilities catalog is the most useful public signal for that second question, and anything on it that you also run should jump the queue regardless of its CVSS score.
Check back next week for another Threat Thursday. See you then!
