CVE-2025-54956 identifies a vulnerability in the 'gh' package for R, maintained by r-lib, affecting all versions prior to 1.5.0. The issue arises because the package's HTTP response data structure inadvertently includes the Authorization header from the corresponding HTTP request. This means that sensitive authentication tokens or credentials used in API calls to GitHub could be exposed within response objects, potentially leaking to unauthorized parts of an application or logs if mishandled. The vulnerability is classified under CWE-669, which refers to incorrect resource transfer between security spheres, indicating a failure to properly isolate sensitive data within the software's internal structures. The CVSS 3.1 base score is 3.2, reflecting a low severity primarily due to the requirement for local access (attack vector: local), high attack complexity, and no privileges or user interaction needed. The scope is changed (S:C), meaning the vulnerability affects resources beyond the immediate component. Confidentiality impact is low, with no impact on integrity or availability. No known exploits have been reported, and no patches have been linked yet. This vulnerability is relevant for developers and organizations using the 'gh' package to interact with GitHub APIs in R environments, as it could lead to inadvertent exposure of authorization tokens within application memory or logs if the response data structures are not carefully handled.

For European organizations, the primary impact is the potential leakage of GitHub authorization tokens used in automated workflows or data analysis scripts written in R that utilize the 'gh' package. Exposure of these tokens could allow unauthorized access to GitHub repositories, potentially leading to data exposure or unauthorized code changes if tokens have write permissions. Although the vulnerability requires local access and high complexity to exploit, insider threats or compromised developer machines could leverage this flaw. Organizations heavily reliant on R for data science, analytics, or DevOps automation involving GitHub may face increased risk of credential leakage. The impact on confidentiality is low but non-negligible, especially for organizations with sensitive or proprietary codebases hosted on GitHub. There is no direct impact on system integrity or availability. The vulnerability does not appear to be exploitable remotely or without local access, limiting its broader impact. However, improper handling of the response data structure in application code or logs could amplify the risk of credential exposure.

European organizations should monitor for the release of an official patch or update to the 'gh' package version 1.5.0 or later and prioritize upgrading as soon as it becomes available. Until then, developers should audit their code to ensure that HTTP response objects from the 'gh' package are not logged, stored, or transmitted in a way that could expose the Authorization header. Implement strict access controls on developer and CI/CD environments to limit local access to trusted personnel only. Use environment variables or secure vaults to manage GitHub tokens and avoid embedding them directly in code or response objects. Employ token scopes with least privilege to minimize potential damage if tokens are exposed. Additionally, consider rotating GitHub tokens regularly and monitoring GitHub audit logs for suspicious activity. Incorporate static code analysis or security reviews to detect improper handling of sensitive data in R scripts using the 'gh' package. Finally, educate developers about the risk of leaking authorization headers through response objects and encourage secure coding practices.