Hackers Can Now Filter Reports by Asset Type
Hackers can now filter their own report inbox by asset type, making it far easier to navigate a large submission history.
What we did:
We added an Asset type filter to the hacker inbox (“My reports”).
Why we did it:
Hackers could already filter their inbox by state, severity, weakness, and program, but not by the type of asset they’d tested. Prolific hackers with hundreds of reports across many programs had no way to pull up “everything I’ve reported against mobile apps” or “all my source code findings”. Program teams have had asset filtering in their inbox for some time; this closes the gap on the hacker side and brings the hacker inbox in line with asset type filtering that already exists everywhere else hackers work.
Who it helps:
High-volume researchers who submit across many programs and asset classes, and anyone who specializes in a particular asset type (mobile, smart contracts, source code, AI models), and wants to review their own track record in that area. There is no change to the program or organization inbox, so no action is needed from customer security teams.
How to use it:
Go to your inbox and make sure My reports is selected.
Click Show filters.
Open the Asset type dropdown and select one or more asset types.
The report list narrows immediately. Clear the dropdown to return to all reports, or save the filtered view as a custom view.
Note: Filtering by asset type shows only reports tied to a program’s scoped asset. Reports submitted to a program with no structured scope won’t appear while an asset type filter is active.
Custom Inbox–Only Users Now Land on Findings
Users with only custom inbox access now go straight to Findings when they sign in or click the HackerOne logo. The Home item no longer appears in their navigation.
What we did:
We changed the default destinations for users with custom inbox access and no program access so that they land on the Findings page instead of the Home page. Home is not blocked. Anyone can still open it by URL or bookmark.
Why we did it:
Home's metrics are built from program access. Custom-inbox-only users saw no open submissions and blank widgets, which users found confusing, thinking that they had no actions to take when, in fact, there were open reports.
Who it helps:
Users who have access only through a custom inbox.
How to use it:
Nothing to enable. Affected users sign in and land on Findings, where their custom inbox reports appear. The logic is program-specific, so if a user has access to a custom inbox for only one program but full program access for a second program, they will be taken to the relevant view for that specific program.
Credential Revocation Alerts Now Cover Program Access Loss
Customer credential revocation notifications now fire consistently across all scenarios in which a researcher loses access to a program, including voluntary departure, program/org ban, and platform ban.
What we did:
Program, organization, and platform bans now trigger the same workflow as a voluntary departure: claimed credentials are marked as revoked in HackerOne, and customer program admins are emailed to revoke that access in their own systems. Previously, a program ban revoked credentials only in our UI, and a platform ban did neither, leaving customer-side credentials live. With a backfill to be completed on October 7, 2026.
Why we did it:
Marking a credential revoked in our UI hides the secret from the researcher, but it does nothing to the credential itself. The credentials keep working against the customer's systems until the customer disables them. Our docs place that step with the customer, but we weren't consistently telling customers when to take action.
Who it helps:
Customers using asset-based credential management. Their offboarding is now driven by a notification rather than by noticing.
How to use it:
Nothing to enable. Program admins receive the notification automatically; credentials are managed under Program Settings → Credentials. A backfill for researchers who left before September 17, 2026, when this change was released, will be completed on October 7, 2026. CSMs have been contacted with potentially impacted customers.
Documentation: Asset-based credential management
Higher Hacker Limit for Spot Checks
Programs can now invite up to 50 hackers to a spot check, up from the previous cap of 15.
What we did:
Raised the maximum number of hackers that can be invited to a single spot check from 15 to 50.
Why we did it:
The 15-hacker cap was hardcoded, but some programs routinely want to run spot check with ~40 hackers. Every one of those required a one-off engineering escalation to override the limit, a recurring support cost that didn't scale.
Who it helps:
Any program running spot checks at scale and the Support/Engineering teams fielding override requests. Immediate relief for AWS, who drove the original ask.
How to use it:
No action needed. When creating a spot check, the hacker-count field now accepts any value between 1 and 50.
Documentation: Docsite page