We checked one host against this week's exploited CVEs with Lattice: two to verify, one exposure to fix, one patch to apply

Ten new vulnerabilities went on CISA's list of known exploited CVEs between 24 and 30 October 2026. The usual response is a list of product names, and you are left to work out which of them you run. This note shows the other half: taking that list to one real machine, ours, and ending with four things to do.

The issue: a list is not an answer

A list of exploited CVEs answers "what is being attacked". It does not answer "does that touch my machine", and the second question is the one with a deadline. CISA gives federal agencies a due date on each entry, and the shortest in this batch is 31 October. Most of the work in answering is not clever. It is looking up each CVE, finding which versions are affected, and comparing that with what is installed.

Lattice is our public, read-only graph of cybersecurity knowledge, built for that lookup. It holds the records; it does not look at your systems, and it did not look at ours. We read the host's package list ourselves and matched it against the records, mostly by their description text, so each match below is a judgement we made, not a scan result.

The host we checked

• Ubuntu 26.04 on a 7.0 kernel, with Docker containers, a business web application that faces the internet, a local model runner, a browser and a mail client.
• Graph snapshot built on 30 October 2026 at 23:11 UTC, against version 2026.10.30 of CISA's exploited-CVE catalog.
• Window: the seven days from 24 October 2026.

How the check runs

Risk on this host

Ten entries came in. Two touch this machine, and neither is yet a confirmed hit: both need a check of how Ubuntu packaged the fix.

Two more findings sit outside the exploited list but belong in the same hour. The first is a real exposure: the internet-facing business web application is several releases behind the fix for a flaw that lets any signed-in, low-privilege user read records they should not see (CVSS 6.5). It needs a login, which is why it is not on CISA's list, and it is the one item here that we have to fix rather than verify. The second is an update already waiting: the browser and mail client are one major version behind.

As-is, in numbers

The 174 is a word search and we say so because it is the number most likely to be misread: a mention of Firefox in a description is not a flaw in the Firefox build that is installed.

How to do the same with Lattice

You need an AI agent that can talk to Lattice over MCP, a key, and a list of what you run. The agent does the lookups; you supply the inventory and make the match.

# 1. Connect an agent to Lattice (the key comes from the access form)
claude mcp add --transport http lattice https://lattice.namiq.io/mcp --header "X-API-Key: YOUR_KEY"

# 2. Give it your inventory, then ask, one CVE at a time:
#    "Look up CVE-2026-111497. Give me the CISA entry and the NVD entry,
#     the affected versions as stated, and say where each fact comes from."

# 3. On the host, collect what you actually run
dpkg -l | grep -i -E 'brotli|sqlite|polkit'
uname -r
snap list

Three habits make the answer worth trusting. Ask for the source of every fact. Treat a link marked inferred as "likely", not "is". And when the graph returns nothing for a product, write "the graph has nothing on that", not "not affected". Our guide for analysts goes through the same four questions on a worked CVE.

• A new CVE, an agent, and four questions →How to read what comes back, including the gaps.
• Connect an agent to Lattice →Snippets for Claude Code, Claude Desktop and other clients.

What to look at: the four actions

Name both snaps in the last command. A bare snap refresh also refreshes the Docker snap, and on this host that has restarted running containers before.

The four SQLite memory-corruption flaws and a low-scoring polkit flaw are local-only and low risk here. We are watching for Ubuntu's patches and doing nothing until they ship.

What this check cannot tell you

• A match on description text can miss a product the description names differently, and can flag one that does not apply. The two verify items are exactly that.
• Ubuntu backports fixes without changing the version number, so "1.2.0 is in the range" is a reason to read the changelog, not a finding.
• The graph is a snapshot. A CVE added tomorrow is not in it.
• Not being on CISA's list does not mean nobody is exploiting a flaw. The web application item is the example.

What's next

• Run the two changelog checks today, and the kernel one before 31 October.
• Update the web application, then re-run its version check and note the date.
• Repeat the check every week, on the new additions only. It takes the same six steps, and the inventory stays the same unless you change what you run.
• For a business, the harder part is the inventory, not the lookup. If you have no list of what runs where, that is the first thing to build.

• Brotli CVE-2026-111497 →Which versions fix it, and where Brotli hides in an estate.
• Linux kernel CVE-2026-46300 →What to patch in what order.
• Today's mission →The week's exploited CVEs in deadline order.
• The IT check →Where your own estate stands, which a reference graph cannot see.