Category: Security

I pay attention when CISA puts a flaw on its Known Exploited Vulnerabilities list, because that list is not theory. It means the government has reliable evidence someone is already exploiting it in the wild. On November 13, CISA added two more, and it gave federal agencies until November 16 — tomorrow — to fix them. If you run any of this gear, you should treat tomorrow as your deadline too.

The bigger of the two for most organizations is CVE-2026-123039 in Check Point Security Gateways and Security Management products. CISA lists it at CVSS 7.8. On its own that number undersells it, because of how attackers are actually using it.

Here is the chain, as Check Point and CISA reporting describe it. Attackers first get in through the gateway’s Mobile Access portal by exploiting the PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619. Then they use CVE-2026-123039 to go to root. That second flaw is in the Gaia OS DynamicCLI daemon, which runs as root and listens on a local, world-writable socket without properly authenticating who connects to it. A low-privilege local user — or an attacker who just landed through the portal — can run commands as root and own the box.

From there it gets worse, fast. Check Point says attackers have deployed webshells and the TSGA backdoor, established persistence, moved laterally into internal networks, and in some cases deployed a wiper called destroy_v6 to erase data on VMware ESXi hosts behind the firewall. The campaign was first seen targeting Israeli organizations on October 30, then a second wave on November 2 hit organizations in multiple countries and sectors. Check Point says fixes were available before the attacks began, which is the part that should sting. This was patchable.

The second flaw CISA added is CVE-2026-114713 in UnrealIRCd, the open-source IRC server, at CVSS 8.6. It affects versions from 6.0.0 up to, but not including, 6.2.7.1. The bug is in the labeled-response module, which does not properly sanitize the IRCv3 label tag. On a network with at least two linked servers, an ordinary user with no special privileges can inject commands into server-to-server traffic and run them with server-level authority — disconnecting users, banning people, and taking administrative control of the network. The UnrealIRCd maintainer confirmed attackers were already trying to exploit it shortly after disclosure.

How bad is this, really? For Check Point shops, bad. Your firewall is supposed to be the door. When the door itself is compromised to root, and the attackers are wiping virtualization hosts behind it, you do not have a patching ticket — you have a possible incident. For UnrealIRCd, the blast radius is smaller — most people do not run an IRC network anymore — but if you do, an unprivileged user taking over your servers is as serious as it gets for that service.

What to actually do:

First, patch Check Point now. Install the vendor’s fixed Jumbo Hotfix for your Gaia version, and make sure the earlier PHP2Shell fixes are in too — patching only the privilege escalation while leaving the portal entry point open is not fixing the chain. If you cannot patch immediately, follow Check Point’s temporary mitigation in its advisory.

Second, do not assume patching cleans a box that was already hit. Look for the indicators Check Point published: suspicious PHP session files, unexpected webshells or backdoor processes, gaps in your logs, and SSH connections from the gateway to ESXi hosts that should never happen. If you find any of that, isolate the gateway and investigate before you trust it again.

Third, patch or upgrade UnrealIRCd to 6.2.7.1 or later if you run it, and check whether your network has linked servers exposed to untrusted users.

Fourth, for everyone else: this is the same lesson I keep coming back to. Internet-facing gear — firewalls, VPN portals, remote access — gets patched first, in days, not on the next monthly cycle. Attackers in this campaign moved about a week after a fix was available. That window is the whole game now.

I run servers for a living, and I would rather spend a Sunday morning patching than a month rebuilding from backups I hope are clean. Check what you are running today, before that deadline passes you by too.

Sources: CISA Known Exploited Vulnerabilities Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) and reporting on the CISA additions and the Check Point attack chain (https://www.infosectoday.io/u-s-cisa-adds-check-point-and-unrealircd-flaws-to-its-known-exploited-vulnerabilities-catalog/) and Check Point’s advisory coverage (https://neotechcloudsolutions.com/en/check-point-vulnerability-cve-2026-123039-firewall-esxi/). Always confirm version and hotfix details against Check Point’s own advisory for your exact Gaia release before you apply them.

On November 13, CISA added two more vulnerabilities to its Known Exploited Vulnerabilities catalog. That catalog matters for one simple reason: CISA does not put a flaw on it because it looks bad on paper. It puts a flaw on it because there is evidence someone is already using it in real attacks.

This time the deadline tells you how serious it is. Federal agencies have until Monday, November 16, to fix both of these. That is a three-day window, not the usual couple of weeks. When I see a deadline that short, I do not treat it as paperwork. I treat it as a sign to check my own systems that same day, even if I am not a federal agency.

The two flaws are very different, and they affect very different people. That is exactly why I am covering both together.

UnrealIRCd: a regular user can act like the server

The first is in UnrealIRCd, the open-source IRC server software a lot of community and gaming networks still run. It is tracked as CVE-2026-114713, with a CVSS score of 8.6. According to the reporting, it affects versions 6.0.0 up to, but not including, 6.2.7.1.

The bug is in the labeled-response module. It does not properly clean up the IRCv3 label tag when it includes that tag in server replies. An attacker can slip in newlines and extra commands, and those commands end up in server-to-server communications. On a network with at least two linked servers, even an ordinary user with no special privileges can end up executing commands with server-level authority. In plain terms, a regular chat user can start acting like the server itself — disconnecting people, banning people, and taking control of how the network runs.

If you run UnrealIRCd, the fix is straightforward: move to 6.2.7.1 or later. Do not wait to see if your small network gets noticed. The maintainer has already confirmed attackers were trying this shortly after disclosure, and automated scanning does not care how big your community is.

Check Point: root on the firewall itself

The second flaw worries me more, because it sits on security equipment itself. CVE-2026-123039, CVSS 7.8, is a local privilege escalation flaw in Check Point Security Gateways and Security Management products. Reporting on Check Point’s advisory says it affects versions R81 through R82.20.

The problem is in the Gaia operating system’s DynamicCLI daemon. It runs as root and listens on a local, world-writable Unix socket without properly checking who is connecting. A local attacker who already has low-level access can connect and run arbitrary commands as root. That is full control of the device.

On its own, “local” might sound like a limit. In the attacks Check Point described, it was not used on its own. According to Check Point Research, as reported by SecurityAffairs, attackers first got in through the Mobile Access portal using separate PHP2Shell vulnerabilities, then used this flaw to climb to root. From there they deployed webshells and a backdoor, moved laterally into internal networks, and in some cases deployed a wiper against VMware ESXi hosts. Check Point said it saw this exploited against a couple of dozen customers. The campaign initially targeted organizations in Israel on October 30, then expanded on November 2 to organizations in multiple countries and sectors. Attribution is still uncertain, and I am not going to pretend otherwise.

That chain is the lesson here. A flaw that only gives you root if you are already on the box sounds contained — until it is paired with a way in from the internet. Then it becomes the step that turns a foothold into ownership of the firewall, and from the firewall into the network behind it.

What to actually do

If you run Check Point, install the November Jumbo Hotfix for your version — reporting lists R82.20 Take 14, R82.10 Take 52, R82 Take 132, and R81.20 Take 174 or later. Then do not stop at patching. Check whether someone got in before the patch: look for unexpected webshells, unknown accounts, and strange outbound connections from the gateway itself. CISA’s current directive explicitly expects agencies to check for compromise before assuming a patch made them clean, and that is good advice for the rest of us too.

What should you do if you run neither of these? Still take two things from this. First, keep an actual inventory of what you run — edge devices, chat servers, the forgotten service on a linked box. You cannot patch what you forgot you had. Second, when CISA gives a three-day deadline, believe the urgency. Patch first, investigate second, and do both this weekend if either product is anywhere in your environment.

Source: CISA, “CISA Adds Two Known Exploited Vulnerabilities to Catalog,” November 13, 2026 — cisa.gov; SecurityAffairs, November 14, 2026 — securityaffairs.com.

If you run Citrix NetScaler ADC or NetScaler Gateway, patch again. I know — you just did this in October. Citrix published a new security bulletin, CTX697305, on November 12, covering 28 memory-safety vulnerabilities in NetScaler ADC and NetScaler Gateway. Nine of them are rated critical at 9.0 or higher. And the worst part is not the count. It is that one of them hits every deployment, including a box left in its default configuration.

What happened

The highest score in the bulletin is CVE-2026-107412, at 9.5. Citrix describes it as multiple memory overflows reachable without authentication on appliances configured as a Gateway — SSL VPN, ICA Proxy, CVPN, or RDP Proxy — or as an AAA virtual server. Those are the remote-access boxes people log into from home, which is exactly why that score is high.

The flaw I care about more is CVE-2026-120868, at 9.3. It is a memory overflow in core packet processing. There is no special feature to turn on, no login required, and no workaround. Citrix’s own wording, quoted in the reporting, is that all NetScaler ADC and NetScaler Gateway deployments are affected, including those deployed with the default configuration. A plain load balancer that has never been a VPN is in scope for this one.

The rest of the bulletin follows the usual NetScaler pattern: memory overflows tied to specific configurations, including SAML authentication, DNS load balancing, Email OTP, and Endpoint Analysis. The fixed builds are 14.1-73.57 and 13.1-64.39 for the standard releases, 14.1-73.58 for 14.1-FIPS, and 13.1-37.293 for 13.1-FIPS and NDcPP. If you updated in October to 14.1-73.49 or 13.1-64.32, you are vulnerable again — those builds predate this bulletin. Citrix also issued companion bulletins the same day, 31 CVEs in total across four bulletins according to SecurityOnline, including a 9.4 authentication bypass, CVE-2026-120869, in NetScaler Console, fixed in Console 14.1-74.34.

Citrix says it is not aware of any exploitation of these flaws, there is no public proof-of-concept reported, and none of these CVEs are in CISA’s Known Exploited Vulnerabilities catalog. Citrix also says some of the flaws were found through AI-assisted code analysis, and that this is the first release under its new monthly security release program.

How bad is it, honestly?

Serious, and urgent, but not a reason to panic if you patch promptly. I want to be precise about two things. First, “not exploited yet” is a statement about today, not a safety guarantee. Edge appliances that sit on the internet and handle logins are exactly the kind of target attackers work on quickly once a bulletin gives them a map. Second, Citrix’s text for most of these flaws says unpredictable behavior or denial of service, while the CVSS vectors beside some of them rate confidentiality, integrity, and availability all High. The bulletin does not reconcile that difference. My rule is simple: plan for the higher reading, because planning for the lower one is what creates a backlog if it turns out wrong.

What makes this bulletin different from a normal NetScaler bulletin is the triage habit it breaks. NetScaler teams usually read the precondition column and patch only the boxes that match. That still works for ordering — internet-facing Gateway and AAA boxes first — but it does not work for deciding what can wait, because CVE-2026-120868 has no precondition. Every appliance needs the upgrade.

What to actually do

First, inventory every NetScaler ADC and Gateway appliance you manage, including both nodes of every high-availability pair. Check the running build — from the NetScaler CLI, show ns version — against the fixed builds above. A patched primary with an unpatched standby is still an exposed appliance after a failover.

Second, upgrade, starting with internet-facing Gateway and AAA appliances, then the rest. There is no workaround for the default-configuration flaw, because the vulnerable path is core packet processing. Turning features off does not fix that one. The upgrade is the response.

Third, do not forget the management side. If you run NetScaler Console, get it to 14.1-74.34 or later for the authentication bypass in the companion bulletin, and keep its management interface off the public internet regardless.

Fourth, if you are still on NetScaler 12.1 or 13.0, treat this as a migration problem, not a patching problem — end-of-life branches do not get this fix. Move to a supported 14.1 build.

My bottom line: if you patched NetScaler in October and thought you were done for the quarter, you are not. Citrix is now on a monthly cadence, and this month’s bulletin includes a 9.3 that applies to every box by default. Patch every appliance, verify the running build afterward, and put the monthly NetScaler release on your calendar from here on.

Sources: Citrix security bulletin CTX697305, published November 12, 2026; ThreatAft, “NetScaler 28 CVEs: 9.5 Overflow, Default Flaw” — threataft.com; Cybersecurity News, “Citrix Patches 28 Security Vulnerabilities in NetScaler, Including a Critical Flaw in Default Installations” — cybersecuritynews.com; SecurityOnline, “Citrix NetScaler Vulnerabilities: 31 CVEs Fixed by Citrix” — securityonline.info.

If you run a web server, check what is answering your traffic today. Apache released version 2.4.71 yesterday, November 11, and the headline fix is a critical flaw in its HTTP/2 module, mod_http2. Tracked as CVE-2026-119618 and rated 9.8 out of 10, it can let a remote attacker run code on the server — no login, no password, nothing but the ability to reach the server.

What happened

Apache’s own advisory describes the bug as heap corruption in mod_http2, in a function called assign_headers, caused by concurrent execution using a shared resource without proper synchronization. In plain terms, the code handling HTTP/2 request headers can corrupt its own memory, and an attacker who understands that corruption can turn it into remote code execution.

The affected range is wide: Apache HTTP Server versions 2.4.55 through 2.4.70. If you run the project’s own releases, 2.4.71 is the fixed version. Standalone builds of the module, released on GitHub as mod_h2, are affected from version 2.0.8 through 2.0.42.

One condition matters more than any other: only servers with HTTP/2 enabled are affected, according to Red Hat, which ships this server in Red Hat Enterprise Linux. HTTP/2 only runs where the Protocols directive turns it on — h2 for HTTP/2 over TLS, h2c for HTTP/2 over plain TCP. That directive can be set server-wide or for a single virtual host, so you have to check every virtual host too.

The flaw was reported on October 26 by Anthropic’s OSS Scanner, a free scanning service for open-source projects. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research also reported it last week. The same release fixes two smaller issues: a crash in mod_md, rated important, and a one-byte overwrite in mod_vhost_alias, rated low.

How bad is it, honestly?

The honest answer is: serious, conditional, and not yet settled. Serious, because an unauthenticated remote code execution flaw in one of the most widely deployed web servers on earth is never a small thing. Red Hat says an attacker who can reach the server could take full control of the server process. Conditional, because a server that never enabled HTTP/2 does not carry this risk at all — and plenty of Apache installs still serve plain HTTP/1.1 only.

Not settled, because the two assessments I trust most disagree on exploitability. Red Hat’s assessment, published yesterday, says public research has demonstrated a reliable exploit against a default server with mod_http2 enabled — though it does not name or link that research. Security company Wiz said later that day that no exploit was available and no exploitation in the wild had been reported. Both cannot be fully true at once, and I am not going to pretend otherwise. I take the disagreement as a short clock, not a reason to relax.

Two more points keep this from being a panic. Red Hat rates the flaw Important rather than Critical on Red Hat Enterprise Linux 9 and 10, because its mod_http2 packages give each HTTP/2 stream its own memory allocator, which makes an attack much harder. Red Hat shipped fixes for those releases yesterday, and Red Hat Enterprise Linux 8 and earlier do not contain the vulnerable code at all. On the other hand, do not assume last spring’s update saved you: an earlier HTTP/2 flaw was fixed in 2.4.67 back in May, and every release from there through 2.4.70 is still inside the range this new bug affects.

The distribution picture is uneven. Debian’s unstable branch has the fixed package, while Debian bookworm and trixie were still listed as vulnerable with no fix when The Hacker News checked. Amazon Linux fixes were pending, and Ubuntu’s tracker had no page for the flaw. If you run a distribution build, your package number will not say 2.4.71 — check your vendor’s advisory for its own fixed package.

What to actually do

First, find out whether HTTP/2 is on. Search your Apache configuration — the main config and every virtual host — for the Protocols directive and look for h2 or h2c. If neither appears anywhere, note that, keep an eye out for your distribution’s normal updates, and move on.

Second, if HTTP/2 is on, update. Move project builds to 2.4.71, or install your distribution’s fixed package — on Red Hat Enterprise Linux 9, for example, the fix ships as an updated mod_http2 package listed in Red Hat’s advisory. Restart Apache afterward and confirm the running version, because an installed package that never got loaded protects nothing.

Third, if you cannot update right away, Apache’s advisory offers no workaround, but Wiz advises one that works: remove h2 and h2c from the Protocols directive, leaving Protocols http/1.1, until you can patch. Your site stays up. You lose HTTP/2’s performance benefits for a while, a far better trade than leaving a 9.8 open. This matters most for the standalone mod_h2 builds, which have no fixed release so far — for them, turning HTTP/2 off is currently the only move.

My bottom line: check the directive first, because it decides whether this is your emergency or somebody else’s. If your server answers h2 or h2c on a version in the affected range, patch today or turn HTTP/2 off until you can. With assessments already disagreeing about whether a reliable exploit is public, waiting for certainty is the one option I would not pick.

Sources: The Apache HTTP Server Project, “Apache HTTP Server 2.4 vulnerabilities” — CVE-2026-119618, fixed in 2.4.71, released November 11, 2026 — httpd.apache.org; The Hacker News, “Critical Apache HTTP/2 Flaw Could Let Unauthenticated Attackers Execute Code Remotely” (November 12, 2026) — thehackernews.com.

Patch Tuesday used to be routine. This one is not. On Tuesday, November 10, CISA added six flaws to its Known Exploited Vulnerabilities catalog — bugs it has evidence are being used in real attacks. Two hit software most people use every day, Microsoft Outlook and Google Chrome. Two hit Barracuda email gateways with a three-day federal deadline. And one, in Cisco BroadWorks, was used in a campaign where the attacker reportedly let an AI agent do the intruding.

What happened

The Outlook flaw is the one I want most people to hear about, because its score undersells it. CVE-2026-124194 is rated moderate, CVSS 6.5. Microsoft says it has been actively exploited. An attacker sends a specially crafted message file and persuades you to open it in Outlook. Outlook then connects to a location the attacker controls without showing the usual external-content warning, and in doing so can disclose your NTLMv2 hash — authentication material an attacker can use to impersonate you. Microsoft notes the Preview Pane is not an attack vector; you have to open the file. The affected products are Microsoft 365 Apps for Enterprise and Office LTSC 2021 and 2024. The fix arrived in Microsoft’s November updates, in a release The Hacker News counts at 1,259 vulnerabilities — the second straight month over 1,000. CISA gave federal agencies until November 24 to apply this one.

The Chrome flaw on the list, CVE-2026-125350 at CVSS 8.8, is the use-after-free bug in Chrome’s XML component I wrote about yesterday. Google already fixed it in Chrome 157.0.8103.50. What changed yesterday is the status: CISA has now formally listed it as known exploited, which removes any remaining argument for waiting on that restart.

The Barracuda pair also changed status. CVE-2026-116606, CVSS 9.3, lets an unauthenticated attacker restore a crafted backup on the Email Security Gateway, fixed in 9.4.0.030. Chained with CVE-2026-111560, CVSS 8.6, an operating system command injection in Barracuda appliances, it can lead to commands running as root. I covered that chain on November 9 when no exploitation had been reported. Now Barracuda has confirmed attacks against a small number of organizations, according to the reporting, and CISA set an unusually short deadline — November 13 — for both Barracuda flaws. Three days is CISA telling you how urgent it thinks this is.

Then there is Cisco. CVE-2026-20320, CVSS 7.5, is an XML external entity flaw in the Open Client Interface parser of Cisco BroadWorks. An unauthenticated remote attacker can use it to read sensitive configuration information. Cisco fixed it in August 2026, in release RI.2026.07. According to Malbear Labs, reported by The Hacker News, a Chinese-speaking threat actor used it against a European telecommunications provider in a campaign dubbed Operation Snowball, using an autonomous framework built with a jailbroken DeepSeek Flash model. The reporting says the agent enumerated hundreds of assets, extracted dozens of credential sets, and exfiltrated thousands of rows of subscriber billing and device records over two weeks, largely without the operator present. The sixth flaw, CVE-2026-111793 at CVSS 4.3 in Openwave Webtop Media Transcoder, lets an authenticated user process unintended document types; it was fixed in October, in version 1.1.22.0.

How bad is it, honestly?

A KEV listing is not hype. It means CISA has evidence of exploitation, not just a proof of concept. Be precise about who is exposed, though. You are probably not running BroadWorks, a Barracuda gateway, or Openwave at home. Those are enterprise and telecom problems, and the teams running them should treat November 13 and November 24 as real deadlines. The Outlook and Chrome flaws reach ordinary desktops, and both already have fixes.

Do not let the Outlook score fool you. A 6.5 that leaks credentials attackers can reuse to impersonate you, and that Microsoft confirms is being exploited, outranks plenty of higher-scored bugs nobody is using yet. Patch order should follow exploitation first, score second. The AI angle on the Cisco case matters for a different reason: if an agent can run reconnaissance, pick an exploit path, and adapt when blocked, then leaving an August patch unapplied for months is no longer a slow human race. The window between a fix shipping and an attack arriving keeps shrinking.

What to actually do

First, run Microsoft’s November updates, and make sure Office updates too — the Outlook fix comes through the Office channel, not just the Windows cumulative update. Verify Outlook is updated, not just that Windows Update ran once.

Second, if you did not already take yesterday’s advice, update Chrome to 157.0.8103.50 or later and relaunch it. Confirm the version on the About page after the restart.

Third, if you run Barracuda ESG or the other affected Barracuda appliances, patch before November 13, restrict the admin interface so it does not answer from the internet, and check for a configuration restore or admin activity you cannot explain. A patch does not prove nobody got in first.

Fourth, if you run Cisco BroadWorks, confirm you are on the fixed RI.2026.07 release or later, and review for credential exposure — the reported campaign was after credentials and configuration, not just a foothold.

My bottom line: six flaws, all confirmed exploited, all already patched by their vendors. There is no research project here and no waiting for more information. Update Outlook and Chrome today, and if you operate any of the enterprise gear on this list, treat CISA’s deadlines as your deadlines.

Sources: The Hacker News, “Microsoft Patches 1,259 Flaws, Including Exploited Outlook Bug That May Expose NTLMv2 Hashes” (November 11, 2026) — thehackernews.com; The Hacker News, “Cisco BroadWorks and Openwave Flaws Actively Exploited Despite Available Patches” (November 11, 2026) — thehackernews.com; SecurityOnline, “CISA Adds Six Exploited Flaws in Outlook, Chrome, Barracuda, Cisco and Openwave to KEV Catalog” (November 11, 2026) — securityonline.info, summarizing CISA’s November 10, 2026 KEV additions.

If you use Google Chrome, stop and update it today. Not this weekend, not when it gets around to restarting itself. Google released a security update on Monday, November 9, that fixes nine vulnerabilities — and one of them is already being exploited by attackers. That makes this a patch you install on purpose, and then verify.

What happened

The exploited flaw is tracked as CVE-2026-125350. Google rates it high severity. It is a use-after-free bug in Chrome’s XML component. In plain terms, a use-after-free is a memory mistake: the program frees a piece of memory, then tries to use it again anyway. An attacker who controls what lands in that memory can sometimes turn a crash into code running inside the browser.

An anonymous researcher reported the flaw to Google on November 6. Three days later, on November 9, Google shipped the fix and said plainly that it is aware an exploit for CVE-2026-125350 exists in the wild. That sentence is the whole ballgame. It means this is not a theoretical bug found in a lab. Somebody is already using it against real Chrome users.

SecurityWeek counts this as the eighth Chrome zero-day exploited this year. The same update also patches six other high-severity flaws in Chrome’s WebGL, FileSystem, Compositing, GPU, V8, and XML components, plus two medium-severity bugs described as uninitialized resource issues in the GPU component. Google discovered most of those other flaws internally, according to SecurityWeek’s reporting.

The fix is in Chrome 157. You want version 157.0.8103.50 or 157.0.8103.51 on Windows and Mac, and 157.0.8103.50 on Linux. Google also released Chrome 157.0.8103.50 for Android on November 9 with the same security fixes, and an Extended Stable update to 156.0.8078.96 for Windows and Mac users on that slower channel.

How bad is it, honestly?

Bad enough to act today, and I will tell you exactly what we do not know, because that matters too. Google has not shared details about the attacks — not who is behind them, not who is being targeted, and not how the exploit is being delivered. SecurityWeek reported that no public information on the exploitation was available when it covered the patch. As of that report, CISA had not yet added CVE-2026-125350 to its Known Exploited Vulnerabilities catalog.

So I am not going to claim this is a mass campaign hitting everyone, and I am not going to claim it is only aimed at a handful of high-value targets. Neither is in the sources. What is established is narrower and still serious: a high-severity flaw in the world’s most widely used browser, an exploit that exists, and a fix that is already out. When the patch exists and the exploit exists, the only question left is which side of that line your browser is on.

Google also said the update will roll out over the coming days and weeks. That staged rollout is normal, but it is exactly why waiting is a bad plan. A browser that has downloaded an update but has not restarted has not applied it. I have seen machines sit in that pending state for days because somebody kept postponing the relaunch to keep their tabs open. Your tabs will come back. Relaunch.

What to actually do

First, update Chrome on every computer you use. Open Chrome, go to Help, then About Google Chrome. Chrome will check for the update and show you the version you are running. If an update is ready, click Relaunch. Afterwards, go back to that same About page and confirm you are on 157.0.8103.50 or 157.0.8103.51 on Windows or Mac, or 157.0.8103.50 on Linux. Do not just trust that auto-update handled it — verify the number.

Second, do the same check on your phone. Update Chrome for Android to 157.0.8103.50 through Google Play if you use it. If you are on an organization’s Extended Stable channel at work, your target is different — 156.0.8078.96 on Windows and Mac — so check with that version in mind instead of assuming the 157 number applies to you.

Third, if you manage computers for a family member, a small office, or clients, push this one. Check their version, relaunch the browser, and confirm it again after the restart. A downloaded-but-not-applied update looks done from a distance and is not.

Fourth, keep the usual discipline while details are still thin. Until Google releases more, be extra careful with unexpected links and downloads, and do not install browser extensions from outside the official store to chase a “fix” — the only fix for this is Google’s update itself. No website, pop-up, or email needs to sell you a patch for Chrome.

My bottom line: this is the cleanest kind of security decision. The flaw is confirmed, exploitation is confirmed, and the remedy takes about a minute. Update Chrome, relaunch it, verify the version number, and do the same for anyone who relies on you to keep their machines straight. That is the whole job today.

Sources: SecurityWeek, “Chrome Update Patches Exploited XML Zero-Day, Eighth This Year” (November 10, 2026) — securityweek.com/chrome-update-patches-exploited-xml-zero-day-eighth-this-year, summarizing Google’s Chrome Stable Channel update for desktop (November 9, 2026); Malwarebytes, “Update Chrome now to fix a flaw attackers are exploiting” (November 10, 2026) — malwarebytes.com.

I have seen this pattern too many times: a security appliance that is supposed to protect the network becomes the easiest way into it. That is where Barracuda’s Email Security Gateway sits this week. Two flaws chain into root access with no login at all, a full technical breakdown is already public, and as of yesterday the common scanners check for it too. If you run one of these gateways, do not queue this for next week.

What happened

Barracuda published its advisory on November 2, covering two flaws. The first, CVE-2026-116606, scored 9.3, is a pre-authentication authorization bypass in the Email Security Gateway, or ESG. It lets a remote attacker restore a crafted configuration backup without authorization. The second, CVE-2026-111560, scored 8.6, is an operating system command injection in the timezone setting, in code shared across Barracuda’s appliance line. Barracuda states that combined, they let an attacker bypass authorization and gain root access.

Here is what changed the urgency. The first advisory listed administrative access as required. On November 5 Barracuda revised that to say authentication is not required — only network access to the administrative interface. That same day, watchTowr published a full analysis built by comparing patched and unpatched code. In plain terms: a failed password change does not stop the request, a backup restore stays reachable, and a timezone value in that backup is later passed to a helper running as root. One crafted restore can turn into a root command.

The bypass affects ESG only. The command injection reaches six products in total: ESG, Load Balancer ADC, Web Application Firewall, Message Archiver, WAF Control Center, and Web Security Gateway. On those other five, an attacker still needs a working admin login first, which makes ESG the urgent one and the rest a close second.

Then came yesterday’s step. A Nuclei scanner detection template for this flaw was proposed on November 6 and merged into the public library on November 8. Scanning stops being specialist work then — anyone can find gateways that answer.

How bad is it, honestly?

Serious, but I will not overstate it. As of November 8 and 9, no source I read reports exploitation in the wild, and neither flaw is in CISA’s Known Exploited Vulnerabilities catalog. CISA’s assessment inside the CVE records, dated November 2, reads exploitation “none” — but it also rates the bypass as automatable with total technical impact. That combination is exactly the window you want to close in: public analysis, public detection, no confirmed attacks yet, and very little skill needed once scanning starts.

Reach matters more than the score. Both flaws sit behind the web administration interface. An ESG whose admin interface answers from the internet is the exposure that matters. An admin interface that only answers on a management network or VPN is a much smaller target, though not a safe one — anything compromised inside the network can still reach it.

This product has history, which is why I say hunt as well as patch. In 2023, a different ESG flaw was exploited as a zero-day, and Barracuda told customers compromised appliances must be replaced regardless of patch version. Nothing links that campaign to this pair. The lesson is narrower: email gateways sit on the internet, see every inbound message, and run with broad privileges. A patch closes the hole from now on. It does not prove nobody used it first.

What to actually do

First, close the door today, before you schedule anything else. Block the admin interface from the internet at your firewall, restrict it to your management network or VPN, and set the Administrator IP range on the appliance. If a provider manages it for you, allow only that provider’s fixed addresses. Mail ports are expected on an email gateway. Admin ports are not.

Second, patch, and verify the patch, not just the firmware number. For ESG, the target is firmware 9.4.0.030 or later, with patch BNSF-40425 applied — or BNSF-40430 on firmware below 9.4.0.017. Check under ADVANCED, then Firmware Update, confirm the patch is listed as applied, and turn automatic patching back on if someone turned it off. Appliances several versions behind may need staged updates. For the other products, the patches are BNADC-16586 for Load Balancer ADC and Web Application Firewall, BNMA-32468 for Message Archiver, BNWF-60060 for WAF Control Center, and BNYF-24789 for Web Security Gateway.

Third, look backwards. Take a configuration backup now, in case the current configuration is evidence. Then check for a restore nobody on your team ran, especially one preceded by a failed password change from an unfamiliar address. Review admin logins and configuration changes in the logs, and who reached the admin interface from outside. If you find a restore you cannot explain, treat the gateway as compromised, not merely unpatched.

Fourth, review who holds admin access on every Barracuda box, and rotate shared, reused, or default credentials. On the five products where the injection still needs a login, credential hygiene is the difference between a flaw and a rooted box.

My bottom line: re-triage this today if your team filed it on November 2 as an admin-only problem. It is not. It is a no-login path to root on an internet-facing email gateway, scanners found it yesterday, and the fix is already out. Patch it, lock the admin interface down, and check whether anyone got there first.

Sources: ThreatDefence, “CVE-2026-116606 Barracuda ESG: Patching and Threat Hunting” (published November 4, updated November 9, 2026) — threatdefence.com/article/barracuda-esg-cve-2026-116606-patching-hunting; Suriq, “Barracuda ESG CVE-2026-116606: Pre-Auth Root RCE Chain” (November 2026) — suriq.io/blog/barracuda-esg-cve-2026-116606-preauth-root-chain, summarizing Barracuda’s advisory (November 2, revised November 5, 2026) and watchTowr Labs’ analysis (November 5, 2026).

I use AI coding tools in my own work, so this one got my attention fast. It is not a hack of a model and it is not prompt injection. It is a convenience button doing exactly what it says — remembering a command so it does not have to ask again — and writing that command, password and all, into a file inside your project. Researchers found more than a thousand copies of that file in public GitHub repositories, with real secrets inside. If you use Claude Code, check your repos today.

What happened

Claude Code is Anthropic’s terminal coding assistant. By default it asks before running most shell commands. If you pick “Yes, and don’t ask again,” it saves an allow rule in .claude/settings.local.json inside the project, according to its permissions documentation. Later sessions then run matching commands without asking.

Sometimes that rule is a pattern, and sometimes it is one exact command. When it is the exact command, any password or token typed into it is saved too, in plain text. Ask the tool to check a database and the command it proposes will often carry the password with it. Approve it once with “don’t ask again” and you have stored that password in a JSON file in your project folder.

Security firm Apiiro published the research on November 5, and The Hacker News reported it on November 7. Apiiro searched public GitHub and found 104,185 copies of the file in 103,617 repositories. About 1.1 percent of them — 1,122 copies — hold at least one secret. Together those current copies hold 1,379 different secrets.

Counting older versions, the shared settings file, and saved agent chat logs, Apiiro puts the total at 2,539 secrets across 1,994 repositories. More than a third of the secrets in the current files open a database directly, including 379 database passwords, plus 43 SSH logins, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. They say 63 organizations own these files, and the strongest cases include a database vendor’s admin-level cloud key and the owner password of a medical-records database.

How bad is it, honestly?

For the people affected, this is serious, but I want to be precise. Apiiro did not test any of the credentials, so this proves exposure, not that every key still works. One company the researchers notified did confirm its key had been live. That is enough to treat any secret in one of these files as compromised until you rotate it.

The protection meant to prevent this does not travel. The first time Claude Code writes the file in a repository, it adds it to your global git excludes, so git on that one computer ignores it. It never adds the file to the project’s own .gitignore. Clone on another machine, or turn a folder into a repo later, and the file can be committed like any other. In 539 of the 1,105 repositories Apiiro traced, a commit listing Claude as a co-author changed the file — the assistant itself often commits it.

Time makes it worse. Every file with a secret was still on its repository’s default branch in the researchers’ snapshot, and in half it had been there at least 217 days. Older versions hold another 734 secrets, and 211 forks carry the same secrets. Deleting the file today does not clean history or forks.

Your scanner may not save you either. Gitleaks flagged 564 of the 1,122 files and TruffleHog flagged 643, but 215 were flagged by neither — most misses are passwords inside commands, where a password looks like an ordinary word. Users had also reported this before: a bug report from August 11, 2025, said the same thing, was closed by a bot as “not planned” in January, and the researchers say the related reports got no reply from Anthropic. I have seen no public response from Anthropic in the reporting I read.

What to actually do

First, search. Look in your GitHub account and any organization you belong to for .claude/settings.local.json and for .claude/settings.json, and check git history too, even where the file is now gone. Secrets also turned up in 298 of 76,011 public copies of that shared settings file.

Second, rotate first, clean up second. Change every password, token and key those files have ever held before you tidy the repo. Removing the file does not undo a leak that reached a public repo or a fork.

Third, untrack and ignore it properly. Stop tracking the file and add it to the project’s own .gitignore, so protection travels with the project.

Fourth, clean your local copy even if you never committed it, and delete every rule containing a secret. The researchers note that plain JSON file can also end up inside a package, a Docker image, a zip, or a synced folder. Fifth, keep secrets out of commands: reference them as variables from a secrets manager, so a saved rule holds the variable name, not the secret, and approve patterns instead of exact commands where you can.

My bottom line: AI tools that remember what you approved will remember your passwords too if you let them. Treat agent settings folders the way you treat .env files — assume they hold secrets, keep them out of git in the repo itself, and rotate anything that ever landed in one.

Sources: The Hacker News, “Claude Code’s ‘Don’t Ask Again’ File Exposes Passwords and Keys in 1,122 Public Copies on GitHub” (November 7, 2026) — thehackernews.com/2026/11/claude-codes-dont-ask-again-file.html; Apiiro research as reported in The Hacker News (published November 5, 2026).

Multi-factor authentication only protects you if the system actually makes you use it. That is the lesson in the SonicWall flaw disclosed on November 6. A company can do the right thing — put its VPN behind SAML single sign-on and enforce MFA through it — and still have a side door that lets someone log in another way and never face the MFA prompt. SonicWall has patched it, CISA says it has already been exploited, and there is no workaround. If you run one of these firewalls, this is a patch-today job.

What happened

The flaw is tracked as CVE-2026-19868, rated 7.1 out of 10 by SonicWall, and classified as CWE-308, use of single-factor authentication. It sits in the SSL VPN service in SonicOS, the operating system that runs SonicWall firewalls. SonicWall’s advisory, SNWLID-2026-0014, was published on November 6 and covers seven vulnerabilities in total. This one was reported by Ryan Harris of The Electronic Office.

Here is how SonicWall itself describes it: an authentication enforcement vulnerability in the SonicOS SSL VPN service may allow a user with valid credentials for an alternate authentication method to bypass SAML authentication controls, and successful exploitation may also bypass SAML-enforced multi-factor authentication. In plain terms, if the VPN is set up to use SAML for logins, but another login method also exists on that firewall, someone holding valid credentials for that other method could use them to get in without going through the SAML step — and without the MFA tied to it.

Two limits matter. First, SonicWall says this only affects the SSL VPN service if SAML is enabled for SSL VPN logins. Second, the attacker needs valid credentials for an alternate method. This is not a no-password, anyone-on-the-internet bypass.

On exploitation, the wording is careful but serious. SonicWall said its team “has investigated a report indicating potential exploitation” and strongly urged customers to upgrade as soon as possible. CISA went further the same day, adding the flaw to its Known Exploited Vulnerabilities catalog on November 6, with a remediation deadline of November 20 for federal agencies. SecurityWeek notes neither SonicWall nor CISA has shared details about the suspected attacks, and it is unclear whether it was exploited as a zero-day. No threat actor or victim has been publicly identified in the sources I read.

How bad is it, honestly?

For an affected firewall, I rate this high in practice, even though 7.1 is not the highest score you will see. The score reflects the preconditions — the attacker already needs a credential for another login method, and SAML has to be in use. What it buys them is exactly what MFA was bought to prevent: a stolen, shared, weak, or leftover password turning into remote access on its own. MFA is the layer that is supposed to make a stolen password not enough. A flaw that quietly removes it from your VPN — the front door for remote staff — is not a minor bug.

At the same time, do not inflate it. It is not unauthenticated remote code execution, and it does not hand an attacker a shell. If you do not use SAML for SSL VPN logins, this flaw does not apply to you, by SonicWall’s own note. And an attacker still has to get an alternate-method credential first. The risk concentrates where passwords are reused, old accounts were never cleaned up, or a local login method was left enabled and forgotten — which, in my experience, describes more real networks than anyone likes to admit.

The same upgrade also fixes the other six flaws in the advisory, two of them 8.8 issues in the management interface that, in certain circumstances, could let a remote attacker act without logging in. That is another reason not to sit on it.

What to actually do

First, check whether you are affected. You need a Gen7 or Gen8 SonicWall — SecurityWeek lists Gen7 TZ, NSa, NSsp, and NSv, and Gen8 TZ, NSa, and NSv — running an old build, with SAML enabled for SSL VPN logins. The affected builds are SonicOS 7.3.3-7015 and earlier on Gen7, and 8.2.2-8015 and earlier on Gen8.

Second, upgrade. The fixed releases are SonicOS 7.3.4-7013 for Gen7 and 8.2.3-8015 for Gen8. SonicWall lists no workaround for this flaw, so there is no setting to toggle while you wait for a maintenance window — the upgrade is the fix. Do not treat November 20 as your deadline; that date binds federal agencies. It is a backstop, not a plan.

Third, audit the alternate login paths. List every authentication method still enabled for that VPN, every local account, and every account not used in a long time. The flaw worked through an alternate method, so know what yours are. If an alternate-method password could have been reused, shared, or leaked, change it and review recent SSL VPN logins for sessions through a method or at a time you do not expect. I am not saying every affected site was breached — no source says that — I am saying a bypass of your login controls earns a look at the logs, not just a patch and a shrug.

My bottom line: MFA you configured is not MFA you got if the box offers another way in. Patch the firewall today, then go count those other ways in.

Sources: SonicWall advisory SNWLID-2026-0014, “SonicWall SonicOS Affected By Multiple Vulnerabilities” (November 6, 2026) — psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0014; SecurityWeek, “SonicWall Patches Exploited SonicOS Vulnerability That Weakens VPN Logins” (November 7, 2026) — securityweek.com/sonicwall-patches-exploited-sonicos-bug-that-weakens-vpn-logins; BleepingComputer, “SonicWall warns of new SSL-VPN MFA bypass flaw exploited in attacks” (November 6, 2026) — bleepingcomputer.com/news/security/sonicwall-warns-of-new-ssl-vpn-mfa-bypass-flaw-exploited-in-attacks.

SSH is the front door I use on every Linux server I run. This week that door turned out to have a strange fault on some systems: type a password that is far too long, and an account that was never supposed to accept a password at all lets you in. It sounds like a joke setup. It is not. OpenSSH rushed out an emergency fix on November 5, and by today researchers were already seeing attempts to use it.

What happened

The flaw is tracked as CVE-2026-123158, rated 8.1 out of 10, and nicknamed SSHole. SecurityWeek reports that it affects the OpenSSH server, sshd, on Linux distributions that use the musl C library with PAM — the Pluggable Authentication Module — disabled. Researcher Özgün Kültekin of Wakefield found it and gave it the name.

Here is the mechanism, in plain terms. Some accounts should never take a password — root on many systems, a key-only deploy user, the default user on some cloud images. Their entry in the password file is marked with a single asterisk, *, meaning no password is set. On an affected system, when someone sends a password between 257 and 1,024 characters long, musl’s crypt function returns that same asterisk as an error signal. sshd then compares the two asterisks, treats them as a match, and grants access. As SecurityWeek puts it, it is a misinterpretation of whether a string is intended to be a password hash.

Alpine Linux is the main case, because its standard openssh-server package is built that way. SecurityWeek notes that Alpine checked every release from 3.21 through 3.24 and edge, plus older releases from 3.16 to 3.20. Builds based on OpenWrt, Buildroot, and Yocto were also named as potentially affected. Alpine adds two more conditions: the target account’s password field has to be that asterisk, and the machine needs at least one other account with a $5$ or $6$ password hash — the SHA-256 or SHA-512 crypt formats.

OpenSSH developer Damien Miller said the flaw is not in sshd itself, but can be exploited through it. The fix shipped in OpenSSH 10.6p2, released as fast as possible after the team learned of the problem the day before. Decipher reports that, within hours of the November 5 disclosure, botnets were attempting to exploit it, citing watchTowr data, and that Previdian saw limited attempts in the past 24 hours. People noticed immediately.

How bad is it, honestly?

For an affected machine, this is as bad as an authentication bypass gets. Alpine’s warning, quoted by SecurityWeek, is blunt: an attacker who can reach your SSH port can log in without knowing any password, in one connection, every time, with no retries. No race to win, no guessing, no stolen key. If that account is root or has admin rights, the server is theirs.

Now the limits, because they matter for triage. This is not every Linux server. The conditions have to line up: musl, no PAM, password authentication enabled, an asterisk account, and another account with a suitable hash. A server that does not use musl, or that checks passwords through PAM, does not meet the conditions described in the reporting. Most mainstream server installs will fall outside this. Your Alpine hosts, containers, appliances, and small embedded builds are where I would look first — exactly the places that are easy to forget because they usually just work.

I am also not going to pretend patching is complicated here. The fix exists, the vendor instructions are short, and the attack is simple and cheap to try at scale. That combination — easy attack, easy fix, public details — is exactly when waiting costs the most.

What to actually do

First, inventory anything running sshd on Alpine or another musl-based build, including cloud images and containers that run SSH. Check the effective configuration with sshd -T and look at whether PAM is in use and whether password authentication is on. Do not rely only on a version banner — distributions backport fixes, so check your package updates too.

Second, patch and restart. On Alpine, run apk upgrade -U -a, then restart sshd with rc-service sshd restart. Elsewhere, update to OpenSSH 10.6p2 or your distribution’s fixed package. The restart is not optional: upgrading the package does not replace the daemon already running in memory, and that old process will keep accepting logins until it is replaced.

Third, if you cannot patch a host today, turn password logins off. Set PasswordAuthentication no, restart sshd, and keep a working key-based session open while you test a new login, so you do not lock yourself out. For most servers I run, key-only SSH is the right long-term setting anyway, not just a temporary workaround.

Fourth, look backwards. Decipher advises auditing sshd logs for successful password logins on accounts that normally never use them, such as the default user in common cloud images. And if you build from Alpine-based images, rebuild and redeploy from a patched base image instead of only patching running instances, so a stale image does not reintroduce the flaw next time you deploy.

My bottom line: check your smallest Linux boxes first — the Alpine containers and appliances nobody thinks about. That is where this one lives, and today is the day to close it.

Sources: SecurityWeek, “OpenSSH Rushes Patches for ‘SSHole’ Authentication Bypass” (November 6, 2026) — securityweek.com/openssh-rushes-patches-for-sshole-authentication-bypass; Decipher, “Attacks Target New OpenSSH Flaw” (November 6, 2026) — decipher.sc/2026/11/06/attacks-target-new-openssh-flaw.