Security: Please enable private vulnerability reporting

[BhujArc24]

Hi @jacktuck,

I've identified a security vulnerability in unfurl.js (SSRF-class) and have a working PoC plus suggested fix.

I tried to use GitHub's private security advisory at /security/advisories/new but it returns 404 — looks like private vulnerability reporting isn't enabled on this repo.

Could you either:

1. Enable private vulnerability reporting (Settings → Security → "Private vulnerability reporting"), or
2. Share an email I can send the report to?

Happy to coordinate disclosure on whatever timeline works for you. Not posting details publicly until you've had a chance to review.

Thanks

[jacktuck]

Hi @BhujArc24 .

Is this about the SSRF you've emailed me about? I'm not sure I consider validation of user input to be part of unfurl.

But If you want to make a PR I would be happy to review it.

[BhujArc24]

Hi @jacktuck, thanks for the quick response.

Quick clarification, I haven't emailed you, this issue is my first
contact. You mentioned "the SSRF you've emailed me about", was that
from a different reporter? Want to make sure I'm not duplicating
someone else's work.

On the validation question: I understand the philosophical position
that URL validation is the caller's responsibility. The reason I
flagged this as a library-level concern rather than caller-level is
the second-order behavior, unfurl auto-fetches oEmbed href values
extracted from server responses, which means even callers who fully
validate their input URL can be pivoted to internal targets via a
malicious public page. That's not something a caller can defend
against without modifying unfurl's behavior.

Happy to share the full PoC + suggested patch privately so you can
evaluate. What's the best way to send it, email, or would you prefer
I open a draft PR with the fix and the writeup?

Thanks

[jacktuck]

The reason I flagged this as a library-level concern rather than caller-level is
the second-order behavior, unfurl auto-fetches oEmbed href values
extracted from server responses, which means even callers who fully
validate their input URL can be pivoted to internal targets via a
malicious public page. That's not something a caller can defend
against without modifying unfurl's behavior.

This is a fair point. It sounds like you are also describing the SSRF scenario I've already been asked about via email. (Which is an odd coincidence?)

I understand the scenario so no need for a PoC. I'm happy for you to go ahead with a draft PR with the fix if you would like to do so. May as well validate the user input as well .

How did you find this btw. Are you using unfurl yourself?

[BhujArc24]

Awesome, will put a draft PR together now with input validation + oEmbed href validation + redirect re-validation.

To answer your question: not using unfurl in production myself. I was looking at the URL-fetching library space for security audit practice and unfurl came up as a well-built but under-audited target. Read through src/index.ts, noticed the fetch path didn't resolve + check destination IPs before requesting, built a quick PoC to confirm. Took about 20 minutes once I knew where to look.

Will tag you on the PR shortly.