I don't know about any particular vulnerability in regards to Silk Road. I will say that I have seen some less than ideal configuration though, for example having detailed error messages enabled in a production site. At the end of the day the security of a site like SR is not of utmost importance for customers, they must handle their security themselves and not rely on an non compromised server. The primary things that present real problems are things like DoS attacks , and of course the risk to DPR and vendors that hackers could steal the escrow. Although this is only ideally, as we all know that most users here do not encrypt their addresses with GPG, etc, and thus they needlessly make it so that they do indeed rely on the security of the server hosting the site. As far as the DoS of SR goes, I cannot say much without knowing specifics of the attack. I don't go to the SR marketplace ever, but I did notice a few things when the forums were said to be being DDoSed. The first thing I noticed is that Tor was indeed building a circuit to the instance of Tor running on the server hosting this forum. It was just immediately closing streams through it. This means that the introduction nodes were not being DDoSed, it also means that the server was not being overwhelmed with bandwidth. If the introduction nodes were inaccessible, I would not have been able to successfully build a circuit that communicated with the instance of Tor running on the server. This also means that the server itself was clearly running and had sufficient bandwidth available, otherwise it would not have a running instance of Tor capable of establishing a connection. It seems to me that the problem is with the actual web server, Apache I believe. The connection to the instance of Tor running on the SR forum server was working fine for the entire time, however after establishing the circuit the streams through it were immediately closed by the remote host. This is what we would expect to see if Tor was running and configured to redirect incoming traffic to a port that had nothing listening on it, or had something malfunctioning listening on it. Another thing I noticed is that intermittently Apache began working again, and the circuit built to the instance of Tor on the forum server was useful for maintaining open streams. During the brief periods in which this happened the server returned 500 errors when attempting to access legitimate pages, but when attempting to access pages such as http://dkn255hz262ypmii.onion/made_up_not_real.php it was returning 404 errors as normal. I see that now attempting to load false .php pages is returning a 'No input file specified' error , and attempting to load any .html page loads the forum index, so apparently they changed something since the forums went down. It didn't take long before the intermittent 500 error messages were replaced with a maintenance message, and the forum came up shortly after that. My impression of the down time for the forum was that their instance of Apache kept crashing and being brought back up. Definitely the server itself remained reachable the entire time, and connections to their hidden service were also flawless the entire time, it is just that Tor was apparently redirecting the traffic to a port that had nothing listening on it. That said, it doesn't rule out a DoS attack. Perhaps the attacker exploited a remote flaw in Apache, or somewhere in the configuration, and kept remotely crashing the web server. But it does pretty definitely rule out a bandwidth flooding DDoS, and also rules out a DDoS on the introduction nodes, and a DoS of the box itself. The first step of determining what went wrong is finding why there was a 500 error being returned. I cannot do this without access to Apache error logs from the server. Searching shows that 500 errors are pretty ambiguous and can refer to a wide variety of different things. Maybe it was caused by a PHP misconfiguration or crash, and that is why fake .php pages were returning 404 errors but real ones were returning 500 errors. The real root of the problem is probably figuring out why Apache was crashing / PHP was throwing a fit or crashing.