Tenable Patched Eleven Bugs in Security Center. A Metasploit Contributor Published Exploits for Exactly the Top Three. The Scanner Holds Your Map and Your Credentials.
- Patrick Duggan
- 5 hours ago
- 8 min read
On August 13, 2026 Tenable published advisory TNS-2026-22 and shipped Security Center 6.9.0. It fixes eleven first-party vulnerabilities in versions 6.8.0 and earlier, including two rated 9.9.
Ten days later a well-known Metasploit community contributor published working proof-of-concept code for exactly three of the eleven — and the three he picked are the two 9.9s and the highest-scoring 8.8.
Our exploit harvester collected all three within about a day of each appearing. None of the eleven is in CISA's KEV catalogue, so there is no federal deadline, no catalogue entry, and nothing telling you this is urgent.
Here is why it is, and the argument is not about severity scores.
The scanner is the blast radius
Tenable Security Center is the platform enterprises use to find vulnerabilities. Think for a second about what has to be inside it for that to work.
A complete map of every weakness in your estate. Which hosts are unpatched, which versions they run, how long they have been exposed, and which of them are internet-facing. That is the document an attacker would otherwise spend weeks of noisy reconnaissance assembling, and it is sitting in one application, already assembled, already prioritised, and helpfully sorted by exploitability.
And the credentials. Authenticated scanning is the whole reason organisations buy this tier of product — credentialed scans see what unauthenticated scans cannot. So Security Center stores privileged accounts for the systems it scans, across the estate, by design. Domain accounts, SSH keys, database logins, API tokens.
Compromise the scanner and you do not get a host. You get the target list and the keys to work through it, at which point every other control you own is being evaluated against an attacker who knows exactly where you are weakest and is arriving with legitimate credentials.
That is what makes an authenticated command-injection bug in this specific product worth an evening of your attention, when the same bug in a departmental web app would not be.
What is actually in the advisory
Eleven first-party CVEs, affecting 6.8.0 and earlier, fixed in 6.9.0:
CVE | CVSS | Class | Auth |
[CVE-2026-19681](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-19681) | 9.9 | OS command injection | Yes |
[CVE-2026-19626](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-19626) | 9.9 | Remote code execution | Yes |
9.0 | OS command injection | Yes | |
[CVE-2026-19679](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-19679) | 8.8 | OS command injection | Yes |
8.8 | Local privilege escalation | Yes | |
8.1 | Privilege escalation | Yes | |
7.2 | OS command injection | Yes | |
7.1 | SQL injection | Yes | |
5.3 | Brute-force enumeration | No | |
4.9 | SQL injection | Yes | |
4.3 | Improper access control | Yes |
The three in bold are the ones with public exploit code. The same release also bundles fixes for eight curl CVEs (upgraded to 8.20) and an underscoreJS issue.
Five separate OS command injection findings in one advisory is itself a finding. That is not one mistake — that is a pattern in how the application shells out.
"Authenticated" is doing a lot of work in that table, and it should not comfort you
Ten of the eleven require authentication, and the reflex is to file that under not urgent.
Security Center is a multi-user platform. It has analyst accounts, auditor accounts, read-only accounts for people who just need to pull a report for a compliance questionnaire, and service accounts for integrations. In a real organisation that is routinely a dozen or more people with a valid login, most of them low-privilege by design.
CVE-2026-19681's CVSS vector is AV:N/AC:L/**PR:L**/UI:N/**S:C**/C:H/I:H/A:H. Privileges Required: Low. Scope: Changed. In plain terms: a low-privilege user of the scanner reaches arbitrary command execution on the underlying operating system, and the impact crosses out of the application's own security boundary onto the host.
The threat model that matters here is not an external attacker with no access. It is a contractor account, a departed employee's login that was never disabled, a compromised analyst laptop, or the read-only auditor credential someone pasted into a shared vault three years ago. Any one of those is now a path to the host that holds your estate's credentials.
The PoC selection is the prioritisation nobody gave you
This is the part we think is genuinely useful, and it is the reason we run a harvester rather than just reading advisories.
Eleven CVEs landed at once. Tenable, correctly, published them all with scores. Nothing in that advisory tells you which ones a competent attacker will actually build first — severity is a model of impact, not a prediction of effort.
Then somebody answered the question by acting. Over August 23 and 24, the repositories appeared:
Repository created | CVE | CVSS |
2026-08-23 13:12 UTC | POC-[CVE-2026-19681](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-19681) | 9.9 |
2026-08-24 10:33 UTC | POC-[CVE-2026-19679](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-19679) | 8.8 |
2026-08-24 12:42 UTC | POC-[CVE-2026-19626](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-19626) | 9.9 |
All three in Python. All three from h00die, a GitHub account active since 2011 with a long history of offensive-security work and a well-documented record as a community contributor to the Metasploit Framework — modules, password-cracking integration work, and testing scripts.
That last detail is the one to weight. A proof-of-concept from someone who writes Metasploit modules has a materially shorter path to becoming one, and a Metasploit module is the step that converts "authenticated RCE, requires skill" into a commodity capability available to anyone who can type use exploit/. We are not claiming a module exists — we checked and we are not going to assert one into being. We are saying the provenance of these three PoCs raises the probability, and that is a planning input.
So patch all eleven, but if you have to stage it: 19681, 19626, 19679, in that order. A researcher has already told you which ones are worth the effort, by spending his.
Our harvester picked all three up on August 24 — 12:00, 12:01 and 18:01 UTC — within roughly a day of each landing. That is not a lead claim over anyone; there is no catalogue entry to be ahead of. It is early warning on a product that has none.
We went and counted the exposure. Then the data killed our own number.
The advisory does not come with an exposure figure, so we pulled one from Shodan's free count endpoint. The first pass looked alarming: 241 hosts serving a Tenable-branded management console, reachable from the open internet. 201 in the United States. 237 on port 443. Roughly 92% sitting on a single ASN — AS16509, Amazon.
That is a publishable headline and it would have been wrong.
We faceted on the TLS certificate subject before writing it up, and the population resolved almost entirely into Tenable's own infrastructure:
Certificate subject | Hosts |
*.dev.app.ermetic.com | 149 |
*.app.ermetic.com | 67 |
fedcloud.tenable.com | 8 |
*.stg.app.ermetic.com | 3 |
sensor.cloud.tenable.com | 2 |
*.labs.university.tenable.com | 2 |
*.cloud.tenable.com | 1 |
Ermetic is the cloud-security company Tenable acquired in 2023, and its app estate is Tenable-operated. Add the tenable.com subdomains and roughly 232 of the 241 are the vendor's own SaaS, development and staging estate — exactly what you would expect to be internet-facing, because that is what SaaS is.
The genuine customer-operated remainder visible in the facets is a handful of hosts, including one university dashboard and a couple of corporate subdomains. We are not naming them; exposure data are victims, not threats, and pointing at somebody's login page serves nobody.
So the honest finding is the opposite of the scary one: internet-exposed customer Security Center consoles appear to be rare. Most organisations running this product have it where it belongs — inside, not answering the internet. That is good news and we would rather report it than bury it because it is less dramatic than the number we started with.
We are including the wrong version here deliberately. A naive Shodan count, published without faceting on the certificate, would have produced "240 internet-exposed vulnerability scanners" — a number that is technically derived from real data and substantively false. The count was not the evidence. The facet was. We wrote a post yesterday about an instrument reporting green while the operator failed to read it; this is the same discipline applied one step earlier, and it cost us the better headline.
The MSP multiplier — an argument, not a measurement
Here is the part we cannot measure and will not pretend to.
The blast-radius argument above scales with how many estates one console covers, and there is a category of operator where that number is not one. A managed service provider running a single Security Center scans many client environments — which means its credential store holds privileged accounts for every downstream organisation it serves, and its scan results are a consolidated weakness map of all of them.
For that operator, an authenticated command injection is not a compromise of one company. It is a compromise of the portfolio, and the downstream clients — typically smaller organisations with no security team of their own, who bought managed services precisely because they could not staff this — have no visibility into the decision and no way to check.
That is the same shape we keep writing about: the soft middle holds the trust for everyone on both sides of it, and the accountability line runs somewhere else entirely.
We have no data showing MSP-operated consoles among the exposed set, and we looked. This is a risk argument from how the product is deployed, not a finding. If you are an MSP running Security Center, you already know whether it applies to you, and the answer determines whether 6.9.0 is a routine patch or a portfolio-wide incident-prevention exercise.
What to do tonight
Upgrade to Security Center 6.9.0. Everything at 6.8.0 and below is affected.
If you cannot upgrade this week, audit who can log in. Every account, every integration service account, every dormant analyst login. Ten of eleven bugs need a credential — so the interim control is reducing how many credentials exist, and that is something you can do in an afternoon without a maintenance window.
Then rotate the scan credentials, and treat that as separate work. If your Security Center has been reachable by anyone you would not vouch for since August 13, the stored credentials for every scanned system are in scope. Rotating those is a bigger job than patching the appliance and it is the one people skip, because the appliance being patched feels like the incident is closed.
And put the scanner inside your own threat model. Most organisations treat security tooling as part of the defence rather than part of the attack surface. It is both, and it is the part with the highest concentration of privilege per host in the entire estate.
Capped where we always cap it at 95 percent: we have no evidence of exploitation in the wild, none of these are in KEV as of today, we have not run the PoCs, and h00die is a legitimate security researcher publishing research — nothing here suggests otherwise. Our first-party contribution is the collection timestamps, the selection observation, the Shodan facet work above — including the number we had to throw away — and the argument about blast radius. The MSP section is explicitly reasoning, not measurement.
Sources
Tenable advisory TNS-2026-22, Security Center 6.9.0, released 13 August 2026; eleven first-party CVEs affecting 6.8.0 and earlier, plus bundled curl 8.20 and underscoreJS updates. CVE-2026-19681 CVSS 9.9 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, published 14 August 2026.
Repository creation timestamps and PoC collection are from GitHub and our own exploit-harvester respectively. h00die's Metasploit contribution history is documented across Rapid7's Metasploit wrap-up posts and his own public repositories.
If you run Security Center and you go and count how many accounts can actually log into it, I would like to know the number. My guess is that it is higher than whoever owns the platform thinks it is, and that gap is the whole risk here. Rate this post below.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=tenable-patched-eleven-bugs-in-security-center-a-metasploit-contributor-published-exploits-for-exac
Comments