deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-5rc7-2jj6-mp64
Package: github.com/linode/terraform-provider-linode/v2 (GO)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: <= 2.41.2
Patched in: unpatched

Summary: Terraform Provider  for Linode Debug Logs Vulnerable to Sensitive Information Exposure

Details:
### Impact
The Terraform Provider for Linode versions prior to v3.9.0 logged sensitive information including some passwords, StackScript content, object storage data, and NodeBalancer TLS keys in debug logs without redaction.

**Important:** Provider debug logging is **not enabled by default**.  
This issue is exposed when debug/provider logs are explicitly enabled (for example in local troubleshooting, CI/CD jobs, or centralized log collection). If enabled, sensitive values may be written to logs and then retained, shared, or exported beyond the original execution environment.

Specifically:
- Instance creation operations logged the full InstanceCreateOptions struct containing RootPass and StackScriptData
- Instance disk creation logged InstanceDiskCreateOptions containing RootPass and StackscriptData
- StackScript update operations logged the complete script content via StackscriptUpdateOptions.Script
- Image share group member creation logged tokens in ImageShareGroupAddMemberOptions.Token
- Object storage operations logged full PutObjectInput structures containing user data
- NodeBalancer config create and update operations logged NodeBalancerConfigCreateOptions and NodeBalancerConfigUpdateOptions containing the SSLKey (TLS private key)

An authenticated user with access to provider debug logs (through log aggregation systems, CI/CD pipelines, or debug output) would thus be able to extract these sensitive credentials.

### Patches
Update to version v3.9.0 or later, which sanitizes debug logs by logging only non-sensitive metadata such as labels, regions, and resource IDs while redacting credentials, tokens, keys, scripts, and other sensitive content.

### Workarounds and Mitigations
- Disable Terraform/provider debug logging or set it to `WARN` level or above
  - To disable the logging, you can unset `TF_LOG_PROVIDER` and `TF_LOG` environment variables
  - Or you can set them to `WARN` or `ERROR` levels to avoid sensitive information logged in `INFO` and `DEBUG` levels.
  - See Terraform docs for details: https://developer.hashicorp.com/terraform/internals/debugging
- Restrict access to existing and historical logs
- Purge/retention-trim logs that may contain sensitive values
- Rotate potentially exposed secrets/credentials, including:
  - Root passwords
  - Image share group tokens
  - TLS private keys/certificates used in NodeBalancer configs
  - StackScript content/secrets if embedded

### Credits
This issue was reported to Terraform by Hasan Sheet via [Akamai's HackerOne Bug Bounty program](https://hackerone.com/akamai).

### Resources
https://github.com/linode/terraform-provider-linode/releases/tag/v3.9.0
https://github.com/linode/terraform-provider-linode/pull/2269
https://github.com/linode/terraform-provider-linode/commit/43a925d826b999f0355de3dc7330c55f496824c0
GitHub Security Advisory: GHSA-5rc7-2jj6-mp64
Package: github.com/linode/terraform-provider-linode/v3 (GO)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: < 3.9.0
Patched in: 3.9.0

Summary: Terraform Provider  for Linode Debug Logs Vulnerable to Sensitive Information Exposure

Details:
### Impact
The Terraform Provider for Linode versions prior to v3.9.0 logged sensitive information including some passwords, StackScript content, object storage data, and NodeBalancer TLS keys in debug logs without redaction.

**Important:** Provider debug logging is **not enabled by default**.  
This issue is exposed when debug/provider logs are explicitly enabled (for example in local troubleshooting, CI/CD jobs, or centralized log collection). If enabled, sensitive values may be written to logs and then retained, shared, or exported beyond the original execution environment.

Specifically:
- Instance creation operations logged the full InstanceCreateOptions struct containing RootPass and StackScriptData
- Instance disk creation logged InstanceDiskCreateOptions containing RootPass and StackscriptData
- StackScript update operations logged the complete script content via StackscriptUpdateOptions.Script
- Image share group member creation logged tokens in ImageShareGroupAddMemberOptions.Token
- Object storage operations logged full PutObjectInput structures containing user data
- NodeBalancer config create and update operations logged NodeBalancerConfigCreateOptions and NodeBalancerConfigUpdateOptions containing the SSLKey (TLS private key)

An authenticated user with access to provider debug logs (through log aggregation systems, CI/CD pipelines, or debug output) would thus be able to extract these sensitive credentials.

### Patches
Update to version v3.9.0 or later, which sanitizes debug logs by logging only non-sensitive metadata such as labels, regions, and resource IDs while redacting credentials, tokens, keys, scripts, and other sensitive content.

### Workarounds and Mitigations
- Disable Terraform/provider debug logging or set it to `WARN` level or above
  - To disable the logging, you can unset `TF_LOG_PROVIDER` and `TF_LOG` environment variables
  - Or you can set them to `WARN` or `ERROR` levels to avoid sensitive information logged in `INFO` and `DEBUG` levels.
  - See Terraform docs for details: https://developer.hashicorp.com/terraform/internals/debugging
- Restrict access to existing and historical logs
- Purge/retention-trim logs that may contain sensitive values
- Rotate potentially exposed secrets/credentials, including:
  - Root passwords
  - Image share group tokens
  - TLS private keys/certificates used in NodeBalancer configs
  - StackScript content/secrets if embedded

### Credits
This issue was reported to Terraform by Hasan Sheet via [Akamai's HackerOne Bug Bounty program](https://hackerone.com/akamai).

### Resources
https://github.com/linode/terraform-provider-linode/releases/tag/v3.9.0
https://github.com/linode/terraform-provider-linode/pull/2269
https://github.com/linode/terraform-provider-linode/commit/43a925d826b999f0355de3dc7330c55f496824c0
GitHub Security Advisory: GHSA-2v6m-6xw3-6467
Package: github.com/fleetdm/fleet/v4 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-201: Insertion of Sensitive Information Into Sent Data
Vulnerable versions: < 4.80.1
Patched in: 4.80.1

Summary: Fleet: Sensitive Google Calendar credentials disclosed to low-privileged users

Details:
### Summary

A vulnerability in Fleet’s configuration API could expose Google Calendar service account credentials to authenticated users with low-privilege roles. This may allow unauthorized access to Google Calendar resources associated with the service account.

### Impact

Fleet returns configuration data through an API endpoint that is accessible to authenticated users, including those with the lowest-privilege “Observer” role. In affected versions, Google Calendar service account credentials were not properly obfuscated before being returned.

As a result, a low-privilege user could retrieve the service account’s private key material. Depending on how the Google Calendar integration is configured, this could allow unauthorized access to calendar data or other Google Workspace resources associated with the service account.

This issue does not allow escalation of privileges within Fleet or access to device management functionality.

### Patches

- v4.80.1

### Workarounds

If an immediate upgrade is not possible, administrators should remove the Google Calendar integration from Fleet and rotate the affected Google service account credentials.

### For more information

If there are any questions or comments about this advisory:

Email Fleet at [security@fleetdm.com](mailto:security@fleetdm.com)  
Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)

### Credits

Fleet thanks @secfox-ai for responsibly reporting this issue.
GitHub Security Advisory: GHSA-5jvp-m9h4-253h
Package: github.com/fleetdm/fleet/v4 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 4.80.1
Patched in: 4.80.1

Summary: Fleet: Authorization Bypass in certificate template batch deletion for team administrators

Details:
### Summary

A broken authorization check in Fleet’s certificate template deletion API could allow a team administrator to delete certificate templates belonging to other teams within the same Fleet instance.

### Impact

Fleet supports certificate templates that are scoped to individual teams. In affected versions, the batch deletion endpoint validated authorization using a user-supplied team identifier but did not verify that the certificate template IDs being deleted actually belonged to that team.

As a result, a team administrator could delete certificate templates associated with other teams, potentially disrupting certificate-based workflows such as device enrollment, Wi-Fi authentication, VPN access, or other certificate-dependent configurations for the affected teams.

This issue does not allow privilege escalation, access to sensitive data, or compromise of Fleet’s control plane. Impact is limited to integrity and availability of certificate templates across teams.

### Patches

- v4.80.1

### Workarounds

If an immediate upgrade is not possible, administrators should restrict access to certificate template management to trusted users and avoid delegating team administrator permissions where not strictly required.

### For more information

If there are any questions or comments about this advisory:

Email Fleet at [security@fleetdm.com](mailto:security@fleetdm.com)  
Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)

### Credits

Fleet thanks @secfox-ai for responsibly reporting this issue.
GitHub Security Advisory: GHSA-9pm7-6g36-6j78
Package: github.com/fleetdm/fleet/v4 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-306: Missing Authentication for Critical Function, CWE-862: Missing Authorization
Vulnerable versions: < 4.80.1
Patched in: 4.80.1

Summary: Fleet: Unauthenticated Android device disenrollment vulnerability via Pub/Sub endpoint 

Details:
### Summary

A vulnerability in Fleet’s Android MDM Pub/Sub handling could allow unauthenticated requests to trigger device unenrollment events. This may result in unauthorized removal of individual Android devices from Fleet management.

### Impact

If Android MDM is enabled, an attacker could send a crafted request to the Android Pub/Sub endpoint to unenroll a targeted Android device from Fleet without authentication.

This issue does not grant access to Fleet, allow execution of commands, or provide visibility into device data. Impact is limited to disruption of Android device management for the affected device.

### Workarounds

If an immediate upgrade is not possible, affected Fleet users should temporarily disable Android MDM.

### For more information

If there any questions or comments about this advisory:

Email Fleet at [security@fleetdm.com](mailto:security@fleetdm.com)
Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)

### Credits

Fleet thanks @secfox-ai for responsibly reporting this issue.
GitHub Security Advisory: GHSA-ppwx-5jq7-px2w
Package: github.com/fleetdm/fleet/v4 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-330: Use of Insufficiently Random Values
Vulnerable versions: < 4.80.1
Patched in: 4.80.1

Summary: Fleet: Device lock PIN can be predicted if lock time is known

Details:
### Summary

Fleet generated device lock and wipe PINs using a predictable algorithm based solely on the current Unix timestamp. Because no secret key or additional entropy was used, the resulting PIN could potentially be derived if the approximate time the device was locked is known.

### Impact

Fleet’s device lock and wipe commands generate a 6-digit PIN that is displayed to administrators for unlocking a device. In affected versions, this PIN was deterministically derived from the current timestamp.

An attacker with physical possession of a locked device and knowledge of the approximate time the lock command was issued could theoretically predict the correct PIN within a limited search window.

However, successful exploitation is constrained by multiple factors:
- Physical access to the device is required.
- The approximate lock time must be known.
- The operating system enforces rate limiting on PIN entry attempts.
- Attempts would need to be spread over multiple days.
- Device wipe operations would typically complete before sufficient attempts could be made.

As a result, this issue does not allow remote exploitation, fleet-wide compromise, or bypass of Fleet authentication controls.

### Workarounds

There are no known workarounds for this issue. Customers should upgrade to a patched version.

### For more information

If there are any questions or comments about this advisory:

Email Fleet at [security@fleetdm.com](mailto:security@fleetdm.com)
Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)

### Credits

Fleet thanks @secfox-ai for responsibly reporting this issue.
GitHub Security Advisory: GHSA-49xw-vfc4-7p43
Package: github.com/fleetdm/fleet/v4 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 4.80.1
Patched in: 4.80.1

Summary: Fleet has an SQL Injection vulnerability via backtick escape in ORDER BY parameter

Details:
### Summary

A SQL Injection vulnerability in Fleet’s software versions API allowed authenticated users to inject arbitrary SQL expressions via the `order_key` query parameter. Due to unsafe use of `goqu.I()` when constructing the `ORDER BY` clause, specially crafted input could escape identifier quoting and be interpreted as executable SQL.

### Impact

An authenticated attacker with access to the affected endpoint could inject SQL expressions into the underlying MySQL query. Although the injection occurs in an `ORDER BY` context, it is sufficient to enable blind SQL injection techniques that can disclose database information through conditional expressions that affect result ordering. Crafted expressions may also cause excessive computation or query failures, potentially leading to degraded performance or denial of service.

No direct evidence of reliable data modification or stacked query execution was demonstrated.

### Workarounds

If an immediate upgrade is not possible, users should restrict access to the affected endpoint to trusted roles only and ensure that any user-supplied sort or column parameters are strictly allow-listed at the application or proxy layer.

### For more information

If there are any questions or comments about this advisory:

Email fleet at [security@fleetdm.com](mailto:security@fleetdm.com)  
Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)

### Credits

We thank @fuzzztf for responsibly reporting this issue.
GitHub Security Advisory: GHSA-3ccg-x393-96v8
Package: code.vikunja.io/api (GO)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-521: Weak Password Requirements, CWE-613: Insufficient Session Expiration
Vulnerable versions: <= 0.24.6
Patched in: unpatched

Summary: Vijkunja has Weak Password Policy Combined with Persistent Sessions After Password Change

Details:
**Summary**
The application allows users to set weak passwords (e.g., 1234, password) without enforcing minimum strength requirements. Additionally, active sessions remain valid after a user changes their password.

An attacker who compromises an account (via brute-force or credential stuffing) can maintain persistent access even after the victim resets their password.


**Details**

1. Weak passwords are accepted during registration and password change.
2. No minimum length or strength validation is enforced.
3. After changing the password, previously issued session tokens remain valid.
4. No forced logout occurs across active sessions.

_Attack scenario:_

Attacker guesses or obtains weak credentials.
Logs in and obtains active session token.
Victim changes password.
Attacker continues accessing the account using the old session.

**Steps to Reproduce**

**1.** Register using a weak password (e.g., 12345678 ).
**2.** Log in and Password Change functionality.
**3.** Change account password with single character (e.g., 1 or a )
**4.** Reuse the old session.
**5.** Observe that access is still granted.

**Impact**

- Persistent account takeover
- Unauthorized access to sensitive data
- Increased brute-force success probability
- Elevated risk for administrative accounts

The combination of weak password controls and improper session invalidation significantly increases both exploitability and impact.

**Recommendation**
_**Password Policy Improvements:**_

- Enforce strong password policies – Require passwords to be 8–16+ characters with a mix of uppercase, lowercase, numbers, and special characters.
- Block common passwords – Use a blacklist of commonly used and breached passwords.
- Use secure hashing – Store passwords using strong salted hashing algorithms like bcrypt or Argon2.
- Enable account lockout – Limit failed login attempts to reduce brute-force risk.
- Educate users – Promote strong password practices and phishing awareness.

_**Session Management Fix:**_

- Invalidate all active sessions upon password change
- Revoke refresh tokens (if applicable)
- Implement token/session versioning
- Regenerate session IDs after credential updates
- Log and notify users of password change events

Implementing both controls will significantly reduce the risk of persistent account compromise.

<img width="1918" height="907" alt="Weak Password Policy Combined with Persistent Sessions After Password Change POC" src="https://github.com/user-attachments/assets/f188b69b-0472-4d2c-aeda-c145384c99ef" />

A fixed version is available at https://github.com/go-vikunja/vikunja/releases/tag/v2.0.0.
GitHub Security Advisory: GHSA-q9hv-hpm4-hj6x
Package: github.com/cloudflare/circl (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-682: Incorrect Calculation
Vulnerable versions: < 1.6.3
Patched in: 1.6.3

Summary: CIRCL has an incorrect calculation in secp384r1 CombinedMult

Details:
The CombinedMult function in the CIRCL ecc/p384 package (secp384r1 curve) produces an incorrect value for specific inputs. The issue is fixed by using complete addition formulas.
ECDH and ECDSA signing relying on this curve are not affected.

The bug was fixed in **[v1.6.3](https://github.com/cloudflare/circl/releases/tag/v1.6.3)**.
GitHub Security Advisory: GHSA-2phg-qgmm-r638
Package: github.com/BishopFox/sliver (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)
Vulnerable versions: < 1.7.2
Patched in: 1.7.2

Summary: Sliver has Potential Zip Bomb Denial of Service in GzipEncoder

Details:
### Summary

GzipEncoder does not limit output size when processing compressed data. This allows unauthenticated remote attackers to crash sliver server by sending a http request with highly compressed gzip data (aka zip bomb).

### Details

In `util/encoders/gzip.go`, `Decode()` method decompresses given data by reading the entire gzip buffer at once without limiting output size.

### PoC

```python
data = gzip.compress(bytes(1024 * 1024 * 1024)) * 16
requests.post(f"http://172.17.0.2/{nonce}", data=data)
```

### Impact

Unauthenticated remote attackers can exhaust memory and cpu resource of sliver server and crash it when they have GzipEncoderID, which can be easily retrived from implant's http traffic, or by brute-forcing.

A fixed version is available at https://github.com/BishopFox/sliver/releases/tag/v1.7.2.
GitHub Security Advisory: GHSA-6v48-fcq6-ff23
Package: github.com/dagu-org/dagu (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 1.16.7
Patched in: unpatched

Summary: Dagu: Path traversal in DAG creation allows arbitrary YAML file write outside DAGs directory

Details:
The `CreateNewDAG` API endpoint (`POST /api/v1/dags`) does not validate the DAG name before passing it to the file store. While `RenameDAG` calls `core.ValidateDAGName()` to reject names containing path separators (line 273 in `dags.go`), `CreateNewDAG` skips this validation entirely and passes user input directly to `dagStore.Create()`.

In `internal/persis/filedag/store.go`, the `generateFilePath` function (line 493) checks if the name contains a path separator, and if so, resolves it via `filepath.Abs(name)` — completely ignoring the `baseDir`. This means a name like `../../tmp/pwned` will write a file to `/tmp/pwned.yaml` instead of the DAGs directory.

**Affected code:**

`internal/service/frontend/api/v1/dags.go` line 120-170 — `CreateNewDAG` handler, no call to `ValidateDAGName`

`internal/persis/filedag/store.go` line 493-498 — `generateFilePath` resolves absolute path when name contains separator

`internal/persis/filedag/store.go` line 213 — `Create` calls `generateFilePath` and writes attacker-controlled YAML content to the resolved path

**PoC:**

```
curl -X POST http://localhost:8080/api/v1/dags \
  -H "Content-Type: application/json" \
  -d '{
    "name": "../../tmp/path-traversal-proof",
    "spec": "steps:\n  - command: id > /tmp/pwned\n"
  }'
```

After this request, a file `/tmp/path-traversal-proof.yaml` will be created with the attacker-supplied content. The file will be written with the permissions of the dagu process.

An authenticated user with DAG write permissions can write arbitrary YAML files anywhere on the filesystem (limited by the process permissions). Since dagu executes DAG files as shell commands, writing a malicious DAG to the DAGs directory of another instance or overwriting config files can lead to remote code execution.