Unpatched SharePoint Opens the Door to Ransomware at Water and Telecom Operators, Plus Critical Flaws in Dell, GitLab and Fortra Tools

Today's most important story is about vulnerabilities that should have been closed more than a year ago. Symantec reports that the Warlock ransomware group is still breaking into organizations through SharePoint flaws patched in July 2025, most recently hitting a water utility and a telecom provider. Alongside it, Dell, GitLab and Fortra each fixed critical flaws in infrastructure that holds high-value credentials: Kubernetes storage, an AI coding gateway and a privileged access manager. Microsoft's own X account was also briefly hijacked for a crypto scam. Below, we cover what happened, why it matters and what to do first.

Priority at a glance

Only one of today's issues is being actively exploited, and it is the oldest. Start there. The three new vendor fixes are not yet known to be exploited, but each sits on infrastructure that holds high-value credentials.

1. Warlock ransomware breaches water and telecom operators through year-old SharePoint flaws

What happened. Symantec and Carbon Black reported on October 1 that the Warlock ransomware group has hit at least four organizations in the past two months: a water utility, a telecom provider, a regional government body and a university. All were in Portuguese- and Spanish-speaking regions across Europe, Africa and Latin America. Warlock is a China-linked group, tracked by Microsoft as Storm-2603, that first appeared in mid-2025.

Who is affected. Any organization still running on-premises SharePoint Server that is unpatched against the ToolShell chain (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770 and CVE-2025-53771). Symantec says the group also exploits newer SharePoint flaws that CISA warned about in July 2026. SharePoint Online in Microsoft 365 is not part of this exposure.

How the attack unfolded. Symantec's case study shows a methodical, nine-day intrusion:

Analysis. The striking part of this report is not new tradecraft; it is how old the way in was. Microsoft issued fixes for ToolShell in July 2025, and the flaws were exploited at scale at the time. More than a year later they still work, against operators of water and telecom services.

Three details deserve attention. First, patching SharePoint alone does not undo the machine-key theft. A server patched after compromise can still be attacked with stolen keys until they are rotated. Second, the attackers needed only nine days to go from a web shell to domain-wide ransomware, and they disabled security tools before encrypting. Organizations that rely on EDR alerting as their last line of defense should assume a capable attacker will try to turn it off first. Third, abusing Group Policy and SYSVOL means the domain itself becomes the delivery system, so a SharePoint server is effectively a path to every machine joined to the domain.

For critical infrastructure operators, the concern is the boundary between IT and operational technology. Symantec does not report any impact on water treatment or network operations, but it is a reminder of why that boundary needs to hold.

What to do. — click a step to check it off, click any code snippet to copy it

1. Inventory every on-premises SharePoint Server, including forgotten ones, and confirm each has the July 2025 ToolShell fixes and all later security updates.
2. Rotate ASP.NET machine keys on every SharePoint server that was ever exposed while unpatched, and restart IIS afterward. Patching without rotation leaves stolen keys usable.
3. Hunt for web shells in SharePoint layout directories and for unexpected .aspx files.
4. Look for Visual Studio Code or code-insiders running as a service on servers, and for VS Code tunnel connections from hosts that are not developer machines.
5. Turn on Microsoft's vulnerable driver blocklist and alert on new kernel drivers being loaded, especially K7 drivers.
6. Watch SYSVOL and Group Policy for new scheduled tasks or startup scripts that deploy executables.
7. Do not leave on-premises SharePoint exposed directly to the internet. Put it behind a VPN or an authenticating reverse proxy, or consider whether the workload can move to SharePoint Online.

2. Dell fixes six critical flaws in Container Storage Modules for Kubernetes

What happened. On October 2, Dell published advisory DSA-2026-448 fixing six critical vulnerabilities in Container Storage Modules (CSM). CSM connects Kubernetes clusters to Dell storage arrays. Dell has not reported any exploitation.

Who is affected. Organizations running Dell CSM releases earlier than 1.18.0, particularly the CSM Authorization module, which controls which tenants can use which storage.

Severity. The six flaws, with scores as reported by The Hacker News:

• CVE-2026-63688 (CVSS 10.0): missing authentication in a gRPC server exposes storage administrator credentials.
• CVE-2026-63692 (CVSS 10.0): authentication bypass in the authorization proxy grants admin-level access.
• CVE-2026-67269 (CVSS 9.9): privilege escalation to root on cluster nodes.
• CVE-2026-54472 (CVSS 9.8): hard-coded credentials allow forged administrative tokens.
• CVE-2026-61421 (CVSS 9.8): hard-coded cryptographic keys allow JWT token forgery.
• CVE-2026-67273 (CVSS 9.6): a template engine flaw allows privilege escalation and tampering with Kubernetes access controls.

Dell describes the first as a complete bypass of the CSM authorization security model.

Analysis. Two of these flaws come from hard-coded secrets. That matters for remediation: hard-coded keys are identical across installations, so anyone who extracts them from one deployment can forge tokens for all of them. Upgrading replaces the code, but any token already issued or forged under the old keys needs to be invalidated too. These flaws also sit on a path from a Kubernetes cluster to the storage arrays underneath it, so a successful attacker could reach data well beyond a single application. Dell products have been exploited by state-sponsored groups before, and public detail on six critical bugs can shorten the time until working exploits appear.

What to do. — click a step to check it off

1. Upgrade CSM to 1.18.0 or later.
2. After upgrading, rotate JWT signing secrets and storage administrator credentials used by CSM, and reissue tenant tokens.
3. Make sure the CSM authorization proxy and gRPC endpoints are reachable only from inside the cluster or from defined management networks.
4. Review Kubernetes audit logs for unexpected changes to role bindings and secrets in CSM namespaces.

3. GitLab patches critical AI Gateway flaw on self-hosted instances (CVE-2026-90970)

What happened. On October 2, GitLab released fixes for a critical flaw in its AI Gateway. An authenticated user with access to GitLab's Duo Agent Platform could escape the prompt-template sandbox with a crafted flow configuration and run commands on the gateway. GitLab has not reported exploitation.

Who is affected. Only self-hosted AI Gateway deployments. Affected releases run from 18.1.6 through 19.1.x, plus 19.2.x before 19.2.4, 19.3.x before 19.3.2 and 19.4.x before 19.4.1. GitLab.com, GitLab Dedicated and self-managed instances that use GitLab's hosted gateway are not affected.

Severity. CVSS 9.9. No workaround is available.

Analysis. This is the second CVSS 9.9 template-engine escape in the AI Gateway this year, after CVE-2026-1868 in February. AI gateways are a new and attractive target: they hold model API keys, see source code and prompts, and often have broad network access to reach the services they call. The attacker must be authenticated, which limits the risk, but in large engineering organizations "any developer with Duo access" can be a big population, and developer accounts are a common phishing target.

What to do. — click a step to check it off

1. Update self-hosted gateways to 19.2.4, 19.3.2 or 19.4.1. For Docker, pull the new image tag; for Helm, update the chart's image settings.
2. Review who has Duo Agent Platform access and limit it to people who need it.
3. Rotate model-provider API keys and other secrets stored on the gateway if you cannot rule out misuse.
4. Treat AI gateways as production infrastructure: patch them on the same cadence and monitor their outbound connections.

4. Fortra patches critical flaws in BoKS privileged access manager

What happened. Fortra fixed eight vulnerabilities in BoKS, its privileged access manager for Unix and Linux fleets. Three are critical. SecurityWeek reported the fixes on October 3, and Fortra has not reported exploitation.

Who is affected. Organizations using BoKS Manager to centrally control access and policy across Unix and Linux servers. Fortra says the password flaw (CVE-2026-79901) affects only deployments that use BoKS keytab management for Active Directory service accounts.

Severity.

• CVE-2026-79901 (CVSS 9.9): BoKS generates Active Directory service-account passwords from a predictable sequence seeded with the current time. An attacker who knows roughly when a password changed can reproduce a small set of candidates and test them offline.
• CVE-2026-12627 (CVSS 9.8): a stack buffer overflow in the autoregistration feature allows remote memory corruption.
• CVE-2026-79898 (CVSS 9.1): command injection lets an authenticated user run shell commands as root on the BoKS Master.

Analysis. A privileged access manager is meant to be the most trusted system in a Unix estate, so flaws in it carry the risk of every server it controls. The password-generation flaw is the most consequential. It does not need a network exploit, only some knowledge and offline guessing, and its output is Active Directory credentials. Patching stops new weak passwords from being created, but it cannot strengthen the ones already issued.

What to do. — click a step to check it off, click any code snippet to copy it

1. Apply the updates in Fortra's BoKS advisories (FI-2026-012 through FI-2026-019, published October 1).
2. If you use BoKS keytab management, reset every Active Directory service-account password that BoKS generated after patching, so none of the predictable ones remain in use.
3. Restrict network access to the BoKS Master and its autoregistration service to managed hosts.
4. Review BoKS Master logs for unusual crlserver activity and unexpected commands run as root.

5. Microsoft's official X account hijacked for a crypto scam

What happened. On October 2, attackers took over Microsoft's main X account, which has more than 13 million followers. For about 30 minutes they used it to promote a fake "$Clippy" cryptocurrency token and swapped its profile picture for Clippy, the old Office assistant. Microsoft confirmed unauthorized access, removed the posts and is investigating. It has not said how the account was compromised.

Analysis. If one of the world's largest security vendors can lose control of its main social account, any organization can. Brand account takeovers tend to follow a few well-known paths: SIM swapping on the recovery phone number, a compromised recovery email, session cookies stolen by infostealer malware, or a compromised third-party social media management tool. Session-cookie theft is the hardest to stop because it bypasses passwords and multifactor authentication altogether. The damage is usually reputational, but a hijacked corporate account can also be used to send customers to phishing or malware sites with the company's credibility attached.

What to do. — click a step to check it off

1. Protect corporate social accounts with phishing-resistant MFA, such as passkeys or hardware security keys, rather than SMS.
2. Use a dedicated, monitored recovery email address that is not a person's inbox.
3. Review which third-party tools and agencies have access to your accounts, and remove any that are no longer needed.
4. Treat the devices of people who manage brand accounts as high-value, with endpoint protection that detects infostealers.
5. Prepare a takeover playbook: who contacts the platform, who posts the correction on other channels, and how quickly.

Touchpoint's Take

Yesterday's brief was about how fast attackers move on new flaws. Today's is the reverse: the most damaging story involves flaws more than a year old. Both are true at once, and a security program has to handle both.

1. The long tail is where breaches live. ToolShell made headlines in July 2025, and Microsoft shipped fixes then. Warlock is still using it against critical infrastructure. Organizations usually miss old flaws for ordinary reasons: a server nobody owns, a patch that failed silently, or a fix applied without the follow-up step. Here, the follow-up was rotating machine keys. Vulnerability management needs a way to find these gaps, not just a queue of new advisories.
2. Fixing the code is not the same as fixing the secrets. Every story today has a credential element: stolen SharePoint machine keys, hard-coded keys in Dell CSM, model API keys on the GitLab gateway, predictable service-account passwords in BoKS and a hijacked social media session. In each case the patch stops new abuse but leaves existing credentials valid. Rotating secrets should be a standard step after any critical patch to software that issues or stores them.
3. The systems that manage access are high-value targets. A privileged access manager, a Kubernetes storage authorization layer, an AI gateway and a collaboration server each sit in front of something larger. When one of them fails, everything behind it is exposed. These systems deserve the strictest network exposure rules and the fastest patch cycles in the estate.

What we would change in a security program:

1. Hunt for old exploited flaws, not just new ones. Each quarter, check your environment against CISA's Known Exploited Vulnerabilities catalog going back at least two years, and treat any hit as an incident until proven otherwise.
2. Add rotation to the patch checklist. For any software that stores or issues keys, tokens or passwords, rotate after a critical fix or a suspected compromise.
3. Assume EDR can be switched off. Block known vulnerable drivers, alert when security agents stop reporting, and keep logs off the host so an attacker cannot erase the evidence.
4. Protect brand accounts like production systems. Use phishing-resistant MFA, owned recovery channels and a tested takeover playbook.

If you would like help checking your exposure to any of these issues, the Touchpoint Security team is available to talk.

Sources

• Warlock Ransomware Attackers Hit Water and Telecom Operators – Symantec and Carbon Black Threat Hunter Team
• Warlock ransomware breach SharePoint in water, telecom operator attacks – BleepingComputer
• Warlock Expands SharePoint Exploitation in Critical Infrastructure Attacks – SecurityWeek
• Dell CSM Flaws Enable Unauthenticated Admin Access and Root on Kubernetes Nodes – The Hacker News
• Dell asks admins to patch max severity CSM flaws as soon as possible – BleepingComputer
• Dell patches critical vulnerabilities in container storage modules – SC Media
• GitLab Patches Critical 9.9 AI Gateway Flaw Allowing Command Execution on Self-Hosted Servers – The Hacker News
• Fortra Patches Critical Vulnerabilities in BoKS – SecurityWeek
• FI-2026-012: BoKS Manager weak password generation (CVE-2026-79901) – Fortra security advisory
• Microsoft's X account hacked in crypto pump-and-dump scheme – BleepingComputer
• Crypto Scammers Hijack Microsoft's Official X Account – SecurityWeek