Lynx has still had remote code execution CVEs in the past. It's probably a smaller attack surface than a regular browser, but far from nonexistent.

It's been over a decade since there was an RCE for Lynx. The difference between the attack surface of Lynx compared to a regular browser is several magnitudes. No code is safe, but giving someone grief over following a link using Lynx is security theater at its worst.

Downloading and executing code is only one way a browser session can be abused. At the very least you're giving away everything your browser (even Lynx) puts in the headers of a request. That's often a heck of a lot of useful information for an attacker. Lynx supports cookies too so it would be possible to track a user between sessions. I don't know how that might benefit an attacker but I'm not an attacker[1].

I think a reasonably paranoid approach like "Hackers might think of ways to abuse this that I haven't thought of" is best. Unless your job is to take a risk and visit a phishing site, don't take the risk. Even with Lynx.

[1] Exactly what an attacker would say!

>At the very least you're giving away everything your browser (even Lynx) puts in the headers of a request.

Which you're giving away any time you browse any external web site.

>Lynx supports cookies too so it would be possible to track a user between sessions.

You're downloading cookies for most external web sites.

If the worst you do is the same as going to espn.com, then reprimand people for going to any external web site.

The point is that you're giving data to a known phishing site by visiting the link in a phishing email. It's true that ESPN might also be a phishing site but it's less likely.

And my point is the data you're giving is not important.

By default, Lynx prompts to deny/accept cookies for every domain.