OpenSSH 10.6p2 fixes password bypass on musl and 5 more

What people are saying

A Hacker News thread treated CVE-2026-83844 as a Paint flaw that lets attackers run code remotely with no user interaction. Commenters quoted Microsoft's advisory wording that an attacker could exploit it "by sending a specially crafted packet to an affected service over the network." Some guessed the bug arrived with the Copilot features Microsoft added to Paint. On Mastodon, one poster joked about getting through the "paintpocalypse."

What holds up

SentinelOne's vulnerability database entry describes the flaw as an out-of-bounds read in Microsoft Windows Paint. The entry says Microsoft published the advisory on October 13, 2026. It says the flaw allows code execution when a user processes a crafted image file.

It says Microsoft has released a security update.

Our verdict is partly confirmed. The flaw and the fix are established. A true zero-click network attack is not, since the description still has a user processing a file. In our reading, the link to Paint's AI features is speculation.

Inside the threads

The Hacker News discussion split between alarm at a network-reachable paint program and skepticism about the advisory text. Another assumed the usual pattern for graphics tools, where an attacker persuades a user to open a malicious file. Practitioners added useful detail: one said the affected range runs from Paint 11.0.0.0 up to, but not including, 11.2605.91.0. Another said the fix came through the Microsoft Store while Windows Update showed nothing. Speculation about thumbnail rendering, background indexing and Copilot circulated without evidence.

Our take

We think this is a file-borne bug wearing a worm's scoring label. The "no user interaction" flag and the generic packet wording fueled the panic, and the scale of the October release makes a templated description plausible. The underrated point is delivery. If the fix ships through the Store, it may bypass the patch reporting many teams rely on, and that gap matters more than the headline. We would treat the AI theory as noise until Microsoft says otherwise.

What to do

• Prioritize workstations and virtual desktops where users open image attachments, and review gateway rules for image types the business does not need.
• Watch Microsoft's advisory for a revised description or scoring before escalating this beyond normal patch priority.

What people are saying

A Moneywise story syndicated on Yahoo Finance quoted Mark Cuban saying that deepfake ads built with an artificial intelligence (AI) copy of his face and voice keep running on Meta's platforms. "Facebook knows the little old ladies are getting ripped off," he said. The article paired his remarks with a year-old figure from internal Meta documents. On Hacker News, commenters resurfaced the original Reuters report on the $16 billion projection.

What holds up

Reuters reported that Meta internally projected about 10% of its annual revenue, or $16 billion, would come from advertising for scams and banned goods. That report ran on Nov. 6, 2025. The figure covers scams and banned goods together. It is not a count of deepfake ads.

The documents also showed that Meta bans advertisers only when its automated systems predict they are at least 95% certain to be committing fraud. One document said Meta earns $3.5 billion every six months from scam ads that present higher legal risk, such as ads falsely claiming to represent a consumer brand or public figure. According to the documents, the Securities and Exchange Commission is investigating Meta over ads for financial scams.

Meta spokesman Andy Stone said the documents present a selective view of the company's approach to fraud. He called the 10.1% estimate rough and overly inclusive. He said the true number was lower, but he declined to give an updated figure. Marketing Brew received a similar statement from another Meta spokesperson.

Moneywise said Meta had not immediately responded to a request for comment on Cuban's remarks. In our reading, the internal estimate is established and Meta has not denied it exists. Its size is contested, and the claim that Meta knowingly runs specific deepfakes rests on Cuban's own account. Our verdict is partly confirmed.

Inside the threads

The largest camp argued that platforms should be held liable for the ads they carry. Several commenters said they had reported obvious scam ads and been told the ads did not violate the platform's terms. One commenter who said they had worked as a media buyer described ad rejections being reversed for large spenders.

Others pointed to legal action abroad, including a German finance YouTuber who, a commenter said, successfully sued Meta over scam ads that used his face.

Our take

We think the headline number is the least useful part of this story for a security leader. The more relevant detail is the 95% certainty threshold. In our reading, impersonation ads that look only probably fraudulent can stay live while the platform decides.

We think executive and brand deepfakes are now a standing exposure, not an occasional nuisance. In our reading, the legal pressure building in several countries is real, but we would not plan around liability changes arriving soon. Our view is that takedowns will keep depending on how well your team documents and escalates each case.

What to do

• Monitor major ad platforms for paid ads that impersonate your executives, products and brand, and assign an owner for this work.
• Build a takedown playbook that pairs platform reporting with legal escalation, and keep dated evidence for every report.
• Tell customers and employees through official channels that your executives do not endorse products in social ads.
• Brief your board on deepfake impersonation as a fraud and reputation risk under your existing board oversight reporting.

What people are saying

watchTowr Labs published research on two vulnerabilities, CVE-2026-116606 and CVE-2026-111560, in the Barracuda Email Security Gateway (ESG). The post's title calls the pair a pre-authentication remote root flaw. watchTowr's account on X shared it alongside a line about what Barracuda says regarding non-exposed appliances, and another X account reposted the link.

What holds up

Barracuda's advisory confirms both CVEs. It says that if the two are exploited in combination, an attacker could bypass authorization controls and obtain root access to the device.

There is one condition. On November 5, Barracuda changed the "Authentication Required" field for CVE-2026-116606 from "Yes, administrative access" to "No (Administrative UI Access Required)." Exploitation requires the administrative user interface (UI) to be reachable by the attacker.

The National Vulnerability Database (NVD) record for CVE-2026-116606 describes an authentication bypass in ESG versions earlier than 9.4.0.030. The record for CVE-2026-111560 describes a flaw that lets an authenticated administrator inject operating system commands that run as root. That record scores it 8.6.

Barracuda lists the bypass as affecting only ESG. The command injection also affects the Load Balancer Application Delivery Controller, Message Archiver, Web Application Firewall (WAF), WAF Control Center and Web Security Gateway.

On exploitation, IONIX says Barracuda's fix summary lists both flaws as not exploited, and it advises treating exploitation status as unconfirmed. Verdict: confirmed, provided the admin interface is reachable.

Inside the threads

The r/netsec post drew a comment that mocked the headline rather than engaging with the research. On X, the posts we saw mostly repeated the blog title. watchTowr's own post pointed readers to Barracuda's exposure caveat.

Our take

We think the admin interface condition is the real story. An ESG with its admin UI exposed to the internet is an emergency. One reachable only from internal networks is still a fast patch, because an attacker already inside can use the same path.

Barracuda's mid-week revision of the authentication field matters. Teams that triaged on November 2 may have filed this as an authenticated bug and deprioritized it, so we would re-check that decision.

The command injection across five other product lines is underrated. It needs admin access, but stolen admin credentials are common.

This appliance family has a history: watchTowr recalls that some ESG units required physical replacement after UNC4841 exploited CVE-2023-2868. A detailed public write-up usually shortens the time before others attempt exploitation.

What to do

• Confirm every ESG has Barracuda's patch for its firmware branch, and turn automatic patching back on where it was disabled.
• Find any Barracuda admin interface reachable from the internet and restrict it to trusted internal networks.
• Patch Load Balancer, Message Archiver, WAF, WAF Control Center and Web Security Gateway units for CVE-2026-111560, and review who holds admin accounts on them.
• Re-triage any ticket that recorded CVE-2026-116606 as requiring authentication.

What people are saying

Brazil's Fundo Garantidor de Créditos (FGC), the private fund that repays depositors and investors when banks fail, posted a notice of unauthorized access to personal data tied to its payout process. A Hacker News thread shared an English translation of the notice's list of affected data and turned quickly to fraud risk. On Reddit's r/cybersecurity, one commenter said they had received a notification email and that their data was included.

What holds up

The FGC says it found unauthorized access in environments linked to the internal workflow for guarantee payments. It first suspected the incident on October 26, 2026.

The exposed fields are name, CPF (Brazil's individual taxpayer number), email and date of birth. Payout data was also accessed: the taxes withheld from each payment and the distribution channel through which the guaranteed investment was made at the failed institution.

The FGC says it has found no evidence that the data was disclosed or misused, and no financial loss. Its investigation, supported by outside firms, is still checking whether data was copied. The fund says it restricted access, blocked improper accounts, preserved evidence and started a review of permissions. It also notified the national data protection authority (ANPD) and the affected individuals.

Agência Brasil reports that the FGC has not disclosed how many people are affected or which financial institutions the records belong to. Brasil 247 notes that the fund is currently handling payouts from the liquidations of Banco Master, Will Bank and Banco Pleno.

The verdict is confirmed. The FGC itself states the core event, and two outlets report it.

Inside the threads

One Hacker News commenter predicted millions of affected records and widespread fraud: "Fraudsters will have a field day with it." That commenter also described the data as including payment data and social security numbers. A second camp argued that most Brazilian personal data is already exposed and linked to an earlier large leak, which in their view limits how much new fraud this incident enables. The Reddit post added only a first-hand account of receiving the notification.

Our take

We think the threads are focused on the wrong fields. In our reading, CPF, name and birth date have circulated in Brazil for years. What is new is the context: a list of people waiting on money from a failed bank, plus tax and distribution-channel details that only a real FGC or bank employee should know. In our reading, that is the material for convincing pretexting, especially fake offers to speed up or buy guaranteed credits. The "millions of records" claim is unsupported for now. The underrated exposure falls on the banks and brokers named as distribution channels, which fraudsters can now impersonate convincingly.

What to do

• If you run security at a Brazilian bank or brokerage that distributed instruments from these liquidated institutions, warn your fraud and contact-center teams to expect impersonation calls that cite accurate payout details.
• Repeat the FGC's own guidance in your customer messaging: the fund says it never asks for passwords, codes or fees, never uses intermediaries, and never contacts people by WhatsApp or text message.
• Add these payout-related pretexts to phishing and vishing awareness material for staff who handle client money.

What people are saying

A researcher published a write-up showing that a self-hosted SourceHut instance that disables registration could still let someone sign up. The post circulated on Lobsters. A tracking site also logged a Hacker News post titled "Sourcehut disabled registration bypass, CVE-2026-121728." In our reading, the discussion was small and approving.

What holds up

The public vulnerability record confirms the core claim: meta.sr.ht versions 0.56.11 before 0.89.0 let unauthenticated users register accounts when public registration is disabled. It lists a base score of 5.3, rated medium.

The researcher's timeline dates the bug to 2021-09-24. The same timeline dates the report to SourceHut's security mailing list to 2026-11-02. It says SourceHut acknowledged the report and a fix landed on 2026-11-03. The attack still requires the instance to complete email confirmation.

InfraStack says instances with public registration enabled are not affected by this bypass. It says SourceHut's hosted service is the vendor's to patch, while self-hosters must update themselves. It lists no reports of exploitation. It also gives a 0.3% predicted chance of exploitation over 30 days.

The verdict is confirmed.

Inside the threads

The Lobsters thread had one comment. It called the post a nice write-up and said the researcher's suggested severity score was reasonable. The commenter added that the work "oozes of responsible researcher." The researcher's post called the find not nearly as impactful as earlier work. Its first lesson was that refactors can swallow security checks. In our reading, the reaction was approval rather than debate, and we saw no inflated claims about impact.

Our take

We think this is a modest bug with a lesson that applies well beyond SourceHut. In our reading, for years, closed registration on these instances was a message on a page rather than a check the server enforced. The medium score fits the direct impact. Still, an unapproved account on a code forge is a foothold inside a system many teams treat as trusted, and it can see whatever the instance shows signed-in users.

Detection is the part we think is underrated, because a rogue account looks like any other user. Fears of mass compromise look overblown to us, since no exploitation has been reported. Treat this as a reason to test that every "disabled" feature is enforced on the server, especially after a rewrite.

What to do

• Update self-hosted meta.sr.ht to 0.89.0 or later.
• Review the user list for accounts nobody approved. The researcher names unknown user accounts as the indicator of compromise.
• Pull account audit logs soon. The SourceHut documentation says they are purged after 14 days.
• On closed instances, onboard users only through one-time invite links, which the documentation describes for instances with registration turned off.