The challenge becomes more significant when organizations operate thousands of applications across cloud, on-premises, and third-party environments. A security team may identify vulnerable cryptography, but replacing it can depend on software releases, certificate infrastructure, vendor compatibility, procurement decisions, and regulatory deadlines.

Why Enterprise PQC Migration Requires Program Management

The technical foundation for post-quantum migration is becoming clearer. NIST finalized its first three principal PQC standards in August 2024: FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA.

However, standardized algorithms do not automatically make enterprise applications ready to adopt them.

An organization must determine which systems use vulnerable cryptography, whether replacement algorithms are supported, who owns the affected components, and how changes can be implemented without disrupting business operations.

Several activities must progress together:

• Cryptographic discovery: Identifying algorithms, certificates, keys, libraries, protocols, and their dependencies.
• Business risk assessment: Determining which applications and sensitive data require attention first.
• Migration sequencing: Establishing realistic remediation phases based on risk, technical readiness, and organizational capacity.
• Execution coordination: Assigning changes to application, infrastructure, security, and external vendor teams.
• Validation and reporting: Confirming that remediation is complete and providing evidence of measurable progress.

The most useful platforms connect these activities rather than treating cryptographic discovery as the final deliverable.

7 Vendors That Manage Enterprise PQC Transition Programs

1. Q.security

Q.security provides Q, an AI-native cryptographic governance and PQC remediation platform that helps enterprises manage the transition to quantum-safe cryptography as a continuous, business-driven program.

The platform is designed around a practical constraint: organizations cannot replace every vulnerable cryptographic component simultaneously. Effective migration therefore depends on identifying the systems that create the greatest business exposure and coordinating remediation in an appropriate order.

Q.security begins with top-down business context rather than treating all discovered cryptographic assets as equally important.

The platform develops a model of the organization’s critical applications, business units, sensitive information, operational dependencies, and regulatory responsibilities. It draws on existing enterprise information, including application inventories, business impact assessments, architecture documentation, and security policies.

The platform then connects that business context with bottom-up cryptographic discovery. Through approved, minimum read-only access and integrations with existing enterprise systems, Q identifies cryptographic dependencies across code repositories, cloud environments, public-facing services, TLS and SSH connections, and other supported infrastructure.

A key distinction is how Q handles completion. A remediation item does not become resolved simply because someone closes a ticket. The platform requires validation evidence confirming that the relevant cryptographic issue has been addressed.

This creates a stronger connection between engineering activity and reported progress. For CISOs and enterprise security leaders, Q provides centralized program visibility across owners, remediation phases, outstanding risks, and completed work. Its continuous cryptographic posture management helps organizations account for new discoveries and changing requirements beyond the initial migration.

Q.security ranks first because it brings business prioritization, cryptographic discovery, execution management, and validated outcomes into one CISO-owned program. Instead of relying on disconnected technical projects, enterprises can coordinate a phased transition with clear accountability and defensible progress reporting.

Key Capabilities:

• Business-first program prioritization: Connects application criticality, data sensitivity, confidentiality lifetime, and regulatory exposure with cryptographic findings.
• Enterprise cryptographic discovery: Uses approved read-only integrations and existing data sources to identify cryptography across supported environments.
• Phased migration planning: Organizes remediation according to business risk, technical dependencies, and organizational priorities.
• Governed remediation workflows: Coordinates owners, runbooks, tickets, and scripted fixes across engineering and security teams.
• Validation-based closure: Requires evidence that cryptographic findings have been resolved before remediation is considered complete.
• CISO-level program visibility: Tracks progress, unresolved exposure, and execution responsibilities across the enterprise.
• Continuous crypto-agility: Maintains cryptographic posture information as applications, standards, and business requirements evolve.

2. IBM Quantum Safe

IBM Quantum Safe provides a portfolio of technologies and services for discovering, evaluating, and addressing quantum-vulnerable cryptography. Its approach combines cryptographic asset management, application analysis, migration capabilities, and consulting support.

IBM Quantum Safe Explorer analyzes source code to identify cryptographic APIs, algorithms, libraries, and dependencies, including information used to generate Cryptographic Bills of Materials (CBOMs). Quantum Safe Cryptography Manager provides broader visibility into cryptographic assets and migration activities, while Quantum Safe Proxy supports interoperability between legacy and post-quantum-ready systems. IBM Consulting also assists organizations with transformation planning and implementation.

Key Capabilities:

• Cryptographic inventory management: Consolidates information about cryptographic assets and dependencies.
• Source-code analysis: Identifies vulnerable cryptographic implementations and generates CBOM information.
• Migration coordination: Supports planning and managing remediation activities across enterprise environments.
• Compatibility mechanisms: Provides options for managing legacy and quantum-safe communications during transition.
• Consulting and transformation services: Supports enterprise migration strategy, architecture, and execution.

3. DigiCert

DigiCert provides cryptographic governance and PQC transition capabilities through DigiCert ONE and Quantum Central. The platform helps security teams consolidate cryptographic information, establish readiness policies, and coordinate remediation tasks.

Quantum Central became generally available in September 2026. It integrates cryptographic asset information from supported sources, evaluates exposure against enterprise-defined policies, and provides dashboards for monitoring readiness. Teams can identify policy violations, generate remediation tasks through Jira, and track their status. DigiCert’s broader certificate lifecycle and digital trust capabilities complement this approach, particularly for organizations managing extensive PKI environments.

Key Capabilities:

• Centralized cryptographic inventory: Brings together information from supported certificate, endpoint, and other discovery sources.
• PQC readiness policies: Evaluates assets against configurable cryptographic standards.
• Risk and readiness dashboards: Provide visibility into cryptographic exposure and migration requirements.
• Remediation tracking: Creates and monitors Jira tasks associated with cryptographic findings.
• PKI lifecycle integration: Connects readiness planning with broader certificate and digital trust management.

4. Keyfactor

Keyfactor provides cryptographic discovery, certificate lifecycle management, PKI modernization, and crypto-agility capabilities for enterprises preparing for post-quantum cryptography.

Its AgileSec portfolio extends cryptographic visibility across areas such as code, binaries, network traffic, cloud workloads, and enterprise infrastructure. AgileSec Analytics identifies cryptographic assets and potential weaknesses, while AgileSec Agility supports changes to cryptography in certain application environments without requiring source code modifications. Keyfactor’s certificate management and PKI capabilities support the operational work of updating certificates, keys, and trust infrastructure during the transition.

Key Capabilities:

• Enterprise cryptographic discovery: Identifies algorithms, libraries, certificates, protocols, and related dependencies.
• Crypto-agility tooling: Supports cryptographic modernization within compatible application environments.
• Certificate lifecycle automation: Manages certificates and machine identities across enterprise systems.
• PKI modernization: Supports adoption of quantum-ready trust infrastructure.
• Cryptographic policy management: Helps organizations establish and maintain cryptographic standards.

5. SandboxAQ

SandboxAQ provides cryptographic posture management through AQtive Guard, a platform designed to identify, analyze, and manage cryptographic exposure across enterprise environments.

The platform supports discovery across code, runtime systems, network communications, and infrastructure, helping security teams build a broader understanding of their cryptographic estate. Its cryptographic analysis capabilities help identify vulnerabilities and inform migration planning. SandboxAQ also supports governance and crypto-agility initiatives, making it relevant to organizations that require extensive technical visibility before coordinating changes across multiple technology environments.

Key Capabilities:

• Cryptographic posture management: Provides visibility into cryptographic assets and security weaknesses.
• Multi-environment discovery: Analyzes cryptography across supported code, runtime, network, and infrastructure sources.
• PQC readiness analysis: Identifies cryptographic implementations requiring migration attention.
• Risk assessment: Supports evaluation of cryptographic exposure and remediation priorities.
• Crypto-agility support: Helps organizations manage changes to cryptographic technologies and policies.

6. Palo Alto Networks

Palo Alto Networks provides Quantum-Safe Security capabilities that help organizations assess and address quantum-related cryptographic exposure through their network security infrastructure.

Its approach uses information from supported firewall and Prisma Access environments, together with additional security data, to identify cryptographic protocols, algorithms, certificates, and potentially vulnerable connections. The platform supports risk assessment and governance, while Cipher Translation capabilities help protect selected legacy communications using quantum-safe cryptographic mechanisms at the network layer. This approach is relevant to organizations managing network infrastructure that cannot be immediately upgraded at the application level.

Key Capabilities:

• Network cryptographic discovery: Uses supported security telemetry to identify algorithms, protocols, and certificates.
• Quantum risk assessment: Evaluates cryptographic exposure within network environments.
• Cipher Translation: Supports quantum-safe protection for selected legacy communications.
• Network-based remediation: Provides migration options that may avoid modifying individual applications.
• Security governance: Connects cryptographic readiness with network security policies and reporting.

7. QuSecure

QuSecure provides post-quantum cryptographic protection through its QuProtect platform, which focuses on securing network communications and managing cryptographic changes through centrally controlled policies.

QuProtect combines cryptographic discovery, quantum-safe protection, and reporting through its orchestration architecture. Its network-layer approach allows organizations to introduce supported post-quantum and hybrid cryptographic mechanisms without rewriting every application. The platform includes capabilities for identifying legacy cryptography in network traffic, managing protection policies, and producing CBOM-related reporting. Its emphasis is on implementing and maintaining quantum-safe communication rather than providing a complete enterprise-wide business prioritization model.

Key Capabilities:

• Network-layer PQC protection: Adds supported post-quantum cryptographic mechanisms to existing communications.
• Centralized policy orchestration: Manages cryptographic configurations across supported environments.
• Legacy cryptography discovery: Identifies relevant encryption activity in network traffic.
• Hybrid cryptographic support: Helps maintain interoperability during phased adoption.
• Cryptographic reporting: Provides inventory and compliance information related to protected communications.

What a PQC Transition Program Should Report to the Board

Executive reporting should communicate more than the number of certificates or vulnerable algorithms discovered. Large cryptographic inventories can grow as discovery improves. An increasing finding count may therefore indicate better visibility rather than deteriorating security.

A program dashboard should distinguish exposure, remediation progress, and unresolved dependencies.

The distinction between activity and outcome is essential. A report showing 500 completed remediation tickets provides limited assurance if those tickets were never technically validated.

Similarly, migrating a large number of low-impact certificates may represent less meaningful risk reduction than completing a smaller group of critical application transitions. A useful board report should connect progress with the enterprise’s most important business risks.

Frequently Asked Questions

What is an enterprise PQC transition program?

An enterprise post-quantum cryptography transition program coordinates the identification, prioritization, modernization, and governance of cryptographic systems that may become vulnerable to quantum computing. It involves security, application, infrastructure, compliance, and vendor teams. A complete program includes cryptographic inventory, business risk assessment, migration planning, implementation, technical validation, and continuous monitoring to maintain quantum-safe readiness.

What is the difference between a PQC assessment tool and a transition management platform?

A PQC assessment tool primarily identifies vulnerable cryptography and evaluates readiness. A transition management platform supports the broader process of deciding what to remediate, assigning responsibilities, coordinating changes, validating outcomes, and tracking program progress. Some vendors provide both capabilities. Enterprise buyers should examine whether a product supports execution and governance or primarily produces technical findings and recommendations.

How should enterprises prioritize their PQC migration programs?

Prioritization should consider application criticality, sensitive data, confidentiality lifetime, Harvest Now, Decrypt Later exposure, regulatory deadlines, and technical dependencies. Organizations should also evaluate replacement readiness and the operational consequences of each change. A phased strategy allows enterprises to address important risks first while managing compatibility challenges and distributing remediation work across responsible technical teams.

Can enterprises migrate to post-quantum cryptography without replacing every application?

Some systems can adopt quantum-safe protection through infrastructure upgrades, network-layer mechanisms, hybrid cryptography, or compatible proxies without immediate application rewrites. Other systems require changes to cryptographic libraries, certificates, protocols, or application code. The appropriate approach depends on architecture and interoperability requirements. Enterprises should distinguish temporary protective measures from complete modernization of underlying cryptographic dependencies.

How can CISOs measure progress toward quantum safety?

CISOs can track critical applications assessed, high-priority vulnerabilities, remediation ownership, validated closures, outstanding vendor dependencies, and compliance milestones. Progress should reflect reduced business exposure rather than the raw number of assets scanned or tickets closed. Continuous cryptographic monitoring also helps identify new vulnerabilities and prevents the transition from becoming a one-time compliance exercise.

But an extension isn’t a static piece of software. It updates silently, it can change owners, and it often has permission to read every page you open. That makes extensions one of the most overlooked supply-chain risks in modern computing, for individuals and organizations alike.

Why Extensions Are a Supply-Chain Risk

A software supply-chain attack targets something you already trust instead of attacking you directly. Browser extensions are an ideal vehicle for that, for three reasons.

They update automatically. Once installed, an extension receives updates in the background. If a malicious version is published, it can reach every user within hours, with no action on their part.

They change hands. Popular extensions with large user bases are valuable assets. Developers sometimes sell them, and the new owner inherits the trust of every existing user. The Great Suspender, a widely used tab management extension, is a well-known example: after it changed ownership, it was removed from the Chrome Web Store in 2021 and flagged by Google as containing malware.

Developer accounts get hijacked. In December 2024, attackers phished the developers of several legitimate Chrome extensions, including one from security company Cyberhaven, and used their access to push malicious updates. The compromised versions were designed to steal session data and credentials, with Facebook advertising accounts among the main targets.

In each case, users did nothing wrong. They installed a trusted tool, and the tool changed underneath them. That is one reason security-conscious teams use tools like the Afina anti-detect browser, which keeps each profile’s cookies, storage and extensions strictly isolated, so a single compromised extension can’t reach every account.

What an Extension Can Actually Access

When you install an extension, the browser shows a permissions prompt. Most people click through it. It’s worth reading, because the most common permission is also the most powerful: “Read and change all your data on all websites.”

An extension with that permission can, in principle:

• read the content of every page you visit, including email, banking and internal company tools;
• see form fields as you type, including some login details;
• access cookies and session data for sites it’s allowed to run on;
• modify pages, inject scripts or redirect links.

Many legitimate extensions genuinely need broad access to work. That’s exactly why a compromised one is so dangerous: it already has the permissions it needs to cause harm.

Browser vendors and tool makers are responding in different ways. Chrome’s Manifest V3 restricts extensions from loading remotely hosted code, which makes some attacks harder. Some browsers built for professional teams, such as Afina, go further by cryptographically signing extensions and scripts against silent tampering and encrypting profile data on the user’s device under a zero-knowledge security model. Whatever browser you use, the goal is the same: make it harder for a changed or malicious extension to run unnoticed, and limit what it can reach if it does.

How to Audit Your Extensions in 15 Minutes

You don’t need special tools to get a clear picture of what’s running in your browser. A short audit every few months is enough for most people.

1. List everything installed. Open your browser’s extensions page (chrome://extensions in Chrome, edge://extensions in Edge, about:addons in Firefox) and look at the full list, including disabled extensions.
2. Remove what you don’t use. If you can’t remember why an extension is there, uninstall it. Every extension you remove is one less thing that can be compromised.
3. Check permissions. For each remaining extension, open its details and review what it can access. Where your browser allows it, restrict site access to “on click” or to specific sites instead of all websites.
4. Check the publisher. Look at who publishes the extension and whether that has changed. A new publisher name on a long-standing extension is a reason to look closer.
5. Read recent reviews. A sudden wave of complaints about ads, redirects or strange behavior often appears soon after an extension is compromised or sold.
6. Separate sensitive activity. Keep banking, admin dashboards and work accounts in a separate browser profile with as few extensions as possible. Extensions installed in one profile can’t see what happens in another.

Policies for Organizations

For businesses, extensions are a shadow IT problem. Employees install tools to save time, and security teams often have no inventory of what’s running on company browsers.

A few controls make a big difference:

• Use an allowlist. Chrome Enterprise and Microsoft Edge support policies that allow only approved extensions and block everything else. Firefox offers similar enterprise policies.
• Control permissions centrally. Policies can block extensions that request specific high-risk permissions, or restrict which sites approved extensions may run on.
• Review approved extensions regularly. Treat extensions like any other third-party software: assess them before approval, recheck them periodically and remove those that are no longer needed.
• Isolate high-value access. Staff who manage advertising accounts, finance systems or customer data should work in dedicated browser profiles with a minimal, approved set of extensions.
• Include extensions in incident response. If an extension is reported as compromised, you should be able to identify affected users quickly, remove the extension and invalidate sessions on the services it could reach.

Warning Signs an Extension Has Gone Bad

Compromised extensions don’t always announce themselves, but a few signs are worth acting on immediately:

• new ads, pop-ups or redirects appearing on sites that never had them;
• your search engine or homepage changing without your input;
• an extension suddenly requesting new permissions after an update;
• unexpected logouts, security alerts or login attempts on your accounts;
• the extension disappearing from the official store, which often happens after a malware report.

If you notice any of these, remove the extension, sign out of active sessions on important accounts, change passwords for services you used in that browser and review recent account activity.

Conclusion

Browser extensions sit in one of the most privileged positions on any device: inside the browser, next to your email, your work tools and your financial accounts. That convenience comes with real supply-chain risk, because the extension you installed last year may not be the extension running today.

The defense isn’t to avoid extensions altogether. It’s to treat them like any other software with access to sensitive data. Keep fewer of them, review their permissions, watch for ownership and behavior changes, and separate your most sensitive activity from everyday browsing. A short audit a few times a year closes one of the easiest doors attackers have into your accounts.

The fixed versions are Node.js 26.13.1, 24.22.3 and 22.23.5, all shipped on November 11. The Node.js advisory rates seven of the 16 flaws as High, six as Medium, and three as Low. Most of the High-rated bugs are in the HTTP/2 and TLS server code, and several can be triggered by a remote client without credentials.

The release follows the advance notice Node.js published on November 3, which gave only the date and the top severity rating. It also lands three weeks after the October 21 release that fixed Node2Shell (CVE-2026-111497), the Brotli decoder flaw.

As of November 11, Node.js has published no CVSS scores for the new CVEs and lists no workarounds, so upgrading is the only fix it offers.

How the Node.js HTTPS Memory Leak CVE-2026-123864 Works

CVE-2026-123864 is a re-entrancy bug in Node.js’s handling of TLS writes within the HTTP parser. When asked to write zero bytes, TLSWrap::DoWrite() immediately calls ClearOut(), which decrypts the next incoming TLS record. If that empty write comes from JavaScript running inside the parser’s on_body callback, the parser is re-entered mid-body, which causes a use-after-free and an out-of-bounds heap read.

The server then copies that freed or unrelated heap memory into the request body. Node.js says the leaked data can include TLS private keys and other users’ requests. To trigger the bug, an application must call res.flushHeaders() before the request body ends and later call res.end() with a non-empty chunk. To read the leaked memory, an attacker needs any ordinary route that echoes or stores a request body.

CVE-2026-123864 affects all three supported lines but only HTTPS servers. Cleartext node:http is not affected. The fix, credited to Matteo Collina, stops empty writes from re-entering the parser.

The Other High-Severity HTTP/2 and TLS Flaws

Four of the remaining six High-rated bugs are in the HTTP/2 server. CVE-2026-123863 lets any unauthenticated client crash a default HTTP/2 server over TLS or cleartext. The client creates a stream that still leaves header memory out of scope after its session ends, so a memory-accounting check fails when the session is destroyed, and the process aborts. Node.js calls it a variant of CVE-2024-27983 that the earlier fix missed. It affects 24.x and 26.x.

CVE-2026-123866 can send freed response memory, including other connections’ response buffers, to a peer. It triggers when a stream is torn down while a write is still pending.

On Node.js 26.9.0 or later, and on 24.22.0 or later, a remote peer can force the teardown on its own. On all three lines, the same bug can also be reached through a teardown the application starts itself, such as a per-stream idle timeout.

CVE-2026-123874 lets an unauthenticated client corrupt server memory in applications that serve files with respondWithFile() or respondWithFD(). Resetting the stream during a pending write frees the stream object, and the server later makes a virtual call through it. CVE-2026-123865, an incomplete fix of CVE-2026-48937, lets a client send GOAWAY and then trigger a protocol error during shutdown. Each connection it does this to then holds server memory and a file descriptor indefinitely.

The other two High-rated flaws are in TLS. CVE-2026-123872 lets a client authenticated for one hostname renegotiate a TLS 1.2 connection under a different server name. It carries its client certificate authentication to a host with a stricter policy. CVE-2026-126051 lets a remote client crash TLS servers that use the SNICallback, OCSPRequest, newSession or resumeSession hooks, or server.addContext(). It affects 24.x and 26.x.

Five Node.js Flaws Credited to Claude and Anthropic Research

Node.js credits five of the 16 CVEs to Chris Rohlf “in collaboration with Claude and Anthropic Research.” There are three High-rated bugs (CVE-2026-123863, CVE-2026-123864, and CVE-2026-123874), the Medium-rated CVE-2026-123875, and the Low-rated CVE-2026-123862. Neither Node.js nor Anthropic has published a technical write-up on how they were found.

Tim Perry, credited as pimterry, reported three High-rated flaws (CVE-2026-123865, CVE-2026-126051 and CVE-2026-123872) and wrote the TLS fixes himself. Node.js credits the Low-rated fs.watch Permission Model bug to Trail of Bits (OpenAI). Matteo Collina wrote most of the other fixes.

Medium and Low Severity Fixes

Among the Medium-rated issues, CVE-2026-123868 lets an HTTP/2 client fill server memory past the maxSessionMemory limit. Node.js says the server retains about 114 bytes for each one-byte data frame that costs the attacker about 10 bytes to send. CVE-2026-123875 crashes HTTP/2 servers that serve files when a client cancels a handful of downloads, and CVE-2026-123828 is a one-byte heap overflow in session.altsvc() triggered by a long :authority header.

Two Medium-rated flaws weaken certificate checks. CVE-2026-123867 lets a client holding a certificate trusted by the default CA complete mutual TLS to a hostname protected by a separate CA. It applies when that hostname’s SNI context has no server certificate. CVE-2026-123877 lets https.Agent reuse a TLS session from the default trust store for a later request that sets ca: []. CVE-2026-123871 stops proxy usernames and passwords from appearing in ERR_PROXY_INVALID_CONFIG error messages, four error paths the fix for CVE-2026-48615 missed.

The three Low-rated bugs cover a recursive fs.watch leak of denied file names on macOS and Windows, a zlib crash after params() and destroy(), and CVE-2026-106071. That last one is a Permission Model wildcard over-grant first fixed in 26.x on October 21, and the November advisory now lists it for 22.x and 24.x as well.

Is the November 2026 Node.js Release Being Exploited?

The Node.js advisory does not report exploitation of any of the 16 CVEs, and as of November 11, Cyber Kendra found no public proof-of-concept code for them. Node.js has not published CVSS vectors either. Under its disclosure policy, CVE records can take a few days to appear after a security release because disclosure runs through HackerOne.

Disclosure has narrowed the gap between patch and exploit for Node.js bugs before. After the October release, public proof-of-concept code for Node2Shell appeared within about a day, according to Sysdig. The November advisory describes several bugs in enough detail to show how they are triggered.

What Node.js Users Should Do Now

Upgrade to Node.js 26.13.1, 24.22.3 or 22.23.5, then restart every Node.js process, since a running process keeps the old runtime in memory. Run node --version on each host, container, and CI runner to confirm the new build. Container images pinned to an older Node.js tag need to be rebuilt.

The release notes for all three lines also update llhttp to 9.4.4 and SQLite to 3.54.1. Node.js 24.22.3 and 26.13.1 also update the bundled Brotli library to 1.2.1 and Undici to 7.30.2 and 8.12.4, respectively. The 22.23.5 notes also include the fixes for four HTTP/2 bugs that the advisory lists only for 24.x and 26.x. All three sets of release notes reference a 17th identifier, CVE-2026-123873, a Low-rated Permission Model fix for heap snapshot destinations that the advisory does not describe.

Node.js 20 and Node.js 25 are end-of-life and receive no fixes, even though Node.js says end-of-life versions are always affected by security releases. The Node.js end-of-life page lists HeroDevs, NodeSource, and TuxCare as commercial sources of patches for retired lines. Anyone upgrading from 22.x or 24.x to 26.x should note that official Linux binaries have linked against libatomic since Node.js 25, which may need to be installed separately.

SignDrop is a local privilege-escalation flaw in clfs.sys, the kernel driver that implements CLFS. It has no CVE ID and no CVSS score, and as of November 11, 2026, Microsoft has not published an advisory or a fix.

The researcher, who also uses the handles Nightmare-Eclipse and MSNightmare, posted the SignDrop proof-of-concept on GitHub on Tuesday, November 10, 2026, with no coordinated disclosure. The repository ships C++ source and a Visual Studio project, and the researcher says a successful run “spawns a SYSTEM shell.”

SignDrop abuses a mitigation Microsoft built to curb CLFS attacks. The CLFS authentication mitigation adds a hash-based message authentication code (HMAC) to each log file and stores it in a “.cnpf” file beside the log, so the kernel can reject tampered logs. SignDrop turns that signing step into a path to privilege escalation.

How SignDrop Works

According to the researcher, the flaw lies in how clfs.sys creates the .cnpf signature file. When a standard user creates a log and a privileged process later opens it, CLFS creates the missing signature file for that privileged process rather than for the user. The proof-of-concept coerces the Microsoft Defender antimalware engine into opening the log, so the file is written as SYSTEM and inherits the original file’s permissions. “Everything is done properly by Microsoft here but the logic allows abuse,” the researcher wrote.

The researcher also claims the technique can disable other antivirus and EDR products, because the file-creation request appears to come from the security tool’s own trusted process — a claim Cyber Kendra could not independently verify.

The CLFS authentication mitigation reached Windows 11 version 25H2 and Windows Server 2025 in updates released on or after October 28, 2025, so only systems where it is active are exposed. The researcher says machines in both the 90-day “learning” mode and later “enforcement” mode are affected, and estimates “80% of the world’s windows installations are vulnerable” — a figure offered without supporting data. The exploit was tested on Windows 11 26H2 and experimental Windows Server 2025 builds.

What Admins Should Do Now

There are no reports of SignDrop being used in attacks as of November 11, 2026, and it is not in CISA’s Known Exploited Vulnerabilities catalog. As a local privilege escalation bug, it requires an attacker to already run code on the machine as a normal user.

No patch exists, and both the researcher and Microsoft’s guidance warn against disabling the CLFS mitigation to dodge SignDrop, since that re-exposes machines to the older CLFS memory-corruption bugs it was built to stop. Until a fix ships, defenders should enforce least privilege on standard accounts and watch for unexpected .cnpf creation by privileged processes and unusual CLFS errors, such as ERROR_LOG_METADATA_CORRUPT. Chaotic Eclipse has dropped a string of unpatched Windows exploits since BlueHammer in April 2026, several of which were later abused in the wild, so patch promptly once Microsoft responds.

CVE-2025-62861 affects Bitcoin Core 28.0 to 28.2 and 29.0 to 29.1. A reorg could corrupt the node’s mempool, the queue of unconfirmed transactions, so that every block template the node assembled failed its own validity check. Bitcoin Core rates the flaw High on its own four-level scale; the advisory carries no CVSS score.

The project published two medium-severity advisories the same day. CVE-2025-62859 let a malicious peer stall a node’s block processing for 10 minutes at a time, and CVE-2025-62860 handed trusted-peer permissions to anonymous inbound Tor connections on nodes with a common non-default setting.

All three are fixed in Bitcoin Core 30.0, released October 10, 2025, and in 29.2, released four days later. Nodes on 30.0 or newer were never exposed to the published details; nodes still on 28.x or older are, and those release lines no longer receive fixes.

How CVE-2025-62861 Stops a Node From Mining

The bug sits in Bitcoin Core’s handling of TRUC transactions, the “version 3” transaction type defined in BIP 431. A TRUC transaction may have at most one unconfirmed parent and one unconfirmed child in the mempool. That is a relay policy, not a consensus rule, so a valid block can legally contain a TRUC parent with several children.

Bitcoin Core 28.0 added “sibling eviction”: when a new transaction would give a TRUC parent a second child, the node treats the existing child as a replacement candidate and evicts it if the newcomer pays enough.

During a reorg, when the node abandons one or more blocks for a competing chain, it puts the transactions from the dropped blocks back into the mempool with a bypass_limits flag that is meant to skip policy checks. The sibling-eviction code did not check that flag. A reorg could therefore restore a parent with multiple children; sibling eviction would remove one of them, and that transaction’s descendants would remain, spending outputs that no longer existed.

With the mempool in that state, block template creation fails, and a mining node has nothing valid to hand its hashers. According to the advisory, the node cannot produce blocks until it is restarted, which consistently reloads the mempool.

Niklas Goegge reported CVE-2025-62861 to the Bitcoin Core security list on September 26, 2025. Greg Sanders opened the fix, PR #33504, three days later; it gates the TRUC checks on bypass_limits so sibling eviction no longer runs during a reorg. The fix was merged on October 2, 2025.

Two Medium-Severity Flaws Hit Compact Blocks and Tor Peers

CVE-2025-62859 involves compact blocks, the bandwidth-saving format peers use to announce new blocks. Affected nodes cleared their download state for a block after reconstructing it but before checking whether its witness data had been tampered with. If that check failed, the node asked the same peer for the full block and waited out a 10-minute timeout.

A malicious peer that announced a block first could trigger the stall. The CVE-2025-62859 advisory says the attack can be repeated indefinitely if the attacker controls the victim’s three high-bandwidth peers, or if the victim runs with -blocksonly. Eugene Siegel reported the flaw on April 28, 2025, and PR #32646 fixed it.

CVE-2025-62860 affects only nodes that set the -whitelist option, which lifts denial-of-service limits and privacy protections for trusted peers. Inbound Tor connections appear to come from the local Tor daemon’s address, so when the whitelisted range covered that address, every anonymous Tor peer was treated as trusted.

The exposure was wide because popular node packages bundled Bitcoin Core with Tor and set -whitelist to match. Bitcoin Core said this led to “thousands of reachable mainnet nodes” whitelisting all inbound Tor connections. Martin Zumsande and Antoine Poinsot reported the issue on September 12, 2025; PR #33395 prevents whitelist permissions from being applied to inbound Tor peers. Poinsot also notified Bitcoin Knots maintainer Luke Dashjr and several affected software providers that month, according to the advisory.

Why Bitcoin Core Waited a Year to Publish

The 13-month gap is policy, not a delay. Under Bitcoin Core’s disclosure policy, medium- and high-severity bugs are published two weeks after the last affected release line reaches end of life. The 29.x line reached end of life on October 27, 2026, with the release of Bitcoin Core 32.1, and the advisories followed exactly two weeks later.

The fixes themselves were public code changes in September and October 2025, merged without security labels. All three CVE IDs carry a 2025 prefix for that reason.

Which Bitcoin Core Versions Have the Fixes

The CVE-2025-62859 advisory lists fixes only in 30.0 and 29.2, so the final 28.x releases still carry the compact-block stall. The mining bug, CVE-2025-62861, does not exist before 28.0, the release that introduced sibling eviction.

Old versions remain common. A network snapshot taken on October 18 found 3,671 of 8,422 self-reported Bitcoin Core peers, or 43.6%, on release lines that had already reached end-of-life, CryptoSlate reported. That count covers 28.x and older, predating the 29.x cutoff.

Is CVE-2025-62861 Being Exploited?

None of the three advisories report exploitation in the wild, and Bitcoin Core has not published proof-of-concept code for any of them.

The CVE-2025-62861 advisory describes the trigger as a reorg that restores a transaction layout the mempool would normally reject. It does not say whether an attacker could cause such a reorg on demand or whether any miner lost blocks to the bug before the fix. Bitcoin Core also gives no rationale for the High rating, a category its policy reserves for bugs with significant impact on nodes or the network.

None of the advisories describes theft of funds or a change to Bitcoin’s consensus rules. The stated impact is lost availability for CVE-2025-62861 and CVE-2025-62859, and weakened denial-of-service and privacy protections for CVE-2025-62860.

What Node Operators and Miners Should Do Now

Operators should run a maintained release: Bitcoin Core 32.1, 31.2, or 30.4 as of November 11, 2026, available from the Bitcoin Core download page. Bitcoin Core does not update itself, and the lifecycle page lists 29.x and all earlier versions as end-of-life.

To check a running node, bitcoin-cli getnetworkinfo returns the version in its subversion field. Pool operators should also confirm the version of every node that serves block templates, not only the public-facing ones.

For CVE-2025-62861, a restart restores block production on an affected node, but it does not prevent the next reorg from breaking the mempool again. For CVE-2025-62860, the advisory lists no workaround other than upgrading; operators of bundled node packages can review their -whitelist setting and check the permissions field in bitcoin-cli getpeerinfo to see which peers are considered trusted. No workaround is listed for CVE-2025-62859.

N-central is the remote monitoring and management (RMM) server that managed service providers and IT teams use to patch, script and remotely control customer machines. The Able2Shell release covers 33 flaws in that server, and the researcher says they allow credential theft, creation of rogue administrator accounts and remote code execution up to root, in some cases without logging in. None of the 33 issues has a CVE ID or a CVSS score yet.

Security researcher Sean Bales, who posts on X as @seankbales, published the findings with proof-of-concept code on GitHub late on Sunday, November 8, US time, without notifying N-able first. N-able opened a critical security incident at 15:15 UTC on Monday, November 9, saying it was responding to a “public disclosure and non-responsible communication of critical vulnerabilities” in N-central.

As of Tuesday, November 10, hosted N-central remains offline in the Americas, Europe and Asia-Pacific; on-premises customers have been told to keep their servers switched off, and no fix has shipped. N-able’s latest estimate puts the hotfix at around midday US Eastern time on November 10.

Is Able2Shell Being Exploited?

watchTowr said on Tuesday, November 10, that its honeypots, decoy servers built to look like real N-central installations, recorded Able2Shell exploitation attempts overnight. The company posted a captured inbound request as evidence and told N-central operators to audit for signs of compromise, restrict access and follow N-able’s mitigation guidance.

N-able’s own statements say something narrower. The company said on November 9 that it had seen no active exploitation of the Able2Shell vulnerabilities, and a later update added that it had no evidence of unauthorised data access. Those statements predate watchTowr’s report, and an attempt against a honeypot is not a confirmed breach of a customer server.

No confirmed compromise through Able2Shell has been reported as of November 10. The vulnerabilities are not in CISA’s Known Exploited Vulnerabilities catalog, which lists flaws by CVE ID, and Able2Shell has none.

Why the Researcher Skipped Coordinated Disclosure

Bales told BleepingComputer that he released the N-central flaws without warning because N-able had not fixed three vulnerabilities he reported in a different N-able product five to six months ago. He said follow-up emails went unanswered and that N-able’s handling showed “they don’t take disclosure seriously”.

Bales also told the outlet that the research was AI-assisted, and that N-able executives contacted him after the release and asked him to take the repository down. The repository was still online on November 10. N-able has not publicly addressed his account of the earlier reports.

Which N-central Versions Are Affected

N-able has not published a list of affected N-central versions. Its guidance treats every deployment as exposed: all hosted environments are offline, and every on-premises server is to stay offline regardless of build.

Bales tested on N-central Appliance 2026.4.0.31, which his write-up describes as a pre-release build, and wrote that “most if not all vulnerabilities should work on previous versions”. N-able’s release notes list the general 2026.4 release as build 2026.4.0.23, so servers on the current public release should be assumed vulnerable.

Able2Shell is the third N-central security emergency since August. Authentication bypasses CVE-2026-18556 and CVE-2026-18577 were exploited in August, and CVE-2026-86218, a pre-authentication remote code execution flaw rated CVSS 10.0, followed in September and was fixed in 2026.3 Hotfix 4. Shadowserver counted nearly 1,500 N-central servers reachable from the internet at that time.

What N-central Admins Should Do Now

On-premises N-central servers should stay offline until N-able confirms they can return. N-able lists no other workaround for Able2Shell, and no configuration change has been offered as a substitute for disconnecting the server.

Hosted N-central customers have nothing to switch off, because N-able has already taken those environments down. N-able says its separate N-able.app console remains available for urgent patching and monitoring during the outage.

Huntress advises reviewing N-central login and authentication activity from November 8 onward and checking for administrator accounts nobody created, scripts nobody deployed and remote-control sessions nobody started. Any of those is a reason to bring in incident response and to check the customer networks managed through that server.

Huntress also notes that N-able sometimes ships live hotfixes without changing the version number, so a patched server may still report the same build. Admins should confirm the fix against N-able’s release notes when the hotfix arrives, not against the version string alone.

This article gives you a simple review checklist for the four things that break most often: headings, links, code blocks, and page breaks. It also covers how to check your source material before you write and the final PDF before you share it.

Review the Source Material First, and the Final PDF Last

Technical documents are rarely written from scratch. You may be working from product specifications, older manuals, research notes, or long PDF references. Before you format anything, make sure the facts you are about to publish are right.

Skim the source for the details that readers will act on: version numbers, command names, setting values, system requirements, and security warnings. Write them down in one place so you can check them again at the end.

Tools such as the iBoomto AI PDF summarizer can be considered when working with longer PDF files and extracting their main points for review.

A summary is only a starting point. Compare it with the original before you use it, especially for version numbers, configuration requirements, and security instructions, because one missing detail can send a reader in the wrong direction.

Do the same comparison at the end. Once the PDF is exported, check the details you wrote down against the final file to confirm that nothing was changed or lost along the way. The sections below cover the formatting checks.

Check Headings

Headings are how readers scan a technical document, so they need to be consistent. Check three things:

• One main title. The document should have a single top-level heading (#), and everything else should sit below it.
• No skipped levels. A ## section should be followed by ### subsections, not #### ones.
• Clear, specific wording. “Installing on Windows” tells readers more than “Next steps.”

Also check the order. Requirements should come before installation, and troubleshooting should come after the steps it relates to. An installation guide often works well in this order: Introduction, System Requirements, Installation, Configuration, Troubleshooting, and Additional Resources.

Here is a common mistake. The last heading below skips two levels, which makes the structure unclear:

# Installation Guide
## System Requirements
#### Download the installer

Changing the last line to ### keeps the outline clean. A consistent heading structure also makes it easy to add a table of contents if the document grows.

Check Links

A broken link can stop a reader in the middle of a task. Test every link in the Markdown file before you export:

• External links: Download pages, official documentation, and API references. Make sure each one opens the right page.
• Links between sections: A reference such as “see Troubleshooting” should point to a section that still exists under that name.
• Link text: Use a short label such as “Installation Guide” instead of a long raw URL, so readers know where the link goes.

After you export, click a few links in the PDF itself. A link that works in your editor should still be clickable in the final file. If the document may be printed, also write the address in plain text next to the most important links, because a printed page cannot be clicked.

Check Code Blocks

Readers copy commands from technical documents and run them, so a small change can cause real problems. Look at every code block in the PDF and check:

• Indentation: Spaces should be preserved, especially in code where indentation has meaning.
• Long lines: Commands should not be cut off at the edge of the page. The whole line should stay readable.
• Special characters: Quotes, dashes, and brackets should look the way you typed them. A double hyphen in a command should not turn into a different character.
• Copying: Copy a command from the PDF and paste it into a terminal or text editor to confirm it still works.

Short blocks are easier to check and easier to follow. Start with one sentence that explains what the command does, then show it:

git clone https://example.com/project.git
cd project

If an example is long, split it into smaller blocks with a sentence between them that explains each part.

Check Page Breaks and Layout

A Markdown file has no pages, but a PDF does. Scroll through the exported file from the first page to the last and look for these problems:

• Stranded headings: A heading at the bottom of a page while its text starts on the next.
• Split code blocks: A command or example broken across two pages in a way that makes it hard to follow.
• Wide tables: Columns that run past the margin or become too small to read. If a table has many columns, consider splitting it in two.
• Separated warnings: A note or warning that ends up on a different page from the step it refers to.

Also glance at margins, page numbers, and spacing. For longer documents, view the PDF at a smaller zoom level to see several pages at once, which makes layout problems easier to spot.

When you find a problem, fix it in the Markdown file and export again. Do not patch the PDF by hand, or the fix will be lost the next time you update the document.

Export the Markdown File into PDF

Once the Markdown file passes these checks, it is ready to export.

Using a dedicated Markdown to PDF converter provides a straightforward way to convert Markdown content into a PDF file. This is useful when technical documentation needs to be shared with people who may not have a Markdown editor or development environment.

A PDF keeps the layout consistent across devices and is easy to send by email, post on project management platforms, or store in a company knowledge base.

Do not assume the export is perfect. Open the PDF and run through the four checks again in this order: headings, links, code blocks, and page breaks. It usually takes only a few minutes and catches problems that only appear after conversion.

Final Checklist Before Distribution

Before you send the document, go through this list:

• The title is clear and says what the document covers.
• Headings use one top-level title and no skipped levels.
• Every link opens the correct page, both in the PDF and in the editor.
• Code blocks keep their indentation, and commands work when copied.
• Tables and examples fit on the page.
• No heading or code block is split awkwardly across pages.
• Version numbers, settings, and security notes match the source material.

Keep this list with your project so the same review is repeated every time the document is updated.

Conclusion

Most PDF problems in technical documents come from four places: headings, links, code blocks, and page breaks. Checking them one at a time, after the source material is verified and again after export, takes little time and prevents most of the mistakes readers would otherwise run into.

A consistent review process, supported by practical document tools, helps ensure that technical PDFs remain useful, clear, and reliable for the people who depend on them.

That point is rarely dramatic. You might notice the admin area dragging during a promotion. A backup that once finished overnight may still be running in the morning. Customers could mention that checkout stalled, while every test you run later looks fine. Annoying, yes. Conclusive, no.

Before changing plans, you need to see a pattern. A bigger server won’t fix a badly compressed image, a broken plugin, or a slow outside service. If the same problems return when the site gets busy, however, the hosting environment deserves a closer look.

The Slowdowns Keep Coming Back

Think about when the problem appears. Does the site behave well on a quiet Tuesday, then struggle after an email campaign goes out? Do searches, logins, and checkout pages slow at the same time? That combination tells you far more than one disappointing speed test.

Pull together a few weeks of evidence. Check page response times, server errors, and resource use during the periods when people complained. You don’t need a wall of charts. You need to know whether the website repeatedly runs short of processing power or memory when normal business activity picks up.

Traffic Numbers Can Fool You

Ten thousand article views can be easier on a server than a few hundred active customer sessions. A cached article requires very little work. A store or membership site has to check accounts, search records, update carts, and save changes. The workload behind each visit is what counts.

Timing changes the picture as well. Five hundred visits across a day may cause no trouble. The same number arriving in ten minutes can overwhelm a setup that was comfortable moments earlier. Campaign launches, ticket releases, and limited offers tend to create these tight bursts.

Workarounds Become Part of the Week

Teams get surprisingly good at living with small hosting limits. Someone runs imports late at night because they slow the public site. Backups are rescheduled again. A useful feature is postponed because the server doesn’t support the required software. 

Each workaround seems harmless until maintaining them becomes regular work. Once those workarounds become part of the weekly routine, the hosting setup is costing your team time. Moving to VPS hosting gives you allocated processing power, memory, and storage, plus deeper control over the server. That’s useful when a measured resource ceiling or blocked configuration is the thing holding the site back.

Be specific about the constraint. “The site feels slow” is too broad. “Product imports use all available memory and delay customer requests” gives you something to solve. That level of detail also helps you choose suitable resources instead of guessing from monthly visitor numbers.

Pay Attention to What Visitors Feel

Server dashboards are helpful, yet visitors experience pages rather than resource graphs. Watch whether forms submit, buttons respond, and important content appears without a long pause. Check the journeys that support the business, such as signing in, finding a product, booking an appointment, or completing payment.

Google’s explanation of Core Web Vitals covers loading performance, responsiveness, and visual stability as people experience them. Use those measures as clues, not a final diagnosis. A slow page can still come from bulky media, browser code, an outside script, or the server itself.

More Control Means More Responsibility

This part is easy to overlook. The target VPS service is self-managed. You gain root access, which lets you choose server software and adjust its configuration. You or your technical team also take care of the operating system, updates, monitoring, application setup, and routine maintenance.

Decide who owns that work before the move. Who checks security notices? Who responds to an alert on Sunday? Has anyone tested whether a backup can actually be restored? If those questions don’t have answers, more control could create a different problem.

A managed service may suit a team that wants stronger resources without handling server administration. The choice depends on your skills and working habits, not just the website’s traffic.

Move Because Something Specific Has Changed

Write down the reason for moving in one sentence. Perhaps the site repeatedly reaches its memory limit during ordinary demand. Maybe an upcoming feature requires software the shared environment can’t run. The reason should be clear enough that you can test whether the move fixed it.

Build a test copy before sending visitors to the new server. Run through logins, forms, payments, email, scheduled jobs, and outside integrations. Plan how recent orders or account updates will move across, and keep a way back if an essential function fails.

Shared hosting has been outgrown when its limits keep interrupting real work, useful fixes have already been tried, and the team is ready for greater responsibility. Don’t move because growth sounds impressive. Move when the evidence is consistent, and the new environment solves a problem you can name.

The first flaw is CVE-2026-116606, a pre-authentication authorization bypass in the Email Security Gateway (ESG). Mandiant, which assigned the CVE record, scores it 9.3 (Critical) on CVSS 4.0. The second is CVE-2026-111560, an OS command injection scored 8.6 that runs attacker commands as root. Only the ESG has the bypass. The injection also exists in five other Barracuda products, but on those it still requires an administrator account.

Barracuda released fixes on Monday, November 2, in an advisory covering six products. On November 5, watchTowr researcher Sina Kheirkhah published an analysis of the patches. It shows that a deliberately failed password change, a forged backup file, and a booby-trapped timezone string are enough to get a root shell.

As of November 6, neither CVE is listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog, and no vendor has reported attacks. Sources disagree on which ESG firmware build fully closes the bypass: 9.4.0.029 or 9.4.0.030.

How the Barracuda ESG Exploit Chain Works

CVE-2026-116606 lives in the ESG’s Index.pm request handler. watchTowr found that when a password change fails, the _process_params function builds a JSON error response and then returns the current user role instead of ending the request. Processing carries on with the low-privilege role assigned to the login screen. An attacker triggers this by sending a POST request to /cgi-mod/index.cgi with mismatched new_password and retype_password fields. The appliance returns HTTP 200 with a JSON body reporting the failure, but the rest of the request still runs.

That leftover processing reaches the bayesian_upload_handler, an upload routine named after the ESG’s Bayesian spam filter. The handler accepts a pu_bayesian_upload parameter and a file, then passes the file to Barracuda::Backup2::restore_all, the appliance’s full configuration-restore routine. Mandiant’s CVE record describes the result as an unauthenticated attacker restoring “a crafted, compatible backup archive” and rewriting the appliance’s global configuration.

Barracuda backups do carry an integrity check: each file’s checksum is an MD5 hash of the file bytes plus a secret value. watchTowr found that the secret is hardcoded, so anyone who knows it can produce checksums the appliance accepts as valid.

CVE-2026-111560 is the second half of the chain. The forged backup’s Spam_Config component loads a MySQL dump that restores the system_timezone setting. Two pieces of code then put that value into a sed shell command run through Perl backticks: finalize_restore in Backup2.pm, and the fix_tz.pl script, which runs as root through sudo. The value was wrapped in single quotes, which don’t stop shell metacharacters, so a timezone string such as UTC#';touch /tmp/watchTowr;# breaks out of the quotes and runs as root. watchTowr demonstrated the chain by writing that file to the appliance.

Barracuda’s fix replaces both sed calls with Perl file reads and writes. It also rejects any timezone that doesn’t exist under /usr/share/zoneinfo/. The bypass patch changes Index.pm, Backup2.pm, bayesian_upload.pm, UserRole.pm and Params.pm. watchTowr compared vulnerable build 9.4.0.027 with patched build 9.4.0.029.

Why Barracuda Calls CVE-2026-116606 “High” and Mandiant Calls It Critical

Barracuda’s own advisory rates CVE-2026-116606 “Severity: High” alongside its 9.3 score. It also lists “Authentication Required: Yes, administrative access” for both CVEs. Mandiant’s CNA record contradicts that line. Its vector, CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, means no privileges and no user interaction are needed. The record classifies the bug as CWE-288, authentication bypass through an alternate path.

BleepingComputer reported on November 6 that Barracuda had since clarified that attackers do not need admin privileges. The “administrative access” line therefore means network reach to the admin interface, not a password. CISA’s enrichment of the CVE record marks the bypass as automatable, with total technical impact.

watchTowr also found a 9.8 Critical rating in a comment inside Barracuda’s patch. The researchers suggest it reflects both bugs scored together but say this is their guess. NVD had not published its own score as of November 4.

Which Barracuda Products Have a Fix

Barracuda has released patches for all six affected products. The table lists the patch IDs from Barracuda’s advisory and the affected versions given in the CVE records.

For the ESG, sources disagree on the fixed build. Mandiant’s CVE record says CVE-2026-116606 affects versions earlier than 9.4.0.030. Barracuda’s Campus remediation page and watchTowr’s analysis both name 9.4.0.029 as the patched build. Barracuda has not explained the difference, so admins should treat 9.4.0.030 as the target and confirm with Barracuda Support if 9.4.0.029 is the newest build their appliance is offered.

Mandiant’s disclosure timeline shows Barracuda reported CVE-2026-111560 on Thursday, October 15, and CVE-2026-116606 on Thursday, October 22. Both records went public with the patches on November 2.

Is CVE-2026-116606 Being Exploited?

As of November 6, Barracuda, Mandiant and CISA have not reported exploitation of CVE-2026-116606 or CVE-2026-111560, and neither CVE is in the KEV catalog. Barracuda has not published indicators of compromise.

watchTowr has not released a weaponized exploit. Instead, it published a Detection Artefact Generator on GitHub so organizations can check whether their appliances are exposed. Its write-up does document the vulnerable endpoint, the six multipart fields the request needs, the checksum scheme and an example payload, along with a video demonstration.

The ESG has been attacked before. In 2023, a China-linked group Mandiant tracks as UNC4841 exploited a different ESG flaw, CVE-2023-2868, as a zero-day, and Barracuda told affected customers to replace their appliances. Nothing public connects the new flaws to UNC4841 or any other actor.

What Barracuda ESG Admins Should Do Now

To check the firmware version, go to ADVANCED > Firmware Update and read “Current Installed Version”. Update to ESG 9.4.0.030 or later and apply BNSF-40425, or BNSF-40430 on builds older than 9.4.017. Barracuda’s advisory also asks customers who disabled automatic patching to turn it back on. Owners of the other five products should apply the patch ID listed for each one in the table above.

Barracuda’s only listed workaround for appliances that can’t be patched right away is to restrict the administration interface to trusted internal networks. On the ESG, that means filling in the Administrator IP/Range field under BASIC > Administration and blocking the web interface port, HTTP 8000 by default, at the perimeter. The chain requires network access to that interface, so an ESG whose admin panel is reachable from the internet is the highest-priority fix.

Teams that want to confirm exposure can run watchTowr’s Detection Artefact Generator against appliances they own. Based on watchTowr’s analysis, a successful attack leaves two traces: a configuration restore that no administrator started, and a timezone value containing shell characters.

The flaw, tracked as CVE-2026-123158 and nicknamed sshhole by its discoverer, carries a CVSS 3.1 score of 8.1 (High) from MITRE. It affects sshd in OpenSSH before 10.6p2 when the server is built against the musl C library and runs without PAM (Pluggable Authentication Modules), which is how Alpine Linux ships its default openssh-server package. The code path behind it has been in portable OpenSSH since version 7.3 in 2016.

OpenSSH maintainer Damien Miller announced the release on Thursday, November 5, one day after the project learned of the bug, and told operators of affected systems to set PasswordAuthentication=no or disable SSH “IMMEDIATELY.” Researcher Özgün Kültekin of Wakefield, credited in the OpenSSH 10.6p2 release notes, has published a full technical write-up at sshhole.

As of November 6, OpenSSH and Alpine Linux have both shipped fixes, while other musl-based platforms such as OpenWrt, Buildroot, and Yocto have not published a fix status. Debian, Ubuntu, Fedora, Red Hat Enterprise Linux, and other glibc-based distributions are not affected.

How the OpenSSH sshhole Bypass Works

CVE-2026-123158 is a logic bug, not memory corruption, and it sits in the gap between two projects. Without PAM, sshd checks a password itself: it runs the submitted password through the C library’s crypt() function with a salt, then compares the result with the hash stored in /etc/shadow.

Accounts meant for key-only login, LDAP-mapped users and root on Alpine often have a single asterisk (*) in that password field, which normally means no password can ever match. For those accounts, sshd borrows a salt from another local account that has a real SHA-256 ($5$) or SHA-512 ($6$) hash. OpenSSH added that salt-borrowing behaviour in 2016 to fix CVE-2016-6210, a timing leak that let attackers work out which usernames existed.

musl’s SHA-based crypt() refuses keys longer than 256 bytes, and since 2012 musl has returned the string * on failure instead of the NULL that POSIX expects. So when an attacker sends a password between 257 and 1,024 bytes, crypt() returns *, sshd compares it with the stored *, the two strings match, and the login succeeds. The attacker needs only network access to the SSH port and the name of a * account; there is no password to guess.

Kültekin says he found the bug while testing sshd builds across combinations of glibc, musl, PAM and shadow support, roughly 17,600 logins in all, and only the musl build without PAM accepted logins it should have rejected. He says he used “agent swarms” for the testing; the write-up does not say AI found the flaw on its own.

Miller wrote the workaround, committed as 4353fdc4 on master and 90f9c2f7 on the 10.6 branch under the title “avoid password authn bypass.” According to TuxCare’s analysis, the change makes sshd reject any stored hash shorter than four characters, so a value like * can never match.

Why OpenSSH Blames musl, and musl Disagrees

OpenSSH’s release notes say the project considers the root cause of CVE-2026-123158 to lie outside sshd, but the bug is exploitable through sshd and can be avoided there, which is why the fix landed in OpenSSH.

musl maintainer Rich Felker has taken the opposite view, according to TuxCare: he calls it an erroneous use of crypt() by the caller rather than a musl bug, while saying the error behaviour will likely change in the next musl release cycle. Felker had already floated revisiting the “unmatchable hash” design in a December 2024 musl mailing list thread about long passwords crashing passwd on Alpine.

Why OpenSSH Skipped the Embargo

OpenSSH released 10.6p2 without the weeks-long embargo that usually precedes a coordinated fix. Miller said the project had recently seen several cases of AI agents rediscovering reported bugs, “sometimes within hours,” and now regards long embargo periods as a dangerous practice that mainly helps attackers.

The short window shows in the downstream picture. Alpine published fixed packages the same day, but on release day many other distributions and mirrors were still offering OpenSSH 10.6p1.

Which Alpine Linux Versions Have a Fix for CVE-2026-123158

Alpine Linux’s November 5 security advisory covers every branch back to 3.16, including branches that no longer receive regular updates. Stable branches carry a backported fix, so a patched Alpine 3.24 server still reports OpenSSH 10.3p1, not 10.6p2.

Alpine warns that its official tiny-cloud images, from 3.18.11 to 3.24.3, ship an alpine user with a * password field and passwordless doas. That account is safe on first boot, but once any other account on the machine gets a $5$ or $6$ password hash, an attacker can log in as alpine and become root. Default settings still block direct root password logins.

The official Alpine Docker image is not exposed on its own, because containers that do not run sshd cannot be reached this way. Images that add sshd and a hashed password are exposed and should be rebuilt on a fixed base. The openssh-server-pam package with UsePAM yes is not affected, and Dropbear’s maintainer has confirmed Dropbear is not affected, which matters for OpenWrt routers that use Dropbear by default.

Is CVE-2026-123158 Being Exploited?

As of November 6, neither OpenSSH nor Alpine reports attacks using CVE-2026-123158, and Cyber Kendra found no CISA Known Exploited Vulnerabilities listing for it. CISA’s enrichment on the CVE record marks exploitation status as “poc,” meaning proof-of-concept code is public.

The CVE record links two public reproduction labs on GitHub, sshhole-repro and sshhole-lab, and Kültekin publishes a check script that reports accounts that accept the bypass. Because the attack needs one connection and one long string, Alpine tells admins to treat affected machines as compromised if they cannot rule out unauthorised access.

What Alpine and musl Admins Should Do Now

On Alpine Linux, run apk upgrade -U -a and then rc-service sshd restart. Alpine stresses that the package upgrade does not replace the running daemon, so sshd stays vulnerable until it restarts. Confirm the installed version with apk info -v openssh-server and compare it with the table above.

Until the update is in place, Alpine and OpenSSH both advise setting PasswordAuthentication no and restarting sshd, or turning SSH off. Check that key-based login works and keep an existing session open while you restart. On Alpine 3.18 and older, drop-in files in /etc/ssh/sshd_config.d/ are ignored, so put the setting in /etc/ssh/sshd_config itself.

To see whether a host meets the attack conditions, list accounts with a bare asterisk using awk -F: '$2=="*"{print $1}' /etc/shadow, and accounts with a SHA-256 or SHA-512 hash using grep -E '^[^:]+:\$[56]\$' /etc/shadow | cut -d: -f1. A host with entries in both lists, password authentication on and sshd without PAM is exposed.

For signs of compromise, Alpine suggests searching /var/log/messages for Accepted password for entries on accounts that have no password, along with unexpected doas activity and new entries in authorized_keys files. Anyone building OpenSSH against musl without PAM on OpenWrt, Buildroot, Yocto, Void Linux or another platform should move to OpenSSH 10.6p2 directly, since none of those projects has published a fix status.