The Username That Vanished from Logs — A Business Logic Breakdown worth more than $xxx

Scope: bugbounty.[REDACTED TARGET]
Weakness: Business Logic Errors
Severity: Low (3.4) $xxx
Reporter: @syarif07
Report date: 2025-05-31

Note: The target name has been intentionally censored in this public writeup. References to the affected service appear as [REDACTED TARGET].

---

TL;DR

A logging/formatting issue allowed attacker-controlled usernames containing newline characters. When such a username performed actions that were recorded in the logs-history log, the entry formatting collapsed and the username disappeared — effectively hiding who performed the action. This weakens audit trails and can be abused to obfuscate malicious activity.

---

Background

Audit logs and logs histories are often trusted sources for accountability, incident response, and compliance. Even small formatting or sanitization bugs in how identities are recorded can break those guarantees.

During a bounty assessment on bugbounty.[REDACTED TARGET] I discovered that the application accepted usernames with control characters (specifically multiple newline characters). Those usernames were later used verbatim when writing logs-history entries. Because log lines were not sanitized or normalized, the injected newlines shifted or removed the visible username portion of the log entry.

---

What I found

• The application allows an authenticated user to update their account name to a string containing newline characters.

• When a user with such a newline-containing name performs actions (for example, creating an logs), the logs history entry is recorded but the username does not appear in the expected position — effectively hiding who performed the action.

• This is a business logic / logging defect (not a classic code execution or privilege escalation), but it has high operational impact for forensics and auditability.

---

Steps to reproduce

The exact URLs and host are intentionally redacted. This section summarizes the steps conceptually.

1. Authenticate as a user with permission to edit your profile.

2. Edit the account name field and set it to a value containing newline characters (for example: \n\n\n\n).

3. Perform an action that is recorded in logs-history (e.g., create an logs).

4. Inspect the logs-history entry for that action. The username will be missing or the log line will be malformed.

Vulnerable request example (redacted):

PATCH /api/v1/users/<ATTACKER_USER_ID> HTTP/2
Content-Type: application/json;charset=utf-8

{"name":"



"}

---

Proof-of-concept

I provided a proof-of-concept during disclosure that demonstrates the behavior. (Censored identifiers and attachments omitted from this public writeup.) The core idea is that newline control characters in a username cause the log formatting to break, removing the visible username from the log line.

---

Impact

• Loss of attribution: Audit and logs can omit who performed an action.

• Reduced trust: Forensic evidence derived from logs history may be incomplete or misleading.

• Operational risk: Attackers can more easily hide or obfuscate activity that would otherwise be tied to an identity.

While the vulnerability is a formatting/business-logic issue (and was triaged as Low severity under the program's scoring), its operational impact on trust and incident response can be significant in sensitive environments.

---

Timeline (abridged)

• 2025-05-31 — Report submitted by @syarif07

• 2025-06-13 — Engineer confirmed the issue (triaged)

• 2025-08-12 — Bounty awarded (fix planned)

• 2025-10-17 — Initial retest showed issue still present

• 2025-11-07 — Final retest: fix verified and report resolved

---

Mitigation & Recommendations

To developers and platform owners:

1. Sanitize user-provided identity fields (names, display names) before storing and before rendering into logs. Specifically:

   • Strip or normalize control characters (newlines, carriage returns, tabs).

   • Consider rejecting names containing control characters at input validation.

2. Canonicalize audit log formatting:

   • Use structured logging (JSON logs with dedicated actor fields) rather than composing log lines through string concatenation.

   • When rendering logs for UI, escape or visualize non-printable characters rather than allowing them to change layout.

3. Hardening and detection:

   • Add regex-based validation for identity attributes to restrict to printable characters and reasonable length.

   • Add monitoring/alerts for log entries that are missing expected fields or that contain suspicious whitespace patterns.

4. Retrospective checks:

   • Re-scan existing logs-history entries for suspicious/malformed entries created from accounts that may contain control characters.

   • If audit trails are used for compliance, consider preserving raw event payloads and separate display formatting to avoid loss of attribution.

---

Lessons learned

• Small input validation holes can have outsized effects on operational security and trust.

• Structured logging saves you from many classes of formatting-related failures.

• When designing audit trails, assume malicious input — including unusual Unicode and control characters.

---

Acknowledgements

Thanks to the engineering team at [REDACTED TARGET] for working through retests and deploying a fix. Thanks also to the HackerOne analysts who reviewed the report, and to the wider security community for encouraging responsible disclosure practices.

---

Full disclosure policy

This writeup is authored by the original reporter. The target name has been censored per the author's request. For questions about technical details or to request additional details (where appropriate), contact the author handle: @syarif07.

---

End of writeup. Rocket science is not rocket science