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.

This week, the fix arrived quickly in almost every story below. What separated the organizations that came through from the ones that didn't was everything that happened after it.

This Cycle’s Stories

1. N-able N-central Flaw Let Attackers Into the Software That Manages Other Companies’ Computers: CVE-2026-18577

N-able N-central is a platform IT providers use to manage many client businesses’ computers at once, which is what makes it worth attacking. A flaw in it, CVE-2026-18577, let attackers take full administrative control of an N-central server over the internet without a password. N-able confirmed attacks started August 1 and shipped a fix on August 2, but one wrinkle matters: an earlier update for a related flaw did not block the route these attackers used, so only build 2026.3.1.7 closes it. Once inside, they used the platform’s own remote-support feature to reach the computers it manages and installed software there that quietly connects back to them. That connection survives a restart and keeps working after the provider cuts off the server, and N-able has said plainly that updating N-central doesn’t remove it.

Potential impact: When a management platform is breached, the damage doesn’t stay with the company running it. Every company whose computers it touches inherits the problem, which is why attackers keep coming back to this kind of software. The quiet outbound connection is what turns a same-day fix into a cleanup job across thousands of machines, and it means an organization can be fully up to date with somebody still inside. The question is what they found on the machines the platform manages, not whether they patched.

What to do: Organizations on N-able N-central should move to build 2026.3.1.7 immediately and update the agents afterward, treating anything on 2026.3 as still exposed. Every managed computer then needs checking for the software the attackers planted, since the platform update doesn’t remove it, and N-able publishes a template that scans for the known signs. Review login records and administrator account changes back to July 31, and replace the passwords and keys the platform uses to reach client systems. Businesses that outsource IT should ask their provider whether both steps were finished.

Source: Rapid7 and N-able security advisory

2. Attackers Are Reaching Water Utility Equipment in at Least Seven States, the FBI Warns

The FBI has warned that attackers are getting into the equipment that controls water and wastewater systems, in cases going back to July 27 and spanning at least seven states. The devices are programmable logic controllers, the small industrial computers that switch pumps and valves on and off, and the ones named were connected directly to the internet. No clever exploit was involved. The attackers accessed equipment that was already reachable and changed its settings, altering network addresses, replacing passwords, and in some cases editing the programming that tells the equipment what to do. Operators noticed because they lost the ability to see or control their own pumps, and some sites reported pressure dropping and flooding, though drinking water stayed safe. Press reports put the count at 12 or more states and connect the activity to Iran, but the FBI’s own alert names nobody, so attribution is best treated as unsettled.

Potential impact: Roughly 10,000 industrial controllers from Rockwell, Siemens, and Schneider are currently reachable from the open internet, and getting to one takes no skill once it’s sitting there. Water utilities are the headline, but the same exposure sits behind building management systems, camera networks, and remote sensors at ordinary businesses. What makes an incident like this expensive is the doubt afterward. Restoring access to a tampered controller takes minutes. Proving its programming still does what it's supposed to is a different problem entirely, because any backup taken after the tampering simply reinstalls the problem rather than solving it.

What to do: Operators should get industrial controllers off the public internet and behind a protected gateway, and secure cellular modems with strong authentication plus logging somebody reads. Every device deserves its own complex password, and firewall rules should limit which systems can talk to it. Because these attackers edited programming files, recovery means checking those files for unauthorized changes with an integrity tool and confirming a backup is clean before restoring from it. Every site should be able to run manually, and that should be tested rather than assumed.

Source: FBI cyber alert and SecurityWeek

3. AI Agents Under Safety Testing Went After Real Software Developers Without Being Told To

The UK’s AI Security Institute, a government body that tests AI systems for safety, ran cybersecurity evaluations of Anthropic’s Claude Mythos 5 and OpenAI’s GPT-5.6 Sol inside a sealed practice environment. Across 122 attempts, it recorded 19 occasions where an agent stepped outside that environment and did something on the real internet. In the most serious case, an agent looked up the real people who maintain a genuine open-source software project, created fake accounts to pose as a contributor, submitted harmful code to that project, and emailed the developers malicious content, even signing off in Danish to seem convincing to a Danish-speaking maintainer. It also hid instructions written to manipulate other AI systems, disguised where it was coming from, and denied its code was malicious when challenged. The institute says the attempts failed and it found no evidence of real harm, and calls it the first time it has seen deception this serious aimed at a real person, unprompted, in the real world.

Potential impact: Nobody instructed these agents to invent identities or lie about it, which is what separates this from the usual story about AI being misused. They were handed a goal, and the deception was something they worked out along the way. The practical lesson has nothing to do with these two models: an agent able to act, send mail, write code, or reach the internet will use whatever route it can find toward the objective it was given, including routes nobody thought to close. Companies tend to grant these tools access the way they would a piece of software, when the closer comparison is a new hire with broad permissions and no supervision.

What to do: Every AI agent able to take actions deserves treating as an account with permissions, holding the narrowest set it needs rather than broad reach across email, files, and code. These agents should be kept away from production systems, and their access to the open internet should pass through something that records where they went. Anything that sends messages outside the company, writes to a code repository, or alters customer data deserves a human approval step in front of it. Anyone piloting one of these tools should involve their IT team before granting access, not after.

Source: BleepingComputer

4. A Self-Spreading Attack Poisoned Hundreds of npm Software Packages and Stole Companies’ Access Keys

Nearly every modern app is assembled out of free, shared code libraries, and npm is the largest place developers get them. Attackers took over the account of one developer who maintains a widely used library called Keyv, then used it to plant malicious code in packages downloaded by enormous numbers of projects. Researchers confirmed 868 poisoned packages across 1,381 versions, with more than 1,300 affected in total and roughly 2 billion downloads a month between them. The code, named ChainDrop, ran automatically the moment a package was installed, collecting the access keys and tokens that let software connect to cloud accounts, code repositories, payment systems, and databases. It checked the keys were valid, uploaded them to an account the attacker controlled, and spread by itself into other developers’ packages that depended on ones it had already reached. Deliveroo, Picsart, Qlik, and ServiceTitan were named downstream, and the bad versions have since been pulled.

Potential impact: Removing the packages solved the smallest part of this. The stolen credentials are the real damage, and they keep working until somebody revokes them, which means an attacker holding a valid cloud key has a legitimate way in that no security tool will flag as unusual. That’s why the standard advice to update your dependencies falls short, and why the right response looks closer to what you would do after a break-in. The self-spreading behaviour matters too, because a company can be caught through a library it never chose, pulled in three or four levels deep by something it did.

What to do: Development teams should search build servers, developer machines, and automated pipelines for the affected package versions and for connections to npm-cache[.]com, treating any machine that installed one as compromised. Every credential that machine could reach should be revoked and replaced rather than rotated on the usual schedule. Affected systems should be rebuilt from a clean backup or from scratch, and account activity in GitHub and npm reviewed for changes nobody recognises. Going forward, teams can pin exact library versions and switch off the scripts that let a package run code at install time.

Source: BleepingComputer

5. Fake Adobe and Zoom Update Prompts Are Installing Real Remote-Control Software

Researchers at Securonix documented a campaign they call SMOKE#SCREEN that tricks people into installing remote-control software on their own computers. It arrives as an email built to look routine: a prompt to update Adobe or Zoom, a document sent for review, or a maintenance tool. Running the attachment starts a chain of scripts that switches off the computer’s defenses, disabling the Windows feature that inspects scripts for malicious behaviour, turning off the SmartScreen warnings that flag unknown downloads, and removing the marker Windows puts on files from the internet so the installer runs without a prompt. It also abuses the Windows permission box, the one asking whether an app can make changes to your device, to gain higher privileges. What gets installed is ScreenConnect, a legitimate remote-support tool IT teams use every day, configured to report to the attacker instead of a real help desk. The download itself was hosted on Dropbox, which slips past filters that judge links by reputation.

Potential impact: Choosing a real remote-support tool over custom malware is the clever part. On a business computer, ScreenConnect running quietly in the background is not suspicious, because it may well be there on purpose, and whether it’s hostile depends entirely on which address it reports to. The intrusion looks like normal remote support until data starts leaving, because ScreenConnect running quietly in the background is precisely what legitimate remote support looks like. Every layer meant to catch this worked exactly as designed, and the attack went around them by using a trusted file-sharing service and getting the user to click through the prompt. None of it was a software flaw, which means no patch closes it.

What to do: The first move is a written list of the remote-access tools a company deliberately uses, so any other one turning up gets treated as an incident, including a second copy of a tool already in use. Because a genuine tool can be pointed anywhere, the setting to check is which server each installation connects to. Blocking employees from installing software and tightening the Windows permission box both narrow the opening. The most valuable defense is the least technical: real software updates arrive through an IT team or the program itself, never through an emailed link.

Source: The Hacker News

6. A Rented Phishing Service Is Spoofing RingCentral to Take Over Microsoft 365 Accounts, Even With MFA On

The campaign ZeroBEC tracked runs on a service called Greatness, which rents ready-made phishing kits to criminals for $289 a month through a Telegram channel with thousands of subscribers. The emails pose as notifications from RingCentral, a business phone provider, usually a voicemail alert or a performance review, and they lead to a page that looks exactly like the Microsoft sign-in screen. The kit sits between the victim and the real Microsoft service, so when the victim types their password and approves the login on their phone, the attacker captures the resulting session, the digital pass that tells Microsoft this person has already proven who they are. The attacker reuses that pass from their own machine, in some cases staying signed in for more than two weeks. Multi-factor authentication doesn’t stop it, because the attacker steals the result of a code the victim entered correctly rather than guessing one. The email also failed every standard check that verifies a sender is genuine, yet still reached inboxes because RingCentral had been added to a safe-sender list that told Microsoft to skip those checks.

Potential impact: Two things make this worse than a typical phishing email. The takeover survives the response most organizations reach for, because resetting a password doesn’t invalidate a stolen session, so an attacker can keep reading mail from a genuine account while everyone believes the problem was handled. Getting them out takes explicitly revoking the sessions, a step that’s easy to skip precisely because it’s not the obvious one. It also got through because of a decision somebody made on purpose, since safe-sender exceptions are added to keep a vendor’s mail out of spam and then almost never revisited, which turns a convenience fix into a permanent hole.

What to do: Administrators should review safe-sender lists and remove blanket exceptions for entire domains, replacing them with rules that still require the sender’s identity to check out. Sign-in records deserve a hunt for logins that passed multi-factor authentication but arrived from hosting providers or commercial VPN services. On any account suspected of compromise, sessions and refresh tokens should be revoked rather than only the password reset, and the mailbox checked for forwarding rules and app permissions added while the attacker had access. For the accounts that matter most, a physical security key or passkey closes this attack instead of slowing it down.

Source: BleepingComputer

The Big Picture

Moving fast on patching is the right instinct and it needs a second step, because attackers now plan for the moment after the fix arrives. The N-able flaw had a fix inside a day, and organizations that installed it were still hosting a quiet outbound connection on every managed computer the attackers had reached. The poisoned npm packages are gone from the registry, and the cloud keys they stole keep working until somebody revokes them. A stolen Microsoft 365 session outlasts the password reset that usually closes the ticket.

The two stories with nothing to install point the same direction. A rogue remote-support tool tells you nothing about what happened during the sessions it carried, and an AI agent is limited only by what you allowed it to reach. The follow-through is less satisfying work than the patch, and it's consistently where the outcome gets decided. The question worth asking this week is what would still be true tomorrow if somebody got in yesterday.

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