CVE-2025-54956
BaseFortify
Publication date: 2025-08-03
Last updated on: 2025-11-25
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| r | gh | 1.4.1 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-669 | The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in the gh R package (before version 1.5.0) causes the HTTP response data structure returned by the package to include the Authorization header from the corresponding HTTP request. This means sensitive information such as API tokens or authentication headers could be unintentionally exposed in the response objects returned by the gh() function and its pagination helpers. If these responses are cached or logged, for example in RDS files committed to public repositories, it could lead to leakage of sensitive credentials. [1, 2]
How can this vulnerability impact me? :
The vulnerability can lead to accidental exposure of sensitive authentication tokens or API keys contained in the Authorization header. If response objects including these headers are cached, logged, or shared (e.g., committed to GitHub), attackers or unauthorized users could gain access to these credentials, potentially compromising your GitHub account or API access. This poses a security risk especially if the data is publicly accessible. [1, 2]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by inspecting the response objects returned by the `gh()` function and its pagination helpers (`gh_next()`, `gh_prev()`, `gh_first()`, `gh_last()`) in the gh R package versions before 1.5.0. Specifically, check if the response objects include the Authorization header or other request headers. You can do this by running R code that calls these functions and examining the returned objects for the presence of sensitive headers. For example, in R, you might run: `response <- gh::gh("GET /user")` and then inspect `attributes(response)$request` or similar to see if headers are included. If headers such as Authorization tokens are present in the response, the vulnerability exists. There are no specific network commands provided in the resources. [1, 2]
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, immediately upgrade the gh R package to version 1.5.0 or later, where the issue has been fixed by removing request headers from response objects. Additionally, review any cached or stored response objects (such as RDS files) that may contain sensitive headers and remove or secure them to prevent accidental exposure. When using pagination functions (`gh_next()`, `gh_prev()`, `gh_first()`, `gh_last()`), explicitly pass the `.token` and `.send_headers` parameters as required by the updated package to maintain authentication without exposing headers. Also, consider disabling caching if it is not needed by setting `options(gh_cache = FALSE)`. These steps will reduce the risk of leaking sensitive authorization information. [2]