This edition centres on MSPs’ own management tools. N-able has taken N-central offline after more than 30 zero-days were published, attackers are using two flaws in the AhsayCBS backup server to deploy webshells and cryptominers, and the OpenSSH flaw SSHole is now being actively exploited. In addition, Google has patched an actively exploited zero-day in Chrome, and attackers are abusing a Qubole integration to drain customers’ AWS environments.
- N-able takes N-central offline after more than 30 zero-days in the RMM software are published
- AhsayCBS backup servers hacked via two flaws: webshells, cryptominers and a hunt for Veeam credentials
- SSHole: previously reported OpenSSH flaw on musl Linux now actively exploited and added to CISA’s list
- Chrome update fixes actively exploited zero-day in the XML component, the eighth this year
- Attackers abuse Qubole integration with customers’ AWS environments to steal secrets and S3 data
N-able takes N-central offline after more than 30 zero-days in the RMM software are published
| Vulnerability | 33 alleged critical vulnerabilities in N-able N-central (hosted and on-premises), which can be chained into four exploit chains under the name ‘Able2Shell’: authentication bypass, credential disclosure, arbitrary file write, XXE, RCE and privilege escalation. Tested on N-central Appliance 2026.4.0.31; older versions are probably affected too |
| CVE number | No CVE assigned |
| Actively exploited | No, N-able had seen no exploitation as of 9 November (15:15 UTC). However, the proof-of-concept exploits are publicly available on GitHub |
| Patch available | No, N-able is working on a hotfix with no release date. N-able has taken the hosted environments offline and advises shutting down on-premises servers until further notice |
What happened?
On the evening of Sunday 8 November, researcher Sean Bales published the ‘Able2Shell’ repository on GitHub containing proof-of-concept exploits, which he says were found partly with the help of AI. According to BleepingComputer, the most dangerous chain is an unauthenticated XXE vulnerability that leads to code execution and the creation of an additional administrator account. N-able reported a ‘critical security incident’, took hosted N-central offline in the Americas, Europe and Asia-Pacific, and has promised an update every four hours.
What could the impact be?
N-central is an RMM platform that MSPs use to manage the systems of all their customers. Control over the management platform makes it possible to push scripts and tools to every connected environment. That has already happened in earlier N-central attacks this year, as Huntress points out. Moreover, as long as there is no hotfix, taking the server offline means losing your own monitoring and patch management.
What should IT administrators do now?
Take on-premises N-central servers offline and keep them offline until N-able confirms it is safe to restore them. If you use the hosted service, expect an outage and follow N-able’s status page. Check authentication logs from 8 November onwards for unexpected access, and look in the audit logs for unusual remote sessions, newly deployed scripts and unknown administrator accounts. Only apply the hotfix once N-able says so; the version number may differ from 2026.4.0.31. Also prepare customer communications, as you will temporarily be unable to provide remote management.
AhsayCBS backup servers hacked via two flaws: webshells, cryptominers and a hunt for Veeam credentials
| Vulnerability | Authentication bypass and unauthenticated remote code execution as SYSTEM (via /rps/api/json/UpdateReceivers.do) in Ahsay AhsayCBS, Ahsay’s backup server (v10 and v7 up to and including v9) |
| CVE number | CVE-2026-105133 (authentication bypass) and CVE-2026-105134 (remote code execution) |
| Actively exploited | Yes, since early October 2026. Huntress saw three servers compromised in a single environment between 8 and 11 October; the first report dates from 8 October, and the follow-up research was published on 9 November |
| Patch available | Yes, AhsayCBS 10.3.4.45 (v10) and 9.15.2.70 (v7 up to and including v9). Huntress has only verified 10.3.4.45. Patching does not remove files that have been planted |
How has this been exploited?
Attackers gained access via internet-facing AhsayCBS servers. According to research by Huntress, they planted five families of JSP webshells, installed an XMRig cryptominer with a SYSTEM task that runs every minute, and deployed a Python implant that communicates with a C2 server via HTTPS and DNS-over-HTTPS. Tunnelling tools (gost, chisel), AnyDesk, Atera and Splashtop also appeared, along with a local account ‘wdguest’, Mimikatz and broad Defender exclusions. One webshell hid payloads in PNG pixel data.
What could the impact be?
The attackers deliberately targeted backup infrastructure. On a related Veeam server, they attempted to extract stored credentials from the database. A compromised backup server provides access to customer data, stored passwords and the recovery capability itself. Whether any data was actually stolen is unknown. A webshell with download functionality could serve as an exfiltration channel.
What should IT administrators do now?
Update to the versions mentioned, then search every server for unknown .jsp files, folders such as ahsay_*, unknown scheduled tasks, Defender exclusions and a Python installation under the SYSTEM profile. Search the AhsayCBS logs for requests to UpdateReceivers.do. In the event of a confirmed compromise, Huntress advises a full reinstallation from a trusted backup and rotating all credentials reachable via the server, including those for other backup software on the network.
SSHole: previously reported OpenSSH flaw on musl Linux now actively exploited and added to CISA’s list
| Vulnerability | Authentication bypass in OpenSSH on musl-based Linux systems such as Alpine: an overly long password causes musl’s hash function to return a ‘*’, which OpenSSH treats as a valid match for accounts with a ‘*’ in /etc/shadow |
| CVE number | CVE-2026-123158 |
| CVSS score | 8.1 (according to The Hacker News) |
| Actively exploited | Yes, first attempts on 5 November, first successful attacks on 6 and 7 November. CISA added the flaw to the KEV catalogue on 9 November |
| Patch available | Yes, OpenSSH 10.6p2 (released on 5 November). Alternative: disable password authentication for SSH |
How has this been exploited?
This flaw was already covered in Patchwork of Friday 6 November. What is new is the confirmed exploitation. According to BleepingComputer, a proof of concept appeared four hours after the patch, and GreyNoise saw the first successful attack around 40 hours after the fix, with 16 attack chains from six IP addresses. Previdian counted attempts from 13 IP addresses in nine countries, while watchTowr observed botnet and cryptominer activity. After logging in, attackers reconnoitre the system and the container, query cloud metadata, try to read password hashes and root SSH keys, and modify authorized_keys for persistence. In one case, the Python implant ‘TAC Agent’ was dropped.
What could the impact be?
Accounts with a ‘*’ in the password field, such as service accounts, can be accessed without a valid password. For accounts with passwordless admin rights, this leads to root. According to The Hacker News, the flaw has been added to the KEV catalogue together with three other vulnerabilities, with a deadline of 12 November for US government agencies. According to Defused Cyber, the exploitation is not yet widespread.
What should IT administrators do now?
Update OpenSSH to 10.6p2 or later, or disable SSH password authentication. Look for unexpected password logins on accounts with a ‘*’ in /etc/shadow, check authorized_keys for unknown keys, and search for TAC Agent files and associated startup services. Pay particular attention to Alpine containers and other musl-based images.
Chrome update fixes actively exploited zero-day in the XML component, the eighth this year
| Vulnerability | Use-after-free in the XML component of Google Chrome, part of an update that fixes nine vulnerabilities |
| CVE number | CVE-2026-125350 |
| Actively exploited | Yes, according to Google. No details about the attacks have been shared, and as of 10 November CISA had not yet added the flaw to the KEV catalogue |
| Patch available | Yes, Chrome 157.0.8103.50 or later (Linux), 157.0.8103.50/.51 (Windows and Mac) |
What happened?
An anonymous researcher reported the flaw on 6 November. Google released the fix on Monday 9 November and says the flaw is already being exploited, according to SecurityWeek. It is the eighth Chrome zero-day of 2026. The update also fixes six high-severity bugs in components including WebGL, FileSystem, Compositing, GPU and V8, as well as two medium-severity bugs.
What could the impact be?
Chrome is installed on virtually every managed workstation. A use-after-free in the browser is often the first step in an attack that starts with a malicious page. Because Google has not yet shared any details, it is unclear who is exploiting the flaw and against whom.
What should IT administrators do now?
Roll out Chrome 157.0.8103.50 or later as soon as possible via your patch management, and check that the browser has actually been restarted after the update.
Attackers abuse Qubole integration with customers’ AWS environments to steal secrets and S3 data
| Vulnerability | Abuse of cross-account IAM roles that customers had created in AWS for data platform vendor Qubole. Attackers used IAM credentials from an AWS account linked to Qubole and assumed the roles using the ExternalId. How those credentials were obtained has not been disclosed |
| CVE number | No CVE assigned |
| Actively exploited | Yes, from 14 to 26 October 2026 in several customer environments. Wiz, Sentra and Mandiant published their findings on 9 November |
| Patch available | No, this is not a software flaw. Administrators need to tighten roles, rotate secrets and search CloudTrail |
How has this been exploited?
According to research by Wiz, vendors are given access via a role in the customer’s account, with a trust policy that allows the vendor’s account to assume that role, usually secured with an ExternalId. The attacker called sts:AssumeRole with that ExternalId, and every attempt succeeded. Wiz points out that the ExternalId is not a secret: it appears in CloudTrail and in infrastructure as code. A source IP restriction would have blocked all the observed attacks. The attacker enumerated S3, EC2, RDS, IAM and KMS, read Lambda environment variables, Secrets Manager and SSM Parameter Store, tested discovered keys with TruffleHog (including for Entra ID and Okta) and in some cases read entire S3 buckets.
What could the impact be?
The pattern is consistent with earlier attacks via trusted vendor identities: a breach at one party opens up the environments of all its customers. Discovered secrets provide access to yet more systems, and revoking sessions does not terminate existing temporary credentials.
What should IT administrators do now?
Inventory all IAM roles that trust external accounts and remove any that are no longer needed. Restrict the trusted principal to the vendor’s specific IAM principal and add aws:SourceIp or aws:SourceVpce. Do not use the ExternalId as the only control. Search CloudTrail from 1 October onwards for AssumeRole from account 805246085872 with a non-AWS source IP, for sessions named ‘quiam-‘ and for GetCallerIdentity with a TruffleHog user agent. If you find a match, rotate all secrets, parameters and Lambda variables that the role could read.
This article was originally published in Dutch on MSP Business. Read the original →
