OpenSSH CVE-2026-123158 + 2 more

The top priority is OpenSSH CVE-2026-123158 (nicknamed sshole). It affects sshd on Linux systems that use musl libc without PAM: Alpine Linux, Alpine-based containers and cloud images, OpenWrt and similar. If you run one of these, update OpenSSH to the fixed version and restart sshd today, or disable password authentication until you can. Typical glibc-based servers such as Debian, Ubuntu and RHEL are not affected. Updates are also out for Ruby on Rails Active Storage (GHSA-f3w6-w445-fwh9, CVSS 9.8) and Barracuda Email Security Gateway (CVE-2026-116606 / CVE-2026-111560).

This digest is based on the CVE record, the OpenSSH release notes, Alpine Linux's announcement, sshhole.com, the GitHub Rails security advisory, Barracuda's official advisory and press reports, checked on November 6, 2026 (JST). Anything not stated is treated as 'not published.' No exploitation in the wild has been reported for any of today's three items, and CISA added nothing new to its KEV catalog between November 5 and 6. Because proof-of-concept code for OpenSSH is public, it is still worth acting before exploitation begins.

According to the CVE record (published November 5, 2026), in OpenSSH before 10.6p2 on Linux, when musl libc is used without PAM, sshd lacks a workaround for a password authentication bypass. For some account configurations, any password between 256 and 1024 characters is accepted. The severity is CVSS 3.1 8.1 (High, scored by MITRE). CISA's SSVC assessment is Exploitation=PoC and Automatable=No. The reporter is Özgün Kültekin (Wakefield).

In plain terms: an account that should not accept passwords at all can be logged in to by typing a long, arbitrary string. Here is how it works. musl's crypt() (the function that hashes a password) returns the string "*" when it fails. SHA-256 and SHA-512 crypt fail on passwords longer than 256 bytes and return "*". Meanwhile, key-only accounts that disallow password login have "*" stored in the password field. The computed "*" matches the stored "*" and authentication passes. The OpenSSH team says the root cause is outside sshd (in musl's crypt()), but that sshd can work around it.

You are affected only when all of the following apply (per Alpine's announcement).

- You run openssh-server (the build without PAM), or openssh-server-pam with UsePAM no
- PasswordAuthentication is enabled (the OpenSSH default)
- At least one account has "*" in the password field (for example root in Alpine base images, key-only users, directory-service users, or the alpine user in tiny-cloud images)
- At least one local account has a $5$ or $6$ password hash

You are not affected on glibc-based systems such as Debian, Ubuntu and RHEL, with PAM-based setups (UsePAM yes), with PasswordAuthentication no, for locked accounts ("!"), on Dropbear, on OpenBSD, or in containers that do not run sshd. Other musl-based environments named by sshhole.com include OpenWrt, Buildroot, Yocto and Alpine-based Docker images.

Is root safe? By default OpenSSH forbids root password login (PermitRootLogin prohibit-password). However, on Alpine's cloud images for AWS, Azure and others (tiny-cloud; the qcow2, VHD and AMI images from 3.18.11 to 3.24.3), the alpine user can run doas without a password, which makes it effectively an administrator. And as soon as another user gains a $6$ hash, that user becomes a target.

The fixed version is OpenSSH 10.6p2 (released November 5). Alpine's fixed openssh packages are below. The point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 also include the fix.

The update alone does not replace the sshd that is already running, so always restart it. If you cannot update right away, the workaround is to disable password authentication. Before changing anything, confirm in a separate session that key-based login works, and keep your current session open.

You can check whether your system is affected with the commands below (run the ones that need privileges as root). If it shows musl, passwordauthentication is yes, usepam is no, and you have both a "*" account and a $5$ / $6$ account, the conditions are met.

To see whether someone has already got in, check the logs. A successful "Accepted password for" entry for an account that has no password (alpine, root, key-only users) is suspicious. Also look at doas usage, unfamiliar new users, and changes to authorized_keys. If you cannot rule it out, treat the system as compromised.

As a side note, this issue topped Hacker News on November 5 with more than 2,700 points. It is a hot topic, but the official severity is 8.1 and it is limited to environments where several conditions overlap. Official sources: CVE record, OpenSSH 10.6p2 release notes, Alpine Linux announcement, sshhole.com

This is a flaw in the image analysis step of Active Storage, Rails' file attachment feature. The GitHub security advisory (rails/rails, published November 4) is titled "Possible arbitrary file write and read in Active Storage image analysis," and no CVE has been assigned. The severity is CVSS 3.0 9.8 (Critical).

Here is how it works. ImageMagick chooses which coder (conversion handler) to use by looking at a file's contents, not its name. Active Storage does not restrict which coders an upload can reach, and analysis runs as soon as a file is attached. As a result, arbitrary files can be written, and when the Disk service is used, files can also be read. If they are read, secret_key_base and credentials could leak.

- Affected versions: activestorage 8.1 or later and before 8.1.4.1, and before 8.0.5.2
- Fixed versions: 8.1.4.1 / 8.0.5.2
- Exploitation: no exploitation in the wild has been reported. The advisory says one attack chain was reported privately and others may exist. According to press reports (Xalgorix), the reporter is RyotaK of GMO Flatt Security
- Conditions (as summarized by press reports): variant_processor is :mini_magick (the default for load_defaults 6.1 and earlier), the ImageMagick policy does not forbid the relevant coders (the Debian and Ubuntu defaults do not), and the app accepts uploads from untrusted users. According to press reports, apps using mini_magick also need mini_magick 5.1 or later
- Press reports say security fixes for Rails 8.0 end on November 7

The official workaround is to copy the rules from activestorage/lib/active_storage/image_magick/policy.xml, bundled with Rails, into the system's ImageMagick policy. At a minimum, deny the MSL coder, the Ghostscript coders and the gs delegate. If you stored attachments with the Disk service, rotate secrets the process can read, such as secret_key_base. To check:

In plain terms: code that merely "receives" an image uploaded by a user can become the way in to reading and writing files on your server. If you do not know whether you use Rails, the quickest route is to ask the company that built your system whether it runs on Ruby on Rails and whether it accepts file uploads. Official source: GitHub advisory GHSA-f3w6-w445-fwh9. Supplementary (press): Xalgorix weekly digest

These are two items from Barracuda's official advisory (published November 2; the authentication-required field for CVE-2026-116606 was updated on November 5). CVE-2026-116606 is a pre-authentication authorization bypass that Barracuda rates High, with CVSS 9.3, and it affects the Email Security Gateway (ESG) only. No authentication is needed, but the attacker must be able to reach the management interface. Press reports say all ESG models before 9.4.0.030 are affected, and that a crafted backup can be restored through the configuration import feature (CWE-288).

CVE-2026-111560 is a command injection that Barracuda rates High, with CVSS 8.6, and it requires administrator privileges. It affects ESG, Load Balancer ADC, Message Archiver, WAF Control Center, Web Application Firewall and Web Security Gateway. According to BleepingComputer, chaining the two can let an unauthenticated attacker run commands as root.

- Patch IDs: ESG BNSF-40425 (9.4.017 or later) / BNSF-40430 (before 9.4.017); Load Balancer ADC BNADC-16586; Message Archiver BNMA-32468; WAF Control Center BNWF-60060; Web Application Firewall BNADC-16586; Web Security Gateway BNYF-24789
- Exploitation: neither the vendor nor press reports describe exploitation in the wild. As background, ESG's CVE-2023-2868 was exploited in 2023
- Action: update to the latest firmware and confirm the version. Apply each patch ID manually if it was not applied automatically. Restrict the management interface to a trusted internal network. Enable automatic patching

In plain terms: an appliance sitting at the front door of your email could be taken over by anyone who can reach its management interface. Risk is lower if the interface is not exposed to the internet, but apply the patches anyway. Official sources: Barracuda advisory, BleepingComputer

- Ask your IT contact or vendor whether any server or cloud system uses Alpine Linux, Alpine-based containers, or OpenWrt routers. If you only use Debian, Ubuntu, RHEL and the like, the OpenSSH issue does not apply
- If it does, update OpenSSH to the fixed version and restart sshd. Until you can, confirm key login works and then disable password authentication
- If you were affected, check the logs for suspicious "Accepted password for" entries, and look for unfamiliar users or changes to authorized_keys
- Ask your development company whether your web service or system is built with Ruby on Rails and accepts file uploads. If so, ask them to update to Rails 8.1.4.1 / 8.0.5.2 or later
- If you use Barracuda Email Security Gateway or related products, confirm the latest firmware and patches are applied and that the management interface opens only from a small set of admin machines
- Record the results of your checks and updates (date, version, who did it) on a single sheet for your next inventory

- Vulnerability digest, November 5
- Linux kernel Copy Fail (CVE-2026-31431) mitigation
- Getting started with patch management (for small businesses)
- Vulnerability assessment cost

- CVE record: CVE-2026-123158
- OpenSSH 10.6p2 release notes
- Alpine Linux: OpenSSH password authentication bypass (Nov 5, 2026)
- sshhole.com
- GitHub advisory: GHSA-f3w6-w445-fwh9 (Rails Active Storage)
- Xalgorix: Weekly AppSec Threat Digest (Oct 30 - Nov 6, 2026)
- Barracuda: pre-authentication authorization bypass and command injection
- BleepingComputer: Barracuda warns of critical flaws allowing root access to devices