A suspicious Git merge almost became a security incident.

A few days ago, I was working on a project and preparing to push some newly developed features to our organization's GitHub repository.

But Git refused to push.

It reported that my local branch and the remote branch were not in sync.

That was strange because I was the only developer actively working on that project at the time. I checked GitHub, compared the latest commits, and everything looked identical. No new commits, no visible code changes.

I initially thought it was just a Git issue.

So, I pulled the remote changes.

That's when I noticed something unusual: Git had entered a merge state, even though my editor wasn't showing any meaningful code changes.

I was about to complete the merge when one question stopped me:

Why am I merging code when I can't see any actual changes?

Instead of proceeding, I decided to investigate further.

After carefully inspecting the changes, I discovered some suspicious, heavily obfuscated code hidden among the project files.

I had seen similar code patterns while exploring an open-source repository a few days earlier. That immediately raised a red flag.

I suspected it was malicious code.

Without taking any further risks, I reverted the suspicious changes and rotated the relevant secrets and credentials as an additional precaution.

Fortunately:

• I hadn't pushed anything to the remote repository.
• No CI/CD pipeline had been triggered.
• No malicious code had reached production.

But the bigger concern came afterward.

When I informed the other team members, I learned that some of them had already been affected.

After investigating the attack pattern in more detail, I understood how dangerous this type of compromise could be.

The general attack mechanism works like this:

1. Malicious code is injected into a repository, often in an obfuscated form that makes it difficult to notice during normal code reviews.
2. When someone clones or executes the affected project, the malicious code can run and attempt to collect sensitive credentials from their machine.
3. If GitHub access tokens are compromised, attackers may use them to access other repositories the victim can reach.
4. They can inject similar malicious code into those repositories, potentially spreading the attack to more developers and projects.

This creates a dangerous supply-chain risk. A developer's compromised credentials can become an entry point into multiple repositories and teams.

I cannot confirm the exact initial entry point in our case, but repository access through other collaborators is one possibility.

A few lessons I took from this experience:

• Never blindly trust a Git pull or merge, even when you are the only active developer.
• Carefully inspect unexpected changes before merging.
• Pay attention to obfuscated or unfamiliar code.
• Keep GitHub tokens and other secrets protected, with minimum required permissions.
• Regularly review repository access and audit unexpected commits.
• Treat suspicious repository changes as potential security incidents, not just Git issues.

Sometimes, the most important security decision isn't writing more code.

It's knowing when to stop and investigate before running or merging code you don't fully trust.