CVE-2026-63087: Critical Grafana OnCall Flaw

CVE-2026-63087 in Grafana OnCall OSS has received a critical severity rating. According to the NVD record for CVE-2026-63087, an unauthenticated remote attacker can obtain a valid PluginAuthToken through the internal plugin installation mechanism. The token provides access to the internal API, and the vulnerability description identifies the ability to create an administrator, revoke the legitimate plugin token and change trusted organisation configuration.

This is a serious incident-management control-plane takeover scenario, but it needs precise communication. At the time this article was updated on 17 July 2026, CISA-ADP metadata did not confirm exploitation in attacks. The record says exploitation: none while also assessing the issue as automatable: yes with technicalImpact: total. Technical criticality is not evidence of an active campaign. It is, however, ample reason to determine immediately whether the organisation still operates Grafana OnCall OSS and whether its interfaces are reachable from an untrusted network.

CVE-2026-63087 at a glance

Field	Confirmed information
Product	Grafana OnCall OSS
Affected versions	through 1.16.11 according to the CVE record
Weakness	CWE-306 — Missing Authentication for Critical Function
Vector	remote, with no prior authentication
CVSS	9.3 under CVSS 4.0 and 9.8 under CVSS 3.1 in CNA data
Potential consequence	valid plugin token, administrator account and modification of trusted configuration
Confirmed attacks	none confirmed by CISA-ADP metadata as of 17 July 2026
Project status	Grafana OnCall OSS was archived on 24 March 2026

The technical description originates in the CVE record prepared by CNA VulnCheck and the VulnCheck advisory. NVD marks the record as awaiting full enrichment, so conclusions should remain within the facts already published. Do not invent an unconfirmed attack chain, indicators of compromise or claims of active exploitation.

Why this defect is so dangerous

The core problem is not a single form or an ordinary information leak. It breaks the trust boundary between Grafana and the OnCall engine. Public source code contained default stack_id and org_id values. The plugin installation mechanism could use them to issue a valid token even though the requester had not been properly authenticated.

CWE-306 describes the absence of authentication around a security-critical operation. If an endpoint that creates or transfers a credential accepts an anonymous request, later authorisation checks offer little protection: the attacker enters the system carrying a token the application treats as trusted.

According to the CVE description, the acquired PluginAuthToken can call the internal API. User-context bootstrap functionality can then create an arbitrary administrator. The attacker can also revoke the legitimate plugin token and overwrite the organisation’s grafana_url and api_token. The final capability matters in particular: changing the destination can direct trusted OnCall-to-Grafana API communication towards infrastructure controlled by an adversary.

This chain has the potential to affect confidentiality, integrity and availability completely. An administrator account provides a durable control point. A token change may disrupt the legitimate integration and impede response. Redirection may expose data sent by a trusted component. Version checking alone is therefore insufficient; teams also need to review configuration, accounts and outbound traffic.

Which environments are at risk

The CVE describes self-hosted Grafana OnCall OSS. It does not automatically apply to every Grafana Cloud service. Establish the product, deployment model and version first. Organisations often retain older instances outside their primary CMDB: a lab, disaster-recovery environment, post-migration copy or installation maintained by one SRE team.

Discovery should cover:

1. infrastructure-as-code repositories, Compose files, Kubernetes manifests and container images;
2. DNS, reverse proxies, load balancers and WAF rules;
3. secrets whose names relate to OnCall, Grafana or plugin tokens;
4. service registries, the CMDB and observability platforms;
5. backups, standby clusters and unused test environments;
6. public and partner address ranges found through External Attack Surface Management.

Do not limit inventory to hosts directly accessible from the Internet. A vulnerable endpoint may be reachable through a VPN, partner network, shared Kubernetes ingress or compromised administrator workstation. Exposure belongs to the whole access path, not a simple “public/private” flag in a spreadsheet.

Important context: the project is archived

The official Grafana OnCall OSS documentation says the project entered maintenance mode on 11 March 2025 and was fully archived on 24 March 2026. Its repository is read-only, active development has moved to Grafana Cloud IRM and Cloud Connection support for OSS installations has ended.

That status changes risk management. The CVE record lists versions through 1.16.11, but it does not identify a supported fixed release. Administrators must not assume that an ordinary pull latest resolves the problem. They should verify official vendor channels and, where no patch is available, isolate the service and plan migration or retirement.

Archived software may continue to function. That does not mean future vulnerabilities will be handled on a predictable schedule. Within a vulnerability management process, product support status should be a separate prioritisation factor alongside CVSS, exposure and asset value.

A four-hour response plan

1. Confirm versions and access paths

Identify every instance and obtain its version from the running artefact, not merely from a repository declaration. Record the proxies, ingress controllers, tunnels and networks through which the OnCall engine can be reached. Assign a business and technical owner to every instance.

2. Reduce reachability without destructive testing

If safety cannot be established immediately, restrict access to trusted administrative segments or temporarily remove public routing. Do not test production with an exploit payload. Such a test could create an account, change a token or alter configuration and thereby become an incident itself.

3. Preserve evidence

Before restarts and credential rotation, retain application logs, reverse-proxy or WAF logs, container-platform events, secret-change history, the user list and organisation configuration. Align timestamps. Where retention is short, export data to a segregated store.

4. Investigate compromise hypotheses

Look for anonymous requests to the plugin installation function, unexpected user-context bootstrap operations, creation of an administrator, token revocation or change, modification of grafana_url or api_token, and outbound connections to unfamiliar hosts. These are detection hypotheses derived from the CVE description, not published universal indicators of compromise.

5. Rotate credentials in the right order

Where misuse is suspected, first prevent unauthorised access and preserve evidence. Then remove unknown accounts and rotate PluginAuthToken, Grafana API tokens and any other secrets accessible to the component. Rotation without closing the vulnerable path may simply give the attacker another credential.

What to monitor in logs and configuration

No single signature will settle the question. Correlate several events:

• a request to the internal plugin installation function from an address, user or agent that does not perform administration;
• creation of a new administrator without a corresponding ticket and IAM workflow;
• plugin token modification or revocation outside a maintenance window;
• a changed grafana_url destination or api_token value;
• a new outbound destination from OnCall, particularly through public DNS or an unusual ASN;
• integration failures, a sudden absence of alerts and repeated authentication attempts after a token change;
• secret changes in Kubernetes, Docker or Vault that did not originate in the approved pipeline.

A SIEM rule should retain raw request and response fields, instance identity, source IP, workload identity and timestamp. Our SIEM vs XDR vs EDR comparison explains the distinct telemetry each platform supplies. For this vulnerability, application, proxy and change-control logs are more valuable than endpoint telemetry alone.

Mitigation, remediation and migration are different

Mitigation reduces the likelihood of exploitation through measures such as allowlisting, segmentation or disabling public routing. Remediation removes the defect or deploys an officially fixed release. Migration removes reliance on the archived product. They can run in parallel, but the first must not be reported as completion of the other two.

If the vendor publishes a fix, deployment should cover every node and validation should confirm the actual container-image version plus legitimate Grafana–OnCall integration. Where a supported patch is unavailable, the most defensible choice is to isolate the service, reduce its functionality and accelerate migration. A security exception needs an owner, expiry date and measurable closure condition.

In practice, connect this response with critical vulnerability prioritisation, internal network segmentation testing and an incident-response tabletop exercise. CVSS describes technical potential. Exposure, support status, data handled and telemetry availability determine the organisation’s actual risk.

What remains unknown today

Responsible analysis includes its knowledge boundaries. As of 17 July 2026, the public record does not confirm active exploitation, publish universal indicators of compromise or identify an unambiguous supported fixed release. The record may be enriched later. Teams should therefore monitor NVD, Grafana and the CNA, then feed any status change into their own risk assessment.

Absence of confirmed attacks is not a reason to wait. With a remote, unauthenticated and automatable path to administrator privileges, exposure time matters. Equally, nobody should publish an alarmist claim about an “ongoing campaign” until credible sources confirm it.

Reporting status without manufacturing certainty

An executive update should separate four fields: technical vulnerability, exposure of the specific instance, evidence of possible misuse and remediation status. “No indicators found” does not mean “no breach occurred” where logs cover only the previous 24 hours or omit administrator changes. Conversely, the presence of an affected version does not prove compromise.

A defensible report records the source and time behind every conclusion. For example: “NVD lists versions through 1.16.11; the instance was reachable from the VPN; 30 days of proxy logs were preserved; no new administrators were found; outbound traffic remains under investigation; public access was restricted at 14:20.” This structure allows the assessment to evolve without rewriting the incident history and makes facts distinct from open hypotheses.

Do not close the task after a firewall-rule change alone. Closure should require a confirmed fixed version or service retirement, a completed exposure-window review, credential rotation where warranted and retained validation evidence.

The decision for the system owner

If Grafana OnCall OSS is not present, document the discovery evidence and close the task. If a version through 1.16.11 is in use, restrict reachability, preserve telemetry, investigate accounts and configuration, and check the official update path. If the product is archived and no supported patch exists, set a date for migration or retirement.

Need an independent assessment of legacy observability services, APIs and administrative panels? Book a BreachRoad penetration test covering safe validation of configuration, access paths, secrets and detection readiness—without running a destructive proof of concept in production.