SVN Server Admin Issue: Fix It!


A few months ago, Anton Isaykin in collaboration with the company 2comrades discovered a serious security problem that is quite typical of big projects (we do not name names here). To test it, they obtained the file structures and even the source code of about 3320 Russian websites and some major English-language websites. Serious problems like this aren’t supposed to exist nowadays. Every serious or visible exploit is found and fixed quickly. But here we will show you something simple and ordinary yet quite dangerous.

What was found is not actually a vulnerability because it’s documented. What we really wanted to show is that major websites and even unique services are affected (SM can’t list them, sorry). That shows again that bad developer habits is the most dangerous vulnerability we can imagine.

What Is It?

Almost every developer has used or is using a version control system such as SVN. SVN is an advanced tool for managing source code and is used by teams consisting of anywhere from two to hundreds of developers. In its architecture, SVN stores some meta data in a hidden sub-directory (called .svn) of every directory. One of the files in there, named entries, is a list of all of the files and directories contained in the folder where .svn is located. source code

It also has a link to the repository itself, developer log-ins, file sizes and dates. That’s a problem right there, isn’t it? So, if a project was developed using SVN, we could go to and see the project’s root file structure, with all of this information.

And we could go even further. In the same .svn directory are some text-base directories containing the latest versions of all project files. Moreover, these files carry the non-standard extension .svn-base (for example, index.php.svn-base). So, the files are not run in PHP, Ruby, Python or Perl but are displayed outright!

We should note that not all websites use SVN this way. We were not able to get the source code in every case.

When we realized that this problem has persisted for almost nine years, we decided to create a crawler to check websites with Russian top-level domains and major .com websites to collect some statistics. But before we report this, let’s go over how to prevent such a thing from happening to your own project.

How To Defend Yourself

You can solve the problem in different ways. The simplest solution is to deny access to SVN meta data directories from port 80 using a Web server configuration.

Solution for nginx

location ~ /.svn/ {
    deny all;

nginx has no global location support, so we have to apply this solution to every server section. For the solution to stick, you have to apply it before any other locations with regular expressions. In most cases, you can use the first location.

Solution for Apache

<Directory ~ ".*.svn">
    Order allow,deny
    Deny from all
    Satisfy All

Apache is simpler. Just add the lines above to httpd.conf, which will secure all of your projects.

Solution Using SVN

The cure for the problem is to use the Web server. Every doctor will tell you that prevention is easier and cheaper than treatment. The best solution, then, is to not let .svn in your Web root. To do this, use svn export. It’s a common good developer’s practice, but apparently in many cases some developers do not follow it.

svn console

Let The Robot Do The Work

As we said, we decided to check the Russian-language Internet for this problem. We established proxy servers, developed a crawler and got a list of .ru domains.

The first crawler version ran for two weeks, getting websites one by one in a thread. When it was finished, we found about 3000 websites affected and had about 100 GB of source code. The problem was that the crawler downloaded every resource, even if the HTTP response code was 500 and not 200, including images and JavaScript. Also some servers responded with a 200 code even when files were not actually there.

The second version was faster. It was multi-threaded and launched from two servers. Also it could work with HTTP response codes and check meta data syntax. This time, the entire .ru zone was covered in four days. Next, we wanted to check .com, but that would have taken about two years with our resources (there are more than 700,000,000 .com domains, compared to only 2,000,000 .ru domains). source code

So, we partnered with a good C developer, Andrey Saterenko3, who implemented a really fast daemon that could do the job 200% faster. Unfortunately, the summer ended and we had jobs to do. We decided not to check the entire .com domain. So, we picked the top websites based on Alexa statistics and threw in some famous websites that we really like.

We had to alert the developers involved in all of these affected projects before we published this article. We first sent letters to the major Russian services, such as Yandex4, Rambler.ru5, Mail.ru6, Opera.com7, Rbk.ru8, 003.ru9, Bolero.ru10 and habrahabr.ru11. Then the remaining 3000+ Russian websites received their letters. After that, we sent emails to the top .com websites.

Some Numbers

  • Domains checked: 2,253,388.
  • Projects affected: 3332. source code

We have no detailed statistics on how many projects have been fixed since our report. Perhaps we’ll publish that information in two weeks. We received replies from six major Russian projects. One .com project sent us thanks. We got an email from Wikimedia, and Rasmus Lerdorf of emailed us (immediately!). Both projects are open source, so their source code couldn’t be “stolen,” but we emailed them just in case. Ten projects ignored our emails, and four fixed the problem without replying.

Fun fact: approximately 10 websites with “hack” or “secure” in their domain name are actually not secure.


All of the source code was printed and then burned. Don’t ask us to sell it or publish it. We don’t have it anymore. Please check if your favorite website is affected. If it is, write a letter to its support team, with a link to this article. If this article has helped you find and fix the problem, please send an email to sam [at] rmcreative [dot] ru. We’ll be glad to read it.

About the authors

The original Russian article12 was written by Anton Isaykin1513 in collaboration with the company 2comrades14 that specializes in Web project analytics, development and support.

Anton Isaykin1513 is professional PHP/Python developer in Russia who specializes in high-load projects and architecture. Translated and adapted by Alexander Makarov16, professional Russian Web developer, who is behind RMCreative17, a Russian blog dedicated to Web developers, designers and everyone interested in how the Web is built.



  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17

↑ Back to top Tweet itShare on Facebook

Alexander Makarov is a professional Web developer in Russia. He is also the person behind RMCreative, a Russian blog dedicated to Web developers, designers and everyone interested in how the Web is built.

  1. 1

    That’s why I like git
    btw.. that can be a problem while using svn, great artice!

  2. 52

    Disclaimer: I don’t use subversion. …Color me stupid but I don’t see why anyone would put Subversion (or any other software like it) on their web site. Package up a release or a fix and move it to the server.

  3. 103

    Right, so i feel abit intimidated asking this because i will probably get ripped by some developers. I am a junior developer and quite new to svn, after reading this article i too have the /.svn/entries directory showing on my website (about to change this i might add). I have seen that alot of people here have mentioned about using svn export instead – i didnt even know this existed untill now. So i have just changed to this method, and now i cant svn up updates of my code to show on the live website, do i have to export the whole site everytime i want my changes applied to the live websitesite copy? thanks.

  4. 154

    All of the source code was printed and then burned.”

    seriously, who makes this shit up??

    PRINT the source code…then BURN IT???

    Is SmashingMagazine full of idiots?? perhaps when it comes to security – their own site got hacked recently.. Next up: Leaving the keys in your Lexus may cause your insurance rates to go up.

  5. 205

    I don’t read Smashing Magazine for security information. Especially since the last security related article I read here amounted to “Our WordPress got hacked and we’re not sure how or why”.

    I’ve always found this site to be interesting reading. I’m sure it’s hard to turn down well-written articles, but if they don’t fit the focus of the web site, it would be better for both Smashing and the author if the article was published elsewhere.

  6. 256

    That was not a literal statement. It is called an exaggeration, used to make a point.

  7. 307

    Well I think, this is a problem that really only affect those developers who chucks the whole SVN checkout onto a web accessible location. That’s unfortunately a problem that could happen in many ways not just involving SVN.

    Usually, the SVN repo path are HTTP password AUTH enabled, so people won’t be able to access folders such as /entries anyway? Or maybe i am not following very well?

  8. 358

    It might be an issue with the translation but I really don’t understand this part:
    “All of the source code was printed and then burned.”
    Does that mean that you printed the 100GB+ of data onto paper and then burned it? Or does it mean that you printed the code onto paper and then burned the HDD? Either way, it’s pretty stupid.

  9. 409

    Mark & Bjorn:

    you cannot be serious, right? Right?

  10. 460

    @dram I sure hope not…

    Yes, SM found the guy who wrote this article, made them print out every page of code for every website they found this issue on, and then made them burn everything right after. SM likes to give the environment “the finger” and then publish it in other people’s articles

  11. 511

    Thank you for posting this!

  12. 562

    I’m not sure this is a flaw, but more of an oversight on the part of the system administrators / web developers who are using SVN as a deployment tool instead of as a revision control system.

    Think of it this way. When your working for a client, do you send them all your scratch pads, prototypes and other “working” documents or just the final polished product? You always clean up your work for presentation. You’d never include the .svn directories because you don’t want the clients to have access to your repository – in most cases your repository is private and it wouldn’t do the client any good anyways.

    The exact same mentality should be applied to your deployments too. You don’t want your repository to be public, so why are you putting your revision control files (.svn, CVS control folders, whatever) in the most public place imaginable (the internet)??

    IF your deploying directly from subversion. The real solution is to trim your revision control directories from the deployment.


    find myapplication/path/ -type d -name .svn | xargs rm -rf

    Theres a reason why most enterprise companies have deployment procedures, and why most application developers have a build process that generates a separate distributable file.

  13. 613

    SSPI logins are not exposed by this I presume? You are only revealing the source code but not the logins?

  14. 664

    Coming next week.. Common code mistakes of leading .com developers

  15. 715

    Visual SVN server doesn’t show the information (this server is based on Apache).
    So, it works for us well.

  16. 766

    @dram and the aptly monikered “Disposable_Hero”

    who cares if he was ‘exaggerating’ or not?
    frankly, (and no exaggeration here) the article was bullshit as valid and as useful as

    1. Dont run with scissors while trimming the hair on your Adam’s apple.

    2. If you drop off a hooker and she ‘cant make change for a $50 bill” for a $30 blow job, DO NOT wait there at 3am till she finds an ‘open store’, DO NOT leave the keys in your car and the engine running while you go get your $20 and NEVER argue with the big, gold toothed man towering over both of you.

    I respect your Mom and always follow her advice (maybe I should ask HER for security and configuration management advice!)


↑ Back to top