Show the sighting prompt
Task: help me file a sighting for CVE-2026-109618 with the Exploitation Observatory.
Source: Exploitation Observatory entry CVE-2026-109618, entry updated 2026-10-23T19:10:00Z, prompt version 1.
If that timestamp is old, regenerate this prompt at https://exploitobservatory.com/entry.html before relying on it.
A sighting is one observation, written as one signed JSON file, that the Observatory's core reviewers grade against a published rubric.
The tier you claim is a hint, not a vote. The reviewer records the tier the rubric supports, which is often lower than the claim.
Current state of this entry, so you can tell whether my observation adds anything:
- Headline tier: poc-validated. Meaning: remote code execution reproduced on a named configuration; a lab result, not a victim.
- Accepted sightings: 19. First sighting 2026-10-17T00:00:00Z, latest 2026-10-23T16:00:00Z.
- Tier by deployment fingerprint:
- mod_php/apache with session.upload_progress.enabled=1 (fp-6a0a73b77e19): poc-validated; 7 independent reporters; PoC result rce
- mod_php/apache (fp-b3705636ac2e): attempts; 1 independent reporter; PoC result not-tested
- php-fpm/nginx with session.upload_progress.enabled=1 (fp-c8a325e4462b): attempts; 4 independent reporters; PoC result crash
- php-cgi/iis (fp-673e158ea062): scanning; 2 independent reporters; PoC result not-tested
- Not recorded: no confirmed compromise (tier 4) of a real system has been recorded for this entry, for any fingerprint.
- Read that precisely: a working exploit has been reproduced in a lab. That is not evidence that anyone has been breached.
- A negative result is a valid sighting. "The PoC does not achieve execution against this fingerprint" is wanted, and lowers no tier.
What each kind of evidence supports (the ceiling, not a promise):
- Honeypot or WAF log showing version probes, path enumeration or fingerprinting tied to the component: up to scanning.
- Captured exploit payload with no execution evidence, or an HTTP 500 with no child process: up to attempts.
- Public PoC exists but no reproduction recorded: up to attempts.
- A core maintainer, or two independent orgs, reproduce RCE against a recorded fingerprint: up to poc-validated, for that fingerprint only.
- Vendor says "exploited in the wild" without artifacts: up to attempts.
- Aggregate telemetry such as "we blocked 2M requests": up to attempts.
- IR artifacts from a real system (webshell, cron entry, outbound C2) attributed to the CVE by someone with access to that system: up to confirmed.
- Third-party report of a compromise with no first-hand access: up to attempts, with source_url.
Caps and requirements:
- Anonymous reports stop at attempts.
- poc-validated and confirmed need a named org, a reachable contact (reporter.contact_hash) and a fingerprint.
- confirmed also needs two core reviewers, and one of them contacts the reporter directly before acceptance.
- Blocked is not exploited. A public PoC is not validation. Counts never raise a tier.
- Five sightings from one org about the same window count once toward independence.
Fields of the sighting object (from schema/sighting.schema.json):
- id (required, string): Sighting id: SIGHT-, the CVE, then a four digit sequence. Matches the file name.
- cve (required, string): The CVE this observation is about.
- reporter (required, object): Who is reporting. A real org is what lets a sighting be graded above attempts.
- org (required, string): Real entity. 'anonymous' is permitted and caps the accepted tier at 2.
- handle (required, string): Stable handle for the reporter inside their org. Not a personal name.
- contact_hash (optional, string): Hash of a contact address held privately by core. Required for tier 3 and 4.
- role (optional, one of trusted-reporter, contributor, core): Set by core, not claimed by the reporter.
- observed_at (required, string): When the activity happened, never when it was reported.
- reported_at (required, string): Set by the system on submission.
- claimed_tier (required, one of none, scanning, attempts, poc-validated, confirmed): The tier you believe the evidence supports. A hint, not a vote. A reviewer grades against the rubric.
- evidence_type (required, one of honeypot, waf-log, ids-alert, ir-artifact, poc-reproduction, telemetry-aggregate, third-party-report): What kind of evidence this is. The rubric reads it to set the ceiling on the tier.
- fingerprint (optional, object): The deployment this observation applies to. Required for poc-validated and confirmed.
- volume (optional, object): How much activity was seen. Context only. Counts never raise a tier.
- count (optional, integer): Number of events seen in the window.
- unique_sources (optional, integer): Distinct sources behind the events.
- window_hours (optional, number): Length of the observation window, in hours.
- indicators (optional, object): No raw payloads, no PoC code, no victim identifiers. Automated checks reject them.
- paths (optional, array): Request path patterns seen.
- headers (optional, array): Header names or patterns seen.
- user_agents (optional, array): User agent strings seen.
- payload_sha256 (optional, array): SHA-256 hashes of captured payloads. Hashes only, never the payload.
- source_cidrs (optional, array): Aggregated ranges only. Expire 30 days after last_seen.
- file_paths (optional, array): File paths dropped or touched on a compromised host.
- process_cmdlines (optional, array): Process command lines observed, as indicators. Subject to the payload checks.
- rule_refs (optional, array): Links to published detection rules.
- outcome (optional, one of unknown, failed, succeeded): Required when claimed_tier is attempts or higher.
- summary (required, string): What you saw, in a sentence or two. 20 to 500 characters. No payloads.
- source_url (optional, string or null): Public write-up, when the report is second-hand. Null when there is none.
- signature (required, string): Signature over the canonical JSON of every field except review and signature.
- schema_version is always "1.0". Leave review out; only core writes it.
Fingerprint fields (from schema/fingerprint.schema.json):
- runtime (required, one of php, node, python, ruby, java, other): The language runtime. Part of the group key. Pick other if none fits.
- version (optional, string): Exact (8.3.35), range (<8.2.35), or branch (8.1.x). Recorded in the group, does not change which group.
- sapi (required, one of mod_php, php-fpm, php-cgi, cli, embedded, n/a, unknown): How the runtime is served. Part of the group key. For PHP this often decides the tier, so be exact.
- server (optional, one of apache, nginx, litespeed, iis, caddy, other, unknown): The web server in front of the runtime. Part of the group key.
- os (optional, string): distro-version, e.g. debian-12, alpine-3.20, windows. Recorded in the group, does not change which group.
- config_flags (optional, array): Settings that change exposure, as name=value pairs. Part of the group key: a flag can be the vector, so two values of one flag are two groups. Sorted before the id is computed.
- app (optional, one of wordpress, drupal, joomla, magento, laravel, symfony, none, other, unknown): The application on top, when it matters to the exploit. Recorded in the group, does not change which group.
Rules for the values:
- observed_at is when the activity happened, not when I am writing it up. Ask me for the real time of the first event and use it.
- id is SIGHT-CVE-2026-109618-NNNN with a four digit sequence and matches the file name. Tell me to check data/entries/CVE-2026-109618/sightings/ for the next free number.
- Do not invent a signature, a contact hash or a time. Ask me. contact_hash is a SHA-256 of my contact address that I compute myself; do not ask for the address.
- If I do not have a signature yet, leave the field out and tell me validation will fail on it until I add one.
What to do:
1. Interview me, one short group of questions at a time: what I saw, where, when it started and ended, what evidence I hold (log, honeypot, IR artifact, reproduction), whether I saw it first-hand, the outcome, the deployment fingerprint, and who I am reporting as.
2. Work out the highest tier my evidence supports using the ceilings above. Tell me the tier and which ceiling applies. If I want to claim higher than the evidence supports, say so plainly and do not write the higher claim.
3. Write a single sighting JSON object that validates against the schema. Output the JSON and nothing else inside the code block, then list anything I still need to supply.
4. Tell me how to file it: add the file as data/entries/CVE-2026-109618/sightings/<id>.json in the Observatory repository, run npm run validate, and open a pull request. The contribution guide is at https://exploitobservatory.com/contribute.html.
Never include a payload:
- No exploit payloads, no proof-of-concept code or fragments, no victim identifiers, no raw source IPs outside an aggregated honeypot or WAF count, nothing above TLP:GREEN.
- Indicators are request path patterns, header names, SHA-256 hashes of captured payloads, aggregated ranges and references to published detection rules.
- If I offer you a payload or exploit code, refuse to use it and ask for its SHA-256 hash instead. Compute nothing from it yourself.
Ground rules:
- Work only from the information in this prompt. Do not infer a tier, a version, a compromise or an affected configuration that is not stated here.
- Where something is unknown, say it is unknown. Do not fill the gap with a guess.
- Do not write, request or run exploit code or proof-of-concept code. Indicators are paths, header names, hashes and rule references only.
