A Screenshot Shows a GitHub Security Advisory—How Do You Recover the Original Record?
Recover the original GitHub Security Advisory from a cropped screenshot: capture six fields in order, verify the GHSA record against GitHub's interfaces, and keep local dependency and exploitability outside what the advisory can prove.
A screenshot of a GitHub Security Advisory is not the original record: the forwarded image usually drops the URL and crops out the affected range or patched version. You recover the record by preserving the exact on-screen text, identifying the publisher host, and searching GitHub’s advisory interfaces by identifier. Do the recovery before you weigh severity, exploitability, or sales impact.
Vulnerability claims for sales often arrive this way: a vendor or partner forwards an image rather than a link, and the missing fields are exactly the fields you need. A GitHub Security Advisory (GHSA) is the identifier GitHub assigns to each advisory it publishes, formatted as GHSA-xxxx-xxxx-xxxx. A Common Vulnerabilities and Exposures (CVE) identifier is the public, cross-vendor reference number for the same vulnerability. GitHub publishes advisory records through an application programming interface (API) — a documented set of web requests that return structured data — so an analyst can pull the full record back by hand or with a script. Recovery starts with identifiers, never interpretation.
Recover six facts from the original record
Capture six fields first: the publisher host; the GHSA identifier; the package ecosystem and package name; the affected version range; the first patched version; and the authoritative update time from the record itself, not the screenshot’s timestamp.
The host tells you whether the image came from GitHub at all; the GHSA or CVE is the lookup key; ecosystem and package name match your dependency inventory; range and patched version define the upgrade decision; update time shows how current the record is. Write the six fields into a recovery record you can cite before commenting.
Follow the order an analyst actually searches
Work through the steps in this order. Skipping straight to severity is how unverified claims reach a sales briefing.
Preserve the exact screenshot text first
Copy every visible string verbatim: identifier, package name, version numbers, dates, CVSS score. A single mistyped character in a GHSA identifier makes the lookup fail. The discipline mirrors status-page screenshots: keep the picture, then rebuild the record from the official endpoint (see recovering a source record from a status-page screenshot).
Identify the publisher host
Look for github.com or api.github.com in any visible browser chrome or URL fragment. If the URL is cropped, a well-formed GHSA identifier still points to a GitHub advisory; an image of a third-party tracker that repeats advisory data is a lead, not a source. Name the host in your recovery record so the provenance stays explicit.
Search by GHSA or CVE
GitHub’s REST API for global security advisories can list and retrieve advisories filtered by GHSA identifier, CVE identifier, or package ecosystem (GitHub Docs, “REST endpoints for global security advisories”, accessed 3 August 2026). Use the identifier from the screenshot as the filter; the response returns structured identifiers and vulnerability records.
Verify ecosystem and version range
The returned record names the ecosystem (npm, PyPI, Maven, and others) and the vulnerable range. Check both against the screenshot text — this catches the classic error: the right CVE attached to the wrong package.
Record patched-version and update fields
Copy the first patched version and the record’s published and updated timestamps into your six-field record; a sales briefing will cite these, so they must come from the record, not the caption.
Run the local-dependency check as a separate step
The advisory record cannot tell you whether your organization depends on the package, runs an affected version, or is exploitable. That is a separate check against your local dependency inventory and running versions, done by your engineering or security team. Keep the two records apart: one states what the advisory says, the other what your environment runs.
Key facts: the GHSA-wf43-fpp3-cf65 worked example
On 31 July 2026, GitHub published advisory GHSA-wf43-fpp3-cf65 for the npm package @apostrophecms/seo, linked to CVE-2026-53608. The GitHub Advisory Database record (published 31 July 2026 at 21:53:56 UTC, updated one second later; retrieved 3 August 2026) gives the vulnerable range through 1.4.2, first patched version 1.5.0, high severity, and a CVSS 3.1 base score of 8.7.
Recovered record:
- Publisher host: api.github.com (GitHub Advisory Database)
- GHSA identifier: GHSA-wf43-fpp3-cf65
- CVE: CVE-2026-53608
- Ecosystem and package: npm, @apostrophecms/seo
- Affected range: through 1.4.2
- First patched version: 1.5.0
- Update time: 31 July 2026 (published 21:53:56 UTC; updated one second later)
- Severity: high; CVSS 3.1 base score 8.7
Measurement context: the CVSS 3.1 score is a severity measurement produced by the advisory’s scoring methodology; it describes the advisory’s assessed impact, not your organization’s exposure. The publication date is a fact about the record, not evidence that any customer was affected or is close to buying.
Why the evidence boundary matters
The record establishes the advisory’s own facts; it does not establish what happens inside your environment. Verifying a claim for sales means stating precisely what is confirmed and what is not. That precision is what keeps a briefing defensible.
Composite example — not a real customer message. A partner forwards a screenshot in a Telegram group captioned: “GHSA-wf43-fpp3-cf65 is live, CVSS 8.7, all our accounts are exposed, patch everything by Friday.” The accounts and the deadline are illustrative only.
The recovered record splits the caption cleanly: confirmed are the advisory, the CVSS score of 8.7, and first patched version 1.5.0; unconfirmed are whether any partner account runs an affected version, whether the flaw is exploitable in their configuration, and the Friday deadline — none of these appears in the advisory record.
What remains unknown, and who must verify it:
- Whether your organization or the partner’s depends on the package at an affected version — checked by your engineering or security team against the local dependency inventory.
- Whether the flaw is exploitable in your configuration — checked by the security team against the affected component and environment.
- Whether the Friday deadline is a real business constraint — asked of the partner directly; a screenshot caption is not evidence of urgency.
The screenshot may arrive through Telegram: Telegram’s Privacy Policy describes bots as independent third-party services that can operate with or without message access, with the mode shown in the interface, and says third-party bot developers should ask permission before accessing data (accessed 3 August 2026). Any tooling that collects forwarded messages therefore stays limited to groups a user intentionally connects. Which official source proves which claim is its own routing problem, covered in official vulnerability source routing.
Only after the independent recovery method above is complete does tooling enter the picture, with the same limits. TOP Prospect processes only Telegram groups you intentionally connect and are authorized to access, produces candidates for review rather than fact certification, leaves the decision to a person, and does not contact group members automatically. It can surface a forwarded advisory screenshot among other mentions in the groups you follow; the recovery and local-dependency check remain yours to run. See the product overview.
FAQ
What if the screenshot shows only a CVE number and no GHSA?
Filter GitHub’s global advisory list by the CVE identifier; the returned record includes the matching GHSA. If nothing comes back, the CVE may be mistyped or from a different publisher — state it as unverified.
The GHSA lookup returns nothing — is the advisory fake?
Not necessarily. GHSA identifiers are three groups of four characters, so one mistyped character breaks the lookup; the advisory may be withdrawn or private, or the screenshot may show a non-GitHub page. Compare the identifier character by character before concluding.
Does a published advisory mean my organization is affected?
No. The record establishes the advisory’s facts; whether you are affected depends on whether the package appears in your local dependency inventory at an affected version. That check is separate and belongs to your engineering or security team.
Next step: take the last advisory screenshot you received and rebuild the six-field record before opening any GitHub page. If the fields match the database record, you have a citable source; if not, you caught a forwarding error early. Either result is worth the two minutes.
Frequently asked questions
What if the screenshot shows only a CVE number and no GHSA?
Filter GitHub's global advisory list by the CVE identifier; the returned record includes the matching GHSA. If nothing comes back, the CVE may be mistyped or from a different publisher — state it as unverified.
The GHSA lookup returns nothing — is the advisory fake?
Not necessarily. GHSA identifiers are three groups of four characters, so one mistyped character breaks the lookup; the advisory may be withdrawn or private, or the screenshot may show a non-GitHub page. Compare the identifier character by character before concluding.
Does a published advisory mean my organization is affected?
No. The record establishes the advisory's facts; whether you are affected depends on whether the package appears in your local dependency inventory at an affected version. That check is separate and belongs to your engineering or security team.