Step 319. Submitting Your First Report & Handling Triage — The Real Work Starts After the Button

Level 4 — Reporting, CVE Analysis & Open-Source Contribution | Difficulty ★★★☆☆ | Estimated time: 2 hours

Prerequisites: you wrote an acceptance-worthy report in Step 318. You understand the target program’s scope and rules.

What you need: the finished report (Step 318’s deliverable), an account on the target program, and a note for recording verdict results. This is a reading-and-roleplay chapter with no command exercises.
Caution: ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. This environment has no external network access, so platform screens and triager messages are all marked as "screen examples."

In Step 318 you finished the report. But the moment you press the submit button, the work doesn’t end — it begins. The report lands on the desk of a person called a triager, and by that person’s verdict it becomes valid, duplicate, or rejected. Today you learn the whole flow of "submit → triage → verdict → follow-up," the basic English expressions for communicating with a triager, and how to write a polite re-review request against a rejection verdict. Not getting discouraged even if your first report is rejected — that is this chapter’s real goal.

1. Learning Objectives

By the end of this chapter, you will be able to:

Explain the triage flow a submitted report goes through (intake → review → verdict)
State the meaning of the four verdicts (valid/duplicate/informative/N/A) and the follow-up action for each
Write basic English expressions to answer a triager’s follow-up questions within 24 hours
Name five common rejection reasons, and write polite sentences requesting a re-review when you disagree
Interpret a verdict as "free coaching" and reflect it in your next discovery plan

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Reporting-platform website (screen examples) + a note for records
Today’s tools	Submission form, triage message thread, verdict status display
Concepts needed	Triage, the 4 verdict types, basic English report expressions, reputation
Today’s deliverable	A "report progress tracker" — a timeline from intake time to final verdict and reason

2-1. Triage — A Word from Emergency-Room Prioritization

Triage is originally the work of classifying emergency-room patients by severity. Same in bug bounty. The triager reads and classifies the dozens of reports arriving each day — "is it a real vulnerability," "is it in scope," "was it already reported."

The triager is not your enemy. They’re a fellow security professional processing hundreds of reports, and the clearer your report, the easier their job — and the faster your verdict. The reason you carefully wrote reproduction steps and evidence in Step 318 shows up here.

2-2. The Four Verdict States

Names differ slightly per platform, but the verdict skeleton is four.

Verdict	Meaning	Your follow-up action
Valid (valid / triaged)	Vulnerability acknowledged. Awaiting fix or reward in progress	Record it, cooperate with the retest if asked
Duplicate	Someone already reported the same vulnerability	A pity, but normal. Read the reason, adjust discovery direction
Informative	A real vulnerability but below the reward bar (small impact or best-practice level)	Decide whether to dig deeper into this class
Not applicable (N/A)	Cannot be acknowledged as a vulnerability (out of scope, rule violation, misunderstanding, etc.)	Understand the reason exactly, decide whether to resubmit

A duplicate verdict is a rite of passage every hunter goes through. Even professional hunters’ valid rates are lower than you’d think. If your first report is a duplicate it’s a shame, but it’s also proof that "what I found was a real vulnerability."

2-3. Communication Is Reputation

The triage process mostly proceeds in a message thread inside the platform. Your attitude there builds a hunter’s reputation. A fast, accurate, polite hunter stays in the triager’s memory and gets a favorable starting point on the next report. Conversely, a hunter who protests emotionally or answers late can cloud even a report that deserved a good verdict.

It’s fine if English feels burdensome. Triage messages aren’t literature; they’re information transfer. Short, accurate sentences beat elegant ones. Section 3-4 organizes expressions you can copy and use as-is.

2-4. Waiting Is Also a Process

A verdict takes days to weeks. Doing nothing in that wait but refreshing the result is a classic beginner pattern. While waiting, ① keep exploring other spots on the same target, ② start recon on another target, or ③ organize your report records. A hunter’s time is not time spent waiting for verdicts — it’s time spent preparing the next report.

3. Follow Along

Today you follow not commands but procedures and sentences. In this environment with no external network, platform screens and messages are reconstructed as examples, giving you formats you can use as-is for your real reports.

3-1. Just Before Submitting — The Final 3-Minute Check

Before pressing the submit button, confirm three things again.

[ ] scope re-check — are the domains/features I tested inside the program rules?
[ ] reproduction steps standalone-executable — can a triager follow them with only my evidence?
[ ] evidence attached — are screenshots/video/request logs all in, nothing missing?

How to read it: reports fired off skipping this check come back N/A most often. An out-of-scope report in particular can mean not just no reward but a program-rule violation with account penalties. Three minutes of checking prevents weeks of re-review.

3-2. Submitting and Recording — Making a Report Progress Tracker

After submitting per the form, make a tracker in your note. Even if the platform shows the status, the habit of recording in my note, in my language, becomes a portfolio later.

Tracker example:

Report #:      #2026-0412
Program:       example-corp bug bounty
Submitted:     2026-09-09 14:20
Title:         Stored XSS in profile bio field
Status:        New (received)
Verdict date:  (pending)
Verdict:       (pending)
Reason/notes:  (pending)
Next action:   awaiting reply — keep exploring other input fields on the same target

Why do this: once reports pile up, you can’t manage which is in what state in your head. With this table, together with the CVE-analysis records of Steps 320–322, it becomes a "research activity log."

3-3. When a Triager’s Question Arrives — The 24-Hour Rule

A message arrives in which the triager asks for what they need to reproduce. Screen example:

Triager: Thanks for the report. I followed your steps but the payload
did not execute on my end. Could you share:
1. The exact browser and version you used
2. A short screen recording of the reproduction
3. The full request/response (with session cookies removed)

How to read it: they asked for three things — environment info, video evidence, traffic logs. The answer to this goes out within 24 hours. A report that stalls slides down the thread, and slides out of the triager’s memory too. The principle when answering: give exactly what was requested, and don’t add what wasn’t.

Answer example (a format you can copy as-is):

Hi, thanks for checking.

1. Browser: Chrome 128.0.6613.120 (Windows 11)
2. Recording attached (repro.mp4, 45 seconds).
3. Full request/response attached (request.txt). Session cookies removed.

The payload only fires after the profile page is reloaded — step 4 in
my original report. Please let me know if you need anything else.

Why do this: the quality of your answer to a question is your second report. If a condition missing from the report surfaces — like "it fires only after a reload" — honestly acknowledge it and add the information. Hide it and you lose trust; own it and you gain trust.

3-4. The Basic English Expressions Cheat Sheet

Sentences frequently used in triage threads. Copy them as-is.

Situation	Expression
Providing additional info	`Here is the additional information you requested.`
Asking them to retry	`Could you try again after a hard refresh (Ctrl+F5)?`
Explaining a condition	`The issue only occurs when the user has already logged in.`
When you need time	`I need a day to prepare a clearer PoC. I will update you by tomorrow.`
Thanks	`Thanks for the quick triage.`
Requesting a re-review	`I respectfully disagree with the severity assessment. May I explain why?`

How to read it: all short. Triagers don’t grade grammar. A sentence containing "what / when / how" is enough. Saying you don’t know what you don’t know (I'm not sure, but let me test that and get back to you.) is also a perfect answer.

3-5. A Verdict Arrived — Follow-Up for the Four Cases

Valid (triaged) verdict example (screen example):

Status changed: New → Triaged
"We have validated the issue and forwarded it to the engineering team."

Congratulations. Record the verdict and date in the tracker, and cooperate when a fix-verification (retest) request comes later. And leave one line in your portfolio as "my first valid report."

Duplicate verdict example (screen example):

Status changed: New → Duplicate
"This issue was already reported by another researcher."

A pity, but not a failure. It means you found, by your own power, a vulnerability real enough that someone found it first. Read the reason — when was it first reported, and so on — and adjust strategy, like aiming next time at a deeper spot or a less competitive target.

N/A verdict example (screen example):

Status changed: New → Not Applicable
"The reflected value is properly encoded in the response body.
Self-XSS in the admin panel is out of scope per program policy."

Here it forks two ways. If the reason is right, take it as learning and move on. If you’re convinced the reason is wrong — it reproduces, yet they say "it’s encoded" — go to 3-6’s re-review request.

3-6. The Re-Review Request — Polite but Evidence-Based

Sentences for when you disagree with a verdict are written with evidence, not emotion.

Re-review request example:

Thank you for the review. I respectfully believe the issue is valid,
and I would like to ask for a second look.

The triage note says the value is encoded in the response body. That is
true for the profile page. However, the same value is rendered WITHOUT
encoding on the public share page (/share/{id}) — please see the
attached screenshot and the new request log.

Reproduction on /share/{id}:
1. (steps re-stated)

If this endpoint is also considered safe, I will accept the decision.
Thank you for your time.

How to read it: can you see the structure? ① Thanks and respect → ② acknowledge the part of their claim you can acknowledge → ③ but present new evidence (a spot they missed) → ④ a line saying you’ll accept it if it’s still a no. This structure works beyond bug bounty, in every technical dispute.

Why do this: even if the re-review isn’t accepted, this message itself raises your reputation. Conversely, an emotional message like "Why was this rejected?? I spent hours!!" casts a shadow over the verdicts of your next reports.

4. Missions & Exercises

Mission — A Report Progress Tracker and a Triage Roleplay

Submit Step 318’s report (or a practice fictional report) to a real program, or if you can’t submit, fill in the tracker through the submission date as a "submission simulation"
Make a report progress tracker in the 3-2 format and update it whenever the status changes
Write an answer in English to 3-3’s triager question (screen example), fitted to your own report’s content
Assume you received a fictional verdict of "N/A — self-XSS is out of scope," and write a re-review request message in English in the 3-6 structure

Exercises

Exercise 1. Explain each of the four verdicts (valid/duplicate/informative/N/A) in one sentence, and state why a duplicate verdict is "not a failure."

Exercise 2. A triager sent a question: "I’m stuck at step 3 of the report." What information should the answer include, and within how much time is it best to reply?

Exercise 3. Point out at least two problems with this re-review request: This is ridiculous. Your triager clearly did not even try my steps. Reopen this NOW.

Exercise 4. Name one thing to do and one thing not to do during the verdict-waiting period (days to weeks).

5. Model Answers & Completion Criteria

Mission Model Answer

The tracker passes if real values fill the 3-2 example format. The key is "were the verdict date and reason recorded regardless of the outcome" — the more rejected the report, the more detailed the reason you should write. That’s the compass for your next discovery.

Model example of a triager answer (for a fictional Stored XSS report):

Hi, thanks for checking.

1. Browser: Firefox 130.0 (Windows 11)
2. Recording attached — note the payload fires only after the bio is
   saved AND the page is reloaded (step 4 in my report).
3. Request/response attached with cookies removed.

Happy to provide anything else.

A model re-review request follows 3-6’s structure: ① respect ② acknowledge the right part of their claim ③ new evidence ④ acceptance line. All four elements present is a pass.

How to verify: ① does the tracker have at least "submitted date/status/next action"? ② does the English answer follow the 24-hour rule and the "exactly what was requested" principle? ③ does the re-review request carry evidence without emotional expressions?

Exercise Answers

Answer 1. Valid: the vulnerability is acknowledged and moves to the fix/reward process. Duplicate: another researcher already reported the same vulnerability first. Informative: a real vulnerability but with impact too small to reach the reward bar. N/A: the vulnerability itself isn’t acknowledged, due to out-of-scope, rule violation, misunderstanding, etc. A duplicate is not a failure because it’s verification that you found a genuinely existing vulnerability yourself — just later than someone else.

Answer 2. Include the execution environment (browser/OS version), a reproduction video or more detailed steps, and request/response logs with secrets like cookies removed. Answering within 24 hours is best. If a condition needed for reproduction was missing from the report (e.g., a reload is required), honestly state that fact too.

Answer 3. ① It’s emotional and accusatory (ridiculous, NOW). ② It has no grounds — it doesn’t say why it should reproduce or what condition the other side missed. ③ With no acknowledgment of the other’s claim, it becomes a protest, not a conversation. A message like this lowers the odds of re-review and erodes reputation.

Answer 4. Do: keep exploring other spots on the same target or start recon on a new target (including organizing report records). Don’t: refresh the verdict status several times a day while waiting, or submit the same vulnerability to another channel (vendor email, social media) before a verdict — double submission can be a program-rule violation.

Completion Criteria Checklist

[ ] I can explain the flow of intake → triage → verdict
[ ] I can state the meaning of the 4 verdict types (valid/duplicate/informative/N/A) and their follow-up actions
[ ] I can write an English answer to a triager’s question using the 3-4 cheat sheet
[ ] I can list common rejection reasons (out of scope, cannot reproduce, impact below bar, misunderstanding)
[ ] I can write the re-review request’s 4-part structure (respect → acknowledgment → evidence → acceptance)
[ ] Mission: I completed the report progress tracker and the triage-roleplay sentences

6. Common Pitfalls & Fixes

Wall 1. After submitting, it turned out to be out of scope

Symptom (screen example):

Status changed: New → Not Applicable
"This asset is out of scope per program policy."

Cause: you skipped the scope re-check before submitting. The scope list on the program page changes from time to time.
Fix: pin "open the scope page again just before submitting" to your checklist. If it already happened, record the reason and use it to prevent recurrence on the next report.

Wall 2. The triager says "I can’t reproduce it"

Symptom (screen example): I could not reproduce the issue following your steps.

Cause: in most cases there’s a hidden premise in the report — login state, a specific browser, a reload, specific account permissions.
Fix: don’t panic; like 3-3, submit environment info, a video, and logs within 24 hours, and state the "trigger condition" explicitly in a sentence. A video is the strongest evidence.

Wall 3. No verdict for weeks

Symptom: the status is stuck at New or Triaged.
Cause: the triage queue is backed up, or the vendor’s confirmation is slow. Not a problem you can solve.
Fix: if the platform rules allow reminders, send one polite nudge every week or two (Hi, just checking if there is any update. Thanks!). In between, spend the time on the next discovery.

Wall 4. My re-review request made things worse

Symptom: after the re-review request, the triager’s replies turned cold.
Cause: emotion or assertions got mixed into the request ("it is clearly a vulnerability" is an assertion; "I reproduced it" is grounds).
Fix: look at 3-6’s structure again. If the sentence that first acknowledges the right part of their claim is missing, a request turns into an argument. Even in the next message, you can bring the tone back with "let me double-check whether there’s a condition I missed."

Wall 5. My first report was a duplicate and my hands won’t move

Symptom: days have passed since the Duplicate verdict and you can’t do anything.
Cause: a normal emotion. But the facts are different — a duplicate is not a "wrong report" but a "late correct answer."
Fix: write one line of "what did I learn" in the tracker’s reason box. Information like "this input field is fiercely competitive" or "this target is already heavily mined" is strategic capital for the next discovery. Pro hunters have low valid rates too — rejection reasons are free coaching.

7. Summary

Today’s Concepts

Concept	One-line explanation
Triage	The procedure that reviews and classifies incoming reports — a word from emergency-room classification
Triager	The security professional who first reads and judges reports — a colleague, not an enemy
Valid (valid/triaged)	The vulnerability-acknowledged verdict
Duplicate	An already-reported vulnerability — a late correct answer, not a wrong one
Informative	A real vulnerability but below the reward bar
N/A	Vulnerability not acknowledged — read the reason, take it as learning or a re-review
Reputation	A hunter’s intangible asset accumulated through communication attitude

Today’s Sentences & Formats

Tool	What it does
Report progress tracker	Timeline management from submission date to verdict reason
The 24-hour rule	The response deadline for triager questions
`Could you share...` patterns	The triager’s representative follow-up request forms
Re-review request 4-part structure	Respect → acknowledgment → new evidence → acceptance

The Core Instinct

The submit button is not the end but the start of a conversation. And the quality of that conversation — fast, accurate, polite — lasts as long as technical skill. More important than the verdict is the record. Valid, duplicate, or N/A, one tracker line with the reason written changes the direction of your next report.

Lastly, if your first report is rejected, being deeply disappointed is normal. When that happens, remember this one sentence — "rejection reasons are free coaching." Understand why it didn’t work and reflect it in the next candidate — that itself is skill.

Once every box is checked, Step 319 is complete.