Top/Articles/Grafana OnCall (open-source) can be fully taken over without login β€” and no patch is coming: CVE-2026-63087, stop using it and migrate
grafana-oncall-cve-cover-en

Grafana OnCall (open-source) can be fully taken over without login β€” and no patch is coming: CVE-2026-63087, stop using it and migrate

A critical flaw, CVE-2026-63087 (CVSS 9.8), lets anyone take over Grafana OnCall (the open-source on-call/alerting tool) completely without logging in. The open-source edition is already end-of-life, so no patch is coming. All versions are affected; block the management port now and migrate to the supported successor.

NewsPublished July 17, 2026 Updated today
Table of contents
Key takeaways

A critical flaw, CVE-2026-63087 (CVSS 9.8), lets anyone take over Grafana OnCall (the open-source on-call/alerting tool) completely without logging in. The open-source edition is already end-of-life, so no patch is coming. All versions are affected; block the management port now and migrate to the supported successor.

A flaw that lets anyone take over the whole system without logging in (CVE-2026-63087) has been found in the open-source edition of "Grafana OnCall," a tool that pages the on-duty engineer by phone, SMS, or app notification when a system fails. Its severity is 9.8 out of 10 on the CVSS scale β€” the "Critical" band. It is made by the monitoring vendor Grafana Labs.

The nasty part is that there is no fix for this flaw. The open-source edition of Grafana OnCall has already reached end of development, and no patch will ever ship. In other words, the usual "update to fix it" does not apply, and every affected version stays vulnerable.

If exploited, an attacker gains admin-level privileges without logging in, and can add users or swap the link to your monitoring system for a server of their own. No real-world attacks have been reported so far, but a proof-of-concept exploit is already public. We explain what happens, why no fix is coming, and how to defend yourself for now β€” in order. In monitoring and operations tooling, flaws such as one in a tool that lets an AI operate Grafana and can leak credentials keep appearing, and the closer a component sits to the foundation, the wider its blast radius.

What happens

In one sentence: an internal endpoint (the receiver for installing a plugin), which should require a login, was left open with no authentication. An attacker only has to send it a single request to have an admin-level token issued. From there, they can do as they please β€” from creating an admin account to swapping the linked destinations.

ItemDetail
CVE IDCVE-2026-63087
AffectedGrafana OnCall (open-source)
all versions through 1.16.11
SeverityCVSS 9.8 (Critical)
9.3 under the newer v4.0
Flaw typeMissing authentication for a
critical function (unauth token issue)
PreconditionNetwork reachability to the
management port
Active attacksNone reported so far
(PoC is public)
ResponseNo fix. Block access for now,
then migrate to the successor

Grafana OnCall is an operations tool that receives failure alerts and pages the on-call staff, used to run a role like PagerDuty on your own server. The problem here concerns setups that run the open-source edition on a self-hosted server. If you use the cloud edition (Grafana Cloud), this article does not apply to you.

Who targets this, and why

The party that can exploit this is an attacker who can reach Grafana OnCall's management port over the network. No login is needed at all. That includes servers exposed directly to the internet, and also an attacker who has broken into an internal network targeting it from the inside. Because the required values are written right into the publicly available program, they do not even need to hold any special information in advance.

What that attacker does is have an admin-level token issued with no authentication, create an admin account at will, and swap the link to the monitoring system for a server of their own. Once they control that destination, they can cut into the flow of legitimate alerts and data, or revoke the tokens the operations team relies on and lock them out. It amounts to hijacking the command post of incident response and reaching into the whole organization's operations. Abusing default setup values written in public source in this way closely resembles the case where a gap in Argo CD's initial setup let attackers take over an entire Kubernetes cluster.

The damage does not stop with the operations staff. An on-call tool controls when, where, and to whom a service reports a failure. Hijack it, and attackers can suppress the real failure alerts so no one notices the attack β€” a nasty knock-on effect. The very shape of seizing admin rights without a login is the same family as the authentication bypass in JetBrains Hub; flaws where the authentication gate is missing spread their impact fast.

A technical look

According to the reporter's technical write-up, the problem lies in the internal plugin-install endpoint /api/internal/v1/plugin/v2/install/. This endpoint explicitly disables authentication and permission checks, letting the request through after merely confirming that this is "a self-hosted open-source edition."

Where secret information should have been required, what was used instead were fixed values written straight into the publicly available source code. Specifically, identifier numbers (stack_id=5, org_id=100) are embedded as defaults, so an attacker only has to send them to receive a valid admin-level token. From there the flow is: create an admin user with that token, rewrite the linked settings (the monitoring system URL and API key) to the attacker's own, and revoke the legitimate tokens to dig in. It is classified as missing authentication for a critical function (CWE-306).

Looking at the severity vector, it can be exploited over the network with no authentication and no user interaction, and the impact spans confidentiality, integrity, and availability (9.8 under CVSS v3.1, 9.3 under the newer v4.0). The fact that everything needed for the attack is available as public information pushes the severity up. VulnCheck and the reporter, George Chen, coordinated the disclosure.

Why no fix is coming

What makes this flaw especially awkward is that no patch will be provided. The open-source edition of Grafana OnCall has already reached end of development and been "archived" (frozen). Grafana Labs announced the phased wind-down on its official blog, and no fix will land in this edition from here on.

WhenWhat happened
Mar 11, 2025Entered maintenance mode
(only critical flaws to be fixed)
Mar 24, 2026End of development, archived
(no fixes at all thereafter)
Jun 5, 2026The code repository
became read-only
Jul 16, 2026This flaw, CVE-2026-63087,
was disclosed

As the successor, Grafana Labs officially points to migrating to "Grafana Cloud IRM," which offers the same purpose in the cloud. Under the open-source license, continuing to use it with your own modifications is possible, but the maintenance is then on you. A situation where no fix arrives and only the danger remains is the same shape as a cheap security camera left with a takeover hole and no fix β€” those who keep using it have to defend themselves. For now, it is not listed in the U.S. CISA catalog of vulnerabilities known to be actively exploited (KEV).

What to do right now

First, confirm whether you run the open-source edition of Grafana OnCall. If you do, there is no option to fix it with an update, so your response comes down to two choices: "close the dangerous port" or "move to another service." The top priority is to check whether the management port (8080 by default) is exposed to the internet or to a broad internal network. If it is, it can be taken over with a single unauthenticated request, so block it promptly first.

For defending yourself in the meantime, the reporter suggests these stopgaps. Restrict access to the management port to only the legitimate Grafana host it links with (using a firewall or network traffic controls). Or place an authenticating proxy in front and reject access to /api/internal/v1/plugin/v2/install/ from anywhere but the legitimate path. These only buy time, though, and are not a fundamental fix. The lasting answer is to migrate to a supported successor like Grafana Cloud IRM, or to rebuild it into a form you can maintain.

It also helps to check whether you have already been compromised. Look for admin accounts you do not recognize, linked URLs or API keys that were changed without your knowledge, and tokens issued unexpectedly. More broadly, taking stock of "the risk of keeping a no-longer-developed open-source component running on your own" helps prevent a recurrence. The mindset of checking your OSS dependencies β€” knowing where the components you rely on come from and how well they are maintained β€” is useful for that kind of inventory.

Bottom line

CVE-2026-63087 is a flaw in the open-source edition of Grafana OnCall that abuses an internal endpoint with authentication stripped and fixed values written into the source to seize an admin-level token with no login. The severity is a high CVSS 9.8, and from there an attacker can move straight to creating admin accounts and swapping linked destinations, so a successful attack leads directly to taking over the operations platform.

The key point is that this edition has already reached end of development and no fix will ship. Because the usual "update to fix it" does not work, if you run an affected setup, first cut the management port's exposure and plan a move to a supported successor. No real-world attacks have been confirmed yet, but the proof-of-concept exploit is public, and all versions are affected. Operations tools, which are easy to forget are even running, are exactly what deserve a stocktake at a moment like this. We will add to this article as new information or attacks are confirmed.

Sources

avatar-m-1

Makoto Horikawa

Backend Engineer / AWS / Django