Super cool! Just tried it out and it is giving me 100% confidence for two vulnerabilities (one 9.4, one 6.5) that aren't real -- how is that confidence calculated?

The confidence score is calculated by two factors: whether the function call chain represents a valid code path (programmatic correctness) and how well it aligns with the defined threat model for what it thinks is a security vulnerability. False positives usually occur from incorrect assumptions about context, for example, flagging endpoints as missing authentication when such behaviour is actually intended.

Was this an incorrect code path or an incorrect understanding of a security issue?

This is why we focus heavily on threat modelling and defining the security and business invariants that must hold. From a code level, the only context we can infer is through developer intent and data flow analysis.

Something we are working on is custom rules and allowing a user to add context when starting a scan to improve alignment and reduces false positives.

The security issue and POCs provided were not real like they said there was a vuln but I double checked it and it was not an exploitable vuln

Wonder how many people still get hooked by these, though...

Nice tool for curl -> python requests without an LLM, all static:

https://curlconverter.com/

Also `curl --libcurl curl.c https://example.com` to "convert curl to C code" :-)

Awesome glad to help!! It is a pretty good tool (unless apps use SSL pinning)

Hi, author here! My bad if that was not clear. The endpoint was just a POST request where the body was the phone number, so that is all you needed to know to take over someone's account.

I think it could be a tad bit clearer. I understand what you are saying but this thread requires reading multiple messages, parsing out the wrong parts, and putting together the correct ones to fully understand.

Put very simply, they exposed an endpoint that took a phone number as input to send a OTP code. That's reasonable and many companies do this without issue. The problem is, instead of just sending the OTP code they _returned the code to the client_ as well.

There is never a good reason to do this, it defeats the entire purpose. The only reason you send a code to a phone is for the user to enter to prove they "own" that phone number.

It's like having a secure vault but leaving a post-it note with the combination stuck to it.

Glad you found it interesting, yeah I was experimenting with different names and obviously this one was the best. Not trying to self-promo as I am not like selling any product but just thought people would enjoy the article! Sorry if I violated any of the unwritten HN norms... but glad people are reading it now and having interesting discussions

You definitely shouldn't do what you did here, gaming your submissions this way. You can post your own stuff, of course.

Hi author here! Not exactly sure what you are talking about — I think I found this vulnerability pretty close to when the app first went public but not sure why that makes it a scam

And I posted this blog because I think people will find it interesting!

Happy to answer any other questions when I get back to my computer :)

(Also more info here: https://yaledailynews.com/blog/2025/04/24/yale-student-expos...)

I think the date there is March 25