From Alpine Honeypots to Production Servers: How the SSHole OpenSSH Bypass Works, Who’s Exposed, and How to Clean Up

SSHole, an authentication bypass in OpenSSH on musl-based Linux, was being exploited less than nine hours after it went public; below: how attackers used it, how the flaw works, and the patching and investigation steps that close it out.

What You Need to Know

Attackers began targeting SSHole, tracked as CVE-2026-123158 with a CVSS score of 8.1, less than nine hours after its publication, and one attacker gained root access on an Alpine Linux honeypot. The flaw affects Linux systems running OpenSSH with the musl C library and without Pluggable Authentication Modules (PAM), including Alpine Linux’s default OpenSSH server package. A fix is available, but patching does not undo access an attacker gained before the update.

What Happened

Threat intelligence firm Previdian recorded eight exploitation attempts against an Alpine Linux honeypot, all from a single IP address geolocated to Japan, 89.116.89[.]18, and confirmed successful root access. The attacker used oversized passwords to establish non-interactive SSH sessions, then ran reconnaissance commands including id, uname, and hostname.

How the Bypass Works

Discovered by researcher Ozgun Kultekin, CVE-2026-123158 stems from password-handling behavior introduced by a 2016 fix for the username enumeration vulnerability CVE-2016-6210. On affected configurations, a password between 257 and 1,024 bytes causes the password-hashing operation to fail and return an asterisk. If the target account’s stored password field also contains an asterisk, OpenSSH treats the matching values as a successful login. Exploitation requires three conditions: password authentication enabled, a target account with that specific password-field value, and another local account with a usable password hash. Systems using glibc, non-Linux platforms, PAM-based authentication, and Dropbear are not affected.

Why This Matters

The activity Previdian observed shows successful exploitation against a deliberately exposed system, not evidence of widespread production compromises. The bypass also has limits: it does not defeat valid password hashes or automatically grant root. Access inherits the compromised account’s permissions, and the honeypot's root access reflects how that system was configured. The real exposure is accounts meant to be key-only, which an attacker can now log into with a password. From there, deployment credentials, application secrets, and any infrastructure the account can reach are in play. A nine-hour gap between disclosure and exploitation leaves little room for a normal patch cycle.

What to Do

Prioritize internet-accessible, musl-based OpenSSH deployments for configuration review. Install OpenSSH 10.6p2 or your distribution’s patched package, then restart sshd so the running service uses the corrected binary. Where patching cannot happen immediately, disable password authentication or restrict SSH access until remediation is complete. Review /var/log/messages for “Accepted password for” entries involving accounts that should not accept passwords, particularly root, deployment users, and key-only accounts, and investigate unexpected doas activity, newly created users, unfamiliar files, and changes to authorized SSH keys. Alpine advises treating an exposed machine as compromised when you can't rule out unauthorized login, since the patch closes the bypass but doesn't remove access or changes an attacker established before the update. A patched sshd only tells you the door is closed now. Your logs tell you whether anyone walked through it first.

Store-Only Fix, Conflicting Version Numbers: Why Microsoft Paint RCE CVE-2026-83844 Needs Its Own Verification

Microsoft’s fix for a remote code execution flaw in Windows Paint ships through the Microsoft Store rather than Windows Update, and public records disagree on which version is safe. Below: the vulnerability, the version discrepancy, and how to prove every copy is actually updated.

What You Need to Know

Microsoft has released a fix for CVE-2026-83844, a remote code execution vulnerability in Windows Paint rated Important with a CVSS score of 8.1, but organizations relying on Windows Update alone will not receive it. Microsoft distributes the corrected build, 11.2609.401.0, through the Microsoft Store. Conflicting version thresholds in public records can also lead scanners to report a device as remediated before it actually is.

What’s Vulnerable

CVE-2026-83844 is an out-of-bounds read vulnerability. Microsoft’s advisory describes an unauthenticated attacker sending a specially crafted packet to an affected service over the network, with no user interaction required, though it does not identify that service. Microsoft says successful exploitation requires a deep understanding of the target system. Microsoft published the vulnerability on October 13.

The Version Problem

Microsoft’s security advisory identifies 11.2609.401.0 as the fixed build, while its CVE record and the corresponding National Vulnerability Database entry still describe versions below 11.2605.91.0 as affected. Scanners using that lower threshold can mark an installation as remediated before it reaches the advisory’s current fixed version, and the advisory’s revision history does not explain the change. Distribution has been uneven as well. Earlier this week, RFF researcher Brian Vitko found Microsoft Store checks across six countries offering an older, unpatched build, 11.2605.81.0. However, his test machine later received the corrected version through automatic Store updates. The Hacker News found the fixed build available in all ten countries it checked.

Why This Matters

Microsoft reported no known exploitation or public disclosure when it published the vulnerability, and The Hacker News found no entry in CISA’s Known Exploited Vulnerabilities catalog when it checked on November 6. The more immediate risk is a false sense of completion. A device can show full operating system patch compliance, pass a scanner check against the NVD threshold, and still run a vulnerable Paint build. Store availability does not mean every endpoint has installed the update, and Paint installs separately for each Windows user account, so one updated profile says little about the rest of the machine.

What to Do

Verify Paint independently of operating system patch compliance, using 11.2609.401.0 or later as the remediation target. Because Paint installs per user and a device can retain a provisioned package used when creating new profiles, checking only the signed-in user can miss older copies. Inventory all users’ installed Paint packages and the provisioned package through elevated PowerShell, trigger Microsoft Store application updates through your endpoint-management platform where supported, and repeat both checks afterward. Microsoft lists no workaround or mitigation. Closing this finding requires evidence that every installed and provisioned copy meets the corrected version threshold, not confirmation that Windows Update completed or that one user received the Store update. When the fix lives outside the usual patch channel, the usual compliance report stops being the source of truth.

Kernel Panics on AMD EPYC and a Separate Kernel Flaw: Two Issues Complicating Veeam Appliance Maintenance

Veeam’s Linux-based Software Appliance can fail to boot on certain AMD EPYC hosts, and Veeam is separately tracking a kernel vulnerability across some of its products. Below: what triggers the boot failure, how recovery works, and how to keep updates moving without losing backup management.

What You Need to Know

Veeam Software Appliance version 13.1 and later can intermittently fail to boot on hosts running AMD EPYC 7262, 7302, and 7F72 processors, hitting a kernel panic after a reboot. Because the appliance runs Veeam Backup & Replication, a failed restart can leave backup management unavailable until administrators recover the virtual machine. Separately, Veeam reports that some products are affected by CVE-2026-98432, a Linux kernel vulnerability that needs its own remediation track.

What Happened

Veeam has warned that affected appliances can panic after any reboot, including one triggered by an update that installs a new kernel. Once the appliance boots successfully, Veeam says no further errors are expected, and Backup & Replication operations are unaffected.

The Details

The failure occurs during an early-boot jitterentropy health test performed in Federal Information Processing Standards (FIPS) mode, part of the cryptographic and health checks the appliance’s underlying Linux kernel runs to support corporate and government security requirements. On certain EPYC processors, that test intermittently fails, and the kernel halts startup rather than continuing. Impacted systems display the error “Kernel panic - not syncing: jitterentropy: Initialization failed with host not compliant with requirements: 9.” Recovery is not a simple restart. Veeam states that restarting the guest operating system does not recover the virtual machine; administrators must power it off and then power it on again.The separate issue, CVE-2026-98432, is a Linux kernel vulnerability that can allow unauthenticated remote root command execution on systems running Multipath TCP listeners. Some affected components are being fixed through private fixes or Veeam Updater.

Why This Matters

The boot failure is a reliability problem originating in the appliance’s Linux kernel, not a reported exploitation campaign. Its intermittent nature makes it operationally awkward: a successful boot last month does not mean the next reboot will succeed, so every update becomes a potential backup-management outage. The obvious workaround, turning off automatic updates, creates its own risk if it drifts into an indefinite patch freeze, especially while a kernel flaw with unauthenticated remote root impact is being fixed in parallel.

What to Do

Veeam recommends redeploying affected appliances onto hosts with different processors. Where that is not possible, its interim guidance is to disable automatic appliance updates and install updates manually while monitoring the virtual machine through the subsequent reboot. Identify which hosts run the affected processor models, build extra recovery time into maintenance windows, and confirm you have access to the hypervisor controls needed for a full power cycle. Treat disabled automatic updates as temporary, and track CVE-2026-98432 remediation independently through private fixes or Veeam Updater while managing the boot issue through supervised updates and verified appliance recovery. Backup infrastructure is what you lean on when everything else goes wrong, so it deserves the same supervised change process as anything in production.

No Patch Yet for D-Link DGS-3130 Zero-Days: DDP, Access Control, and Firmware Flaws Put Switch Management at Risk

D-Link has disclosed multiple unpatched vulnerabilities in its DGS-3130 series managed switches, with no corrected firmware or CVE identifiers yet. Below: what is confirmed, what is still under investigation, and how to reduce exposure until a fix ships.

What You Need to Know

D-Link has disclosed multiple unpatched vulnerabilities in DGS-3130 series managed switches that could lead to sensitive information disclosure, unauthorized administrative changes, and service disruption. No corrected firmware was available at the time of reporting, and D-Link has not published CVE identifiers or detailed technical descriptions. Until a patch arrives, administrators have to manage the exposure through configuration.

What’s Vulnerable

According to D-Link, the flaws involve D-Link Discovery Protocol (DDP) authentication, access control, information handling, and components of the devices’ firmware security architecture. Spectrum Community Solutions network engineer Giresh Kumar Enugu identified the issues in multiple DGS-3130-30TS firmware versions, and D-Link’s investigation into other switching platforms is ongoing. An attacker with access to an affected network could exploit certain vulnerabilities to retrieve sensitive device information, perform unauthorized administrative operations, modify configurations, or disrupt network services. Reported consequences also include credential changes, disclosure of SNMP community strings, device resets, and factory resets. D-Link is also investigating firmware security mechanisms involving SSH service configuration, underlying operating-system credentials, firmware encryption, and embedded cryptographic keys.

Why This Matters

These switches serve small-to-medium businesses and metro Ethernet deployments, which puts the risk at the infrastructure layer rather than on a single workstation or application. An unauthorized configuration change or reset can cut connectivity for every system behind the switch. At the same time, the disclosure has clear limits. Although the flaws are described as 0-days, the report does not establish active exploitation, and exploit availability, attack activity, and the full range of affected devices remain open questions. The firmware security areas are under review, not confirmed vulnerabilities across every D-Link switching product, so the available information does not support treating the entire vendor portfolio as affected.

What to Do

Until firmware fixes are available, D-Link recommends disabling DDP to remove the primary known attack vector. Pair that with restrictions limiting SSH, the web management interface, and SNMP to isolated management networks and designated administrative hosts. Remove unnecessary or default SNMP community strings, keep offline copies of switch configurations, and monitor device logs for unexpected configuration changes, unexplained reboots, or factory resets. Identify DGS-3130-30TS deployments and record their firmware versions while tracking D-Link’s investigation for additional affected models and remediation guidance. Disabling DDP addresses the primary disclosed entry point but isn't a complete fix for every firmware issue under investigation; configuration backups support recovery if a switch is altered or reset, and management-plane isolation reduces the number of systems that can reach the exposed services while you wait for a patch. When there is no patch to deploy, the management plane is the control you actually own.

Dark Project Ransomware: 38 Claimed Victims, an 80/20 Affiliate Program, and What the Numbers Don’t Prove

Dark Project is a newer ransomware operation that publishes victims and recruits affiliates. Below: who it claims to have hit, how its affiliate model works, which access routes it relies on, and where the available intelligence stops short.

What You Need to Know

Dark Project, an emerging ransomware operation, has claimed 38 victims across eight countries, with manufacturing and healthcare making up half the listings. The group runs double-extortion attacks and advertises an affiliate program paying partners 80% of ransom proceeds. Initial access is associated with phishing, exposed RDP, compromised credentials, and VPN access bought from infostealer logs or access brokers, which is where defenders should focus first.

Who’s Been Listed

In a threat intelligence snapshot reported by GBHackers, manufacturing accounts for 12 listings, healthcare seven, and construction four. Thirty listed organizations are in the United States, followed by two in the United Kingdom and one each in Germany, Brazil, the Philippines, Turkey, Mexico, and Canada. A separate public tracker lists 40 victims across the same number of countries.

How the Operation Works

Dark Project combines data theft and system encryption with threats to publish stolen information through a Tor-hosted leak portal. According to research attributed to Gurucul, it advertises an affiliate program that gives partners 80% of ransom proceeds and keeps 20% for platform services and reporting. The advertised recruitment process runs through Tox for contact, followed by vetting, onboarding, assigning a partner identifier, deploying payloads, and settling commissions. Affiliates allegedly handle deployments while core operators manage victim communications and ransom negotiations. The group also advertises a Tor dashboard, EXE and BIN agents containing affiliate identifiers, and social-engineering tools. The supplied intelligence maps its activity to WMI, SMB, credential abuse, data exfiltration, encryption, and recovery inhibition.

Why This Matters

Much of what is known about Dark Project comes from the operators themselves, so it needs careful handling. The victim figures reflect allegations published through criminal infrastructure, not independently verified breaches, and the gap between 38 and 40 victims shows how collection windows shift reported totals. The sector distribution does not establish deliberate targeting and may reflect which organizations affiliates could get into. The advertised tooling remains operator claims rather than validated features. The timeline is also uncertain: the supplied dataset includes June 2026 disclosures, while public trackers place the group’s emergence or first observed listings in August, and neither date indicates when the underlying intrusions occurred. The technique mappings also should not be read as proof that every victim saw the same attack sequence. What is consistent is the double-extortion model, which means restoring systems does not resolve the incident on its own.

What to Do

Prioritize removing unnecessary remote-access exposure, investigate compromised VPN credentials, and enforce MFA on remote access. Detection teams should correlate unusual remote logins with unexpected WMI execution, SMB activity, large outbound transfers, and attempts to interfere with recovery. Keep tested, isolated backups to address encryption-related disruption, but recognize that they do not reverse data theft. Incident response plans need parallel procedures for restoring operations and assessing exposed information, rather than treating a successful recovery as the end of an extortion incident. Getting systems back online is half of a double-extortion response; knowing what left the network is the other half.