> ## Documentation Index > Fetch the complete documentation index at: https://docs.pharussecurity.com/llms.txt > Use this file to discover all available pages before exploring further. # Disclosure inbox > Read, answer and triage vulnerability reports from your disclosure page and security mailbox, and declare an incident from one. **Plans:** Every plan, and Free. **Who:** any member reads, replies, triages and declares an incident; owners and admins remove a reporter's personal details. The **Disclosure inbox** collects every vulnerability report sent through your [disclosure page](/disclosure/disclosure-page) or by email to your inbound address. Each report keeps the whole conversation with the reporter and an append-only triage log, so you can answer the reporter, decide what the report is and show later how you handled it. ## Where reports come from **Web form.** A report from `/disclose/` arrives with the product family the reporter chose, the language of the form and whether they want to be credited. **Email.** Every email to the inbound address under **Settings → Disclosure** becomes a report. Forward your `security@` mailbox there. The email's subject becomes the report's subject, without `Re:` or `Fwd:` prefixes, and the sender's name and address are the reporter. Pharus keeps the message as plain text and only the names of attachments: "Ask the reporter to share files another way if you need them." **Acknowledgement.** When a report has an email address, Pharus emails the reporter straight away: "We received your report", with the report number, your acknowledgement time, the policy and the privacy notice. It goes out in the language of the form they used; an email report gets your company's **Default language**. Auto-replies, bounces and mailing-list mail get no acknowledgement. The triage log records "Acknowledgement sent". **Follow-ups.** When the reporter writes again from the same address, with the report number in the subject (for example `[#118]`) or as a reply to one of your emails, the message joins the report and the log records "Reporter wrote again". Mail from any other address opens a new report, even with a report number in the subject. ## The inbox list Open **Disclosure inbox** in the sidebar. The header links to your **Public form** and to **Disclosure settings**. The tabs filter by status: **Open** (New, Triaging and Accepted, the default), **New**, **Triaging**, **Accepted**, **Resolved**, **Duplicate**, **Rejected** and **All**. Each row shows the number, the subject and channel, the reporter, the product, the severity, when it was received, the first response and the status. A report without a name or address shows as "Anonymous reporter". The **First response** column shows where each report stands: | Shown | Meaning | | - | - | | Acknowledge by *date* | Nobody has replied yet; this is the deadline. | | Overdue | The deadline has passed without a reply. The most overdue report is highlighted. | | Answered | Someone replied, or changed the status of a report that has no email address. | | Closed without reply | The report was closed as Duplicate, Rejected or Resolved before anyone replied. | The deadline is the end of the last business day in your **Acknowledge within** setting, counted from the Oslo day the report arrived. Weekends and Norwegian public holidays don't count. The automatic acknowledgement doesn't stop the clock; your first reply does. For a report with no email address, the first status change does. ## Read a report Select a report to open it. The header shows when it was received (Oslo time), the reporter, the channel, the product family ("Not stated" if none), whether the reporter "Would like to be credited" and the first-response deadline. The **Conversation** card shows every message in the order sent and received: the reporter's on the left, yours indented with the sender's name, and the automatic acknowledgement as "Sent automatically". An encrypted message carries an **OpenPGP encrypted** badge and is shown as it arrived; decrypt it with your own key, outside Pharus. ## Reply to the reporter In **Reply to the reporter**, write your message. The card shows the reporter's address and the subject, which has the form `Re: [#118]`. Select **Send reply**. Pharus emails it to the reporter, adds it to the conversation and logs "Replied to the reporter". Your first reply stops the first-response deadline. The reply's reply-to address is your inbound address, so when the reporter answers, their message comes back to this report. The email's footer follows the language of the form the reporter used; the message is your own text, so write in the reporter's language. If the reporter left no email address, the card says "The reporter left no email address, so you can't reply from Pharus." Changing a report's status doesn't email the reporter. Tell them in a reply when you accept, decline or fix it. ## Triage the report The side panel on a report holds the triage controls. Every change goes into the triage log and the [audit trail](/reports/audit-trail). ### Status | Status | Meaning | | - | - | | **New** | Not looked at yet. | | **Triaging** | Being reproduced and assessed. | | **Accepted** | Confirmed as a vulnerability. Fix and advisory in progress. | | **Duplicate** | Already reported or already known. | | **Rejected** | Not a vulnerability, or out of scope. | | **Resolved** | Fixed and disclosed, or otherwise closed with the reporter. | Pick the new status, add an optional **Note** and select **Update status**. Duplicate and Rejected need a note: "Say why. The reporter may ask, and it goes in the triage log." ### Classification Set **Severity** (Critical, High, Medium, Low or None; "Not rated" until you do) and the **Product family**, then select **Save classification**. The product family also decides which SBOMs the upstream report draws on. ### Links Under **Links**, connect the report to what it is about: * **Vulnerability ID:** type an ID such as `CVE-2026-41120` or a GHSA ID and select **Link vulnerability**. The report then links to the vulnerability's page. * **Incident:** choose an open incident and select **Link incident**. Drills aren't offered. ### Triage notes Use **Triage note** and **Add note** for what you found, for example "Reproduced on Gateway G3 4.2. Not on 4.1." ### The triage log The **Triage log** is append-only: "Entries can't be changed afterwards." It records, with who and when: * Report received via web form or email, with the form language and the credit choice * Acknowledgement sent, replies, and each time the reporter wrote again * Status changes, with the note * Severity and product family changes * Links to a vulnerability or an incident * Notes * Removal of the reporter's personal data ## Declare an incident from a report If the report shows that a vulnerability is being actively exploited, or describes a severe incident, the CRA reporting clocks apply (CRA Art. 14(1) and 14(3)). Declare the incident from the report, so the two stay linked. Under **Links**, select **Declare incident from report**. Under **What happened**, pick **Actively exploited vulnerability** or **Severe incident**. Check the **Title** (the report's subject to begin with), the **Product family** and, for a vulnerability, the **CVE or vulnerability ID**. Set **Aware since**: when you became aware that the vulnerability is actively exploited, or that the incident is severe. That isn't when the report arrived, unless that is when you knew. It can't be in the future. Select **Declare incident**. The incident opens, linked to the report, with "From the disclosure inbox" as its source and the report number as the basis for awareness. The 24 h and 72 h clocks run from **Aware since**, in Oslo time. See [clocks](/incidents/clocks). On Free you can't declare an incident. The card says so instead: Pharus doesn't run the CRA clocks or prepare SRP packs on Free, so if the report needs reporting, file it in ENISA's Single Reporting Platform yourselves, or start a plan. ## Report the flaw upstream When the flaw is in a third-party component, the report page has a **Report to the component's maintainers** card. Set the report's product family first: the component comes from that family's SBOMs. Pharus drafts the report in English; you send it. See [report upstream](/incidents/report-upstream). ## Draft an advisory A report has no advisory button. Draft the advisory under **Advisories → Draft advisory**, or from the incident's **Customer advisory** card if you declared one. If the reporter asked to be credited, add their name under **Acknowledgments** in the advisory. See [advisories](/disclosure/advisories). ## Remove a reporter's personal details If a reporter asks you to delete their personal data, an owner or admin can remove it from the report. On the report, find **Reporter's personal data** and select **Remove reporter details**. Read the confirmation and select **Remove details**. Pharus removes the reporter's name, email address and IP hash from the report, its conversation, the triage log, the audit trail and the email log. The report then shows the reporter as "Removed on request". What they wrote stays, and so do your own notes: check them for anything else that identifies the reporter. This can't be undone. You can't reply to the reporter from Pharus afterwards, and new emails from them open a new report. Removing a reporter's details also works when the workspace is read-only, because the request can't wait for a subscription. ## Notifications for new reports * **Email.** Owners and admins with alert emails on get "New vulnerability report" with the number, subject, reporter, channel, product and the date to acknowledge it by. Each person turns alert emails off under **Settings → Notifications**. Members don't get these emails. * **Slack, Teams and webhooks.** On Core and Plus, and during the trial, a destination subscribed to "New disclosure reports" gets the report number, the product family and the acknowledgement deadline, never the reporter or what they wrote. See [notifications](/notifications/overview) and [outgoing webhooks](/api-reference/webhooks). ## On Free | Works on Free | Needs a plan | | - | - | | New reports from the form and by email, with acknowledgements | Declaring an incident from a report | | Reading reports and replying | Reporting upstream | | Status, classification, links and notes | Slack, Teams and webhook alerts | | Removing a reporter's details | | | **Settings → Disclosure** and the inbound address | | If an owner closes the workspace, no new reports arrive and the inbox is read-only, except for removing a reporter's details. ## Related The public form, policy and inbound address. What happens after you declare an incident. Send a flaw in a component to its maintainers. Tell customers what is affected and what to do. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.