Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On one of my web applications, I accidentally left the .git directory readable by the web server for the last few weeks. Index listing was disabled. Visiting the URL would result in a 404 error that was indistinguishable from any other 404 error, but browsing to for example would download the file.

What kind of risks are there with my applications? Is it possible that enough information is exposed that someone could have downloaded the entire application's source code?

share|improve this question
Did you try a git clone That is the major risk (being able to clone the full repo). – VonC Aug 24 '11 at 14:28
I'll have to test it on my dev server... I just realized the vulnerability while daydreaming and fixed the bug ASAP. – Thomas Hunter Aug 24 '11 at 14:45
up vote 3 down vote accepted

Yes, it's possible to download the entire repository contents (including history) – a simple git clone would do it. However, this assumes someone knew about the existence of that .git's more likely that nobody has even noticed it. You can always check your web server's logs to be sure.

share|improve this answer
except if you have some "auto-testing" folks around there which curl $URL/.git/config all day long for every url they see ... :) – akira Aug 24 '11 at 14:30
With the .git folder being in the root, someone only would have needed to run git clone And it would have worked with the directory listing disabled? – Thomas Hunter Aug 24 '11 at 14:41
@Thomas: Git does not use directory listings, since their format varies greatly between web servers. All required information is in refs and packed-refs. – grawity Aug 24 '11 at 15:05
Thanks for the advice. I checked my lighttpd access logs and didn't see any requests to the git directory (other than my own panicked checking today). – Thomas Hunter Aug 24 '11 at 15:19
These comments are not true. Git fetches the name of the various pack files by reading the directory entries, so if the webserver dir listings are disabled, you can only fetch the unstaged entries by parsing .git/index – Willem May 2 '15 at 22:31

A simple git clone on the document root is not entirely accurate. Cloning an exposed GIT repository is not possible with "dumb" servers, such as an accidental exposure of .git via HTTP, unless git update-server-info is executed on the server. While some of the metadata is available, obtaining the contents of the .git/objects directory (aka the juicy stuff) is not always possible. It is possible to recover objects that aren't packed. Should not be the case with a working copy/repository on a production server.

It's a different story for a development machine with committed changes that aren't pushed to a remote. In this case, the garbage collector is not usually called, unless you invoke git gc, hence the files aren't part of packfiles, yet. You may recover via HTTP the files which are committed since the last push.

update-server-info basically creates a map of the refs (.git/info/refs) and of the packfiles (.git/objects/info/packs). While .git/packed-refs may be used to substitute the first, obtaining the packfiles isn't possible without having the directory index enabled or actually brute-forcing SHA-1's (which is a bad idea from the start).

share|improve this answer
This should be the accepted answer – Willem May 3 '15 at 8:21
See also PoC scripts to fetch the .git/index refs: and… and – Willem May 3 '15 at 8:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .