PolinRider Scanner

    Download

    Analysis

    Found temp_auto_push.bat in your repository?

    · 4 min read

    temp_auto_push.bat is the script PolinRider uses to push its payload into repositories. If you have found it in a repository or listed in a .gitignore nobody on your team wrote, a computer that pushes to that repository has very likely been infected. Check that computer before you touch the repository. Cleaning the repository first does not last, because the same computer will push the payload straight back.

    What the script does

    OpenSourceMalware published the script in full in its first report on the campaign, in March 2026. It is a Windows batch file, and run inside a Git repository it does something careful. It reads the current branch and the last commit’s date, time, message and author. It sets the Windows clock back to that commit’s date and time, and sets the repository’s Git name and email to that commit’s author. It stages every change in the folder and amends the last commit with the same message, skipping any commit hooks. Then it puts the clock right and force-pushes the branch to origin, again skipping hooks.

    By the time it runs, another part of the malware has already appended its loader to a config file such as postcss.config.mjs, tailwind.config.js or eslint.config.mjs. The script folds that change into a commit that already existed and pushes it over the original.

    Why your history still looks clean

    Because the clock was wound back, Git records the amended commit with the old date. The author, the message and the branch are all unchanged. Reading git log, the commit looks as if nobody touched it.

    Two things do change. The commit gets a new ID, since a commit’s hash covers everything in it, but that only helps if you still have a copy from before. The more useful one is GitHub’s record of the push itself. As OpenSourceMalware showed in its October guide to investigating a repository’s real history, the activity feed lists every push and force-push with the account that made it and GitHub’s own time. None of that comes from the commit, so a changed clock or a changed Git name cannot forge it. Our page on why your Git history looks clean shows where to find it.

    In the repository, or only in .gitignore

    You can meet the name in two ways. The first is the file itself, committed. OpenSourceMalware uses the name to find victims: a GitHub code search for it in April found 101 repositories, 22 of which also carried a malicious .vscode/tasks.json.

    The second is quieter. In September OpenSourceMalware reported that infected computers add this block to .gitignore:

    config.bat
temp_auto_push.bat
temp_interactive_push.bat
branch_structure.json

    These are the push tool’s working files on the developer’s own computer, and the entries keep them out of git status so nobody notices them. The team found the block in every infected organization it examined. Where it appears, at least one contributor’s computer is infected, even if no payload has reached that repository yet. One repository traced in October shows how it looks in practice: its history dated a commit April 2025, but a force-push in June 2026 had replaced it with a rewritten copy that added the script to .gitignore.

    Not only a Windows problem

    The script found so far is a batch file, and changing the Windows clock needs administrator rights. OpenSourceMalware has also reported evidence of the same history rewriting on other operating systems, though no tool was left behind there. Not finding the .bat file on a Mac or a Linux machine does not clear it.

    How it spreads between people

    The script runs on the infected computer with the credentials already stored there, and it runs again whenever its trigger fires: a scheduled task, a background process or someone opening an infected project again. A teammate who opens one of the rewritten repositories in VS Code and trusts the folder is infected in turn, and their computer starts doing the same. VS Code’s Workspace Trust prompt is the main thing standing in the way.

    If you publish a Go module or a Composer package straight from the repository, the rewritten commit is the release. OpenSourceMalware has reported compromised Go modules spread this way.

    What to do

    Do not open the repository in an editor, and do not install or build it, until it has been checked. If VS Code asks whether to trust the folder, say no.

    Then find the computer. In the repository’s activity feed, look for the force-pushes and the account that made each one. The feed records whose credentials pushed, not who was at the keyboard, so treat that account’s owner as a probable victim. If the name only appears in .gitignore, every contributor’s computer is a candidate.

    Check that computer before anything on GitHub. Look for temp_auto_push.bat and config.bat anywhere on its disk, then check the rest of it. polinrider reports temp_auto_push.bat and temp_interactive_push.bat as confirmed wherever it finds them. On GitHub it flags a .gitignore that lists them for review instead, because that points at a contributor’s computer rather than a payload in the repository. Once the computer is clean, change every credential from a clean machine, then clean the repositories and start signing your commits. The cleanup checklist has each step.

    Sources