Administrators running sshd on Alpine Linux servers are being told to update openssh and restart sshd right away, since upgrading the package alone leaves the old daemon running. A flaw in the OpenSSH server lets attackers log in without a password. Those who cannot patch yet can close the hole by setting PasswordAuthentication to no and restarting sshd. 

How the OpenSSH Server Flaw Works 

An attacker who can reach the SSH port gets in with a single connection that works every time, with no retries. The attacker needs the name of an account whose password field is * (normal for key-only accounts) plus at least one other account with a $5$ or $6$ hash, then sends a password of 257 to 1,024 bytes. One user with a password exposes every account without one.  When built without PAM, sshd hashes each attempt with crypt() and compares it to the stored field, borrowing another account's salt when that field is too short to hold one. musl's crypt() returns * as an error indicator for keys over 256 bytes, which exactly matches the stored field of passwordless accounts. OpenSSH 10.6p2 fixes this, and no CVE had been assigned at the time of writing. 

Which Alpine Linux Servers Are Affected 

Alpine Linux servers are vulnerable when they run openssh-server (built without PAM) or openssh-server-pam with UsePAM no, keep the default PasswordAuthentication yes, hold at least one local $5$ or $6$ hash, and have an account with a * password field. That includes root, shipped as root:* in the base image since about Alpine 3.16. The default PermitRootLogin prohibit-password shields root unless it is set to yes, but not if another account can become root through doas. Key-only users created with adduser or usermod -p '*', directory users via musl-nscd (nslcd, winbind, sssd), and the tiny-cloud alpine user also count. Every release checked is affected: 3.21 through 3.24, edge, and the older 3.16 to 3.20.  Safe setups include containers not running sshd, systems with PasswordAuthentication no or UsePAM yes, locked accounts (user:! in /etc/shadow), machines with no $-style hash, and cloud-init images, which write PasswordAuthentication no. 

Patching the OpenSSH Server 

Running apk upgrade -U -a, followed by rc-service sshd restart, applies the fix, which ships in Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4. Fixed builds are edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11, 3.21 9.9_p2-r1, 3.20 9.7_p1-r6, 3.19 9.6_p1-r3, 3.18 9.3_p2-r4, 3.17 9.1_p1-r7 and 3.16 9.0_p1-r6. Although 3.21 reached end of support on 2026-11-01, patched packages go back to 3.16.  For the workaround, root should first confirm key login works and keep the current session open. A drop-in file, /etc/ssh/sshd_config.d/00-no-passwords.conf (read from 3.19 onward), sets PasswordAuthentication no, while a sed command flips every such line in sshd_config, Match blocks included, and saves sshd_config.bak. Running sshd -t && rc-service sshd restart, then sshd -T | grep -i passwordauthentication, should print passwordauthentication no. Deleting the drop-in and restoring the backup undoes it. 

Cloud Images and Spotting Attacks on Alpine Linux Servers 

Official tiny-cloud images (qcow2, VHD and AMI) from 3.18.11 through 3.24.3 ship an alpine user with a * field and passwordless doas. They are safe on first boot but become exploitable once any $6$ hash appears, such as a console password or a user-data account with hashed_passwd, giving attackers a shell as alpine and then root. Instances from earlier point releases need updating or password logins disabled.  Admins should check /var/log/messages for sshd "Accepted password" lines on passwordless accounts and review doas use, new users, files, and authorized keys. If a login cannot be ruled out, the machine should be treated as compromised.  Özgün Kültekin of Wakefield reported the issue. Damien Miller and Darren Tucker of the OpenSSH project delivered the fix and the 10.6p2 release; Timo Teräs helped analyze the bug, and Natanael Copa built and uploaded the updated packages. 

For more than three years, computers at several American universities were allegedly doing work their owners never asked for. According to a federal indictment, two Canadian men broke into campus networks, stole passwords and quietly used the machines to mine cryptocurrency for themselves. One of them is now in the United States to face charges in the university supercomputer hacking case. The other is still fighting extradition in Canada. U.S. Attorney Michael DiGiacomo announced that a federal grand jury has indicted Ryan James Roach, 35, of Saskatchewan, and Mathiew James Stubbings, 41, of Ontario. Both face charges of conspiracy to obtain information from and cause damage to a protected computer, obtaining information from a protected computer, and intentional damage to a protected computer. The charges carry a maximum penalty of 10 years in prison and a $250,000 fine.

Why the University Supercomputer Hacking Targeted Campuses

The indictment points to a clear reason for the choice of targets. Roach and Stubbings allegedly went after educational institutions in the United States that had supercomputers. The scheme relied on processing power. Once inside, the pair allegedly forced victim computers to run cryptocurrency mining software, putting the machines' computing power to work for their own financial gain. Machines built for heavy computation made the scheme more profitable. Victims included educational institutions in New York, Tennessee, North Carolina and Massachusetts. Some of the damaged computers belonged to a higher education institution in the Western District of New York, where the case is being prosecuted.

How the Alleged Scheme Worked

According to the indictment, the scheme ran from June 2016 to December 2019 and followed a set pattern. The pair allegedly researched security weaknesses in victim networks before getting in. They accessed computers without authorization and deployed malware to take control. They then stole login credentials and sent the data to servers they controlled. Once inside a network, they allegedly used sophisticated techniques and tools to carry out reconnaissance and expand their access. The stolen login credentials were stored on their servers, the same servers that sent out malware and mining software to victim machines. The indictment says Roach and Stubbings damaged 10 or more protected computers within a one-year period, causing a loss of at least $5,000.

How They Allegedly Stayed Hidden

The case also shows the effort the pair allegedly put into avoiding detection. They used virtual private servers in multiple countries, registered under false names. Those servers delivered malware and mining software to victim computers and held the stolen credentials. To conceal their identities further, they allegedly used a server and compromised computers belonging to one victim to gain access to another. That meant intrusions could appear to come from a victim's own systems instead of from the people behind them.

Where the University Supercomputer Hacking Case Stands

Roach was extradited from Canada to the United States on October 28. He was arraigned before U.S. Magistrate Judge Mark W. Pedersen and held pending a detention hearing on November 3. Extradition proceedings for Stubbings are continuing in Canada. The investigation was carried out by the Federal Bureau of Investigation, under the direction of Special Agent-in-Charge Allen D. Davis II, and the Department of Justice's Computer Crime and Intellectual Property Section. The Justice Department's Office of International Affairs helped secure Roach's arrest and extradition. Assistant U.S. Attorney Meghan K. McGuire is prosecuting the case.

What Is Still Unclear

The indictment leaves several details open. It does not say how much cryptocurrency the pair allegedly mined, how many institutions were affected in total, or which universities were targeted beyond their states. The loss figure stated in the charges, at least $5,000, is the legal threshold tied to the damage count, not a full estimate of the harm. An indictment is an accusation, not proof. Both men are presumed innocent unless and until proven guilty.

Discord plans to let Google and other search engines index selected Discord Messages from Discoverable Servers, pushing parts of its public community conversations onto the open web.  The company announced the change on October 27. Server Web Pages and discussion summaries arrive first, on November 16, 2026. Individual messages follow in mid-December rather than November, giving users and moderators time to check their privacy settings before anything becomes searchable.  Discord says the goal is to make useful answers reachable without searching inside the platform first. It argues that knowledge in gaming guides, support discussions, and community forums often stays hard for outsiders to find. 

Which Discord Messages From Discoverable Servers Qualify? 

Only Discoverable Servers are affected. Anyone can find and join these communities without an invitation, and each must have at least 1,000 members, be eight weeks old and meet activity and safety rules. Discord puts the current total above 63,000. Private servers, direct messages, and group direct messages are excluded.  From November 16, every Discoverable Server gets a Server Web Page. Where moderators haven't published one, Discord builds a default page from the Server Profile. Automated Channel Summaries covering discussions from that date onward may also appear the same day.  Individual Channel Messages roll out gradually from mid-December, and only eligible messages sent from then on can appear. Older message histories won't be published through the feature. Usernames and avatars are hidden, and messages initially appear as text.  Under Discord's member guidance, participating channels display an icon and a notice before users post. Public threads and forums can qualify, while private threads and private forums cannot. 

Keeping Discord Messages Off Discoverable Servers' Web Pages 

Users can open User Settings > Data & Privacy and disable "Show my message content from Discoverable channels on web pages." The account-wide switch covers every Discoverable Server a user belongs to. It can be changed in the desktop app or a browser and applies across devices, including mobile.  The setting is on by default in most regions but off by default in the EU/EEA, UK, Canada, Brazil, Australia, and South Korea. Teen accounts are excluded and cannot enable it. Server and channel eligibility rules still apply where the setting is on.  Switching it off only protects messages sent afterward. Posts made while it was enabled can still appear, even if they haven't reached a web page yet, so users must delete them to remove them from Discord's pages. Search engines may keep indexed or cached copies longer, requiring separate removal steps.  This is a planned publishing feature, not a security breach, which sets it apart from Discord's earlier customer support data breach involving unauthorized access through a third-party provider. 

Moderator Controls and Security Concerns 

Moderators can manage participation through Server Settings > Web Presence, excluding selected channels or disabling channel participation entirely. Without changes, public channels stay enabled. User opt-outs don't disable Channel Summaries, which have separate admin controls. Communities unwilling to maintain a Server Web Page can leave Discovery and remain Community Servers.  For security teams, the concern is wider exposure rather than a new flaw. Hiding usernames doesn't strip identifying details written inside Discord Messages, so public support channels deserve review before publication, particularly where members discuss workplace systems or share personal information.  Search visibility also isn't proof of trust. Earlier reporting on expired Discord invite links used to spread malware showed attackers steering visitors into fake communities. Readers who find Discord answers through Google should check destinations and avoid running commands presented as account verification steps.