Copyright © 2001-2013,2014 by Thomas E. Dickey


lynx is designed to be run either as a single-user application, or as a server, e.g., as a web portal accessed via telnet.


To allow it to be used as a server, it has configurable restrictions on the types of operations which can be performed by a user. In theory, lynx is secure.

In practice, lynx suffers from its age: it was implemented largely in the mid 90's, by programmers who were not acquainted with modular/portable design. Repairing this is an interesting problem in maintainability (interesting to me at any rate). Since lynx does build and run on a wide variety of platforms, it cannot simply use two of the panaceas advocated by people who are familiar with the jargon of secure programming: mkstemp and snprintf:

Not all buffer manipulations fall readily into these categories; we review use of fixed-size buffers to ensure that they are being handled properly.


One problem with work in this area is that few people know much, but there is a lot of second-hand information. Second-hand information is frequently inaccurate.

Many of the posters of exploits to BugTraq, for instance, are more concerned with being first to post than with the accuracy of their postings. Much of the traffic relating to lynx, in particular is ultimately due to a system administrator (in this case, read "computer operator") who apparently favors FreeBSD over Linux, and has made numerous (a few are accurate) disparaging remarks relating to security on Linux. We have addressed the items that are based on facts, but it appears that the main reason there are no current reports is that this loose cannon has evolved into a "security consultant".

When preparing for lynx 2.8.3 (April 2000), I noted (after inspecting the related source code) that lynx's competitors (w3m and links) suffered from the same sort of issues. See for example w3m. For some reason, links appears to be ignored by BugTraq, though it is not unusual for that application to dump core.

In late 2001, I noted that while there there had been no security reports more recent than before lynx 2.8.3, common gossip continued that lynx is subject to multiple buffer overflows. (From 2009, that comment still holds; there are occasional issues to resolve, but "multiple buffer overflows" is nonfactual). It is in fact easier to fix the code than to stop the gossip. Report bugs if you find them. However, asserting in a BugTraq-style posting that one "could" cause a failure in a program is different from actually doing so.


It used to be the case that security teams would notify the developer of flaws and get them involved. Perhaps some still do, but for others, the goal appears to be guided by the intent to publish the flaw first. Since they're generally unfamiliar with internals of larger programs, the published fixes tend to fall short of solving the problem.

This advisory states "several vulnerabilities", though two are reported. Further, the patch (mostly code-cleanup) was one that I wrote, as inprogress development. However two organizations misattributed it to OpenBSD. Rather than checking with me to help with a minimal patch, they simply published it.

In an earlier advisory, I had responded to the report, and constructed a patch. The security team issued a different patch, which did not actually solve the problem, as I noted here.