Blog

  • Update Chrome Now: Attackers Are Already Exploiting This One

    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.

  • One Model, Two Doors: Anthropic Split Its Strongest Claude in Two

    On November 9, Anthropic released two new versions of Claude at the same time: Fable 5.2, which anyone can use, and Mythos 5.2, which is held back for verified organizations doing approved work. They are not two different brains. By the reporting I read, they are the same underlying model, split by who gets in and what they are allowed to ask it to do.

    That split is the story. The capability is the other half of it.

    Anthropic says these models are built for difficult technical work — long coding projects and hard science that earlier models struggled with. In testing, the company had Fable 5.2 build an operating system from scratch. It coordinated more than 1,000 AI agents over eight days and produced a working system that could boot on a laptop, with windows, file storage, and a login screen. Anthropic also reports the models helped solve two previously open problems in black hole physics and designed three working electronic devices. Those are company-reported results, not independent tests. The models are also reported to answer up to 30 percent faster than their predecessors, at $8 per million input tokens and $40 per million output tokens for Fable.

    Fable is the public door, with safeguards that block potentially dangerous cybersecurity and biology requests. Mythos is the locked door behind it. It keeps those capabilities, but only for organizations verified for approved cybersecurity or life-science research.

    Sources: The Neuron, “Everything That Happened in AI Today — Tuesday, November 10” — theneuron.ai; SXF Brief, “AI News Nov 10, 2026” — sxf.si/brief, which also summarizes the November 9 release, the pricing, and the verified-access split.

    The case for splitting it

    The strongest case is simple: some work is legitimate and dangerous at the same time, and pretending otherwise helps nobody.

    A security researcher testing a system she is authorized to test needs a model that will actually talk about exploits. A biology lab doing approved research needs answers a public chatbot should not hand to anyone who asks. If you only ship the locked-down version, you push that real work back to slower tools, or worse, to less careful providers. If you ship the open version to everyone, you hand the same power to people who will misuse it.

    Splitting the model tries to thread that needle. Keep the general tool fast, cheaper to run, and available. Gate the sensitive capability behind verification, so access is a decision, not an accident. That is how we already handle plenty of other powerful things in the real world. The tool is not banned outright. The person and the purpose are checked first.

    A model that can coordinate a thousand agents for eight days is not a chatbot anymore. It is closer to a junior engineering team you rent by the token. Teams like that need boundaries built into the product, not bolted on after something goes wrong.

    The case against it

    The strongest case against is also simple: who decides, and how would you know if they got it wrong?

    Verification sounds clean on a press page. In practice it means a private company becomes the gatekeeper for research. A small lab or independent researcher may do good work and still fail the paperwork or wait too long, while a large organization gets in because it looks safe on paper. That favors incumbents and concentrates quiet power in one approval process.

    If Fable and Mythos really are the same model underneath, the line between them is policy and filters, not physics. Filters leak. Prompts get reframed. Capabilities have a way of surfacing through the public door when thousands of users probe it every day. So the split may give a feeling of control that is thinner than it looks — restricted for the honest, porous against the determined.

    The headline demonstrations also need independent checking. A company demo is a company demo. How much human steering was in those eight days? Would it do the same job twice? Until outside teams run it on their own hard problems, I am filing those results as claims, not proof.

    Where I land

    I land in favor of the split — cautiously, and with conditions.

    One public model for everything was never going to hold once these systems got this capable. Either everything gets dumbed down until the serious work cannot get done, or everything stays open until someone does real harm and regulators shut the whole thing down for everybody. A tiered door is not perfect, but it is a grown-up attempt to avoid both endings.

    My conditions are practical. Publish clear criteria for who qualifies for Mythos, how long approval takes, and whether there is an appeal when someone is turned down. Get independent evaluations out fast — not just speed and price, but whether Fable’s safeguards hold and whether Mythos helps verified researchers do work they could not do before.

    If Anthropic does that, this release is more than a new model number. It is a workable pattern for the next few years: build the strongest tool you can, then be explicit about which parts are public, which parts are gated, and why.

    If it stays a black box — trust us, we checked them — then the critics are right, and we have just traded an open risk for a private one.

  • Your Barracuda Email Gateway Can Be Rooted Without a Login

    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).

  • How HTTPS Lets Two Strangers Talk in Private

    Every time I log in to a bank, buy something, or check email in a browser, I am trusting a conversation between two machines that have never met. Anyone on the network between us could, in principle, listen in. HTTPS is the system that lets that conversation stay private anyway, and once I understood how it works, the padlock in the address bar stopped being decoration and started meaning something specific.

    The Problem It Has to Solve

    Plain web traffic, the old HTTP, travels as readable text. If I send a password over it, any router, hotspot, or provider handling the packets can read it. Encryption fixes the reading part — scrambled data looks like noise to everyone except the intended reader — but it creates a new problem right at the start.

    To scramble a message so only one other party can unscramble it, we normally need a shared secret key that both sides know and nobody else does. My browser and a server I have never visited do not share a secret yet. If the browser simply sends a new key in plain text, the eavesdropper we were worried about gets a copy too. HTTPS solves that chicken-and-egg problem in two stages, using two different kinds of encryption for two different jobs.

    One Key That Locks, a Different Key That Unlocks

    The first kind is called asymmetric encryption. Instead of one shared key, a server holds a pair of keys that are mathematically linked. The public key can be given to anyone. The private key stays on the server and is never shared. Anything locked with the public key can only be unlocked with the private key. Anything signed with the private key can be checked with the public key.

    Think of it like a padlock I hand out freely. Anyone can snap it shut on a box, but only I hold the key that opens it. That is what lets a stranger send me something private without us agreeing on a secret first. Asymmetric encryption is powerful but slow, so HTTPS uses it only at the beginning — just long enough to set up something faster.

    How Do I Know Whose Padlock This Is?

    A padlock by itself is not enough. If an attacker sits between me and the real server, the attacker could hand my browser its own padlock and pretend to be the site. My browser would lock its secrets to the attacker, the attacker would open them, then pass them on to the real site. Neither side would notice from the encryption alone.

    That is why servers carry a certificate. A certificate says, in effect, this public key belongs to this domain name, and it is signed by a certificate authority — an organization browsers are configured to trust. My browser checks that the name matches the site I asked for, that the certificate has not expired, and that a trusted authority signed it. If any of that fails, I get the warning page instead. The certificate does not encrypt anything by itself. Its job is identity: proving the padlock belongs to who I think it does.

    The Handshake, in Plain Steps

    When I open an HTTPS page, my browser and the server do a short opening routine, called the TLS handshake, before any real page data moves. The browser says hello and lists the encryption methods it supports. The server picks one and sends back its certificate, which the browser verifies.

    Then, using that certificate and modern key-exchange math, the two sides create a fresh shared secret for this session only — without ever sending it across the wire in a form an eavesdropper can use. A listener can record the whole handshake and still not recover the session key.

    From there, both sides switch to symmetric encryption, where the same session key locks and unlocks the data. It is fast, so it handles the actual page, images, and form entries. When the session ends, that key is discarded. The next visit makes a new one.

    What HTTPS Does Not Do

    HTTPS protects data in transit. It does not prove a site is honest or safe to give a card number to. A scam site can have a valid certificate, because the certificate only proves the operator controls that domain — not that the operator deserves my trust. It also does not hide which site I am visiting, though it hides the specific pages and what I type. And it does nothing for data after it arrives: if the server stores my information carelessly, the private trip does not help.

    The Practical Takeaway

    Here is how I use this daily. I treat the padlock as a minimum, not a medal — a site asking for a password or payment without HTTPS is out, immediately. I pay attention when a browser warns about a certificate instead of clicking through, because that warning means the identity check has failed. And I remember what the system promises: a private pipe to the place named in the address bar. Whether that place should get my money is still my call.

    Two strangers, no shared secret, and a conversation nobody in the middle can read. That is not magic. It is a public padlock for identity and setup, a fresh private key for the real work, and a trusted signature tying the two together.

  • One Click in Claude Code Saved Your Password to GitHub

    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).

  • Everything Wants a Monthly Payment Now

    I used to buy a thing and own it. I paid once, I took it home, and if I took care of it, it kept working. That is not how most things arrive anymore. Now I rent access to music, movies, software, storage, and even features in products I already paid for. Everything wants a monthly payment, and each one asks so politely, and so cheaply at first, that saying yes feels like the practical choice.

    The Convenience Is Real

    I am not going to pretend the old way was better in every respect. Streaming puts a library in my pocket that no shelf in my house could hold. Software that updates itself does not leave me hunting for a disc or wondering whether I missed a fix. Cloud storage means a dead drive is an inconvenience, not a loss of years of work and photos. I would rather have a tool maintained by the people who built it than a frozen copy slowly going stale on my machine.

    There is also an honest cash-flow argument. Paying a little each month can be easier than finding a large sum all at once, especially in a month when a car repair or a utility bill has already taken its bite. A subscription can turn an impossible purchase into a usable tool today. That matters on a real budget.

    The Bleed You Do Not Feel

    The problem is not any single payment. It is that each one is designed to be forgotten. It renews while I am asleep and keeps charging in months when I barely touch the thing. One service is a rounding error. A dozen of them are a utility bill I never agreed to in one decision — I agreed to it in a dozen small decisions, months apart, and nobody ever showed me the total.

    Ownership had a discipline built into it that renting does not. When I bought something outright, the pain happened once, up front, and I thought hard before I paid it. A monthly charge spreads that pain so thin I stop thinking at all. Companies know this. That is why the free trial wants my card before it gives me anything, and why canceling often takes more clicks than signing up did. The business model is not just selling me a product. It is selling me my own inattention.

    When the Payment Stops, the Thing Stops

    The deeper change is what happens when I quit paying. A record I bought still plays. A tool I bought still opens. A subscription, when it lapses, takes the library, the files, or the feature with it — not because the thing wore out, but because permission ran out. I have not bought a collection; I have rented a key, and the key stops turning the moment the payment does.

    In a small town, that hits differently than it might in a place with a store for everything. Out here, people keep things a long time. A truck gets repaired, not replaced. A cast-iron pan outlives its buyer. There is a practical pride in owning something outright, and a real security in knowing nobody can switch it off from a server somewhere else. The subscription economy prefers that I never quite finish paying for anything I depend on.

    I feel the tension in my own work, too. I run websites, and I know recurring revenue is what lets a small operation keep the lights on and keep improving what it sells. I am not against a business charging monthly for a service it actually provides every month — hosting, support, and upkeep are real work that never ends. The line for me is whether the monthly charge matches monthly value. If someone is working for me every month, paying every month is fair. If I am paying every month for something finished long ago, I am not a customer anymore. I am just a habit on a billing cycle.

    A Practical Way to Handle It

    Here is what I have landed on, and it is not complicated. Once in a while I list every recurring charge in one place and ask three questions of each one. Did I use it this month? Would I buy it again today at this price, knowing what I know now? And if I canceled, what would I actually lose: a convenience, or something I cannot replace?

    Then I keep the ones that earn their keep, cancel the ones that survive only on forgetfulness, and, where I can, I buy outright the things I expect to use for years. I also keep local copies of anything I cannot afford to lose access to, because a library that vanishes when a payment fails was never really mine.

    I am not trying to live off the grid or swear off subscriptions for good. Some of them are worth every cent. I am just refusing to let a dozen quiet charges make a loud decision for me. Own what you can, rent only what earns it, and make every recurring payment argue for its place — out loud, on paper, more than once a year.

  • Your SonicWall VPN Had MFA On. Attackers Could Skip It Anyway.

    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.

  • The Voters Changed Congress. The Old One Still Has to Pay the Bills.

    On Tuesday, voters changed who will run Congress. On Monday, the Congress they just voted out comes back to work — and it still has the one job nobody can postpone. Federal funding runs out after December 11. If nothing passes, a funding lapse begins December 12, weeks before the new Congress is sworn in on January 3. That is the problem: an election decisive about the future, and a deadline belonging to the present.

    What We Know, and What We Do Not Yet

    As of today, Democrats have won control of both the House and the Senate in the November 3 midterms, according to race calls reported by the Associated Press and analyzed by NPR, as summarized in this roundup of the calls. Reuters was reported there as putting Democrats at at least 54 Senate seats to 44 for Republicans, with flips in states including North Carolina, South Carolina, Ohio, Texas, Kansas, Iowa, and Maine. Two Senate races — Alaska and Mississippi — were still uncalled, more than two dozen House contests were still awaiting calls, and no state had finished certifying its results. So the direction is settled and the exact margins are not.

    The funding facts are firmer. The current stopgap law, Public Law 119-103, funds agencies through December 11, as the University of Illinois farmdoc daily analysis notes. As of November 3, the House had passed 3 of the 12 regular spending bills and the Senate had passed none, according to the Committee for a Responsible Federal Budget, summarized in this breakdown of the deadline. Most bills need 60 Senate votes, so neither party can do this alone, and President Trump still holds the veto. The options are: a full-year package, a short stopgap into January or March, a mix of the two — or nothing, and a partial shutdown.

    The Strongest Case for Finishing the Full-Year Bills Now

    The case for the outgoing Congress finishing its work is a governing case, not just a partisan one. Its members are still the lawful Congress until January 3, they started these bills, and leaving unfinished spending to a brand-new Congress is a mess handed off, not respect for the voters. A full-year package gives agencies and service members a stable year instead of month-to-month guessing. Republicans about to lose the gavels also argue from their own mandate: they were elected to set spending priorities, that term has not ended, and a deal that still needs Democratic Senate votes and the President’s signature is by definition a compromise, not a unilateral lock-in. If a bill can get 60 votes in December, it has earned passage as it would have in October.

    The Strongest Case for a Short Stopgap and a Fresh Start

    The incoming majority’s strongest case is a simple democratic claim: voters just spoke, and the biggest spending decisions ahead should be made by the Congress they chose, not finished in a hurry by the one they removed. A short, clean stopgap into January is not avoidance on this telling — it is the honest bridge. It keeps the government open at current levels and lets the new House and Senate negotiate the real bills in the open. Democratic leaders have signaled a focus on affordability and accountability, as the roundup above notes, and their voters will expect action on health care and costs rather than ratification of a package written before the election. Practically, too, a rushed omnibus that nobody fully reads is how bad provisions become law.

    The Case Against Using a Shutdown as Leverage

    Both parties will be tempted by a third option: let the deadline slip, blame the other side, and start January with maximum leverage, on the theory that a lapse would be short and the blame would land elsewhere. I do not buy it. A shutdown does not punish Congress first. It delays paychecks for people who still have to show up and slows loans and filings for people who did nothing to cause it. After the long shutdowns of the past year, noted above, it also asks the public to treat a basic failure to fund the government as a normal negotiating move. It is not normal, and using it on purpose is an admission that the regular process failed.

    Where I Land

    I land on the short, clean stopgap — into January, not into spring — with no big contested riders from either side. The outgoing Congress should do the minimum its oath requires: keep the government funded, finish only must-pass work that is ready, and do no further harm on its way out, to borrow the farmdoc analysis’s plain standard. The incoming Congress should arrive ready to write real bills quickly, knowing divided government means each will need votes from people who disagree and a signature from a president who did not want this result.

    I said on Election Day that brakes are not the enemy of getting somewhere. Republicans still holding the gavels have to accept that the election limits what a lame-duck deal should lock in. Democrats about to hold them have to accept that winning Congress is not winning everything — the veto is real, 60 votes are real, and governing starts with keeping the lights on. Pass the bridge bill. Then let the Congress voters chose do the arguing — and the appropriating — in full view.

  • A Too-Long Password Just Opened SSH on Some Linux Servers

    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.

  • GPT-6 Cyber Is Built to Break Software — and to Stay in Bounds

    On November 5, OpenAI introduced a model with an unusual job description: find exploitable vulnerabilities in real software, build working exploits for them, develop fixes — and stay strictly inside the boundaries the researcher set. It is called GPT-6 Cyber, and OpenAI is not handing it to just anyone. I read the announcement the way I read most security news, asking two questions at once: how much can this help the people defending software, and how much trouble is it if the same ability gets loose?

    What happened

    OpenAI describes GPT-6 Cyber as a cybersecurity-specialized model, released through its API and Codex to a select group of approved customers in a program it calls Daybreak Red, with wider access for those customers promised soon. The full announcement is here: GPT-6 Cyber: Advancing the frontier of aligned cybersecurity agents.

    The numbers OpenAI reports are the headline. On ExploitGym, a benchmark that tests whether a model can exploit a specified vulnerability, GPT-6 Cyber scores 48.5%, up from 32.1% for GPT-5.6 Cyber. OpenAI classifies it as Critical in cybersecurity under its own Preparedness Framework, up from High for the previous cyber model. And this was not only lab work. OpenAI says its researchers used the model to develop working exploits for 948 Linux kernel privilege-escalation vulnerabilities, and to identify 81 previously unknown high-severity vulnerabilities in Firefox, which it disclosed to Mozilla along with candidate patches. Mozilla, OpenAI says, has released fixes for many of them.

    The other half of the announcement is about restraint. In an evaluation designed to tempt the model into attacking easy, out-of-scope services to complete its task, OpenAI says GPT-6 Cyber stayed in bounds in 99.93% of tests without a safety prompt, and 100% with one, up from 94.49% for its predecessor without that prompt.

    The case for it

    The strongest case is simple: defenders are outnumbered by old code. The Linux kernel and Firefox have been reviewed for years by very good people, and a model still turned up dozens of serious, previously unknown flaws in one and hundreds of reproducible privilege-escalation paths in the other. That is not a party trick. Every one of those findings that gets disclosed responsibly and patched is a hole an attacker does not get to use first.

    Scale is the point. A human security researcher is slow, expensive, and rare. A model can read code all night, test one more variation, and draft a candidate patch for a maintainer to review. If that work flows to open-source projects and small teams that could never hire a red team, the overall level of software gets better, not just the software at rich companies.

    I also take the scope work seriously. An agent that finds exploits is only useful to a professional if it respects the rules of engagement — what systems are in scope, what actions are allowed, what gets reported. A jump from roughly 94% to over 99% on staying in bounds, if it holds up outside OpenAI’s own tests, is the difference between a tool I would supervise closely and one I might actually trust with a defined job.

    The case against it

    Now the other side, stated plainly: a better exploit builder is a better exploit builder, no matter whose logo is on it. ExploitGym does not know whether the person running the test is a defender. OpenAI’s own Critical rating is an admission of that dual-use problem, not a marketing line.

    The guardrails are also, for now, largely OpenAI grading its own work. The benchmarks, the honeypot test, and the access rules are all OpenAI’s. Access is restricted — identity checks, approved customers, monitoring, IP allowlisting — and that helps. But restricted access is a policy, and policies change, leak, and get copied. Once this level of capability exists in one lab, the practical question is not whether similar capability spreads, but how fast, and into whose hands.

    There is a quieter risk, too. A tool this confident can make a team lazy. A candidate patch is not a correct patch until a human who understands the system reviews it. A vulnerability report is not a fix. If organizations use a model like this to claim their software was audited without doing the slow verification work, we will get more paperwork and the same number of holes.

    Where I land

    I am for this release, with my eyes open. The Firefox and Linux results, disclosed to the maintainers with patches, are exactly the shape this technology should take: find it, prove it, hand it to the people who own the code, and let them fix it. That is defense getting faster in a measurable way.

    But I would treat GPT-6 Cyber the way I treat any powerful tool on a server: useful inside a defined scope, with logs, with a human reviewing the output, and with no illusions about what it could do outside that scope. The model staying in bounds 99.93% of the time is impressive. The remaining fraction is why the human stays in the loop.

    Software has accumulated more known-unknown holes than human reviewers can clear. If models like this spend most of their time clearing them for the defenders, that is a real win. Keeping it that way is now the job — OpenAI’s, and everyone who uses it.