Not in a public Git repo. Not in a flashy headline about a supply chain hack. Buried deep in an internal branch, hidden by months of rebase history that had rewritten commits until the truth was barely traceable. It was a zero-day risk created not by an attacker’s craft, but by our own workflow.
Git rebase zero day risk is the weak point no one talks about. A tool designed for tidy histories can also bury the very event that could compromise your system. Every force-push after a rebase can wipe out the forensic chain needed to spot malicious code. The attack isn’t in the commit you see — it’s in the one you can’t.
When code moves fast and rebases rewrite history, any injected exploit can slide into the main branch without raising alarms. Logs get fragmented, signatures drop, past merges vanish. You think you’re looking at clean code. You’re not.
The threat surface here is subtle. Rebase changes commit IDs. Hashes shift. Review tools that track differences across rebased chains may fail if you don’t have immutable snapshots. Continuous integration gives a false sense of security when the target shifts with every rebase. Standard auditing cannot rely on references that no longer exist.