deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-wj3p-5h3x-c74q
Package: github.com/rancher/backup-restore-operator (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 9.0.0, < 9.0.1
Patched in: 9.0.1

Summary: Rancher Backup Operator pod's logs leak S3 tokens

Details:
### Impact
A vulnerability has been identified within the Rancher Backup Operator, resulting in the leakage of S3 tokens (both `accessKey` and `secretKey`) into the rancher-backup-operator pod's logs.

Specifically, the S3 `accessKey` and `secretKey` are exposed in the pod's logs under the following logging level conditions:

| Variable Exposed | Logging Level Condition | 
------------------ | ------------------------- |
| accessKey            | `trace: false` (default), and `debug: false` (default) |
| secretKey             | `trace: true` or `debug: true`|

**Note:** The S3 `accessKey` is exposed in the logs without requiring any supplementary configuration.

For further information on this attack category, please consult the associated [MITRE ATT&CK - Technique - Log Enumeration](https://attack.mitre.org/techniques/T1654/).

### Patches
This vulnerability is addressed by applying redaction to sensitive information that was leaking.

Patched versions of Rancher Backup Operator include: `108.0.1+up9.0.1`, `107.1.2+up8.1.2`, `106.0.6+up7.0.5`, and `105.0.6+up6.0.3`.

### Workarounds
Users are advised to rotate both S3 `accessKey` and `secretKey` once they have upgraded to a fixed version, especially if logs are exported.

Users who cannot update Rancher are advised to refresh the Rancher app Repository, which should provide the ability to update just the Rancher Backup chart alone. This will patch the vulnerabilities without requiring Rancher to be updated. This will not work for Rancher clusters in an air-gap setup.

For air-gapped Rancher clusters, the Rancher version must be updated first, and then after you will find the patched version of the Rancher Backup chart to upgrade. You will also need to sync new images for the release to your image mirror.

Users who cannot update either Rancher or Rancher Backup should ensure that both debug and trace values are both false (default). Users should revert the values to the default until they can update to prevent potential leaks.

### References
If you have any questions or comments about this advisory:
- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
GitHub Security Advisory: GHSA-gqf8-rvrh-g7w6
Package: github.com/rancher/rancher (GO)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-284: Improper Access Control
Vulnerable versions: >= 2.5.0, < 2.5.9
Patched in: 2.5.9

Summary: Rancher cloud credentials can be used through proxy API by users without access

Details:
A vulnerability was discovered in Rancher 2.2.0 through the aforementioned patched versions, where cloud credentials weren't being properly validated through the Rancher API. Specifically through a proxy designed to communicate with cloud providers. Any Rancher user that was logged-in and aware of a cloud-credential ID that was valid for a given cloud provider, could call that cloud provider's API through the proxy API, and the cloud-credential would be attached. The exploit is limited to valid Rancher users. There is not a direct mitigation outside of upgrading to the patched Rancher versions.
GitHub Security Advisory: GHSA-gqf8-rvrh-g7w6
Package: github.com/rancher/rancher (GO)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-284: Improper Access Control
Vulnerable versions: >= 2.2.0, < 2.4.16
Patched in: 2.4.16

Summary: Rancher cloud credentials can be used through proxy API by users without access

Details:
A vulnerability was discovered in Rancher 2.2.0 through the aforementioned patched versions, where cloud credentials weren't being properly validated through the Rancher API. Specifically through a proxy designed to communicate with cloud providers. Any Rancher user that was logged-in and aware of a cloud-credential ID that was valid for a given cloud provider, could call that cloud provider's API through the proxy API, and the cloud-credential would be attached. The exploit is limited to valid Rancher users. There is not a direct mitigation outside of upgrading to the patched Rancher versions.
GitHub Security Advisory: GHSA-8w87-58w6-hfv8
Package: github.com/rancher/rancher (GO)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-312: Cleartext Storage of Sensitive Information, CWE-522: Insufficiently Protected Credentials
Vulnerable versions: >= 2.6.0, <= 2.6.3
Patched in: 2.6.4

Summary: Rancher doesn't properly sanitize credentials in cluster template answers

Details:
### Impact

It was discovered that in Rancher versions up to and including 2.5.12 and 2.6.3 there is a failure to properly sanitize credentials in cluster template answers. This failure can lead to plaintext storage and exposure of credentials, passwords and API tokens.

The exposed credentials are visible in Rancher to authenticated `Cluster Owners`, `Cluster Members`, `Project Owners` and `Project Members` on the endpoints `/v1/management.cattle.io.clusters`, `/v3/clusters` and `/k8s/clusters/local/apis/management.cattle.io/v3/clusters`.

Sensitive fields are now stripped from `Clusters` objects before the object is stored. For objects that existed before this security fix, a one-time migration happens on startup.

**Important:**
- It is highly advised to review for potential leaked credentials in this scenario, and to change them if deemed necessary.
- The final impact severity for confidentiality, integrity and availability is dependent on the permissions that the leaked credentials have on their own services.

### Patches
Patched versions include releases 2.5.13, 2.6.4 and later versions.

### Workarounds
Limit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions.

**Important:** It is highly advised to review for potential leaked credentials in this scenario, and to change them if deemed necessary.

### For more information
If you have any questions or comments about this advisory:
* Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
* Open an issue in [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
* Verify our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
GitHub Security Advisory: GHSA-8w87-58w6-hfv8
Package: github.com/rancher/rancher (GO)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-312: Cleartext Storage of Sensitive Information, CWE-522: Insufficiently Protected Credentials
Vulnerable versions: >= 2.5.0, <= 2.5.12
Patched in: 2.5.13

Summary: Rancher doesn't properly sanitize credentials in cluster template answers

Details:
### Impact

It was discovered that in Rancher versions up to and including 2.5.12 and 2.6.3 there is a failure to properly sanitize credentials in cluster template answers. This failure can lead to plaintext storage and exposure of credentials, passwords and API tokens.

The exposed credentials are visible in Rancher to authenticated `Cluster Owners`, `Cluster Members`, `Project Owners` and `Project Members` on the endpoints `/v1/management.cattle.io.clusters`, `/v3/clusters` and `/k8s/clusters/local/apis/management.cattle.io/v3/clusters`.

Sensitive fields are now stripped from `Clusters` objects before the object is stored. For objects that existed before this security fix, a one-time migration happens on startup.

**Important:**
- It is highly advised to review for potential leaked credentials in this scenario, and to change them if deemed necessary.
- The final impact severity for confidentiality, integrity and availability is dependent on the permissions that the leaked credentials have on their own services.

### Patches
Patched versions include releases 2.5.13, 2.6.4 and later versions.

### Workarounds
Limit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions.

**Important:** It is highly advised to review for potential leaked credentials in this scenario, and to change them if deemed necessary.

### For more information
If you have any questions or comments about this advisory:
* Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
* Open an issue in [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
* Verify our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
GitHub Security Advisory: GHSA-vf6j-6739-78m8
Package: github.com/rancher/rancher (GO)
Severity: HIGH (CVSS 8.0)
CWE: CWE-269: Improper Privilege Management, CWE-271: Privilege Dropping / Lowering Errors, CWE-384: Session Fixation
Vulnerable versions: >= 2.7.0, < 2.7.4
Patched in: 2.7.4

Summary: Rancher's Azure AD permission changes are not reflected on active sessions

Details:
A bug has been identified in which permission changes in Azure AD are not reflected to users while they are logged in the Rancher UI. This would cause the users to retain their previous permissions in Rancher, even if they change groups on Azure AD, for example, to a lower privileged group, or are removed from a group, thus retaining their access to Rancher instead of losing it.

### Impact
This issue only affects Rancher instances with Azure AD integration enabled, regardless of the [automatically refreshing settings](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups#automatically-refreshing-user-information) which are enabled by default. The users that obtained a token (or kubeconfig) to access Rancher through the following sessions are affected by this issue:
1) Users using the Rancher UI.
2) Users using `kubectl` based on a `kubeconfig` downloaded through the Rancher UI.
3) Tokens created via the Rancher UI Create API Key feature.

Note that the permission caching is persisted even when the Rancher Manager pod is restarted. The only way for a user to get the new permissions is to logout and login again.

### Patches
Patched versions include releases `2.6.13`, `2.7.4` and later versions.

### For more information
If you have any questions or comments about this advisory:

- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
GitHub Security Advisory: GHSA-vf6j-6739-78m8
Package: github.com/rancher/rancher (GO)
Severity: HIGH (CVSS 8.0)
CWE: CWE-269: Improper Privilege Management, CWE-271: Privilege Dropping / Lowering Errors, CWE-384: Session Fixation
Vulnerable versions: >= 2.6.7, < 2.6.13
Patched in: 2.6.13

Summary: Rancher's Azure AD permission changes are not reflected on active sessions

Details:
A bug has been identified in which permission changes in Azure AD are not reflected to users while they are logged in the Rancher UI. This would cause the users to retain their previous permissions in Rancher, even if they change groups on Azure AD, for example, to a lower privileged group, or are removed from a group, thus retaining their access to Rancher instead of losing it.

### Impact
This issue only affects Rancher instances with Azure AD integration enabled, regardless of the [automatically refreshing settings](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups#automatically-refreshing-user-information) which are enabled by default. The users that obtained a token (or kubeconfig) to access Rancher through the following sessions are affected by this issue:
1) Users using the Rancher UI.
2) Users using `kubectl` based on a `kubeconfig` downloaded through the Rancher UI.
3) Tokens created via the Rancher UI Create API Key feature.

Note that the permission caching is persisted even when the Rancher Manager pod is restarted. The only way for a user to get the new permissions is to logout and login again.

### Patches
Patched versions include releases `2.6.13`, `2.7.4` and later versions.

### For more information
If you have any questions or comments about this advisory:

- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
GitHub Security Advisory: GHSA-7rp8-r62p-q6wc
Package: chainguard.dev/melange (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 0.40.5
Patched in: unpatched

Summary: `melange update-cache` has unbounded HTTP download that can exhaust disk in CI

Details:
`melange update-cache` downloads URIs from build configs via `io.Copy` without any size limit or HTTP client timeout (`pkg/renovate/cache/cache.go`). An attacker-controlled URI in a melange config can cause unbounded disk writes, exhausting disk on the build runner. Affected versions <= 0.40.5.

**Fix:** Merged
**Acknowledgements**

melange thanks Oleh Konko from [1seal](https://1seal.org/) for discovering and reporting this issue.
GitHub Security Advisory: GHSA-pc8g-78pf-4xrp
Package: github.com/OliveTin/OliveTin (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.0.0[PII_REDACTED]2407-2eb5f0ba79d4
Patched in: 0.0.0[PII_REDACTED]2407-2eb5f0ba79d4

Summary: OliveTin has Unauthenticated Denial of Service via Memory Exhaustion in PasswordHash API Endpoint

Details:
## Summary

The PasswordHash API endpoint allows unauthenticated users to trigger excessive memory allocation by sending concurrent password hashing requests. By issuing multiple parallel requests, an attacker can exhaust available container memory, leading to service degradation or complete denial of service (DoS).

The issue occurs because the endpoint performs computationally and memory-intensive hashing operations without request throttling, authentication requirements, or resource limits.

## Details

The vulnerable endpoint:

`POST /api/olivetin.api.v1.OliveTinApiService/PasswordHash`

accepts a JSON body containing a password field and returns a computed password hash.

Each request triggers a memory-intensive hashing operation. When multiple concurrent requests are sent, memory consumption increases significantly. There are no safeguards such as:

- Authentication requirements
- Rate limiting
- Request throttling
- Memory usage caps per request
- Concurrency controls

As a result, an attacker can repeatedly invoke the endpoint in parallel, causing excessive RAM allocation inside the container.

In a test environment, 50 concurrent requests resulted in approximately 3.2 GB of memory usage (≈64 MB per request), leading to service instability.

This behavior allows unauthenticated attackers to perform a denial of service attack by exhausting server memory resources.

## PoC
Environment

- Docker container: olivetin-test
- Exposed API on: http://localhost:1337
- Default configuration (no authentication enabled)

## Reproduction Steps

Run the following script to send 50 concurrent requests:

```bash
for i in $(seq 1 50); do
  curl -s -X POST http://localhost:1337/api/olivetin.api.v1.OliveTinApiService/PasswordHash \
    -H "Content-Type: application/json" \
    -d "{\"password\":\"flood-$i\"}" &
done
docker stats olivetin-test --no-stream
wait
```

```bash
┌──(root㉿kali)-[~/cve/OliveTin]
└─# docker stats olivetin-test --no-stream
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O         BLOCK I/O        PIDS
18509670bf3e   olivetin-test   344.63%   6.189GiB / 7.753GiB   79.83%    313kB / 288kB   4.31MB / 106MB   7

```

`Docker CPU is 344.63%`

### Impact

This vulnerability allows unauthenticated remote attackers to:

- Exhaust server memory
- Crash the service
- Cause availability loss
- Trigger container termination in orchestrated environments

This is a Denial of Service (DoS) vulnerability affecting service availability.

Production deployments without reverse proxy rate limiting (e.g., Nginx, Traefik) are especially at risk.
GitHub Security Advisory: GHSA-54p8-x2m9-c593
Package: github.com/chainguard-dev/malcontent (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 1.21.0
Patched in: 1.21.0

Summary: malcontent: Error-path cleanup gap can leak scanners and fds and degrade availability

Details:
Several extraction and scanning code paths registered late defers which could leak resources and exhaust system resources.

This report is an aggregate of these individual reports for the affected code:
Advisory | Affected File
-- | --
`GHSA-jjgh-mc5q-gch7` | `pkg/action/scan.go`
`GHSA-mwmf-fxh2-w4x7` | `pkg/archive/deb.go`
`GHSA-p8j3-rpf5-gwv3` | `pkg/archive/gzip.go`
`GHSA-qfh4-7f5v-75gq` | `pkg/archive/zlib.go`
`GHSA-wxxf-r586-5rf5` | `pkg/archive/bzip2.go`

**Fix**: #1354, #1355, #1356, #1361

**Acknowledgements**

Thank you to Oleh Konko from [1seal](https://1seal.org/) for discovering and reporting all six of these issues.
GitHub Security Advisory: GHSA-5r3p-6rj5-7937
Package: github.com/bytebase/bytebase (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: <= 1.0.0
Patched in: 1.0.1

Summary: Bytebase vulnerable to Improper Authentication

Details:
### Impact
- GitLab login allows login by any user.
- JWT auth token can be derived as long as the server isn't rebooted.
- Developers can assign issues to non-admin/DBA users.
GitHub Security Advisory: GHSA-6rxq-q92g-4rmf
Package: github.com/chainguard-dev/kaniko (GO)
Severity: HIGH (CVSS 8.2)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 1.25.4, < 1.25.10
Patched in: 1.25.10

Summary: kaniko has tar archive path traversal in its build context extraction, allowing file writes outside destination directories

Details:
kaniko unpacks build context archives using `filepath.Join(dest, cleanedName)` without enforcing that the final path stays within `dest`. A tar entry like `../outside.txt` escapes the extraction root and writes files outside the destination directory. In environments with registry authentication, this can be chained with docker credential helpers to achieve code execution within the executor process. Affected versions >= 1.25.4, <= 1.25.9.

**Fix:** Merged with [PR #326](https://github.com/chainguard-forks/kaniko/pull/326) — uses securejoin for path resolution in tar extraction.

**Acknowledgements**

kaniko thanks Oleh Konko from [1seal](https://1seal.org/) for discovering and reporting this issue.
GitHub Security Advisory: GHSA-xfx2-prg5-jq3g
Package: github.com/romitou/insatutorat (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-285: Improper Authorization
Vulnerable versions: < 0.0.0[PII_REDACTED]5457-15ae47425aed
Patched in: 0.0.0[PII_REDACTED]5457-15ae47425aed

Summary: INSATutorat has an authorization bypass vulnerability in its  /api/admin/* endpoints

Details:
### Impact

An authorization bypass vulnerability was discovered in the administration pages of the tutoring application. When a standard user (logged in but without administrator privileges) attempts to access a resource under /api/admin/, the system detects the error but does not block the request.

As a result, sensitive data is still transmitted by the server in the request (GET), and modification actions such as campaign creation (POST) are executed successfully despite the FORBIDDEN error message. All /api/admin/* endpoints are affected.

### Remediation

The issue was resolved by adding the missing c.Abort() instruction in the Gin authentication middleware (commit 15ae474). This instruction immediately interrupts the processing chain if the user is not an administrator.

### Workarounds

There is no workaround other than applying the fix in the source code.

### Resources:
* Link to the fix commit: [15ae474](https://github.com/Romitou/INSATutorat/commit/15ae47425aed337181f7a6c54a9d199c93b041eb)


### Credits
INSATutorat thanks the Master 2 SSI 25-26 team at the University of Rouen Normandie for their research work on this project.
- Malak Bekkai
- Matthieu Espada Mora
- Amen Allah Khalf Allah
- Liam Laouenan
- Neila Ould Slimane
- Lucas Thomire

This advisory was translated from French to English by GitHub Copilot.
GitHub Security Advisory: GHSA-945p-3jhm-6rcp
Package: github.com/chainguard-dev/malcontent (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-703: Improper Check or Handling of Exceptional Conditions
Vulnerable versions: < 1.21.0
Patched in: 1.21.0

Summary: malcontent: Nested archive extraction failure can drop content from scan inputs

Details:
Previously, malcontent would remove nested archives which failed to extract which could potentially leave malicious content. A better approach is to preserve these archives so that malcontent can attempt a best-effort scan of the archive bytes.

**Fix**:  https://github.com/chainguard-dev/malcontent/pull/1383

**Acknowledgements**

malcontent thanks Oleh Konko from [1seal](https://1seal.org/) for discovering and reporting this issue.
GitHub Security Advisory: GHSA-gxvv-45f6-3ch8
Package: github.com/openshift/openshift-apiserver (GO)
Severity: HIGH (CVSS 8.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 0.0.0-alpha.0.0[PII_REDACTED]3947-0eb84cd66658
Patched in: unpatched

Summary: openshift-apiserver: SSRF via Missing IP/Network-Range Validation in User-Supplied Image References

Details:
A flaw was found in ose-openshift-apiserver. This vulnerability allows internal network enumeration, service discovery, limited information disclosure, and potential Denial of Service (DoS) through Server-Side Request Forgery (SSRF) due to missing IP address and network-range validation when processing user-supplied image references.
GitHub Security Advisory: GHSA-gxvv-45f6-3ch8
Package: github.com/openshift/openshift-apiserver (GO)
Severity: HIGH (CVSS 8.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: = 4.0.0-alpha.0
Patched in: unpatched

Summary: openshift-apiserver: SSRF via Missing IP/Network-Range Validation in User-Supplied Image References

Details:
A flaw was found in ose-openshift-apiserver. This vulnerability allows internal network enumeration, service discovery, limited information disclosure, and potential Denial of Service (DoS) through Server-Side Request Forgery (SSRF) due to missing IP address and network-range validation when processing user-supplied image references.