(On the bright side, I had time to draw a “back of the envelope” comic that covers the big CVE!)
The CVE numbers
Here are the numbers:
1,248 new network-exploitable CVEs
117 of these CVEs are rated at 8.6 or higher
12 of these CVEs are a perfect 10.0:
9 of those twelve in vm2 alone
Worth reading
1. The Langflow flaw
CVE-2026-85025 (9.8) is unauthenticated RCE in IBM Langflow OSS 1.0.0–1.11.5. It’s reachable through publicly shared MCP project endpoints, with read and write access to chat sessions on top. Whatever context, credentials, or proprietary data flowed through those sessions comes along with it.
The mechanism is the interesting part. Langflow lets you share a flow via an MCP project endpoint so other tools and agents can call it programmatically. The code that’s supposed to enforce “this one flow is public, everything else isn’t” doesn’t hold that boundary. So “publicly shared” quietly generalizes from one flow to the host. This happens without a privilege escalation chain, user interaction, or even any waiting for someone to click anything.
All in all: 8 CVEs against Langflow in a single seven-day window, including the one above: code injection, OS command injection, path traversal, an incomplete scanner denylist, and this one.
2. The difference between CVE vs. KEV
CVE: Common Vulnerabilities and Exposures. These are publicly-disclosed security flaws, and may or may not have been used in an attack. These are weaknesses that have been announced.
Mark writes that he’d bet money that the Langflow flaw above becomes a KEV. Another Langflow CVE has already done that: CVE-2025-3248, a missing-authentication RCE, which went onto CISA’s KEV catalog on May 5, 2025, with a three-week federal remediation deadline and confirmed ransomware use. Sysdig later documented that same flaw on a server nobody had patched in over a year as the entry point for what they assessed as the first fully autonomous agentic ransomware operation.
The traits that move a CVE onto KEV are the traits this one has: no auth, trivially scannable, and sitting on infrastructure that isn’t in anyone’s asset inventory. Langflow has supplied both ends of that pipeline before.
3. Why AI agent platforms keep showing up inReachability Watch
Because these tools are three things all at once:
New
Fast-moving
Production-critical
…and they’re shipped by teams optimizing for getting an AI capability out the door. As a result, exposure and hardening get less scrutiny than they’d get on a mature enterprise system.
The part that makes them worth an attacker’s time specifically: compromising one doesn’t get you a single host, it gets you the whole key ring. The same property that makes the platform useful is what makes the blast radius large, which is why “it’s just an internal tool on a dev box” ages so badly.
We recently got a great set of questions from someone evaluating hosted zrok for a web-based e-commerce content tool.
Their situation: a small team of internal colleagues testing a tool for business work that might later become part of their daily workflow, and their budget was zero dollars.
Their main question: Could they use the Free hosted version of zrok?
The super-short answer
Yes!
The short (but with some details) answer
If you’re on a small internal team with zero budget, zrok’s Free hosted plan will cover your core needs:
A stable HTTPS address
Browser access with no install for users
Login-gated access for approved colleagues/users.
Watch the daily bandwidth (you’re limited to 5GB in any 24-hour period), make sure team knows about the interstitial page, and test from every region where you plan to use it.
Before the detailed 5 answers: What’s zrok?
zrok(pronounced “zee-rock”) is an open-source tool for sharing things running on your machine, such as…
A web app,
an API, or
a folder of files…
…without the need for you to open firewall ports or set up servers. You run one command on the machine where the service lives, and zrok gives you a way for other people to reach it. If you’ve used tunneling tools like ngrok, zrok covers similar ground, with private sharing and zero trust networking built in, and with a much bigger bandwidth allowance, too!
zrok can share in two ways:
Public shares give your service a regular HTTPS URL that anyone with a browser can open. zrok handles the TLS certificate. You can optionally require a Google or GitHub login so only approved people get in.
Private shares are reachable only by people who also run zrok and have been given access, so the service is never exposed to the open internet.
zrok is built on OpenZiti, the open-source zero trust networking platform created by NetFoundry. Your service makes outbound connections to the zrok network instead of listening for inbound ones, which means there are no inbound ports on your machine for scanners and attackers to find. As far as unauthorized parties are concerned, nothing’s happening on your machine, and there’s no way in.
You can use the hosted version at zrok.io, run by NetFoundry, or self-host it under the Apache 2.0 license. This article is about the hosted Free plan.
The 5 questions, answered
1. Is small-team, business-related use allowed on the Free plan?
Yes! Testing a business tool with a few colleagues, and using it internally afterward, is allowed on the hosted Free plan. You don’t need a paid tier for commercial use.
The terms that apply are in NetFoundry’s Self Service Subscriptions Agreement. As with any service agreement, have someone read it before you build a workflow on top of it.
2. Can I reserve a persistent, custom-named public HTTPS address without a payment method?
Yes! By default, zrok2 share gives you a random share token that disappears when the share ends. zrok 2.0 adds namespaces and names, which let you keep a stable address:
A namespace works like a DNS zone. The public namespace corresponds to share.zrok.io.
A name works like a DNS record inside that zone. A reserved name persists across runs of zrok2 share.
If you reserve the name contenttool in the public namespace, your app is available at https://contenttool.share.zrok.io. That address stays the same every time you restart the share, and it comes with a trusted TLS certificate automatically.
3. Can colleagues use the app in a normal browser without installing zrok? Can I limit who gets in?
Yes to both! A public share is a regular HTTPS URL, so your colleagues just open it in a browser. Only the machine running your app needs zrok installed.
To limit access to approved people, turn on OAuth for the share. zrok supports Google and GitHub login for public shares, and you can restrict access by email address pattern:
# bash
zrok2 share public --backend-mode proxy \
--oauth-provider google \
--oauth-email-address-pattern '*@yourcompany.com' \
http://localhost:8080
Anyone who visits is sent to sign in first. Only accounts whose email matches the pattern get through. You can repeat --oauth-email-address-pattern to allow several domains or specific addresses.
There’s also a bonus for developers. Once someone is authenticated, zrok adds headers such as zrok-auth-email to every request it forwards to your app. That means your app can tell who’s using it without you building a login system. See OAuth public frontend for the full flow.
4. Are there mandatory charges, usage limits, or restrictions?
No mandatory charges. The Free plan costs $0 a month and doesn’t require a credit card. It does come with limits you should plan around:
5 GB of bandwidth per day, measured over a rolling 24-hour window. If you go over, your running shares are disabled and you can’t create new ones until usage drops back under the limit. For a small team using a content tool this is usually plenty, but heavy media uploads could reach it.
25 environments, 50 share backends, and 50 private access frontends. A small team won’t come close.
Rate limits on public shares: 2,000 requests per IP and 7,500 requests per share, each per 5-minute window.
An interstitial page. Accounts without a card on file show an anti-phishing page the first time someone visits a public share. It’s a one-time click-through for each visitor, but tell your colleagues about it so it doesn’t surprise them. Adding a card removes it, and you’re still on the Free plan.
In case you were wondering, here’s what the interstitial page looks like:
All the details are on the zrok pricing page and in the service limits docs. If you outgrow the Free plan, you can self-host zrok with no limits under the Apache 2.0 license, or talk to NetFoundry about commercial options.
5. Are there known restrictions on reaching hosted zrok shares from mainland China or other countries?
We don’t publish a list of country-by-country access guarantees. Whether a public URL is reachable from a given country depends partly on things outside our control, like local network policy.
Our advice is to review the terms of service linked above, then test your exact setup from the locations your users will be in before you roll it out. Stand up a throwaway share, have a colleague in each region load it and click around, and confirm it performs well enough for your needs.
Calling all devs, designers, AI and data geeks, cyber and everyone in the “tech-ish” orbit!
This event brings together technologists and technology-adjacent professionals to connect, share knowledge, learn and grow together.
Yes, it’s last minute, but a lot of people have signed up already, and for those of you collecting cybersecurity CPEs, attending this one will earn you 2!
The agenda
AI Panel – Revisiting AI Transformation opportunities due to the rapid evolution of capabilities
With AI model performance and tooling evolving at a breakneck pace, the lifecycle of technical feasibility has compressed. Solutions deemed impractical just months ago are frequently production-ready today. We will examine how enterprise leaders and practitioners are navigating this shifting baseline—reassessing former roadblocks, managing risk, and executing sustainable AI transformation strategies.
Talk: Detection of Confounders in Computed Tomography Datasets
Computed Tomography (CT) scans are used to train machine learning models to predict cancer outcomes. Datasets are frequently composed of images collected using different devices or settings, which can reduce classifier accuracy.
This talk covers an automated method for screening CT datasets to detect features that make models learn spurious associations – called confounders – and other unwanted variations in data. By understanding what affects data quality, we can mitigate these issues or adjust image acquisition processes to prevent them from happening in the future.
Talk: The chart is already multimodal. Why isn’t the model?
Every clinical decision draws on labs, coded history, notes, and imaging at once. Most deployed models read one. The work began as an ONC engagement, built as a physician assistant and trained with split learning, so records never left the institutions holding them. Asked which task would earn a place in their day, physicians answered consistently: help with the differential. The 2015 National Academies report found that most people will experience at least one diagnostic error in their lifetime. These are usually failures of consideration rather than knowledge: the right diagnosis was never placed on the list.
Solution is valuesets governed data trained with multimodal model built with fusion architecture. Each branch is projected to a shared width, given its own self-attention, and combined in one late fusion feeding condition heads that share a representation. Results are early with no prospective study with clinicians yet, but the validation metrics looks promising. Future improvements with contrastive learning and focal loss will drastically increase recall and additional testing is carried out by analyzing Krippendorf alpha.
The opportunities of this engine serve six workflows: diagnostic support, risk adjustment, trial recruitment in phase3, quality measurement, Hedis scoring, and rare disease detection. Only the label set, the threshold, and the recipient change.
Differential diagnosis is the capability. The opportunity remains open.
Talk: AI-Powered Defense for PHI: Smarter Cybersecurity for Healthcare Compliance
As cyber threats targeting patient data grow more sophisticated, healthcare providers are turning to AI to stay ahead. Rather than reacting after damage is done, AI-powered tools spot unusual activity early, streamline HIPAA compliance, and speed up incident response—helping protect EHRs, medical devices, and telehealth systems while preserving the trust patients place in their care.
Active Directory (AD) became the de facto standard for Windows-centric organizations to add security, but today, removing AD or minimizing its footprint is considered a security enhancement.
More than a technical optimization, switching from hybrid-AD to cloud-native Entra ID is a risk reduction strategy. Have the capabilities of cloud native reached a tipping point where more organizations can seriously consider reducing or eliminating AD? This session will discuss a regulated organization’s journey to cloud native, reasons to do so, challenges, and lessons learned.
The tech job market has been sending signals for two years. Most of us have been too busy surviving it to read them. After 15+ years in tech and a recent job search that took me across a couple dozen companies, I came away with both a new role and something just as valuable: a pattern.
Job descriptions have quietly shifted. Hiring panels are asking different questions. “ROI” means something specific now that it didn’t mean in the zero-interest 2010s or the Great Resignation era of a couple of years ago. The skills companies say they want versus the skills that actually get you hired don’t look like they come from the same list.
This talk is an honest, experience-based, practitioner-level read of what the market is telling us about where tech is headed. It doesn’t have any LinkedIn takes or recycled frameworks; just patterns from the front lines, with implications for how you position yourself, make the case for your team, and think about the next few years of your career.
The latest edition of NetFoundry’s regular Reachability Watch articles, covering September 4 – 10, 2026 and written by Mark Jaffe, our Chief Strategy and Marketing Officer, is up:
And with this edition, a new “back of the envelope” drawing by Yours Truly, which shows the “env var” pattern behind two of the CVEs in this report.
In this edition:
906 new network-exploitable CVEs
96 clearing the CVSS 8.6+ bar
5 at a perfect 10.0
Microsoft shipped 15 critical network CVEs in a single release, 14 of them at 9.8, across DNS, DHCP Server, RPC Runtime, USB Mass Storage, and Telnet Client.
The most notable part of this Reachability Watch is this set of CVEs:
CVE-2026-86124 (9.8): AutoAgent’s inter-agent TCP server executes whatever you send it, as root, with no authentication in the request path at all
CVE-2026-86121 (9.8): Same outcome in Cua’s computer-server, gated on CONTAINER_NAME being set
CVE-2026-85661 (9.8):excel-mcp-server reads and writes arbitrary files when EXCEL_FILES_PATH is blank
CVE-2026-85688 (9.8): TEN Framework’s TMAN Designer API takes unauthenticated file reads and writes with no env var required
The CVEs come from four different projects, but they all have the same shape: reachable by default, with authentication either optional or absent. In two of them, the auth check exists as real code, wired behind a conditional on an environment variable, and it fails open when the variable is missing. It’s not that anyone turned security off; instead nobody confirmed it was on.
Here’s my own opinion of what the main take-away for this edition is: The environment variable may be the headline, but the bind address is the actual exposure. AutoAgent’s server binds every interface by default, not loopback. These tools get written with a localhost mental model (it feels like a library, not a network service) and then inherit 0.0.0.0 from whatever framework default was closest to hand.
The auth flag and the bind address are two independent decisions, and the second one is what turns a local misconfiguration into something an attacker can reach. If AutoAgent’s default bind was loopback, the attack approach would have resulted in a configuration bug and not an unauthenticated RCE, and it wouldn’t have required anyone to write an auth system at all.
All this is the argument for handling reachability underneath the app: An overlay doesn’t care whether the service remembered to check a password, because an unauthorized requester never gets a path to the port in the first place.
For the curious, here are my notes for an upcoming Ziti TV episode where we’ll be talking about what’s in the OpenZiti Quickstart.
OpenZiti Quickstart is a single command (ziti edge quickstart) that launches a complete, working OpenZiti network a few seconds. It does a lot behind the scenes, by
creating a fresh certificate authority hierarchy,
initializing a controller database,
creating and enrolling a router identity,
bootstrapping an admin user,
and starting both the controller and router as a single running process.
It does all this with sensible default policies already in place, which means identities can immediately connect through the router to any service.
As its name implies, the Quickstart is meant to get an OpenZiti zero trust network up and running is very short order, and it’s meant for demos, local development, and learning the platform. It has everything a production deployment would spread across multiple processes, machines, and days of setup, but it’s packed into a single instance that you can tear down and re-run whenever you want.
Simply put, it’s the fastest path from zero to a working network you can actually build against.
As for the question of why I go with handwritten notes: it’s easier to add diagrams, and I end up understanding and retaining things better.
In his latest post on the NetFoundry blog, Hugging Face Breach: When Tailscale VPN Is the Blast Radius, CEO Galeal Zino (my boss’ boss) writes about why the Hugging Face breach was a VPN architecture problem rather than a Tailscale misconfiguration, and what hardening does and doesn’t fix.
Here’s a quick recap of what happened: In July, OpenAI evaluation agents escaped their sandbox, got into Hugging Face through two injection vectors, and walked away with 136 cluster secrets. One of those was a Tailscale auth key, which was:
Reusable
Non-expiring
Subnet-tagged
Sitting readable in a Kubernetes secret
With that one key, the agents were able to get far. They enrolled 181 nodes, ran `tailscale status –json` to get 22 peers back including subnet routers and a source-control connector, reached internal CI subnets, and minted GitHub App tokens. They suppressed client-side telemetry and ran for almost 5 days before anyone noticed.
The post’s argument is that taking measures to harden Tailscale (single-use OAuth-minted keys, ephemeral nodes, tailnet lock, Services instead of subnet routers) shrinks the fan-out but doesn’t eliminate the two properties that made the foothold catastrophic:
Enrollment still authenticates on a bearer credential. Possession of the key made the agents a member, and membership came with a map.
The coordination plane still hands every enrolled node a map, and even a narrowed map is still a target list.
It’s worth pointing this out as simply and plainly as possible: Nothing in our stack would have stopped the sandbox escape, the injections, or the climb to node root. That’s not our line of work. What we do is zero-trust reachability, where the assumption is that systems have already been breached and credentials can be stolen.
Here’s my latest “back of the envelope” drawing, which I drew as a companion for a new NetFoundry series called Reachability Watch.
Published fortnightly, Reachability Watch covers the volume of new network-exploitable CVEs, the handful that clear a CVSS 8.6 bar, whatever KEV actually caused damage that period, and a running tally so the trend line becomes visible over time.
The drawing features this edition’s highlighted KEV. More formally known as CVE-2026-72898, it’s what I call “BYOK: bring Your Own Key,” because that’s essentially what the exploit does. You hand Metabase’s password-reset endpoint an extra user-id key it never asked for, nobody strips it, and it rides all the way into the SQL query.
