2026/09/03

12:56 Using HackerOne and Intigriti is a terrible experience

I would like to record a video one day about how terrible the UX of these two platforms, it is a complete joke that such low-quality products are being used as the standard of reporting vulnerabilities. I might update this this post later with more critique of UX of these platforms, it's just terrible and unusable. See for example the following screenshots when you are opening Intigriti from a mobile phone:

../i/12:56_Using_HackerOne_and_Intigriti_is_a_terrible_experience/2026-09-03_13-55-19_screenshot.png
../i/12:56_Using_HackerOne_and_Intigriti_is_a_terrible_experience/2026-09-03_13-55-31_screenshot.png
../i/12:56_Using_HackerOne_and_Intigriti_is_a_terrible_experience/2026-09-03_13-55-44_screenshot.png
../i/12:56_Using_HackerOne_and_Intigriti_is_a_terrible_experience/2026-09-03_13-55-58_screenshot.png

The website is just not usable, it shows a desktop version (which is already badly designed). Anyway I had a terrible experience with Intigriti workers after I was trying to submit a vulnerability to NVIDIA related to slurmstepd (Nvidia bought Slurm a while ago). Now check the discussion. After I created the report (which, mind you, is a critical root escalation) I got a response form them after around a month telling me that we are only working on Nvidia's assets and this is not one of them.

This was just astonishing. I realized then that, I am probably not dealing with an Nvidia employee even (looks like the researchers of that platform are outsourced engineers and not specialized in these products). I would just leave the comments timelien here to document this terrible experience:

Them:

pedrazinho [ triage ]
19/08/2026, 15:52:17
Hi @lr0,
Thanks for your submission. Upon reviewing your report, we noticed that
Slurm is developed by SchedMD, not NVIDIA. Please report this to SchedMD's
security team and this kind of issue is not in scope for this program.
Unfortunately, we cannot forward your report to the company and we will
close it as out of scope.
Please, also ensure that you read the full scope guidelines before
conducting any testing, for reasons indicated in our community code of
conduct.
We'll close this accordingly but don't let this discourage you, we look
forward to your next findings.
Have a good day!
Best regards,
@pedrazinho

Me:

lr0 [ researcher ]
25/08/2026, 16:31:40
@pedrazinho https://github.com/SchedMD/slurm/security
Mentions this form here.

Them:

pedrazinho requested feedback
26/08/2026, 15:58:51
Hi @lr0 ,
Thanks for your feeback. We've had a look at your report and we need a bit
more information from your side.
Could you give a clear reproduction procedure?
Thank you. Waiting for your feedback. Have a good day!
Best regards,
@pedrazinho

Me:

lr0 [ researcher ]
27/08/2026, 08:03:48
Hi @pedrazinho,
I think the attachements should suffice in that, however I was looking into
it this morning and I find it pointless to keep on it,looks like the issue
has already been resolved upstream and re-standing up a cluster to
demonstrate a now-patched bug isn't a good use of my time.
I understand the timeline as follow;
2026‑07‑26; reported
2026‑08‑11; patched upstream by SchedMD, 57083deba5d3, 16 days after my
submission
2026‑08‑19; first response from your side, mistakingly closed out of scope
(24 days after submission!)
2026‑08‑25; reopened to Triage after I pointed out the scope determination
was incorrect
2026‑08‑26; reproduction requested The original report included a full
AddressSanitizer trace showing an unprivileged local user corrupting the
heap of a root slurmstepd via REQUEST_GETPW with a negative lengt, and it
was independently fixed upstream before it received a first substantive
review here.

Them:

pedrazinho [ triage ]
27/08/2026, 14:42:04
Hi @lr0,
Thanks for your feedback. The original report don't include reproduction
steps in the report description which is required. It only include the c
file and the cash script. If the latest version was the vulnerable version
at your time of writing feel free to use/checkout the affected branch and
it will be triaged. For the moment, we'll need to close your submission as
Informative. Please note that it won't affect your ranking.
If you have any questions, please tag me in your comments. Have a good
day!
Best regards,
@pedrazinho

Me:

logo
lr0 [ researcher ]
27/08/2026, 14:53:23
edited at 27/08/2026, 14:53:53
@pedrazinho "only the c file and the crash script" sorry this is just
false. I made it clear under the PoC section there, it had;
-the exact build
-the cluster config
-how to get a root stepd: srun -N1 sleep 600 &
-the resulting socket path and mode (/var/spool/slurmd/_1.0, srwxrwxrwx)
-the precise attacker wire sequence: proto handshake to REQUEST_GETPW to
mode to uid=0 to len=-2 to 8 KB of 0x41 plus the ASan trace pinning the
crash to the exact source lines. Second, the run_scenario.sh is the
step-by-step reproduction eight labeled stages (A–H) that stand up MUNGE,
write slurm.conf, start slurmctld/slurmd, launch the step, verify the
slurmstepd is root, compile the client, run the attack as an unprivileged
user, and report the crash. A runnable staged script is a reproduction
procedure.
And yeah the latest version was the vulnerable version at the time of
writing. I filed on 2026‑07‑26; the fix (57083deba5d3,) was authored
2026‑08‑11 and merged to master 2026‑08‑25. Every version in existence at
submission was affected. Per your criterion, this qualifies for triage, you
can re-triage against that revision.

Funny enough an Nvidia employee stepped in:

digitaldoug [ company ]
02/09/2026, 03:13:32
@pedrazinho slurm is ours, is this a valid finding? Thanks!

Them:

pedrazinho requested feedback
02/09/2026, 18:29:42
Hi @lr0 ,
" I made it clear under the PoC section there". No, you're required to
provide the setup reproduction steps also which are not included in the
report or the bash script.
Could you please provite it also? Thank you!
Best Regards,
@pedrazinho

Me:

lr0 [ researcher ]
02/09/2026, 18:38:12
@pedrazinho The run_scenario.sh has the reproduction steps, unsure why you
keep dismissing that. But I give up following up into this if it needs more
than a month to get an update and a week (and an owner nudge?) to get a
reply. Feel free to close this or whatever.
@digitaldoug tl;dr; the vulnerability was fixed (perhaps unrelated to my
report) 24 after my submission (although the root cause is not fixed yet).
If you are the owner, I suggest improving the communication channel and
response time. I honestly regret using this platform instead of emailing
nvidia directly.

Them:

pedrazinho [ triage ]
02/09/2026, 18:59:53
Hi @lr0 ,
Your reproduction steps assumed a Slurm development environment. The script
handles runtime setup, not the initial build.
Best Regards,
@pedrazinho

At this point I just gave up talking to them, am I to understand they are expecting me to show them how to set up Slurm? Anyway I gave up and decided not to follow up, they ended up reporting to Nvidia finally after two months from the report. I don't think I will use that platform again. #Programming

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论