Project-Wide Passes for Cluster-Scoped Powers: OneUptime’s Fifteen-Advisory October Batch and CVE-2026-112047

2026-10-19 AI Vulnerabilities & CVEs by al-ice.ai Editorial

Between 13 and 18 October 2026, OneUptime published fifteen repository security advisories against its open-source observability and incident-management platform (OneUptime/oneuptime, ~7,700 stars, TypeScript): three critical, four high, eight medium. Only one of the fifteen carries a CVE identifier so far — CVE-2026-112047, published 18 October at 12:19:36Z from VulnCheck, in which the platform’s Kubernetes AI actions were authorised at project scope instead of cluster scope. The other fourteen sit in the repository advisory database with cve_id: null, invisible to every scanner that keys on CVE identifiers. If you run OneUptime self-hosted, your feed has told you about roughly seven percent of this batch.

The headline CVE is the right place to start because it is the purest statement of the theme this site has tracked all month: an agent that can run commands, approved by a check that never looked at the object. But the batch around it is, frankly, the more dangerous reading — a 9.8 session forgery from a placeholder secret, a 9.9 credential exposure to read-only roles, and a tenant identity provider that could mint instance-administrator sessions.

CVE-2026-112047: the AI agent took orders at project altitude

OneUptime binds a Kubernetes AI agent (or a Runner) to each monitored cluster. That agent does genuinely privileged things: the Test connection action (POST /kubernetes-cluster/ai-access/test) runs kubectl version and kubectl auth can-i --list on the cluster and records its last-verified time; Reset agent disconnects the agent until it re-registers; approving an AI-composed kubectl plan executes cluster changes; and the incident AI conversation offers read-only kubectl and infrastructure commands against linked clusters and resources. Each of these is a power over a specific cluster — and each was gated by a check that asked only whether the caller could edit clusters anywhere in the project.

The advisory states the mechanism plainly: a permission limited to some labels or to owned clusters, and a block on one of the cluster’s labels, were never applied to the cluster being acted on. So a member whose edit permission covered only Staging-labelled clusters could run the access test on any cluster they could view — learning its Kubernetes version and the RBAC permissions held by its agent credential, spending the agent’s time, and rewriting its last-verified timestamp. With the AI admin permissions, the same member could reset another cluster’s agent, disconnecting it for minutes. With runbook-start permission, they could approve a pending AI-composed kubectl plan against a cluster they may not edit. And any responder who could see an incident could have the AI run commands on linked clusters and resources they may not view, because the conversation offered commands on every linked object with AI investigation switched on, to whoever asked.

Note the shape of the information leak inside the “read-only” test: kubectl auth can-i --list output is a map of what the agent credential may do. A scoped-down member spending someone else’s agent to print its own capabilities is reconnaissance laundered through a diagnostics button.

The fix is PR #4960, merged 17 October as commit 264e1ba (83 files, +5,686/−211), on a branch named claude/k8s-ai-access-test-scope — the record shows the name; we make no claim about authorship beyond it. Release 14.0.69 shipped 18 October at 04:52:23Z, and the advisory followed at 04:53:37Z, seventy-four seconds later. Each action is now decided for that very cluster or resource — labels, owners, blocks, custom roles and read-only credentials included — and the incident AI conversation offers commands only on objects the asker may view. VulnCheck scores it medium (CVSS 4.0 5.3); the vendor advisory scores 5.4 under CVSS 3.1 (CWE-863). The repository advisory credits reporter carfeii; the CVE record credits George Chen.

The three criticals around it

GHSA-xc2h-75j8-wwgm (9.8): the placeholder was the key. Self-hosted installs whose ENCRYPTION_SECRET was unset, empty, or still a shipped placeholder (secret, or the please-change-this-to-random-value from config.example.env, which the README quick start copies verbatim) signed every session token with that public value. Anyone with network access could mint a session for any user id — including nonexistent ones — flagged as master admin. No account needed. The server logged a startup warning and carried on signing. The same key keyed every other proof-token in the system, and the advisory’s list is worth reading slowly: project and global SSO tokens, status-page sessions and master-password cookies, in-progress identity-provider sign-ins, phone-keypad callbacks, the verification-email resend token — and the MCP server’s authorization-request and delegation tokens. OneUptime operates an MCP server, and its delegation tokens were forgeable under the same placeholder. Fixed in 14.0.51 (PR #4750): affected installs now generate a random 256-bit key stored in their own database and refuse tokens signed with shipped values. Reported by 28Hus. If your Compose install was copied from the example file without the “Generate random secrets” step, rotate everything after upgrading — changing the secret invalidates stored integration tokens and forces password resets, which is the price of the fix.

GHSA-gmhg-x8h3-66gm (9.9): read-only roles could read the Twilio auth token. A project’s Call/SMS configuration holds its Twilio account SID and auth token; the token was readable by every role that could see the configuration — Member, Viewer, Settings Admin, Settings Member, Settings Viewer, and API keys holding those roles — and stored unencrypted. A second path ran through list filters: filtering status pages by a related record’s field was never held to that field’s read permission, so status-page roles could pull the Twilio token or a status page’s SMTP password through crafted filters. Impact is direct account abuse: send SMS and place calls on the customer’s bill, read message and call history, change or release numbers. Fixed in 14.0.56 (PR #4801): the token is now Owner/Admin/permission-gated and encrypted at rest, and related-field filters inherit the field’s read permission. Rotate the Twilio token and status-page SMTP passwords after upgrading if limited roles ever held read access.

GHSA-358p-w79v-cc3r (9.1): a tenant’s identity provider could sign in as anyone, including instance admins. A project’s own SAML/OIDC provider is configured by that project’s administrators and can assert any email address; the sign-in callbacks matched the asserted address to an existing account and minted a session carrying its isMasterAdmin claim. A project Owner pointing their provider at an IdP they control could take over the whole instance from a tenant-level role. A September mailbox-confirmation step had closed this for ordinary accounts on the hosted service but never for administrator escalation — and never for self-hosted installs. Fixed in 14.0.51: a project’s own provider now refuses administrator accounts outright, on every edition, before anything is emailed, provisioned or signed; instance-admin access requires a first-party credential or the operator-controlled Global SSO provider.

The SSO cluster: four advisories, one subsystem

Four of the fifteen land in single sign-on, and they read as one audit finding split four ways. GHSA-vp9r-wrw4-vp33 (8.1): SAML sign-in verified signature, issuer and subject but never Audience, Recipient, Destination, the validity windows, or replay — a signed response worked as a reusable bearer credential across every OneUptime SAML provider trusting that IdP, usable after expiry and after the user was disabled, and responses issued for other applications on the same IdP were accepted. The fix (14.0.67, PR #4934) enforces audience/recipient/destination, a ten-minute freshness bound with three minutes of clock skew, and a shared-cache replay record — with fail-closed 503 if the cache is unreachable. GHSA-5mv6-h9hc-3v74 (7.4): because every token was signed with one key and the session reader accepted any token naming a user, the 30-day SSO sign-in token doubled as a full session, surviving sign-out, password change and revocation. The fix types every token (session, SSO sign-in, status-page) and each reader accepts only its own kind. GHSA-66gg-x99r-p5hj (6.6): removing master-admin access left existing sessions fully empowered for up to 15 minutes — including re-granting the access to themselves — while the dashboard claimed otherwise (reported by Tike00). GHSA-pfjr-x3xx-x8hq (4.2): “Require SSO for Login” was not enforced while its own setting was unreadable from the database. All four fix in 14.0.67.

Two more highs complete the privilege picture. GHSA-7v74-x6fg-g7mw (8.8): workflow steps that create, change or delete records could write team permissions and memberships, so anyone who could build a workflow — including the default Project Member role — could escalate to Project Admin (and to Project Owner before 14.0.15, when steps ran as OneUptime itself). The fix (14.0.65, PR #4921) removes identity-plane writes from workflow steps entirely; automation that manages teams must now be a person or an API key. Reported by Wenhao Wu. GHSA-5xgm-8pww-qc5v (7.7): Slack and Teams connect callbacks let anyone link their chat account to another user’s OneUptime account — fixed back in 14.0.2, disclosed now, another patch-before-advisory instance.

The medium tail, for the record: probe-result impersonation across projects (6.5, →14.0.70), notification-method injection into foreign projects (5.4, →14.0.70), Owned-scoped monitor deletion removing others’ monitors (6.5, →14.0.71), status-page subscription takeover by subscriber id (5.4, →14.0.68), and concurrent-creation plan/seat limit bypass (4.3, →14.0.66).

What to do

Upgrade to 14.0.71 or later — not 14.0.69, which the CVE names, because the 18 October advisories fix in 14.0.70 and 14.0.71. Then work the backlog the advisories imply: rotate the Twilio auth token and any status-page SMTP passwords that limited roles could have read; re-derive your SSO configuration against the new audience/recipient enforcement and confirm clocks agree within three minutes; set a real ENCRYPTION_SECRET if you never did, accepting the re-entry cost; audit teams for workflow-granted membership changes; and treat any session predating 14.0.67 on an SSO-mandated project as suspect. The fixes are version-gated but the exposures were configuration-shaped — least-privilege label scoping on clusters only started working as documented at 14.0.69, so verify the scopes you thought you had, rather than assuming they held.

No OneUptime record appears in the CISA KEV catalogue (checked 19 October 2026 against the 16 October catalogue, 1,748 entries), and no exploitation has been reported for any of the fifteen. That is the expected state for advisories days old — several of whose fixes were public weeks earlier — not a safety signal.

Our verification was read-only. CVE-2026-112047’s identifier, publication timestamp (2026-10-18T12:19:36Z), source (VulnCheck), CWE-863 assignment, affected range and references were read first-hand from the CVE record; its severity (medium, CVSS 4.0 5.3) and finder credit (George Chen) from the VulnCheck advisory page. All fifteen GHSA identifiers, severities, CVSS 3.1 vectors, CWE assignments, affected and patched versions, publish timestamps, reporter credits and the quoted remediation detail were read first-hand from the GitHub repository security-advisory API. Fix PR #4960’s metadata (merged 17 October 2026, 83 files, +5,686/−211) and the 14.0.69 release notes and publish timestamp were read first-hand from the GitHub API, as were the 14.0.70 and 14.0.71 release timestamps and the 14.0.68-to-14.0.69 file delta. Repository metadata (7,743 stars, 475 forks, TypeScript, created June 2021, not archived) is from the GitHub API. KEV status was checked directly. Brave Search was used for discovery only and returned no independent technical analysis of any of the fifteen. We installed nothing, created no account, configured no provider, and executed no proof of concept.

Sources: