Weekly Threat Intelligence Round-Up: OpenSSH SSHole on Alpine Containers, a Misattributed Zyxel Zero-Day and the Chainalysis Token Breach

This week’s weekly threat intelligence round-up has one headline for cloud teams: the OpenSSH SSHole flaw on Alpine containers (CVE-2026-123158). On musl-based builds with PAM disabled, an over-long password can log in to an account that has no password set. Alpine’s default sshd configuration fits that description, and Alpine is the base image under a large share of the world’s containers. The fix is OpenSSH 10.6p2. In a container estate, though, that fix only lands when someone rebuilds the image.

Three more stories round out the week. A Zyxel switch campaign turned out to be using a different, unpatched bug from the one defenders were told about. Chainalysis widened its breach disclosure from contact details to every user’s credentials and tokens. And there is a short follow-up on last week’s Airbyte warning.

1. OpenSSH SSHole on Alpine containers: an inventory problem first, a patch problem second

What was reported. OpenSSH shipped 10.6p2 on 5 November to fix CVE-2026-123158, which researchers have nicknamed “SSHole”. Reporting from The Hacker News, OX Security, Ostorlab, SOC Prime and others agrees on the core conditions:

• OpenSSH built against musl libc
• PAM disabled
• Password authentication enabled
• An account with no password set

When all four are true, a password of roughly 257 to 1,024 bytes is accepted for the passwordless account. OpenSSH developer Damien Miller is quoted as saying glibc and PAM-based systems are not affected, which covers most mainstream distributions. Red Hat’s CVE page tracks the issue. The reported root cause is the long-password handling added years ago to mitigate CVE-2016-6210, a user-enumeration timing flaw. The code that hid valid usernames ended up opening a different hole.

Severity and exploitation. The Hacker News gives the flaw a CVSS score of 8.1 and says OpenSSH rates it critical. Check the NVD record before you quote a number. The same outlet reports exploitation attempts within hours of disclosure, including root access on a honeypot, citing a single research firm. We have not confirmed that independently, and as of Friday it was not on CISA’s Known Exploited Vulnerabilities list. For an authentication bypass this simple, plan as if it will be exploited.

Why cloud teams should care more than anyone. On a normal Linux server, sshd on Alpine is rare. In cloud estates it shows up in places nobody tracks centrally:

• Container images that bundle sshd for “debug access” or legacy deployment tooling
• Bastion and jump hosts built on Alpine for their small size
• CI runners and build agents that accept SSH from an orchestrator
• Marketplace and vendor appliances whose base OS you never chose
• Kubernetes debug pods and sidecars that someone created once and nobody removed

Each of these runs an image built at some point in the past. Running apk upgrade on a host doesn’t fix an image, and patching a running container is undone the next time it restarts from the old image. The fix is to rebuild from an updated base and redeploy.

What to check:

1. Find sshd first. List every workload that exposes TCP/22, inside the VPC as well as to the internet, and every image whose entrypoint or process list includes sshd.
2. Narrow to musl. Check which of those images are Alpine-based or otherwise musl-based (cat /etc/os-release inside the container, or your registry’s image metadata).
3. Check the config. sshd -T | grep -Ei 'passwordauthentication|usepam' shows the settings sshd is actually running with. Password authentication enabled with PAM off is the exposed combination.
4. Look for passwordless accounts. In /etc/shadow, an empty password field is the precondition. Locking those accounts is a valid interim mitigation.
5. Disable password authentication wherever key-based access is possible. That is good practice regardless of this CVE.
6. Rebuild and redeploy from a base image that ships OpenSSH 10.6p2 or your distribution’s backported fix. Alpine has reportedly backported fixes as far back as 3.16; check the Alpine security tracker for the exact package version on each branch you run.

2. Zyxel GS1900: defenders patched the wrong CVE

In September, roughly 1,000 compromised Zyxel GS1900 switches were attributed to CVE-2026-7273, which CISA had already added to the KEV catalogue. Teams that applied that patch had good reason to think they were covered.

According to Binarly’s research, reported by SecurityWeek and others, they weren’t. The intrusions used a separate flaw, CVE-2026-107441 (CVSS 8.8), an unauthenticated out-of-bounds write in the switches’ CGI handling that leads to OS command execution through a crafted HTTP request. Binarly reports that the CVE-2026-7273 patch did not stop this exploit. Zyxel began shipping fixed firmware in late October and published its advisory on 3 November, covering ten GS1900 models. Canada’s Cyber Centre issued alert AV26-603.

The lesson goes beyond Zyxel. Vulnerability management usually starts by matching a CVE to an asset and then checking whether the patch is installed. When the public attribution is wrong, that whole process confirms the device is safe while it is still exposed. Two habits help:

• Track exposure, not just patch state. If a device’s management interface is reachable from the internet, treat that as a finding whatever its CVE status. A switch admin page should never face the internet.
• After a mass-exploitation event, assume the device may already be compromised. Patching closes the door but doesn’t remove anyone who got in. On affected models, apply the fixed firmware, then review configuration changes and new accounts since August.

3. Chainalysis: the breach that keeps getting wider

Chainalysis first disclosed an incident on 30–31 October, describing an intruder using “offensive agentic techniques” (AI-driven automation) and initially saying customer names and email addresses were exposed. By 6 November, The Hacker News reported that the company had widened the scope to all users, including usernames, password hashes and live tokens. Reactor and Data Solutions access was removed, the KYT interface and API were taken offline, accounts were locked, and users were told to reset passwords and rotate API keys. Chainalysis says it has no evidence that investigation data was accessed or attribution data altered.

This fits a pattern we have covered recently. When a SaaS or developer platform is breached, the attacker often gets the credentials customers use to call that platform’s API, and sometimes the platform’s credentials into customer systems. We wrote about the vendor-access side of this after the Northflank incident: what a vendor breach means for the roles they hold in your cloud.

If you integrate with Chainalysis, or with any vendor that has disclosed a breach this autumn:

• Rotate every key, not only the one you remember. Look in SIEM connectors, compliance pipelines, scheduled jobs, CI secrets and anywhere else the key may have been copied.
• Review API usage for the period between the intrusion and your rotation.
• Treat the first disclosure as a minimum. Scope estimates in a vendor’s first statement are often revised upward, as happened here.

4. Follow-up: Airbyte

Our Airbyte vulnerability checklist covered the Connector Builder remote code execution flaw (GHSA-g35w-6r6v-h4r7). One detail worth repeating: the advisory was published around 17 October, and the in-the-wild warning came roughly three weeks later. If you deferred the upgrade because nobody was exploiting it yet, that reason no longer holds. Self-managed versions below 2.2.0 are affected, 1.x legacy charts have no fix, and Airbyte Cloud is not affected.

Impact assessment

The CloudShieldSecure perspective

Every story this week comes down to the same question: what are we actually running, and what can it reach? The SSHole fix is a single version number, but you can’t apply it to images you don’t know about. The Zyxel campaign succeeded because CVE matching said the devices were patched while they were still exploitable. The Chainalysis and Airbyte incidents both turn on credentials stored in places nobody listed.

That gap is the reason CloudKonsult built CloudShieldSecure. It maps internet-facing and internal services such as port 22 across all your cloud accounts, flags workloads running from old image builds, and keeps an inventory of third-party integrations and the keys they hold. When the next “rebuild everything on Alpine” advisory comes out, the list of affected images should already exist. Find out more at cloudshieldsecure.cloudkonsult.cloud.

Recommended actions

1. Today: list every Alpine/musl workload with sshd, check PasswordAuthentication and UsePAM, and lock any passwordless accounts.
2. This week: rebuild affected images on OpenSSH 10.6p2 or a backported fix, and switch to key-only SSH wherever possible.
3. If you run Zyxel GS1900: apply the November firmware, take management interfaces off the internet, and review the device for changes since August.
4. If you integrate with Chainalysis: rotate every API key wherever it is stored and review API activity.
5. If you self-host Airbyte: upgrade to 2.2.0 or later and rotate the credentials stored in your connectors.

Sources and references

• Red Hat: CVE-2026-123158
• OX Security: OpenSSH password authentication bypass on Alpine Linux
• Ostorlab: OpenSSH musl password bypass, fixed in 10.6p2
• The Hacker News: OpenSSH issues emergency fix · SSHole exploited within hours
• SecurityWeek: Zyxel switch hacks blamed on patched flaw actually exploited a zero-day
• Canadian Centre for Cyber Security: Zyxel security advisory AV26-603
• Zyxel: GS1900 out-of-bounds write advisory (3 Nov 2026)
• The Hacker News: Chainalysis breach exposes all users
• BleepingComputer: Chainalysis discloses data breach from offensive agentic techniques
• Airbyte: GHSA-g35w-6r6v-h4r7