Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE Program

  • In six of today’s ten stories, the authoritative record has nothing to say at all

    In six of today’s ten stories, the authoritative record has nothing to say at all

    The most consequential item on the site today is cPanel’s parked-domain flaw. The vendor’s own advisory says an authenticated account holder who can add a parked or addon domain “can create arbitrary files on the server,” and that “successful exploitation leads to code execution as the root user, giving an attacker full control of the server and every account, website, and database on it.” Fixed builds are named across five branches, so this is a task you can finish tonight. It outranks the bigger-sounding story — Boston Scientific told the SEC that a cybersecurity incident caused a global disruption to its operations, and the clinical detail is worse than the filing, but almost nobody reading this can act on it. What decides the ranking is the second half of the cPanel item: three days after the advisory, CVE-2026-65643 has no record at NVD or the CVE Program, so nothing in your scanner or your ticket queue will raise it on its own. Tonight’s one fixable catastrophic flaw is the one your tooling is guaranteed to miss.

    The day had a thread, and it is yesterday’s failure mode inverted. Yesterday the authoritative record said the wrong thing; today, in six of ten stories, it says nothing at all. cPanel’s CVE has no record. AjaxPro’s record, now on a federal clock, still says no fixed version exists, though the maintainer shipped deserialization controls in November 2021. Two CVE records describe unauthenticated root code execution on the Unitree G1 EDU humanoid, one of them from Bluetooth range with no pairing, and neither the records, the CNA, nor Unitree names a firmware version that fixes it. The argocd-mcp flaw scored 10.0 on Saturday had a public GitHub advisory, and a fix, eighteen days before any CVE was attached to it. libuser’s only modern score says the bug cannot touch confidentiality or integrity, and NVD has published no primary v3 score of its own to arbitrate. And Anthropic’s warning to Claude users exists only as an email, with nothing on the newsroom or the status page.

    Order of business after cPanel. WPMU DEV Dashboard’s second unauthenticated admin bypass this month, CVSS 9.8, fixed in version 5.0.2 on August 24 and hitting exactly the Hub-connected sites the first one missed. Then MCP servers: VulnCheck published thirteen CVEs against thirteen separate projects inside a thirteen-second window on August 27, and the recurring defect — bind to every interface, accept sessions without credentials — is the one that earned argocd-mcp its 10.0. Then the two KEV additions that share a September 9, 2026 federal deadline, libuser and AjaxPro; ten days out rather than this week, and in both cases what an agency has to work around is the record, not the code. Unitree G1 operators have no patch to apply and should treat network and radio range as the only control they have.

    Four items moved without handing anyone a task, though one is worth an hour on your endpoints. Anthropic says commodity infostealers — Vidar, LummaC2, StealC, RedLine, and Acreed on Windows, Atomic Stealer on macOS — are lifting Claude sessions off users’ machines, which makes it a workstation problem rather than a vendor one. An extortion group calling itself FulcrumSec put 86 GB, a sample, and a claimed access path behind the Manchester Airports breach. Socket found nineteen wallet-draining Chrome and Edge extensions, five of them bought from the developers who built them. And at Boston Scientific, every patient implanted since August 25 is storing data instead of sending it.

    Still open. CVE-2026-65643 still has no record, and nobody has said which CNA holds it. MAG’s statement, dated August 27 and not updated since, lists four field types; FulcrumSec’s sample shows itineraries and payment amounts, which are not among them. Anthropic has neither confirmed nor disputed the email, and nobody outside the company knows how many accounts received it. No one has named fixed firmware for the Unitree G1. Boston Scientific says the timeline for a full restoration is not yet known. And the September 9 deadline falls a week from Wednesday.

  • VulnCheck published thirteen MCP server CVEs in thirteen seconds, and the argocd-mcp record that followed on Saturday scores 10.0

    VulnCheck published thirteen MCP server CVEs in thirteen seconds, and the argocd-mcp record that followed on Saturday scores 10.0

    Thirteen Model Context Protocol CVE records went into NVD from a single assigning authority inside a thirteen-second window on August 27; a fourteenth, scoring 10.0 against Argo CD’s MCP server, followed on August 29 — and the flaw it describes had a public GitHub advisory, and a fix, eighteen days earlier with no CVE attached.

    What happened

    On Saturday, August 29, 2026 at 2:16 p.m. UTC, NVD published CVE-2026-82456 against argoproj-labs’ argocd-mcp. VulnCheck is the assigning authority and supplied both scores: CVSS 4.0 base 10.0 and CVSS 3.1 base 10.0, the v3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The weakness is CWE-1327, binding to an unrestricted IP address. The record’s description, in the CNA’s own words: “argocd-mcp 0.8.0 binds its HTTP transport to every network interface and accepts MCP sessions without requiring caller credentials when ARGOCD_API_TOKEN is configured.” An attacker who reaches the port initializes a session with no credentials and then operates Argo CD with the operator’s stored token, creating applications and synchronizing attacker-supplied manifests into a Kubernetes cluster.

    That record is two days old. What it led us to is four days old, and the dates matter, so here they are plainly. On Thursday, August 27, 2026, between 5:20:51 p.m. and 5:21:04 p.m. UTC, VulnCheck published thirteen CVE records against thirteen separate MCP projects: CVE-2026-81091 through CVE-2026-81102, twelve consecutive identifiers, plus CVE-2026-81735. The affected projects are mcp-use, mcp-go, Apify’s actors-mcp-server, mcp-router, pg-aiguide, ToolUniverse, rails-mcp-server, Telnyx’s telnyx-mcp, Timescale’s tiger-slack and tiger-gh-mcp-server, Airtable’s airtable-mcp-cli, Dropbox’s mcp-server-dash, and ByteDance’s UI-TARS-desktop.

    Severity Daily published a page on CVE-2026-81735 on August 28, treating it as a standalone record. It was one of thirteen, published in the same thirteen seconds, by the same assigner. That context was not in our page and should have been. A dated note has been added there pointing here.

    The weakness distribution across those thirteen is the most useful thing in the set. Five carry CWE-346, origin validation — mcp-go, pg-aiguide, tiger-slack, tiger-gh-mcp-server, and mcp-server-dash. Three carry CWE-306, missing authentication for a critical function — mcp-router, telnyx-mcp, and UI-TARS-desktop. Two carry CWE-918, server-side request forgery — mcp-use and actors-mcp-server. The remaining three are one each: CWE-94 code injection in ToolUniverse, CWE-78 OS command injection in rails-mcp-server, and CWE-200 information exposure in airtable-mcp-cli. CVSS 4.0 base scores run from 2.3 to 10.0.

    The sweep is not confined to one assigner. An NVD keyword search for “MCP” limited to records published between August 25 and August 30, 2026 returns 31 results. GitHub’s security advisory program supplied a cluster on August 25 alone, including PraisonAI, mcp-shell, nextcloud-mcp-server, browse-mcp, genieacs-mcp, and the MCP PHP SDK. VulDB contributed records on August 27 and August 28. VulnCheck added mcp-fetch on August 26 and NousResearch’s hermes-agent, at CVSS 4.0 base 9.0, on August 28. That 31 is a floor rather than a count: keyword search matches description text, and two records in the August 27 batch — CVE-2026-81097 and CVE-2026-81101 — do not contain the string and do not appear in the result.

    None of these records states that exploitation has been observed, none appears in the KEV catalog, and no federal deadline attaches.

    Why it matters

    Thirteen records in thirteen seconds is not thirteen discoveries. It is one query run against a class of software, and the shape of the result tells you what the query was. Someone enumerated MCP server implementations, checked what address each one binds by default and whether it validates the host header a request names, and filed what came back. The productivity of that exercise — thirteen hits across projects maintained by Dropbox, Airtable, Telnyx, Apify, Timescale, and ByteDance — is the finding. These are not obscure hobby repositories. They are connectors shipped by companies with security teams.

    We made the structural argument about MCP’s transport shift in the UI-TARS page and will not repeat it. The new information is in the distribution, and specifically in the low-scoring records, which are where the useful lesson sits. Dropbox’s mcp-server-dash scored 2.3 on CVSS 4.0, the lowest in the batch. Read what it did: it bound its listener to the loopback address. That is the correct, widely recommended mitigation — the thing every hardening guide tells you to do, and the thing an engineer who had read the UI-TARS advisory would have done. It was still reachable, because per the CNA record it “never checked the host a request named,” so “a name that had been pointed at the loopback address still reached the listener while carrying the attacker’s host name.” A web page in a browser on that machine could drive the server and invoke its tools under the Dropbox credential the server holds.

    That is DNS rebinding, and it is the reason five of the thirteen carry CWE-346 rather than CWE-306. The two defects are usually discussed as one problem — “the MCP server was exposed” — and they are not. Binding to loopback closes the network path and does nothing about the browser path, because the browser is already on the loopback interface. A defender who audits bind addresses across their MCP fleet, finds them all set to localhost, and marks the task done has completed half of an audit and will believe they completed all of it. The second half is whether the transport validates Host and Origin, which is not visible from a port scan, not visible from a process listing, and only visible by reading the transport configuration or the code.

    Read the score spread as a warning rather than a ranking. Sorting an MCP inventory by CVSS and working down addresses the servers that did nothing and defers the ones that did something insufficient — which is close to backwards, because the projects that bound to loopback are the ones whose operators believe they are safe.

    The argocd-mcp record carries a separate problem worth naming on its own. GitHub’s advisory for this flaw, GHSA-rp45-5x3v-48mr, was published on August 11, 2026, credits the reporter shmulc8, names 0.8.0 as affected and 0.9.0 as fixed, and carries the same CVSS 10.0. That advisory states “No known CVE.” The CVE record arrived eighteen days later, from a different assigner. NVD’s record for CVE-2026-82456 references the GitHub advisory; the GitHub advisory does not reference the CVE. For eighteen days a critical, fixed, publicly documented flaw in a Kubernetes deployment tool existed with no CVE identifier — which means it was visible to anyone reading GitHub advisories and invisible to every scanner, SBOM tool, and vulnerability feed that keys on CVE IDs. The fix shipped in 0.9.0 during that window. Organizations that patch from advisories got it; organizations that patch from CVE feeds did not know there was anything to get.

    What to do

    Build the inventory first, because most organizations do not have one. MCP servers are installed by developers, run as user processes, and rarely appear in a CMDB. Look for listening processes started from npm and pip packages with “mcp” in the name — on developer laptops, build agents, and any host running an internal agent framework.

    For each, answer two separate questions. What address does it bind — loopback being necessary and not sufficient? And does the transport validate the Host and Origin headers? If that answer is no or unknown, the server is reachable from any web page the operator visits, whatever the bind address.

    Where fixed versions are named in the records, they are specific. Upgrade argocd-mcp to 0.9.0 or later. Upgrade mcp-router to 0.6.3 or later, which defaults the host to loopback and refuses to start without a token when given a non-loopback host. For rails-mcp-server, 1.6.1 restricts what the sandbox permits and 2.0.0 removes the affected tool entirely. Look up the remaining identifiers at services.nvd.nist.gov by CVE ID; every record in this batch names its fixed release in the CNA’s description text.

    Then treat any MCP server that holds a credential as a service with that credential’s privileges, and scope the token accordingly. The argocd-mcp record is a clean illustration: the flaw grants no Argo CD access of its own, it grants whatever ARGOCD_API_TOKEN was given. A read-scoped token would have produced a materially smaller incident than an admin-scoped one, and nothing about the vulnerability would have changed.

    Sourcing note

    Checked: the NVD records for CVE-2026-82456, CVE-2026-81091 through CVE-2026-81102, and CVE-2026-81735, each retrieved individually by CVE ID from the NVD 2.0 API, which supplied every timestamp, score, vector, weakness, and quoted description above; VulnCheck’s public advisory page for argocd-mcp; and GitHub advisory GHSA-rp45-5x3v-48mr, which supplied the August 11 publication date, the reporter credit, the affected and patched versions, and the “No known CVE” status. Counts of the wider sweep come from NVD keyword searches over the stated date range, run against the API.

    Could not reach: api.github.com returned HTTP 403 to automated requests, so the advisory dates were read from the rendered advisory page rather than the API, and we could not retrieve the repository’s release timestamps to confirm when 0.9.0 actually shipped. cisa.gov returns HTTP 403 to automated fetching, so the absence of any KEV entry here was confirmed through NVD’s own CISA fields rather than the catalog page.

    Unresolved: whether the August 27 batch reflects a single coordinated research project and, if so, whose. VulnCheck is the assigning authority for all thirteen, but the records do not uniformly name a discovering researcher, and we found no writeup describing the sweep as a whole. Also unresolved: why GitHub’s advisory carried no CVE for eighteen days, and whether the two records will be reconciled. No exploitation of any identifier in this story has been reported by any CNA, vendor, or agency as of publication.

  • cPanel says a parked-domain flaw gives any account root on the whole server, and the CVE it names has no record

    cPanel says a parked-domain flaw gives any account root on the whole server, and the CVE it names has no record

    cPanel’s August 27 advisory says any account holder who can add a parked domain can execute code as root on the whole server — and three days later the CVE identifier in the advisory’s own title has no record at the CVE Program or NVD.

    What happened

    On Thursday, August 27, 2026, cPanel published a support advisory titled “Security: CVE-2026-65643 Vulnerability in cPanel’s Domain Parking Functionality.” It describes the problem in one sentence: “An authenticated cPanel account holder who is able to add parked or addon domains can create arbitrary files on the server.”

    The impact statement is the second sentence, and it is not hedged: “Successful exploitation leads to code execution as the root user, giving an attacker full control of the server and every account, website, and database on it.”

    Fixed builds are named across five branches: 11.110.0.141 or later, 11.134.0.53 or later, 11.136.0.37 or later, 11.138.0.2 or later, and 11.138.1.7 or later for WP Squared. All supported versions below those builds are affected.

    That is the entire advisory. It carries no CVSS score. It carries no severity rating of cPanel’s own. It names no researcher and no credit. It gives no technical detail beyond the two sentences quoted above — no affected component path, no explanation of how file creation becomes root code execution, no proof-of-concept constraints. And it makes no statement in either direction about whether the flaw has been exploited.

    As of Sunday, August 30, 2026, three days after that advisory, CVE-2026-65643 has no published record anywhere in the vulnerability record system. A query to NVD’s API for the identifier returns an empty result set. A query to the CVE Program’s own services API for the same identifier returns HTTP 404. As a control on that second result, the same API returns a fully populated record for CVE-2026-76581, published on August 28, so the 404 reflects the absence of a record rather than a failed lookup.

    Why it matters

    Shared hosting has exactly one security boundary that matters, and this is a bug in it. The premise of the product is that hundreds or thousands of unrelated customers can be packed onto one machine because the control panel keeps each of them inside their own account. A flaw that turns an ordinary account into root does not primarily harm the account holder who exploits it. It harms every other customer on that server — their files, their databases, their mail, their customers’ data — none of whom have any relationship with the attacker, any visibility into the machine, or any way to find out.

    The privilege the attacker needs is the cheapest thing on the menu. Adding a parked or addon domain is not an administrative capability; it is a standard feature of entry-level hosting plans, the kind of thing a customer does to point a second domain at the same site. So the cost of entry is the price of a hosting account, and the attacker can buy that account from the same provider whose server they intend to take. There is no need to compromise anyone first. This is the structural reason that local privilege escalation in a multi-tenant control panel deserves to be read as remote code execution with a small purchase order attached, and why “authenticated” in the advisory’s first sentence is doing much less work than it looks like it is doing.

    Which brings up the missing record, and it is worth being fair about what that does and does not mean. A gap of days between a vendor’s own advisory and the appearance of a CVE record is ordinary. Identifiers get reserved before they get published, CNAs publish on their own schedules, and cPanel has done nothing improper by shipping a fix and telling customers about it before the paperwork caught up. The vendor got the patch out and said what it was for. That is the important part and cPanel did it.

    The consequence is still real, and it falls on the operator rather than the vendor. Most organizations do not learn about vulnerabilities by reading vendor knowledge bases. They learn about them from a feed — a scanner, an SBOM tool, a vulnerability management platform, a ticket that opens itself when a CVE matching an inventoried product crosses a threshold. Every one of those systems is keyed on the CVE record. For three days there has been nothing for them to key on. A hosting provider whose patch process is driven by CVE ingestion has not seen this, will not see it until the record publishes, and has no way to notice its absence, because the thing that is missing is precisely the thing that would have told them.

    The same gap runs through prioritization. CISA’s BOD 26-04, in force since June 10, 2026, derives federal remediation deadlines from four binary variables: internet exposure, KEV listing, exploit automation, and total versus partial technical impact. Two of those — KEV listing, and any scoring input a triage process layers on top — require a record to exist. A vulnerability with no CVE record cannot be listed in KEV and has no published score to feed a risk model. None of that changes what the flaw does to a server. It changes only whether the machinery organizations have built to notice such things will notice it. The directive binds federal agencies, but the prioritization pattern it formalizes is the one most private-sector patching programs already run on, and it has the same blind spot.

    The absence of a severity rating in the advisory compounds this in a smaller way. An operator deciding between an emergency maintenance window tonight and the next scheduled one has to weigh this against everything else in the queue, and the only signal cPanel provides is the phrase “code execution as the root user.” That phrase is a strong signal and it should be treated as one. But it is prose, and queues are sorted by numbers. cPanel has published severity ratings on advisories before; there is none here, and no explanation of why.

    What is genuinely unknown, and worth stating rather than glossing, is whether anyone has used this. The advisory does not say the flaw has been exploited, and it does not say it has not. Silence is not a denial. Given that a patch shipped across five branches simultaneously, and given that the advisory gives no credit to an outside researcher, the two most common explanations — an internal audit finding, or a report from a hosting partner who noticed something — point in opposite directions on urgency, and nothing public distinguishes them.

    What to do

    Check the installed build with /usr/local/cpanel/cpanel -V and compare it against the fixed build for your branch, not against a single version number. The five thresholds are 11.110.0.141, 11.134.0.53, 11.136.0.37, 11.138.0.2, and 11.138.1.7 for WP Squared. Because cPanel servers track different release tiers, the correct target depends on which tier the machine is on, and a build number that looks lower than another server’s may still be patched.

    Confirm that automatic updates are enabled and have actually completed, rather than assuming they have. Check that upcp has run since August 27 and that it finished, then re-check the version rather than trusting the schedule.

    The advisory offers no mitigation and no workaround. Its own wording implies that an account without the ability to add parked or addon domains cannot reach the flaw, so restricting that feature at the package level would narrow exposure — but cPanel does not present this as a mitigation, has not validated it as one, and it should be treated as an inference from the vendor’s sentence rather than as vendor guidance. Updating is the only remediation cPanel names.

    For retrospective review on a multi-tenant server, the artifact to look for is file creation outside an account’s own home directory attributed to that account’s activity, and any new or modified files in root-owned paths that do not correspond to a package operation. Reconcile recent parked and addon domain additions against the customers who should have made them.

    Sourcing note

    Checked: cPanel’s own support advisory for CVE-2026-65643, dated August 27, 2026, which is the source of every quoted sentence and every fixed build listed above; NVD’s API by CVE ID, which returned no record; and the CVE Program’s CVE Services API for the same identifier, which returned HTTP 404. The control lookup against CVE-2026-76581 on the same API returned a published record, confirming the API was functioning at the time of the check.

    Not established: whether the flaw has been exploited, who reported it, what the underlying component is, and what severity cPanel assigns it. None of these appear in the advisory, and there is no second primary source — no CVE record, no NVD entry, no researcher writeup — to check them against. The vulnerability’s real severity is inferred here from cPanel’s own impact sentence, which is the strongest statement available and the only one.

    Unresolved: when CVE-2026-65643 will publish, and which CNA holds it. The identifier’s numeric range does not reliably indicate the assigner, and with no record present there is nothing to read it from. This page will not be updated silently if that changes; a new development gets its own note.