Filesystem Directory Transversal Issue - TruffleHog Fails to Discover Secrets

[Archer36]

TruffleHog Version

trufflehog 3.95.5 (brew)

Trace Output

https://gist.github.com/Archer36/67d13077055a68131b7306d0e7ddcacd

Expected Behavior

The presence of a sibling directory should not affect whether another sibling directory is traversed and scanned.

Given:

trufflehog-repro/
├── blue-team/
│   └── project-notes.txt
└── blue-team-deprecated/
    └── AWSCredentials.txt

TruffleHog should traverse and scan blue-team-deprecated/AWSCredentials.txt regardless of whether blue-team exists.

Actual Behavior

When a sibling directory named blue-team exists, TruffleHog discovers the directory blue-team-deprecated but does not descend into it.

As a result:

• AWSCredentials.txt is never enumerated.
• AWSCredentials.txt is never scanned.
• No findings are produced.

If blue-team is renamed to blue-team2, TruffleHog immediately traverses into blue-team-deprecated, scans AWSCredentials.txt, and reports the expected AWS finding.

Removing blue-team entirely produces the same result.

Steps to Reproduce

1. Create the following directory structure:

trufflehog-repro/
├── blue-team/
│   └── project-notes.txt
└── blue-team-deprecated/
    └── AWSCredentials.txt

2. Populate AWSCredentials.txt with fake AWS credentials:

AWS_ACCESS_KEY_ID=AKIA7QW9K2M4X8N5R3TZ
AWS_SECRET_ACCESS_KEY=Vw8rL3qP9zNxY2mK7cTfH5sJ1aBdE6uQ4gWpR0xZ

3. Run:

trufflehog filesystem trufflehog-repro --log-level=5

4. Observe:

   • No findings are reported.
   • Trace output shows blue-team-deprecated being discovered but not traversed.

5. Rename:

mv trufflehog-repro/blue-team trufflehog-repro/blue-team2

6. Run the same scan again:

trufflehog filesystem trufflehog-repro --log-level=5

7. Observe:

   • AWSCredentials.txt is enumerated and scanned.
   • An AWS finding is reported.

8. Rename the directory back to blue-team.

9. Run the scan again.

10. Observe that the finding disappears.

Environment

• OS: macOS 15.5
• TruffleHog Version: 3.95.5

Additional Context

This issue was originally encountered while scanning a SharePoint export, but was reduced to a minimal reproduction that does not require SharePoint data or real credentials.

The issue appears to be related to directory traversal rather than detector behavior.

The key observation from the trace logs is:

Failing case (blue-team exists):

Entry found is a directory
path:"trufflehog-repro/blue-team"

Entry found is a file
path:"trufflehog-repro/blue-team/project-notes.txt"

Entry found is a directory
path:"trufflehog-repro/blue-team-deprecated"

At this point traversal stops. The scanner never enters blue-team-deprecated and never enumerates AWSCredentials.txt.

Successful case (blue-team2 exists):

Entry found is a directory
path:"trufflehog-repro/blue-team-deprecated"

Entry found is a file
path:"trufflehog-repro/blue-team-deprecated/AWSCredentials.txt"

scanning file
path:"trufflehog-repro/blue-team-deprecated/AWSCredentials.txt"

The scanner traverses into the directory, scans the file, and reports the expected finding.

The behavior appears deterministic:

Layout	Findings
blue-team + blue-team-deprecated	0
blue-team2 + blue-team-deprecated	1
blue-team-deprecated only	1

This suggests that the existence of a sibling directory whose name is a prefix of another sibling directory may affect filesystem traversal.

References

None currently.

I attached a bash script to help create the test environment.

th-bug.sh

[Archer36]

For what its worth I let codex take a shot at it and it identified the following:

The fix is in pkg/sources/filesystem/filesystem.go:258. The bug was in the resumption skip logic: it was comparing whole paths as raw strings, which misordered siblings like blue-team and blue-team-deprecated because - sorts before /. That made the
  scanner think the longer sibling had already been passed and skip it.

  I changed that comparison to use path components relative to the scan root, so it follows actual traversal order instead of lexicographic string quirks. I also added a regression test in pkg/sources/filesystem/filesystem_test.go:682 that reproduces
  the prefix-sibling case and asserts the longer sibling still gets scanned.

The important pieces are in pkg/sources/filesystem/filesystem.go:249. os.ReadDir returns entries sorted by name within a directory, and the scanner assumes that order when it decides whether to keep skipping or stop skipping. In the bad case:

  1. It scans blue-team/project-notes.txt first.
  2. That updates resumeAfter to .../blue-team/project-notes.txt.
  3. When it later reaches sibling blue-team-deprecated, the old code compares full strings and decides blue-team-deprecated is still “before” the resume point because - sorts before /.
  4. So it skips that whole subtree, even though it has not actually been scanned.

  So the bug is not the scan order itself. It is that the resume logic uses the wrong ordering rule to decide what is already done.

Building trufflehog and running the same test shows it now finds the credentials in all three scenarios, fixing the bug I encountered, but I'm not sure at what cost or downstream impacts it has.

Archer36@9ff6322

[shahzadhaider1]

Hey, thanks for sharing a detailed report. You may find some context here.

[Archer36]

Hey, thanks for sharing a detailed report. You may find some context here.

That's helpful and it seems cursor essentially identified the same thing (#4797 (comment)). From what I can tell, this hasn't been yet fixed correct? It was mentioned "This looks like a bug, but it might be one that we're comfortable with in the short term." but for me at least it undermines the trustworthiness of the results. In my case TruffleHog completely missed several high impact findings. The only way I caught it, was because TruffleHog scanned the zip and identified the credentials. However when I scanned the decompressed zip, no findings were present which is what caused me to dig in.