The cryptography expert Bruce Schneier, who has been writing about computer security for more than fifteen years, is not given to panic or hyperbole. So when he writes, of the “catastrophic bug” known as Heartbleed, “On the scale of 1 to 10, this is an 11,” it’s safe to conclude that the Internet has a serious problem. The bug, which was announced on Tuesday—complete with an explanatory Web site and a bleeding-heart logo—is a vulnerability in a widely used piece of encryption software called OpenSSL.

Heartbleed is as bad as it is possible for a security flaw to be. It can be easily exploited by anyone on the Internet without leaving a trace, and it can be used to obtain login names, passwords, credit-card information, and even the keys that keep our encrypted communications safe from eavesdroppers. The bug first appeared in OpenSSL code that was released in March, 2012—so the vulnerability has been open to exploitation for more than two years. The Internet-security firm Netcraft reported that up to five hundred thousand sites thought to be secure were, in fact, vulnerable—including Twitter *, Yahoo, Tumblr, and Dropbox.

When you log on to a secure Web site—your bank’s, for example—you see a green-padlock icon at the top of your browser window, which confirms that your connection is secure. In order for browsers to communicate securely with servers, there is a standard set of steps that both sides must perform to create, and to maintain, that secure connection. This protocol is called Transport Layer Security, or T.L.S., and everything that it requires from both sides of a secure connection is laid out in a document called RFC 5246, which describes something like the Platonic ideal of a secure Internet connection. Of course, RFC 5246 cannot, by itself, be used to keep your bank account safe. To do that, someone has to write software that will make your Web browser and your bank’s Web server actually follow the steps that RFC 5246 delineates.

Among programmers, cryptography is notorious for its difficulty—even a tiny mistake can render your seemingly secure code worthless—and the conventional wisdom is that, whenever possible, the implementation of cryptography should be left to the experts. Since 1998, one way that programmers have been able to avoid implementing encryption protocols themselves has been to use an open-source library called OpenSSL. A code “library” is just a set of common functions that programmers can use within their own code, rather than having to write them from scratch. If many people are all using the same library, and the code is open-source—so that anyone can check it for bugs—it should be more reliable and more secure than a code that one person or firm could create alone.

Heartbleed is a bug in OpenSSL’s implementation of a small part of the T.L.S. protocol, called the heartbeat extension. A “heartbeat,” in this context, is like the “beep… beep…” of a hospital heart monitor: a quick way to check that the other end of a secure connection is still there. One side sends the other side a small piece of data, up to sixty-five kilobytes long, along with a number indicating the size of the data that has been sent. The other side is supposed to send back the exact same piece of data to confirm that the connection is still active. Unfortunately, in OpenSSL the replying side looks at the stated size of the data rather than at the actual size, and it always sends back the amount of data that the request asked for, no matter how much was sent. This means that if the stated amount of data is more than the amount actually provided, the response contains the data that was sent plus however much additional data, drawn from the contents of the computer’s system memory, is required to match the amount requested.

Here is why this is so bad: the heartbeat response can contain up to sixty-four kilobytes of whatever data happens to be in the server’s random access memory at the moment the request arrives. There is no way to predict what that memory will contain, but system memory routinely contains login names, passwords, secure certificates, and access tokens of all kinds. System memory is temporary: it is erased when a computer is shut down, and the data it holds is written and overwritten all the time. It is generally regarded as safe to load things like cryptographic keys or unencrypted passwords into system memory—indeed, there is little a computer can usefully do without temporarily storing pieces of sensitive data in its system memory. The Heartbleed bug allows an attacker to “bleed” out random drops of this memory simply by asking for it. Heartbeat requests aren’t usually logged or monitored in any way, so an attack leaves no trace. It’s not even possible to distinguish malicious heartbeat requests from authentic requests without close analysis. So an attacker can request new pieces of system memory over and over again; it’s almost impossible for the victim to know they’ve been targeted, let alone to know what data might have been stolen.

Among the items that can be found in a server’s system memory are the keys to cryptographically secured connections and the certificates that allow servers to prove they are what they claim to be. An attacker who steals cryptographic keys could use them to decode and read encrypted data that had previously been intercepted; an attacker who steals certificates could use them to mimic a secure site and to intercept communications. In other words, your browser could be tricked into thinking that it’s connected securely to your bank and instead be connected to an intermediary that can read all the data flowing back and forth.

In the worst-case scenario, criminal enterprises, intelligence agencies, and state-sponsored hackers have known about Heartbleed for more than two years, and have used it to systematically access almost everyone’s encrypted data. If this is true, then anyone who does anything on the Internet has likely been affected by the bug.

But, before you panic, it is worth remembering that, at this point, we don’t know how close we are to the worst-case scenario. It is possible, though improbable, that the security researchers who exposed this flaw were, in fact, the first people to find it, which would mean that it has only been known about, and exploited, for a few days. (It was found, independently, by a team of security researchers at Codenomicon and Neel Mehta, of Google Security.) At the same time the bug was announced, a new, secure version of OpenSSL was released, and updating most of the affected servers is a straightforward task. Major services like Google and Yahoo have already patched the vulnerability. Engineers did not need to stay up all night in a mad scramble to make repairs, but, as one system administrator told me, the nature of the bug made this something more than a routine update. “It’s an update, a configuration change, and a notification to your users that there’s no way to know if their data was stolen or not,” he said. To be safe, identity certificates for servers and users must be revoked and then reissued. The fix, in other words, is both urgent and tedious, which is the worst kind of job for a programmer or system administrator.