Boruta OAuth/OIDC Authorization Server Sensitive Token Logging Disclosure

Technical Analysis

The vulnerability stems from Boruta's business event logging writing full token values (access, refresh, ID, VP tokens, authorization codes, agent tokens, and direct-post codes) rather than redacted or hashed representations. The entry point is any component with read access to application logs: log aggregation systems (e.g., ELK, Splunk), centralized logging infrastructure, or Boruta's own administration log viewer UI. An attacker who compromises or has legitimate but overprivileged access to these log sinks gains the ability to replay valid OAuth/OIDC credentials, impersonating the original client, user, or agent until the token is revoked or naturally expires. Because agent tokens are explicitly among the logged values, this crosses into agent identity territory: an AI agent authenticating via Boruta-issued credentials could have its session hijacked by anyone with log access, enabling downstream privilege abuse or impersonation across any service trusting that token.

Affected Systems

Boruta; protocols: OAuth 2.0, OpenID Connect

Detection Signatures

• Log entries containing full unredacted 'access_token=', 'refresh_token=', 'id_token=', or 'agent_token=' values in Boruta business event logs
• Presence of raw authorization_code or direct-post code values in log aggregation dashboards
• Admin log viewer displaying complete token strings rather than truncated/masked values
• Unusual authenticated requests using tokens shortly after log access by non-standard accounts

Remediation Steps

1. 1

   Upgrade Boruta

   Update to Boruta version 0.10.0 or later, which patches the logging behavior to avoid exposing sensitive token values.

2. 2

   Rotate exposed credentials

   Treat all tokens, codes, and agent tokens logged prior to patching as compromised; force revocation and reissuance.

3. 3

   Restrict log access

   Apply least-privilege access controls to log aggregation systems and the Boruta administration log viewer, limiting exposure to only essential personnel.

4. 4

   Implement log redaction

   Configure log pipelines to mask or hash sensitive fields (tokens, codes) before they reach persistent storage or aggregation systems, even after patching, as defense in depth.

5. 5

   Shorten token lifetimes

   Reduce access and agent token TTLs and enforce refresh token rotation to limit the window of exploitability for any leaked credentials.

6. 6

   Audit historical log access

   Review who accessed logs and the admin log viewer during the vulnerable period to identify potential misuse.