CVE-2026-8794 — Username Enumeration via Authentication Timing Side-Channel in PaperCut NG

Summary

PaperCut NG's authentication endpoint exhibits a measurable timing discrepancy between login attempts against existing and non-existent accounts. This discrepancy — caused by bcrypt password hashing only being performed when a matching account is found — allows an unauthenticated attacker to reliably determine whether a given username exists in the system by measuring HTTP response times.

When combined with CVE-2026-8793 (absence of brute-force protection), this vulnerability enables a complete credential-compromise attack chain: enumerate valid usernames first, then perform unlimited targeted password guessing with no risk of lockout.

Technical Details

Root Cause

The timing discrepancy stems from a classic implementation pattern: the application only invokes bcrypt comparison when an account matching the submitted username is found in the database. For non-existent accounts, the authentication routine exits early — before bcrypt is called — resulting in a measurably shorter response time.

Valid username:   DB lookup (found) → bcrypt comparison → failure response  ~2.1s avg
Invalid username: DB lookup (not found) → immediate failure response         ~0.2s avg

This pattern is well-documented (see CWE-208). The standard remediation is to perform a dummy bcrypt comparison even when the account does not exist, equalising response times across both code paths.

Measurement Methodology

Authentication attempts were made against the PaperCut NG login endpoint under controlled conditions:

• Environment: Isolated lab, Windows Server 2022, local network (sub-millisecond base latency)
• Sample size: 15 attempts per condition (valid username / invalid username)
• Tool: curl with --write-out "%{time_total}", intentionally wrong password in all cases

Results

The two distributions show zero overlap, making enumeration reliable even over moderate network jitter.

Proof of Concept

# Measure response time for an existing account (wrong password)
curl -s -o /dev/null -w "%{time_total}\n" \
  -X POST "http://<target>:9191/app" \
  -H "Origin: http://<target>:9191" \
  --data "service=direct/1/Home/%24Form&inputUsername=admin&inputPassword=wrongpassword"
# Output: ~2.1s

# Measure response time for a non-existent account
curl -s -o /dev/null -w "%{time_total}\n" \
  -X POST "http://<target>:9191/app" \
  -H "Origin: http://<target>:9191" \
  --data "service=direct/1/Home/%24Form&inputUsername=zz_doesnotexist_zz&inputPassword=wrongpassword"
# Output: ~0.2s

A response time significantly above ~0.5s reliably indicates a valid username. A simple script can automate enumeration against a wordlist of common corporate naming patterns (firstname.lastname, flastname, etc.).

Attack Chain with CVE-2026-8793

This finding is most impactful when used as the first step in a two-stage attack:

1. Step 1 (CVE-2026-8794, this finding) — Build a list of valid PaperCut NG account names by timing authentication responses. In corporate environments, a short wordlist of firstname.lastname combinations derived from public sources (LinkedIn, company website, email footers) is often sufficient.

2. Step 2 (CVE-2026-8793) — Submit unlimited password attempts against confirmed valid accounts. The absence of rate-limiting or lockout means any credential-stuffing or password-spraying attack can be conducted entirely online at full speed.

Impact

An unauthenticated attacker with network access to TCP/9191 can:

• Reliably determine whether any given username is registered in PaperCut NG
• Build a valid username list without triggering any alerts or lockouts
• Use this list as the first step toward full credential compromise via CVE-2026-8793

In typical corporate deployments, PaperCut usernames mirror Active Directory accounts. A confirmed valid PaperCut username is therefore also a confirmed valid domain account name, amplifying the reconnaissance value beyond PaperCut itself.

Remediation

For administrators (interim mitigations):

• Restrict network access to TCP/9191 to trusted management hosts only
• Deploy a reverse proxy or WAF in front of PaperCut NG that enforces rate-limiting on the login endpoint
• Use non-guessable, non-standard username formats where possible

For the vendor:

Perform a constant-time dummy bcrypt comparison when the submitted username does not match any account, ensuring response times are equalised regardless of whether the account exists:

# Pseudocode — constant-time authentication pattern
user = db.find_user(username)
if user:
    valid = bcrypt.verify(password, user.password_hash)
else:
    bcrypt.verify(password, DUMMY_HASH)  # always run, result discarded
    valid = False

This is a well-established pattern for mitigating CWE-208 in authentication flows.

Timeline

References

• CVE-2026-8794 on cve.org
• CVE-2026-8793 — Chained vulnerability
• CWE-208: Observable Timing Discrepancy
• Timing Attacks on Passwords — OWASP
• PaperCut NG Product Page

Disclosed in accordance with responsible disclosure principles. Full technical details were shared with the PaperCut Security Team prior to public release.

Researcher: Vivien LEBAS — @Hazaz