CloudflareApiToken detector misses 40-char tokens ending in '-' (trailing \b)

[sumlac]

Summary

The CloudflareApiToken detector does not match a 40-character token whose
final character is -. Cloudflare API tokens are [A-Za-z0-9_-]{40}, so a
token ending in - or _ is a valid token that is silently skipped.

This looks like a trailing \b word boundary in the detector's pattern: \b
cannot assert a boundary after a non-word character, so the match fails when
the 40th character is -.

Reproduction

Two tokens, identical in their first 39 characters, differing only in the last.
Both are exactly 40 characters and both are valid Cloudflare API token shapes.

#!/usr/bin/env bash
set -eu
BASE="zymMlopiWfqUyHRSIf8NFmAUNLnY5Yx0y3RnjDQ"   # exactly 39 chars
[ "${#BASE}" -eq 39 ] || { echo "BASE must be 39 chars"; exit 1; }
for LAST in "A" "-"; do
  TOKEN="${BASE}${LAST}"
  D=$(mktemp -d)
  printf 'cloudflare:\n  auth:\n    apiToken: %s\n' "$TOKEN" > "$D/c.yml"
  N=$(trufflehog filesystem "$D" --json --no-update --log-level=-1 \
        --no-verification --results=verified,unknown,unverified 2>/dev/null \
      | grep -c CloudflareApiToken || true)
  printf "final char %-4s len=%s -> %s\n" "'$LAST'" "${#TOKEN}" \
    "$([ "$N" -gt 0 ] && echo DETECTED || echo MISSED)"
  rm -rf "$D"
done

Actual output

final char 'A'  len=40 -> DETECTED
final char '-'  len=40 -> MISSED

Expected

Both should be detected. - is in the documented token alphabet and carries no
less signal than A.

Versions affected

Reproduced identically on 3.94.3 and 3.97.5 (current at time of filing),
macOS arm64, Homebrew builds. 4/4 with independently generated high-entropy
39-character prefixes, so it is not specific to the value above.

Why it matters in practice

Found while running TruffleHog over a large repository estate. A real, live
Cloudflare API token committed in a serverless.yml was not reported, and its
only distinguishing feature versus tokens that were reported is that it ends
in -. The same detector concurrently produced ~2,364 matches on 40-character
hex strings in a single yarn.lock — so in that estate the detector had a high
false-positive rate on lockfile hashes while missing the genuine credential.

A second scanner using a generic high-entropy rule did report it, which is how
the gap surfaced.

Suggested fix

Anchor the trailing edge on something that tolerates a non-word final
character — e.g. a lookahead for a non-token character or end-of-input rather
than \b — so the full [A-Za-z0-9_-]{40} alphabet is matched. The same
consideration likely applies to any other detector whose alphabet includes
- or _ and which relies on a trailing \b.

[sumlac]

Adding evidence on the obvious question: does Cloudflare actually issue tokens ending in -?

Yes. While investigating this I had a real, Cloudflare-issued API token in hand with these properties:

• exactly 40 characters
• alphabet strictly [A-Za-z0-9_-]
• the final character is -, and it is the token's only hyphen
• Cloudflare's own /user/tokens/verify returned 200, success: true, status: active for it

Since API tokens are generated server-side by Cloudflare rather than chosen by a user, a token that Cloudflare issued and still reports as active is sufficient to establish the shape occurs in practice. That token is exactly the one the detector skipped.

Scope is narrower than the whole alphabet — only - triggers it:

final char 'A' -> DETECTED
final char '-' -> MISSED
final char '_' -> DETECTED

_ is a word character, so a trailing \b succeeds after it. That asymmetry is consistent with the trailing word-boundary diagnosis rather than a broader pattern problem.

Rough frequency: with a 64-character base64url-style alphabet and a uniform final position, on the order of 1 in 64 tokens (~1.6%) would end in -. That is an estimate from the alphabet rather than a measurement of Cloudflare's generator, but it suggests this is not a rare edge case — it was hit on the first live Cloudflare token encountered in the estate being scanned.