Hackers may have compromised the GitHub accounts of thousands of users

A series of attacks of almost unimaginable scale and impact has recently taken place. This attack demonstrates just how vulnerable modern software development practices are. In the campaign known as “Megalodon,” attackers were able to inject modifications into more than 5,000 GitHub projects that, at first glance, appeared to be harmless developer maintenance, but in reality, were designed to obtain sensitive data.

According to reports, the attack may have affected more than 5,500 GitHub repositories within a few hours. The goal was not to cause programs to visibly malfunction or for users to notice anything immediately. On the contrary: the attackers attempted to intervene at a point that many development teams treat as routine and therefore rarely scrutinize thoroughly.

They didn't tamper with the software itself, but with its release process

When people think of a hacker attack, they often picture hacked websites, stolen passwords, or systems crashing dramatically. Megalodon used a quieter method. Instead of rewriting the visible parts of the software, it targeted the background processes responsible for developing, testing, and releasing the software.

This is dangerous because these systems often have access to highly sensitive data. A development automation tool may require access keys, cloud permissions, or release approvals. If attacker gains access here, they can compromise not just a single machine, but potentially an entire development chain. This also means we must understand that older practices—such as an external development firm guaranteeing that it has reviewed the code it wrote, or even me doing this myself—no longer work. In fact, such an attack could remain hidden even from more sophisticated checks.

A seemingly harmless modification could have led to data theft

The attackers’ trick was that, at first glance, the changes appeared to be routine system updates. A busy developer or system administrator could easily overlook such a change, especially if it did not affect the program’s core functions.

In the background, however, the malware could have been searching for data that could later be used for further attacks. This could include access keys for corporate systems, cloud access credentials, developer tokens, hidden configuration files, or environmental data that is normally only used during the software release process.

One of the most concerning aspects of the attack is that the malicious code would not necessarily have caused an immediately noticeable error. Some variants could have remained dormant and only activated later. This makes detection difficult: just because a project appears to be functioning normally does not mean everything is clean in the background.

An official release could also be at risk

One notable example from the campaign was Tiledesk, an open-source customer service and chatbot platform. According to sources, the problematic modification may have made its way into multiple released versions not by directly hacking the package’s repository. Instead, the malicious change may have been introduced into the source code stored on GitHub, and the maintainer then released a new version from there.

This is particularly important because it shows why it is difficult to defend against such attacks. The user or another developer sees that the package comes from an official source, with a familiar name, from a familiar publisher. The problem, however, may have occurred earlier, at a less visible stage of the development process.

It's not just GitHub's problem

Megalodon is part of a larger trend: attackers are increasingly targeting developers’ tools and the software development process. The reason is simple. If someone gains access to a popular project or development system, they can achieve a much greater impact than by attacking end users one by one.

The open-source world is a particularly valuable target because countless companies and developers rely on such projects. A single malicious modification can spread to other systems, packages, or corporate development processes. This is why such incidents are called supply chain attacks: they target not the endpoint, but a link in the chain leading to it.

What should I check now?

Affected companies and developers should first check whether any suspicious changes occurred in their projects around May 18, 2026. In particular, they should review files that control automated testing, building, or deployment processes running in the background.

If a project may be affected, the suspicious changes must be rolled back, and access keys and passwords must be changed. It’s also worth reviewing the logs: were there any unusual executions, unexpected data transfers, or unknown cloud logins?

According to experts, simply blocking a known malicious server is not enough. If the data has already been compromised, the old keys and tokens remain a threat and must therefore be revoked.

At the same time, this task is far more complex, as all modern software contains code snippets, libraries, or other files from third parties (e.g., GitHub) that ultimately become “part” of this newer software as well. In other words, a multi-layered and multi-component ecosystem has now been compromised, so maximum caution is warranted. A permanent fix is also expected to take a long time, as detecting potential attacks, finding built-in backdoors, and implementing a truly secure fix is a very time- and labor-intensive process. Meanwhile, we are often dealing with community-developed tools, but in any case, with code maintainers with limited resources, from whom it would be unreasonable to expect them to immediately mobilize massive resources.

The lesson: this attack vector needs to be taken even more seriously

The key message of Megalodon is that software security today goes beyond simply reviewing program code, as outlined, for example, in the EU’s existing Cyber Resilience Act, which sets out specific requirements. Among many other factors, it is also important to consider how the software is developed, who has access to the release process, what automated processes run in the background, and what sensitive information these processes might access.

So, this attack was effective because it attempted to infiltrate the development systems through seemingly mundane modifications. However, drawing the correct conclusions is still a long way off, as the focus right now is primarily on understanding the problem and developing or updating the right strategies.