CVE-2026-55221 in boruta-server
Summary
by MITRE • 09/02/2026
Boruta is a standalone authorization server that aims to implement OAuth 2.0 and Openid Connect up to decentralized identity specifications. Prior to version 0.10.0, Boruta logged sensitive OAuth and OpenID Connect values in business event logs. Logged values could include access tokens, refresh tokens, authorization codes, agent tokens, direct-post codes, ID tokens, VP tokens, and tokens submitted to introspection or revocation endpoints. An attacker with access to Boruta logs, log aggregation systems, or the administration log viewer could recover these credentials and use them until expiration or revocation. This issue has been patched in version 0.10.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified as CWE-532 involves the improper logging of sensitive information within Boruta, a standalone authorization server designed to implement OAuth 2.0 and OpenID Connect specifications including decentralized identity frameworks. Prior to version 0.10.0, the application was configured or coded in such a manner that it recorded high-value security credentials directly into business event logs. This flaw affects critical components of the authentication lifecycle, specifically where tokens are generated, exchanged, validated, or revoked. The operational impact is severe because these logs often reside on systems accessible to system administrators, DevOps personnel, or third-party log aggregation services such as ELK Stack, Splunk, or CloudWatch. Consequently, any individual with read access to these logging infrastructure components can extract the recorded data without needing to exploit a separate software vulnerability in Boruta itself.
The specific sensitive values exposed by this flaw include OAuth 2.0 and OpenID Connect tokens that are essential for maintaining authenticated sessions and accessing protected resources. These logged items encompass access tokens, which grant temporary permission to interact with APIs; refresh tokens, which allow the issuance of new access tokens without re-authentication; authorization codes used in the initial exchange process; agent tokens representing service-to-service authentication; direct-post codes facilitating specific protocol flows; ID tokens containing user identity claims; and VP tokens related to verifiable presentations. Additionally, tokens submitted to introspection or revocation endpoints were also logged. The presence of these values in plaintext logs effectively compromises the confidentiality guarantee provided by the token-based authentication mechanism. An attacker leveraging this information can perform session hijacking attacks, impersonate legitimate users or services, and access sensitive data until the tokens naturally expire or are manually revoked through administrative action.
From a threat modeling perspective aligned with MITRE ATT&CK techniques, this vulnerability facilitates Credential Access via Unsecured Logs (T1552) and potentially Account Manipulation if an attacker uses stolen refresh tokens to maintain persistent access. The attack vector is primarily local or internal network-based depending on the log storage architecture, but it represents a significant risk in environments where centralized logging is standard practice for monitoring and debugging purposes. The exploitation does not require complex payload delivery or remote code execution; rather, it relies entirely on the misconfiguration of logging verbosity regarding security-sensitive data fields. This highlights a common oversight in application development where developers prioritize functional completeness over secure coding practices related to data sanitization before persistence.
To mitigate this vulnerability and prevent similar issues in future deployments, organizations must ensure they are running Boruta version 0.10.0 or later, which contains the patch for this logging flaw. For environments still operating on older versions, immediate remediation involves manually scrubbing existing log files to remove any recorded tokens and configuring application-level filters to exclude sensitive fields such as authorization headers, token parameters, and response bodies from being written to standard output or file-based logs. Security teams should also implement strict access controls around log aggregation systems to ensure that only authorized personnel with a verified business need can view raw event data. Furthermore, adopting automated secret detection tools in CI/CD pipelines can help identify accidental logging of credentials during the development phase before they reach production environments. Regular audits of application configurations against industry standards like OWASP ASVS are recommended to verify that sensitive data is never persisted in plaintext within log files.