What you review is not always what git applies.

Submodule pointer bump

A submodule pointer moves to a different, unfetched commit. The one-line Subproject commit diff is easy to wave through. A submodule is a bookmark to a specific commit in another repo; only the bookmark moved, but it can now point at booby-trapped code.

-Subproject commit 1111111...
+Subproject commit 2222222...

# points at a commit you don't have

Submodule 'vendor/sub':
   1111111... -> 2222222...
[ERROR] submodule not an initialized git repo;
        cannot show diff. Failing closed.

The catch: the tool surfaces the pointer move and fails closed: when it can't safely show the changed submodule, it refuses rather than pretend it reviewed it.

Backdoor path: Bump the gitlink to a commit the reviewer can't see; on recursive clone or CI that submodule's code (and its hooks) run. The review only ever saw a 40-char hash.

Seen in the wild: CVE-2025-48384, a malicious-submodule RCE, is in CISA's KEV catalog (its list of actively-exploited flaws), and CrowdStrike documented in-the-wild attacks that clone a booby-trapped repo against developers. Public reporting has not tied it to a specific named group. The related submodule-clone RCEs CVE-2024-32002 and CVE-2018-11235 remain proof-of-concept only.

Symlink retargeted

A tracked symlink is quietly repointed at a sensitive-looking path. Viewers that follow the link can render it as if nothing moved. A symlink is a shortcut: retargeting it silently redirects a read or write somewhere else.

lrwxrwxrwx  link-notes

# target changed; the listing barely hints

SYMLINK 'link-notes':
   'notes.txt'
     -> '/nonexistent/DEMO-CREDENTIALS'

The catch: old target and new target are printed side by side: a retarget can't slip through as an unchanged link.

Backdoor path: Repoint a tracked symlink at a path inside .git or at a sensitive file, so checkout writes (or the build's reads) land where the attacker chose.

Seen in the wild: part of the in-the-wild CVE-2025-48384 exploitation: a symlink pointed a checkout into .git/modules hooks. In CISA's KEV catalog; no specific group named in public reporting.

Bidi override in a filename

The filename below carries a right-to-left override in the middle, so its real .txt tail renders flipped: the file looks like it ends in an image extension.

  new file:   report‮gpj.txt‬

# you read ".jpg"; git stored ".txt"

[WARN] path 'report_gpj.txt' has
       suspicious bytes:
    -> U+202E RIGHT-TO-LEFT OVERRIDE (Cf)

The catch: the path is scanned like content is; the hidden control character is reported and the real filename ending is shown.

Backdoor path: Commit setup<RLO>gpj.sh that displays as setup.jpg; reviewers approve an 'image' while the build runs an executable script.

Seen in the wild: right-to-left override filenames (MITRE ATT&CK T1036.002) used in real spearphishing by Ke3chang, BlackTech, BRONZE BUTLER and Ferocious Kitten.

Bidirectional override

A single invisible U+202E flips the reading order of a line. The logic you read runs backwards from the logic that executes. Like reading a line in a mirror: the letters you see spell something different from what runs.

   const char *access_level(int admin) {
+     /* return ‮nimda‬ */ return admin ? "user" : "admin";
   }

# reads one way, the bytes say another

[WARN] src/hello.c suspicious Unicode:
  hello.c:4: /* return [U+202E]nimda[U+202C] */ ...
    -> U+202E RIGHT-TO-LEFT OVERRIDE (Cf)
    -> U+202C POP DIRECTIONAL FORMATTING (Cf)
--- diff (neutralized) ---
+ /* return _nimda_ */ return admin ? "user" : "admin";

The catch: the override never reaches your terminal; it becomes an inert _, and the exact codepoint is named.

Backdoor path: Hide a bidi override in a comment or string so the branch reviewers read as a safe check actually compiles as its opposite: e.g. an authorization test that silently always passes.

Proof of concept: CVE-2021-42574 (Trojan Source): research disclosure; no documented in-the-wild source-code use.

Homoglyph identifier

The a below is Cyrillic (U+0430), not Latin. It is a different identifier that renders pixel-for-pixel the same: the same trick as a lookalike domain like paypaI.com (capital i), identical to the eye, different underneath.

+   return vаlidate("role");

# looks like validate(); it isn't

[WARN] src/hello.c suspicious Unicode:
    -> U+0430 CYRILLIC SMALL LETTER A (Ll)
--- diff (neutralized) ---
+ return v_lidate("role");

The catch: two identical-looking identifiers resolve to different symbols. The tool marks the imposter character.

Backdoor path: Name a function or variable with a look-alike letter so a call the reviewer reads as validate() actually invokes a different, attacker-defined symbol.

Proof of concept: CVE-2021-42694: the homoglyph half of Trojan Source; disclosure only.

ANSI escape sequence

A cursor-up + erase-line escape (not a color code) rewrites the previous line. Your terminal shows PASS over the real FAIL.

STATUS=PASS

# the escape erased "STATUS=FAIL" a line above

[WARN] data/config.env suspicious Unicode:
    -> U+001B ESC (Cc)
--- diff (neutralized) ---
+ STATUS=FAIL_[1A_[2KSTATUS=PASS

The catch: the escape is neutralized, so FAIL is right there in plain sight. (Real color codes are kept on purpose.)

Backdoor path: Embed a cursor-up + erase-line escape in the diff or a build log so the reviewer's terminal repaints the malicious line as benign: the backdoor lands while the screen says it never existed.

Proof of concept: CVE-2025-55754: disclosed in Apache Tomcat; the advisory reports no known attack vector.

Zero-width character

A U+200B splits a token where you see none. ADMIN​TOKEN and ADMINTOKEN look identical; only one matches: an invisible extra character wedged inside a word.

+ ADMIN​TOKEN=granted

# one hidden character lives between N and T

[WARN] data/config.env suspicious Unicode:
    -> U+200B ZERO WIDTH SPACE (Cf)
--- diff (neutralized) ---
+ ADMIN_TOKEN=granted

The catch: the invisible becomes visible: one inert _ exactly where the zero-width byte hid.

Backdoor path: Split an identifier with a zero-width character so admin_token and admin<zwsp>_token look identical but bind to different values, routing a secret to the attacker's name.

Unicode whitespace

A no-break space (U+00A0) stands in for an ordinary space. Perfectly legitimate, endlessly confusing, and it must be surfaced, not treated as an error.

+ RETRY_LIMIT = 0

# those aren't ASCII spaces

[WARN] data/config.env suspicious Unicode:
    -> U+00A0 NO-BREAK SPACE (Zs)
    -> U+00A0 NO-BREAK SPACE (Zs)
--- diff (neutralized) ---
+ RETRY_LIMIT_=_0

The catch: a benign-but-baffling change is shown plainly rather than crashing the review: an ordinary-looking space that is really a Unicode character.

Backdoor path: Swap an ASCII space for U+00A0 in a config key, so the parser reads a different key than the reviewer: a hardening flag that looks set is silently ignored.

Over-long line

One 6000-character line. Pagers truncate it or hang; the interesting part scrolls off the right edge into oblivion.

+ payload=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... (6000)

# what's hiding past column 200?

[WARN] data/config.env has a '6008'-char line;
        a viewer may truncate/hang.

The catch: the length is called out up front, so a truncating viewer can't quietly swallow the tail.

Backdoor path: Pad the line with thousands of characters so a payload sits far past where the pager truncates: off-screen, and unreviewed.

Embedded NUL byte

One \0 makes git treat the file as binary. The real change is never rendered: git just says the files "differ".

Binary files a/data/config.env and
b/data/config.env differ

# the actual change is invisible

[WARN] data/config.env suspicious Unicode:
    -> U+0000 NUL (Cc)
[NOTICE] looks BINARY (NUL byte); shown as
         --stat only, not opened in the viewer.

The catch: the binary flip itself is flagged, so "git treated this as binary" can't be mistaken for "nothing to see".

Backdoor path: One NUL byte flips a source file to 'binary', so git diff shows only 'Binary files differ' and the added backdoor line is never rendered for review.

.gitattributes that hides a change

Add a .gitattributes marking a changed file -diff, and a plain git diff shows nothing for it. The edit ships unseen. Like a note on a package telling the inspector 'don't open this box', and the inspector obeys.

+ secret.txt -diff
  (.gitattributes)

# secret.txt WAS changed, but not shown

[ERROR] .gitattributes changed: it can hide
        OTHER files' contents from the diff.
        Failing closed.
[NOTICE] set GIT_REVIEW_ALLOW_GITATTRIBUTES=1
         to review anyway.

The catch: rather than trust an attribute that can blind it, the tool refuses. The same holds when the file sits in a non-ASCII directory that git quotes in its output.

Backdoor path: Commit a .gitattributes marking auth.c -diff, then backdoor auth.c: the pull request shows no change for that file, so the edit ships invisibly.

Executable bit, no content change

Flip a file to +x without touching a byte of content. A content diff is empty; the file is now runnable.

(no visible change)

# same bytes, so a content diff is blank

MODE CHANGE 'src/build.sh':
     100644 -> 100755
[NOTE] 'src/build.sh' is now EXECUTABLE (+x).

The catch: the mode transition is reported explicitly, so "nothing changed" can't hide "it's executable now".

Backdoor path: Set +x on a committed data or config file with no content change; a content-only diff shows nothing, but a build step or cron now executes it.

File that mimics a gitlink

An ordinary file whose contents read Subproject commit <40 hex>, dressed up as a submodule pointer without being one.

+Subproject commit 3333333...

# looks exactly like a submodule bump

[WARN] 'fake-sub' content mimics a gitlink
       but mode is not 160000; treating as a
       regular file. Possible obfuscation?

The catch: the tool checks the real object mode, not the text, and flags the disguise.

Backdoor path: A file whose content reads Subproject commit <hash> makes a reviewer believe a submodule pointer moved, masking what really changed, or disguising a payload as an inert gitlink line.

Spoofed ref names

One branch reads as releasegpj; the other sits next to master and is a homoglyph of it. git prints both verbatim.

 * [new branch]  release‮gpj‬
 * [new branch]  mаster

# which one is your real master?

[WARN] ref 'release_gpj':
    -> U+202E RIGHT-TO-LEFT OVERRIDE (Cf)
[WARN] ref 'm_ster':
    -> U+0430 CYRILLIC SMALL LETTER A (Ll)

The catch: scan ref names, not just file content -- a fetched branch list is attacker-controlled text too.

Backdoor path: Push a branch whose name is a homoglyph of master; a maintainer merges the look-alike and pulls attacker code, believing they merged the real default branch.