Coders who use the popular code-sharing site GitHub were put on alert on Thursday after it was found that many have been inadvertently posting private files, including their private encryption keys, there.

The concern arose because the search function on the site made those private credentials searchable, potentially compromising their use of online services all over the web – in effect publishing the equivalent of their passwords for all sorts of sites, and making them accessible to any browser.

Overnight, GitHub's search function stopped working, though the site didn't acknowledge the cause. It simply said on its status page that "Search remains unavailable. The cluster is recovering slowly and we continue to monitor its progress. We'll provide further updates as they become available."

GitHub is a source code repository which lets developers work on programs together as a team, even when they are in different locations. Each repository on the site is a public folder designed to hold the software code that a developer is working on.

The public folders are copies of private folders stored on the developers' own computers, so each developer can work on their own version of a piece of source code, and only commit changes to the public repository once happy with them. An individual in charge of a software project, called a maintainer, can then evaluate the versions of the same software held in different repositories, and select the best ones to become part of the main source code.

Launched in 2008, GitHub appeals particularly to open-source software developers: it offers a free hosting option for open-source public repositories with unlimited numbers of public collaborators.

In keeping with its open-source ethos, GitHub offers a search tool. Visitors can use its search facility to search for repositories and source code. The problem is that developers were putting private files into their repositories, which were then being copied into public repositories and made searchable.

On Thursday, software developers on Twitter started posting web links to searches for sensitive files using GitHub's own search tool. These included private "keys" for SSH, a popular encryption and authentication technology. SSH keys are often used instead of passwords to gain access to online services.

Computers running Unix (including Linux and Macintosh machines) store a user's SSH keys for regular use, and also store a "known hosts" file, which contains a list of the online services that they can access with the keys. Publishing these keys and files would be like publishing a list of your passwords to popular web sites for everyone to use.

But the tool that generates SSH keys stores them in a user's home directory – and researchers said that many users were inadvertently copying these into their GitHub repositories along with other files, making them available in a public search on the Github site.

"One thing that's troubling about this is that these folks have let hosts they're connecting to be compromised, which probably means that you can compromise their own account," said Dragos Riui, a Canadian security researcher and founder of the annual CansecWest security conference, which will be held in Vancouver in March.

"That means that you can trojan up their projects, too. You could modify the source, and put a backdoor in it so that you could make the users of that source code project also vulnerable". But because the attacker would have used the official programmer's keys, there would be no sign that an unauthorised change had been made.

Other types of sensitive keys were also in danger, including private keys created for encrypting email and other communications using services like GNUPG.

After people began posting links to searches on Twitter, others began to caution them: "People posting github repo security screw-ups: *please* tell the maintainer and give them time to respond before posting here," tweeted one. "It would be responsible of @github I think to blacklist some well-known private files like ~/.ssh/ and ~/.gnupg/," said another.

Emerson Tan, an organiser at security vulnerability information site PacketStorm Security, pointed to developer inexperience as a key contributor to the problem. "The risk of trojanised software isn't huge; what is more worrying is that so many of the developers don't get fundamental security concepts," he said. "Just because you can code doesn't mean you understand security fundamentals. There is no barrier to coding."

But who is culpable? The users publishing their private keys by mistake, or the sites who reveal such details in search engines? Dan Kaminsky, a researcher who found a fundamental bug in the internet's domain naming system several years ago, said that it's the users' problem.

"I don't think anyone's going to say that Git should not add a warning," he said. "But that's not the role of the archive, to be sniffing around and blocking things."

But when it happens to people in large numbers, it becomes a broader problem, said one Twitter user who works in the security field. "When one person pushes their private key to GitHub, it's an idiot problem. When a hundred people do, it's not about idiot users anymore," the researcher said.

Github co-founder Thomas Preston-Werner did not return the Guardian's calls. Neither his Twitter account nor GitHub's official account acknowledged the flaw at the time of writing. However, several searches that had shown private files earlier in the day no longer worked.

This wouldn't stop a determined hacker, though: Google searches for the private files using advanced search operators still revealed private keys unwittingly posted by GitHub users as of 5am GMT, Friday.

Kaminsky downplayed the event. "If some of those projects are actually significant, then yes, you've got problems. But GitHub's enormous," he said. "An attacker can target a certain number of developers that use Github. Do any of those developers work on something that is significant?"

One security researcher, Veracode's Melissa Elliott, claimed on Twitter to have found a target. "Oh jeez just found an ssh password to a production server of a major, MAJOR website in China on Github," she tweeted on Thursday.

GitHub isn't the only source repository to experience this issue, and it isn't a new concept. "Googledorks" – people who leave sensitive files and credentials exposed to indexing by the search giant – have long existed, and there are websites that deliberately expose them.

The sudden focus on the problem followed a GitHub blogpost on Tuesday, in which spokespeople highlighted major upgrades to the site's search engine. "Finding great code on GitHub just got a whole lot easier," it said. It is unlikely that the search upgrade introduced the problem, but it may have caused hackers to begin exploring the site in more detail.

Now that this flaw has gained public attention, it will put the onus on developers to check and purge their sensitive files – and their software. "We've no idea how long this has been going on," said PacketStorm's Tan. "Some enterprising bastard has probably vacuumed up all the results and is going through it right now. Seriously, that is what you have to assume in the case of a credential compromise."