Author: qpid

  • Attackers Are Already Inside Check Point Firewalls — And CISA’s Deadline Is Tomorrow

    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.

  • AT&T Says It Has Nearly 500 AI Agents in Production. The Interesting Part Is How It Got There.

    Most AI announcements I read are about a model. This one is about work.

    On November 14, SiliconANGLE reported that AT&T has nearly 500 agentic AI workflows already in production, and plans to triple that number next year. Luke Corbin, AT&T Business’s assistant vice president of digital transformation and AI, was speaking at an Amazon Web Services event in Boston earlier this month.

    According to that reporting, AT&T processes about 45 billion AI tokens a day across the company, and its agentic platform handles more than 1 million transactions a month. The workflows range from customer provisioning to sales prospecting. Some of them now operate autonomously.

    The group behind it is called Business Agent Foundry, set up in early 2025. Instead of collecting isolated automation ideas, the foundry maps a whole business process, looks for unnecessary steps, handoffs, and dependence on old applications, and then redesigns the process around what agents can do. One early example involved AT&T’s mainframe computers: changes to customer fiber installation orders used to require employees to pull tickets from queues, update records by hand, and return them to the workflow. Agentic automation removed portions of that manual work. In another example in the report, AT&T halved the time needed to provision dedicated internet connections in buildings where fiber was already installed.

    The case for it

    The strongest part of this story, to me, is not the number of workflows. It is the order of operations.

    AT&T did not, by this account, start by letting everyone build customer-facing agents however they wanted. Personal productivity agents are open to employees. Workflows that touch customers have to go through the foundry and through security, privacy, and compliance review. Every production workflow starts with human oversight. Only after accuracy reaches the mid- to high 90 percent range, within what the company considers a permissible risk profile, can an agent run autonomously. Then it stays under continuous monitoring for drift.

    That is a practical ladder: human in charge, human checking, autonomy earned, monitoring after. It treats autonomy as something a process qualifies for, not something a tool gets by default.

    I also like that the work started with process maps instead of prompts. A lot of failed automation I have seen keeps every bad step in a process and just makes the bad steps faster. Mapping first gives you a chance to delete a handoff or an old application dependency entirely. Deleting work beats automating work.

    And there is a real legacy problem here worth solving. Corbin pointed to the cost of maintaining old applications and training people to use them. When advanced software ends up talking to a mainframe so a fiber order can move without a manual queue in the middle, that is not a demo. That is the kind of unglamorous connection that actually saves time in a large company.

    The case against it

    Now the caution, because this is still a company telling its own story at a vendor event.

    Every figure in that report — the nearly 500 workflows, the token count, the transaction count, and Corbin’s statement that production AI investments are achieving fivefold returns within a year — comes from AT&T itself. SiliconANGLE reported what Corbin said. That is not the same as an independent audit of what those workflows cost, how often they fail, or what the return calculation includes and leaves out.

    Tripling the count next year is a plan, not a result. A workflow count is also an easy number to grow and a hard number to judge. Five hundred small, well-scoped workflows and five hundred broad ones are not the same thing, and the report does not give me a breakdown I can weigh.

    There is also the accuracy threshold itself. Mid- to high 90s sounds high until you apply it to a process that touches a lot of customers. A process that is right 96 times out of 100 still gets it wrong regularly at scale, and the cost of the wrong cases depends entirely on what the workflow does. Provisioning help and sales prospecting are not the same risk as billing changes or service cancellations. The governance described in the article is a good sign, but the proof is in the error handling I cannot see from outside.

    Finally, redesigning processes around agents creates a new maintenance burden while it removes an old one. Business logic stored centrally, retrieval agents, planning agents, monitoring for drift — that is real infrastructure that has to be owned, updated, and understood after the foundry team moves on. Corbin himself said the foundry should not exist in the long run and its work should be distributed through the organization. I agree with the goal. Distribution is also where a lot of good central programs lose their discipline.

    Where I land

    I believe the direction, and I am reserving judgment on the numbers.

    If a company the size of AT&T can map a process honestly, remove steps before automating what is left, keep customer-facing work behind review, and make agents earn autonomy with measured accuracy and continued monitoring, that is a model worth copying — especially for anyone running older systems that are not going away this year.

    What I will not do is repeat the fivefold return or the plan to triple as if they were proven facts. They are claims from the company doing the work, reported on November 14, and they should be read that way.

    The useful lesson for the rest of us is smaller and more durable than the headline count: do not start with the agent. Start with the process, write down where a human must stay in charge, decide in advance what accuracy earns more freedom, and keep watching after you grant it. That discipline is the technology story here. The agents are just what it produces.

  • How DNS Turns a Name You Type Into the Server You Actually Reach

    When I type a domain name into a browser, I am not really telling the browser where anything lives. I am giving it a name that people can remember. Computers on the internet reach each other using IP addresses — numbers that identify a particular machine or service. DNS, the Domain Name System, is the system that translates the name I remember into the number the network actually needs. Without it, I would have to keep lists of numbers for every site and service I use, and change those lists every time a server moved.

    Start With the Parts of a Name

    A domain name is read in pieces, from right to left. The rightmost part, like .com, is the top-level domain. To its left is the registered domain — the name someone actually bought from a registrar. To the left of that can be subdomains, like www or mail, which the owner of the domain can create for different services. Each level narrows the question: which top-level domain, which registered domain under it, and which host or service under that domain?

    That structure matters because DNS is not one big list held in one place. It is delegated. Different organizations are responsible for different levels, and each level points to the next one down. That is why a domain owner can move a website to a new server, change email providers, or point a subdomain somewhere else without asking the whole internet for permission — they control the records for their own zone.

    What Happens When You Visit a Site

    When my browser needs an address it does not already have cached, it asks a resolver — usually a service run by my internet provider, my router, or a public resolver I have chosen. The resolver does the walking for me.

    First, if the answer is not cached, the resolver asks a root nameserver where to find the nameservers for that top-level domain, such as .com. Next it asks one of those top-level nameservers where to find the authoritative nameservers for the specific domain. Then it asks the domain’s own authoritative nameserver for the actual record — for a website, usually an A record for an IPv4 address or an AAAA record for an IPv6 address. The resolver returns that address to my browser, and only then does the browser connect to the server and start the separate process of loading the page, including the encryption setup for HTTPS.

    Most of the time I never see any of this, because caching makes it fast. Resolvers and browsers remember answers for a period set by the record itself, called its TTL, or time to live. A long TTL means fewer lookups and less load, but slower changes. A short TTL means a move or fix takes effect sooner, at the cost of more frequent queries. When I am planning a server change, I lower the TTL in advance, make the change, and raise it again once the new answer is stable.

    Records Are Not Just for Websites

    The A and AAAA records are only part of the picture. MX records tell other mail servers where to deliver email for a domain. TXT records carry plain text that other systems check — commonly to prove domain ownership or to publish email authentication information that helps receivers judge whether mail claiming to be from a domain is legitimate. CNAME records make one name an alias of another, so a subdomain can follow a service’s own hostname instead of a fixed address. NS records name the authoritative nameservers themselves — the delegation at the heart of the whole system.

    Where DNS Goes Wrong

    In my experience, most DNS trouble comes from a short list of ordinary causes. A record was edited but the old answer is still cached until its TTL expires, so some visitors see the new server and some still see the old one. A name was pointed at the wrong address, or a needed record — especially for email — was deleted during a cleanup. Or the delegation itself is wrong: the registrar points to one set of nameservers while the records were edited on another, so the changes exist but nobody is being sent to them.

    Why This System Has Lasted

    What I appreciate about DNS is that it solves a human problem and a technical problem at the same time, and it does it by delegation instead of central control. I get names I can say out loud, remember, and print. Server owners get the freedom to move machines, change providers, and split services across different companies without changing the public name. The network gets a system that scales because no single server has to know everything.

    Next time a site will not load, or mail stops arriving after a change, it is worth asking the DNS question before blaming the server: what name was queried, what record was returned, who is authoritative for it, and how long ago could that answer have been cached? More often than I expected when I started running servers, the server was fine. The directions to it were the problem.

  • CISA Gave Check Point and UnrealIRCd Users Until Monday to Patch — And It’s Already Being Exploited

    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.

  • NetScaler Again: 28 New Flaws, and One Hits Every Box by Default

    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.

  • The Small Repair You Put Off Becomes the Big Bill


    I have never met a big repair bill that did not start out as a small one I could see coming. A drip under a sink. A noise from a car that only happens on a cold morning. A warning on a computer I click past because the machine still boots. At first it is a small problem I could deal with on a Saturday. Left alone, it becomes the kind of problem that picks its own day — usually the worst one — and charges me extra for the privilege.

    Why I Put It Off, Honestly

    I do not put repairs off because I am lazy, and I do not think most people do either. I put them off because money is already spoken for, because I do not have a free afternoon, and because as long as the thing still works, it is easy to tell myself it is not really broken yet. A car that still drives feels fine. A roof that only leaks in a hard rain feels like a problem for a dry week. Hope is cheaper than a part and quieter than a mechanic, so hope wins for a while.

    There is another honest reason: I do not always know how serious a small thing is. Not every noise is a warning, and not every warning is real. If I paid a professional every time something sounded odd, I would be broke for a different reason. So I wait to see if it gets worse — and sometimes that is the right call, and sometimes that waiting is exactly what makes it worse.

    What Waiting Actually Does

    The pattern is the same whether it is a house, a truck, or a server I run. Small damage spreads. Water does not stay under the sink; it finds the floor and the cabinet and turns a washer into woodwork. A worn part does not wear alone; it makes the parts around it work harder until they wear too. A small software or security problem on a computer does not stay small either — it sits there while everything around it changes, until fixing it means untangling months of other work as well.

    Waiting also takes away my choices. A repair I schedule is a repair I can price, plan for, and do on my terms. A repair that fails on a workday, or on a trip, or in the middle of a storm, is one I take at whatever price and whatever hour it is offered. The work itself is often the same. What I lose by waiting is not just money. I lose the chance to decide when, how, and by whom it gets done.

    Not Everything Is an Emergency

    I want to be careful here, because the other mistake is just as real. Some things can wait, and some things should. A scuff, a squeak that has been checked and is harmless, a cosmetic fix on something that works fine — those are not ticking clocks, and treating them like emergencies is how people get sold work they do not need. Fear is a good salesman. I have learned to ask one plain question before I spend: will this get worse on its own, or will it just stay ugly? Ugly can wait. Worse cannot, not for long.

    That is also where knowing my own limit matters. Some small repairs I can do myself with basic tools and patience, and doing them early is the cheapest money I ever save. Some — brakes, wiring, anything where a mistake puts someone at risk — belong to a professional even when they look small. Paying a pro while a job is still small is not waste. It is almost always cheaper than paying that same pro after my attempt, or my delay, made the job bigger.

    A Practical Way to Stay Ahead of It

    Here is what works for me now. Once in a while I walk the whole list — house, car, computers, tools — and I write down every small thing I have been noticing and ignoring. No fixing, just writing. Then I sort it by three questions: Will it get worse on its own? Will it damage something else if it does? Will it stop me working, driving, or living in the house if it fails?

    Anything with a yes goes to the top, in order of how fast it is moving, and I take care of one at a time as the money allows, starting with the one that is cheap now and expensive later. The rest go on a watch list with a date to look again. That turns a vague worry in the back of my mind into a short, honest list I can actually work.

    I still put things off. Everybody with a real budget does. The difference is that now I try to put them off on purpose, with my eyes open and a date attached, instead of by hoping a small problem will be polite enough to stay small. It rarely is.

  • Apache Just Fixed a 9.8 in HTTP/2 — Update to 2.4.71

    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.

  • Can Congress End a War the President Wants to Keep Fighting?

    Eight months into the war on Iran, voters have said plainly they want it to end, and they handed Congress to the party that promised to push for that. The president has said the opposite: he defends the war, says he has won it, and says it will continue. That sets up the real question for January, and for December too: can Congress actually end a war a president wants to keep fighting — and should it try with the one tool it clearly owns, the money?

    What We Know

    The war began on February 28, when the United States launched strikes alongside Israel, without approval from Congress beforehand, according to a Reuters explainer published November 12. Lawmakers have voted repeatedly since then on war powers resolutions to end the fighting unless the president seeks authorization. One passed both chambers, the administration ignored it, and legal experts, Reuters notes, do not agree on whether it was binding. A Reuters/Ipsos poll this month, reported in that explainer, found 71% of Americans — including 93% of Democrats and 51% of Republicans — want Congress to pass legislation ending the conflict.

    Congress can write into a spending bill that no funds may be used for hostilities against Iran, refuse war funding in the defense authorization bill, and hold hearings with subpoenas. The president can veto any of it, and overriding takes two-thirds of both chambers, so Democrats would need real Republican support. Reuters also reports the president has asked for a large defense increase plus additional war money — a request the incoming majority says it will not approve as written. Funding expires December 11, so this fight arrives soon either way.

    The Strongest Case for Using the Purse to End It

    The strongest case for Congress acting is constitutional, not just political. The Constitution gives Congress the power to spend, and the power to declare war, for a reason: a war that lasts eight months and affects prices and lives at home should not rest on one person’s say-so alone. If the elected branch cannot say no to paying for a war, its war power is mostly words on paper.

    Voters knew this war was unpopular, said so in polling, and then changed who controls Congress in part because of it. Ignoring that would tell people their vote matters for everything except the biggest decision a government makes. Supporters also note that presidents rarely end open-ended wars on their own timetable. Speeches are easy to wait out. Money is not.

    The Strongest Case Against a Funding Cutoff

    The strongest case against is also serious, and it is not just loyalty to the president. A commander in chief has to be able to run an operation without 535 people voting on each move, and a sudden cutoff in the middle of fighting can put the people already deployed at risk. Troops in the field need fuel, protection, and a way home that is planned, not improvised because a funding clause took effect on a date chosen for political effect.

    There is a negotiating point too. If an adversary believes American funding will run out on a fixed public date no matter what happens at the table, it has every reason to wait rather than settle. And there is a governing risk at home: a funding ban attached to a must-pass bill invites a veto, and a veto invites a shutdown, with troop pay and ordinary services caught in the middle. Opponents are right to ask whether a Congress that cannot yet override a veto is promising an ending it cannot deliver.

    The Middle Path: Force an Authorization Vote and Oversight

    Between a blank check and an abrupt cutoff sits the work Congress is built for. Hold the hearings. Subpoena the strategy, the costs, and the legal basis, and make the administration defend them in public. Then force a clean vote on authorization itself — not a symbolic resolution lawyers can argue about, but a yes-or-no question: is this war authorized, for what purpose, and until when? That puts every member on the record, gives anti-war Republicans and fiscal hawks a specific thing to join, and gives the president a fair chance to make his case that the threat requires more time.

    Where I Land

    I land with Congress — but with a dated, responsible end, not an overnight cutoff. The president should have to seek authorization for a war this long, and if Congress will not grant it, funding should wind down on a clear schedule that fully pays for protecting our people and bringing them home safely. That respects the Constitution, the election result, and the troops enough not to strand them in an argument between two branches.

    What I do not support is using a shutdown as the weapon, or pretending a veto-proof majority exists when it does not. Pass the authorization question first, in the open. If the votes to end this war are really there — across party lines, as the polling suggests they might be — that vote is how we find out, and how an ending, when it comes, will actually hold.

  • AI Proved Signal’s Code, Not Just Its Design

    Most software security is testing. You run the code, throw bad inputs at it, and hope the bug you missed is not the one somebody else finds. Formal verification is different. You state, in mathematics, what the code is supposed to guarantee, and then you prove it actually delivers. It is the strongest assurance we have, and so slow and expensive that almost nobody does it for production code.

    That is why I paid attention to what Google DeepMind announced on November 10.

    What happened

    DeepMind says its researchers built a new agentic framework called AlphaProof Code and used it to formally verify the actual code underneath the Signal protocol — the technology behind private conversations in Signal and Google Messages. DeepMind describes this as the first time AI has been used to formally verify a widely deployed cryptographic protocol at this depth, and the first time an implementation like this has been verified at this depth by any method.

    The division of labor matters. Human experts worked with a mix of models to translate Signal’s security goals into formal specifications, and reviewed every one. Then AI agents, powered by Gemini Carbon, did the proving work, generating over six million lines of Lean — the language the proofs are written and machine-checked in. The agents also flagged the small part that needed a second look from a human. DeepMind puts that at about one percent.

    Two details keep this from being just a press release. First, the team did not stop at the design. They proved properties of the compiled code, down to the code that runs on devices — where real flaws often hide, in the gap between a good design and an imperfect implementation. Second, they tested the tester: they put two real, previously fixed bugs back into an isolated copy, and in both cases the system produced a machine-checked proof that the buggy version was insecure. The process took four weeks, on a job DeepMind says historically takes expert teams years. DeepMind is open-sourcing the artifacts.

    Source: Google DeepMind, “Introducing AlphaProof Code,” November 10, 2026 — deepmind.google/blog/introducing-alphaproof-code

    The case for it

    The strongest case is that this attacks the right bottleneck. We have never lacked security properties worth proving. We lacked the man-hours. Proving production code by hand means a few expensive experts spending years on one system, so it happens for a handful of critical pieces and almost nothing else. If AI agents can do the bulk of the proving — the long, mechanical, checkable part — while humans keep the part that takes judgment, deciding what needs to be true, verification stops being a luxury and starts being something ordinary critical software could actually get.

    The checkability is the other half. An agent’s proof here is not an opinion you have to trust. Every proof is checked by Lean. If it is wrong, the checker rejects it. And the target was well chosen: a flaw in a messaging protocol is everybody’s problem at once.

    The case against it

    The honest case against starts with the specification. A proof only proves what was specified. If the security goals were stated wrong, or a property was left out, the proof can be perfect and the conclusion still incomplete. DeepMind says experts reviewed every specification, which is the right process — but the trust has not disappeared. It has moved, from the code to the shorter list of statements about the code. That list is where a reader should spend their skepticism.

    Scope is the second limit. This verifies Signal’s core cryptographic code and the properties specified. It does not prove the whole app on your phone is safe, or that a future version will not introduce a new flaw. Every change needs the work done again. A proof is a statement about one version, under stated assumptions — not a permanent clean bill of health.

    Third, this is a research result from a frontier lab, not a tool I can download and run on my own projects this weekend. DeepMind released the artifacts, not a general product. The gap between “a top lab did this once” and “this is routine practice” is still real.

    Where I land

    I land firmly on the side that this matters — with the limits kept in plain view.

    Most AI news is a model scoring a few points higher on a test. This is different in kind. AI agents did sustained, verifiable work — work whose output a machine can independently check — on code that protects real conversations, and the system proved it could tell good code from buggy code when deliberately handed the buggy kind. That is the pattern I want more of: AI doing the volume, humans doing the judgment, and a checker standing over both.

    What I will watch next is boring on purpose. Does anyone outside DeepMind build on the released artifacts? Does the approach get applied to a second, unrelated system, by a smaller team? And does the cost come down far enough that verifying code in medical devices or grid software — examples DeepMind itself points to — becomes an expectation instead of a research event?

    If that happens, November 10 will look like the week proving software stopped being something only the richest projects could afford.

  • CISA Says Six Flaws Are Being Exploited Now — Outlook Is the One Most People Missed

    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.