Skip to content
The Injection_
LIVE
LIVElast sweep next in--:--:--

[ RSS ][ JSON ][ llms.txt ]

Pulse: read-only viewers could decide the assistant's approvals

Pulse checked who you were before accepting an AI command approval, but not whether you were allowed to decide it.

· Pulse · Research by naroSEC

CVE-2026-129428
MEDVulnerability

Pulse, a self-hosted dashboard for Proxmox, Docker and Kubernetes, let any signed-in viewer list, approve or deny the AI assistant's pending command approvals. Version 6.8.0 adds the missing permission check.

01What happened

Pulse published advisory GHSA-9vxw-m79f-gxxr on 13 November 2026 for a missing authorization flaw reported by naroSEC. Versions 5.0.17 through 6.7.0 let an authenticated user holding only viewer access in an organization list pending AI Assistant approval requests and approve or deny them. VulnCheck assigned CVE-2026-129428 the next day.

02How it works

The approval routes checked authentication, API token scopes, organization membership and request state, but never checked whether the signed-in user held approval permission. API tokens remained subject to their own scope checks, so the gap reached browser sessions. The fix in pull request 4127 requires the same approval permission already used for the Actions review before a session can list, approve or deny a request.

03Who is affected

Pulse installations on v5.0.17 through v6.7.0, plus the v6.8.0-beta.1, beta.2 and rc.1 prereleases, with the AI Assistant in use and more than one user in an organization. Pulse is self-hosted monitoring for Proxmox VE, PBS and PMG, Docker, Kubernetes, TrueNAS and vSphere, and it also exposes an MCP server for coding agents.

04What to do

Upgrade to Pulse v6.8.0, published on 13 November 2026. Until the upgrade lands, the maintainer's workaround is to grant viewer access only to users who should be able to see and decide pending approvals.

Questions people ask

Could a Pulse viewer run commands on a host through this flaw?
No. The Pulse advisory states that this path does not by itself establish cross-organization access or command execution on a host. A viewer could read the proposed commands and target details in other users' pending requests, and could approve or deny unexpired pending requests, which changes the approval decision and the audit record.
Were Pulse API tokens affected in the same way?
API tokens were not. The advisory says tokens remained subject to their scope checks, while browser sessions were never checked for approval rights, so the missing authorization reached signed-in users of the web interface. Upgrading to v6.8.0 applies the approval permission check before any session can list, approve or deny a request.
How do I tell whether my Pulse instance was affected?
Compare the running version against the advisory's range: v5.0.17 through v6.7.0 and the v6.8.0 prereleases beta.1, beta.2 and rc.1 are affected, and v6.8.0-rc.2 is the first fixed prerelease. The workaround points at the viewer role, so also review which users hold viewer access in each organization.

Sources 3 links, all fetched

  1. 1github.comPulse Advisory
  2. 2vulncheck.comVulnCheck Advisory
  3. 3github.comPulse v6.8.0 Release