418sec / huntr Goto Github PK

It was raised that pre-GitHub database vulnerabilities/bounties are missing, meaning that Timeline activities are not being tracked on some profiles.

Thanks to @ferretwithaberet for raising this issue!

e.g. 039-js-valib and 053-js-vizion are old IDs that were not translated over to the new DB.

We need to:

1. Reconcile all previous vulnerabilities from the old database that are missing
2. Create vulnerability.json and README.md files for each
3. Associate the correct Discloser and Fixer IDs
4. Add these events to the Timeline database

We should look to have this done by the end of the week - cheers!

I was presented with a default pull request template when I was submitting a fix for remote code execution in cordova-serve. cordova-serve pull request template should be replaced by the default huntr pull request template

I was just looking into this vulnerability (https://www.huntr.dev/app/bounties/open/1-npm-commit-msg) and I couldn't reproduce it. I have fix based on the theory but In reality, this isn't exploitable.

Hi

One of the problems I see with removing bug bounties is that if we link to it (from thirty party websites), the link will go dead once a fix is been released for that bug bounty. It's a bad design because, on one side, research/programmers can't point the CVE/any proof to your website; secondly, it will also hurt SEO.

My suggestion would be to change it to design where you can still see the repo/program on huntr website (even if a fix is been released) the same thing like HackerOne where each application has multiple bugs submitted, and you can close that bug but still have all the conversations in it.

From a design perspective, wouldn't it be great to move reporting vulnerabilities to issues instead of a pull request? Once it is verified and reviewed by the team (as the researcher provided the PoC in the issue), someone from the community/author (security researcher) can make a pull request. I think it will benefit the security researcher to report vulnerability without making much effort (ASAP). Secondly, if they disclose the vulnerability and the reviewers find out it doesn't qualify for bug bounty, that would save a lot of time for the security researcher.

For reference: karuppiah7890/easy-pdf-merge#28 (comment)

This is because the GITHUB_TOKEN is not accessible for security reasons.
The suggestion is to revert to success/failure depending on the outcome of validation.

Please Provide a Feature Letting the Researcher know about Status of a bug if some one is working on that , did they already Provided a fix for the issue which helps the researcher to make a Priority based decision . which helps Researcher to select other issue or provide a better fix for existing Fix

The enricher is not supposed to create issues if an issue is already referenced within the vulnerability.json, however it is still creating them.

Bounty information page hyperlinks are difficult to spot

Of course, not all PRs entered are actually bugfixes, maybe a misunderstanding or maybe something that causes breaking changes.

For myself, I find it slow to navigate for issues that do not have a pull request for the issue and if it does, I have to go to the original issue in GitHub, it would be good to have:

1. A count of PRs open against an issue
2. Maybe some way of tracking the "amount of time it takes" to get a PR request reviewed (or declined).
   2a. this would really help provide a feedback loop to all that there was not an "accepted fix" because of side effects, breaking changes, not actually resolving the issue etc...