Links web browser 1.00pre12 and Elinks 0.9.2 with smbclient installed allows remote attackers to execute arbitrary code via shell metacharacters in an smb:// URI, as demonstrated by using PUT and GET statements.

A Debian bug report [1] indicated that Links does not properly verify SSL certificates. If you visit a web site with an expired SSL certificate, Links will only display "SSL error" without any indication as to what the error was. This, in and of itself, is not a flaw however when testing, I found that when you go to a site with a valid SSL certificate, but for a different hostname (for example, if you go to https://alias.foo.com which might be a CNAME or a proxy for https://foo.com) Links will connect without any errors or warnings. Doing the same in a browser like Google Chrome, however, reports "You attempted to reach alias.foo.com, but instead you actually reached a server identifying itself as foo.com." and allows you to either proceed or not, before loading the site.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694658

CRLF injection vulnerability in Lynx 2.8.4 and earlier allows remote attackers to inject false HTTP headers into an HTTP request that is provided on the command line, via a URL containing encoded carriage return, line feed, and other whitespace characters.

ELinks before 0.11.3, when sending a POST request for an https URL, appends the body and content headers of the POST request to the CONNECT request in cleartext, which allows remote attackers to sniff sensitive data that would have been protected by TLS. NOTE: this issue only occurs when a proxy is defined for https.

Untrusted search path vulnerability in the addfilenametostring function in intl/gettext/loadmsgcat.c for Elinks 0.11.1 allows local users to cause Elinks to use an untrusted gettext message catalog (.po file) in a "../po" directory, which can be leveraged to conduct format string attacks.