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.
PHP, the programming language behind a large share of the web, got an emergency fix this week for flaws found with help from AI, and attackers were testing them before the patch arrived. It’s the update to put first this week. It also wasn’t the only advisory that showed up after the attackers did, and the stories below show why an advisory’s date says little about when the risk began.
This Week’s Stories
01. PHP2Shell: Attacks on PHP Started Four Days Before the Fix (CVE-2026-109618, CVE-2026-109619)
Roughly 70% of websites run on PHP, including sites built on WordPress, Joomla, and Drupal. On October 21, its developers released emergency updates for two serious flaws, now called PHP2Shell (CVE-2026-109618 and CVE-2026-109619), that let an attacker take control of a web server from the internet without a password. Amazon’s security team has since reported that someone tried the attack against its decoy servers on October 17, four days before the fix existed, and it isn’t clear how they learned the details so early. Attempts from several groups followed on release day. Some researchers have also claimed the fix is incomplete. One new bug introduced by the update has been confirmed, but it can crash a server rather than hand it over, and claims of a full workaround to the fix haven’t been reproduced.
Potential impact: The early start changes what ‘patched’ means. A server updated on October 22 was still exposed for at least five days, and security firm CrowdStrike says a successful attack leaves almost nothing behind in the server’s records. The larger exposure is older websites, since many run versions of PHP that no longer get official fixes and won’t be covered without an upgrade. Sites hosted by outside providers are easy to overlook too, because the business owns the risk but not the server.
What to do: Organizations should update every server running PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (or the matching package from their Linux vendor) and restart the web server so the update takes effect. Sites on older, unsupported versions need an upgrade plan. Reviews for signs of attack should reach back to October 17, not the release date. Ask web hosting providers to confirm they’ve updated, and watch PHP’s site for a follow-up release.
Source: Amazon Threat Intelligence
02. ConnectWise Shuts Off Cloud Backup After Attackers Abuse Its Microsoft 365 Access
ConnectWise sells a Microsoft 365 backup service, formerly called SkyKick, that many IT providers use to back up their customers’ email and files. To do that job, the service holds broad, standing access to each customer’s Microsoft 365 environment. In mid-October, attackers began signing in as that service, and because they logged in as a trusted app rather than a person, multi-factor authentication (the extra code at sign-in) never came into play. Security firm Huntress confirmed unauthorized sign-ins at more than 160 Microsoft 365 environments, and ConnectWise shut the service off on October 17, along with two related products. In one environment, the attacker gained full admin rights and planted extra logins on two other apps, set to stay valid until 2028. ConnectWise says it has found no sign that stored backups were accessed and began restoring service in phases on October 21.
Potential impact: This is what happens when a trusted tool’s access becomes the prize. The attacker didn’t need to trick anyone or beat a login prompt, because the backup service already held the keys. Shutting the service off cut that path, but it didn’t remove the separate back doors planted on other apps, so turning one thing off isn’t the same as cleaning up. There’s also a less visible cost: while the service is paused, new email and files aren’t being backed up.
What to do: Organizations using ConnectWise Cloud Backup, SaaS Security, or Cloud Management should keep those app connections disabled until ConnectWise’s restoration steps apply to them. Save Microsoft 365 sign-in and audit records first, then review every connected app for new passwords or certificates added since October 13, unexpected admin rights, and email forwarding rules nobody created. Plan for the gap in backups until the service fully returns.
Source: Infosecurity Magazine
03. BeyondTrust Remote Support Flaw Was Exploited Six Weeks Before Disclosure (CVE-2026-102764)
BeyondTrust Remote Support is a tool help desks use to connect to and fix computers remotely. On October 15, BeyondTrust disclosed CVE-2026-102764, a flaw that lets an attacker skip the login and work with files on the system over the internet. The company confirmed attackers used it as early as August 29, against one system it hosted and one a customer ran. Google’s Mandiant team linked the activity to a suspected China-backed spying group, which installed hidden tools, took full control of the system, tried to pull out its stored passwords, and erased logs. BeyondTrust fixed its cloud customers on October 9, while organizations running their own copies have to install the patch themselves. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its list of actively exploited vulnerabilities on October 16.
Potential impact: Remote support tools sit in a privileged spot, connected to many computers and often holding the passwords used to reach them. Six weeks gives a patient attacker plenty of time to collect credentials and set up ways back in, and BeyondTrust’s own guidance is that installing the patch doesn’t remove anything already planted. Erased logs make it harder still, since the evidence that would answer ‘were we hit?’ may already be gone. Here, the review matters as much as the update.
What to do: Organizations running their own BeyondTrust Remote Support or Privileged Remote Access should install patch BT26-05-RS right away, upgrading first if they’re on a version older than 24.3.1. Next, check for signs of compromise using the indicators BeyondTrust and Mandiant published, and rebuild from a clean copy if a break-in can’t be ruled out. Change every password the tool stores, including for cloud customers.
Source: Rapid7
04. GitLab Patches a Top-Severity Flaw Affecting 12 Years of Releases (CVE-2026-110264)
GitLab is a platform software teams use to store their code and automate how it’s built and released. On October 21, GitLab fixed CVE-2026-110264, a flaw rated 10 out of 10 for severity that could let someone with no account run their own commands on a company’s GitLab server. The bug sits in the code GitLab uses to read search patterns, and it affects every self-hosted version back to 2014, so GitLab took the unusual step of releasing fixes for older versions too. The company hasn’t detailed the exact conditions an attack needs, and it reports no signs that anyone has used the flaw. The researcher who found it has now reported four similar flaws in about a month. GitLab’s own hosted service is already fixed.
Potential impact: This is the one story this week where defenders got there first. A code server holds more than code, since it usually stores passwords and keys for the systems that code is deployed to, so a takeover can spread well beyond the development team. A steady run of related flaws also suggests researchers, and likely attackers, are studying the same part of GitLab closely. Organizations that update now never have to ask whether attackers got in first.
What to do: Companies that host GitLab themselves should update to the fixed release for their version, ranging from 19.5.1 down to 18.11.13 for older installations. Some updates make database changes, so single-server setups should plan a short maintenance window. Updating is the only real protection, since there’s no temporary workaround. GitLab also published detection rules that look in its logs for crashes tied to this flaw.
Source: The Hacker News
05. OpenCode AI Coding Assistant Flaw Let Malicious Add-On Servers Run Code on Windows
OpenCode is an open-source AI coding assistant developers use to write and edit code. Like many AI tools, it can connect to outside services through MCP (Model Context Protocol), a standard way of giving AI tools extra data and abilities. Security firm Pillar Security found that on Windows and WSL (the Linux environment built into Windows), a malicious MCP service could run commands on a developer’s computer when the developer signed in to it. Pillar reported the flaw privately on August 29. OpenCode’s maker fixed it in version 1.18.33 on September 28 but didn’t call it a security fix, didn’t request a CVE identifier, and said malicious MCP services fall outside what it defends against. No attacks have been reported, and Mac and Linux computers aren’t affected.
Potential impact: Without a CVE, security scanners and software alerts have nothing to match against, so older copies won’t show up on anyone’s report. The fix sat in public for three weeks before most people had any reason to look for it. Developer computers are valuable targets because they often hold access to source code, cloud accounts, and internal systems. As AI tools pick up more add-ons, each new connection is another party trusted to run on that machine, and it deserves the same scrutiny as any other software.
What to do: Organizations should check the OpenCode version directly on Windows and WSL machines and update to 1.18.33 or later. Developers should review the MCP services connected to their AI tools and remove any nobody has vetted, since a once-trusted service can change hands. AI coding tools belong on the software inventory, with someone responsible for keeping them current.
Source: The Hacker News
06. SafePay Ransomware Has Hit at Least 600 Critical Infrastructure Organizations, Agencies Warn
U.S. agencies including CISA, the FBI, and the Secret Service, along with German and UK law enforcement, published a joint warning on October 20 about SafePay, a ransomware group active since August 2024. The agencies say SafePay has compromised at least 600 organizations across critical infrastructure sectors in North America, South America, Europe, and Australia. The group typically gets in with stolen or guessed passwords, through remote-access connections, or by exploiting known flaws in firewalls and similar equipment. Once inside, it uses ordinary admin tools to spread, turns off security software, copies data out, and deletes backups before locking files and demanding payment. Victims who refuse see their data posted online, and some get pressure phone calls. Because only non-paying victims get posted, the real count is likely higher.
Potential impact: The advisory covers activity reaching back to late 2024, which shows how long these intrusions build before the visible part. Locking files is the final step, and by then the attacker has usually held access for some time, taken data, and gone after backups. That’s why the entry points and the backups deserve more attention than the ransom note. Every one of SafePay’s ways in is a familiar gap, which means each can be closed before the group ever reaches a network.
What to do: Organizations should update firewalls, VPNs, and other internet-facing equipment first, starting with flaws on CISA’s list of actively exploited vulnerabilities. Require multi-factor authentication on remote access and admin accounts, and watch for new admin accounts or unfamiliar remote-management tools. Keep at least one backup copy offline or unchangeable, and test restoring from it. Security teams can check the advisory’s indicators against their logs.
Source: BleepingComputer
The big picture
The date on an advisory tells you when a fix became available, and this week showed how far ahead of that date an attacker can start. The head start ran from four days to six weeks, and a fix that ships without any announcement leaves people without a reason to check at all.
So when a serious advisory lands, ask whether you’re updated and what happened on those systems before you were. Answering the second question depends on logs that reach back far enough and sit somewhere an attacker can’t erase them, and that’s easier to set up between advisories than in the middle of one. Patching before anyone is exploiting a flaw, as GitLab customers can this week, means the second question doesn’t need an answer.
Make sure to check back here each week for another Threat Thursday update. See you then!
