deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-gq2m-77hf-vwgh
Package: github.com/OliveTin/OliveTin (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-384: Session Fixation, CWE-613: Insufficient Session Expiration
Vulnerable versions: < 0.0.0[PII_REDACTED]3115-d6a0abc3755d15
Patched in: 0.0.0[PII_REDACTED]3115-d6a0abc3755d15

Summary: OliveTin Session Fixation: Logout Fails to Invalidate Server-Side Session

Details:
### Summary
OliveTin does not revoke server-side sessions when a user logs out. Although the browser cookie is cleared, the corresponding session remains valid in server storage until expiry (default ≈ 1 year).

An attacker with a previously stolen or captured session cookie can continue authenticating after logout, resulting in a post-logout authentication bypass.

This is a session management flaw that violates expected logout semantics.

### Details
During logout:
```
// Logout only clears browser cookie
response.Header().Set("Set-Cookie", localCookie.String())
```
However, the server still accepts the session:
```
session := sessionStorage.Providers[provider].Sessions[sid]
...
return session
```
The SID is not deleted from sessionStorage.

Why vulnerable: Logout does not remove the SID from sessionStorage; old cookie is still accepted until expiry (~1 year).

File: [api.go](app://-/index.html?hostId=local#), [sessions.go](app://-/index.html?hostId=local#), [local.go](app://-/index.html?hostId=local#)
Lines: api.go:392-427; sessions.go:39-59, 61-80; local.go:32-47
Behavior
- Login → receive SID cookie
- Logout → cookie cleared client-side
- Replay old SID manually → still authenticated

Expected:
- Logout invalidates session immediately

Actual:
- Old SID remains usable until expiry

### PoC

Minimal config
```
listenAddressSingleHTTPFrontend: 0.0.0.0:16642
authRequireGuestsToLogin: true

authLocalUsers:
  enabled: true
  users:
    - username: low
      usergroup: users
      [CREDENTIAL_REDACTED]..."

actions:
  - title: Dummy
    id: dummy
    shell: "echo dummy"
```

### Reproduction

Login and capture SID:
```
LOGIN=$(curl -i -X POST http://localhost:16642/api/LocalUserLogin \
  -H 'Content-Type: application/json' \
  -d '{"username":"low","password":"lowpass"}')

SID=$(printf '%s\n' "$LOGIN" | awk -F'[=;]' '/olivetin-sid-local/{print $2}')
```
Works before logout:
```
curl -X POST http://localhost:16642/api/WhoAmI \
  -H "Cookie: olivetin-sid-local=$SID"
```
Logout:
```
curl -X POST http://localhost:16642/api/Logout \
  -H "Cookie: olivetin-sid-local=$SID"
```
Replay old cookie:
```
curl -X POST http://localhost:16642/api/WhoAmI \
  -H "Cookie: olivetin-sid-local=$SID"
```
Result

User is still authenticated after logout.
### Impact
Type:

Session Management Flaw

- Logout Bypass
- Session Replay

Risk:
- Stolen cookies remain valid
- Persistent unauthorized access
- Users falsely believe logout ended the session

Attack scenarios:
- Shared computers
- XSS/session theft
- Proxy logs
- Malware/browser compromise
GitHub Security Advisory: GHSA-hcff-qv74-7hr4
Package: github.com/forceu/gokapi (GO)
Severity: MODERATE (CVSS 4.6)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: < 2.2.3
Patched in: 2.2.3

Summary: Gokapi has CSRF in Login Endpoint

Details:
### Summary
The login flow accepts credential-bearing requests without CSRF protection mechanisms tied to the browser session context. The handler parses form values directly and creates a session on successful credential validation.

*Issue found by [aisafe.io](aisafe.io)*

### Impact
An attacker can force a victim browser into a session associated with an existing user account where the attacker knows the credentials, causing user confusion, activity misattribution, and potential misuse of trusted user actions.
GitHub Security Advisory: GHSA-q658-hfpg-35qc
Package: github.com/forceu/gokapi (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 2.2.3
Patched in: 2.2.3

Summary: Gokapi has privilege escalation via incomplete API-key permission revocation on user rank demotion

Details:
### Summary
A privilege escalation vulnerability in the user rank demotion logic allows a demoted user's existing API keys to retain ApiPermManageFileRequests and ApiPermManageLogs permissions, enabling continued access to upload-request management  and log viewing endpoints after the user has been stripped of all privileges.

### Impact
Any user who previously held Admin rank and had API keys with ApiPermManageFileRequests or ApiPermManageLogs retains those capabilities after demotion. This allows offboarded or demoted users to:
  - Create, list, and delete upload requests
  - Read application logs and system status
GitHub Security Advisory: GHSA-vgjm-2cpf-4g7c
Package: gogs.io/gogs (GO)
Severity: HIGH (CVSS 7.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 0.13.3
Patched in: unpatched

Summary: Gogs: DOM-based XSS via milestone selection

Details:
# Summary

It was confirmed in a test environment that an attacker can store an HTML/JavaScript payload in a repository’s **Milestone name**, and when another user selects that Milestone on the **New Issue** page (`/issues/new`), a **DOM-Based XSS** is triggered.

# Impact

* Theft of information accessible in the victim’s session.
* Extraction of CSRF tokens and submission of state-changing requests with the victim’s privileges.
* Repository operations performed with the victim’s privileges (Issue operations, settings changes, etc.).

(The impact scope depends on the victim’s permission level.)

# Remediation

A fix is available at https://github.com/gogs/gogs/releases/tag/v0.14.2
GitHub Security Advisory: GHSA-x9p5-w45c-7ffc
Package: gogs.io/gogs (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-598: Use of GET Request Method With Sensitive Query Strings
Vulnerable versions: <= 0.13.3
Patched in: unpatched

Summary: Gogs: Access tokens get exposed through URL params in API requests

Details:
### Summary

The Gogs API still accepts tokens in URL parameters such as `token` and `access_token`, which can leak through logs, browser history, and referrers.

### Details

A static review shows that the API still checks tokens in the URL query before looking at headers:

  - internal/context/auth.go reads `c.Query("token")`
  - internal/context/auth.go falls back to `c.Query("access_token")`
  - internal/context/auth.go only checks the `Authorization` header when the query token is empty
  - internal/context/auth.go authenticates using that token and marks the request as token-authenticated

Token-authenticated requests are accepted by API routes through `c.IsTokenAuth` checks:
  - internal/route/api/v1/api.go

### Impact

If tokens are sent in URLs such as `/api/v1/user?token=...`, they can leak in logs, browser or shell history, and referrer headers, and can be reused until revoked.

### Recommended Fix

- Authentication headers should be used exclusively for token transmission.
- Token parameters should be blocked at the proxy or WAF level.
- Query strings should be scrubbed from logs.
- A strict referrer policy should be set.

### Remediation

A fix is available at https://github.com/gogs/gogs/releases/tag/v0.14.2.
GitHub Security Advisory: GHSA-vgvf-m4fw-938j
Package: gogs.io/gogs (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 0.13.3
Patched in: unpatched

Summary: Gogs: Stored XSS in branch and wiki views through author and committer names

Details:
### Summary

Stored XSS is still possible through unsafe template rendering that mixes user input with `safe()` plus permissive sanitizer handling of data URLs.

### Details

`safe()` still turns off escaping:
- internal/template/template.go
- `func safe(raw string) template.HTML { return template.HTML(raw) }`

Branch pages still render committer names using `safe()`:
- templates/repo/branches/overview.tmpl
- templates/repo/branches/all.tmpl
- templates/repo/wiki/view.tmpl

The locale still injects a raw second argument: conf/locale/locale_en-US.ini (`branches.updated_by = updated %[1]s by %[2]s`)

### Impact

An attacker who can inject commit metadata such as author/committer name can trigger script execution on affected pages, leading to session abuse, CSRF token theft, or unauthorized actions.

### Recommended Fix

- Untrusted arguments should be escaped before being used in translations.
- Data URLs should be limited or blocked in the sanitizer.

### Remediation
A fix is available at https://github.com/gogs/gogs/releases/tag/v0.14.2.
GitHub Security Advisory: GHSA-v9vm-r24h-6rqm
Package: gogs.io/gogs (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
Vulnerable versions: <= 0.14.1
Patched in: 0.14.2

Summary: Gogs: Release tag option injection in release deletion

Details:
### Summary

There is a security issue in Gogs where deleting a release can fail if a user-controlled tag name is passed to Git without the right separator, allowing Git option injection and therefore interfering with the process.

### Affected Component

  - internal/database/release.go
    `process.ExecDir(..., "git", "tag", "-d", rel.TagName)`

### Details

  `rel.TagName` is used as a CLI argument to `git tag -d` without `--` or `--end-of-options`.
  If the tag name begins with `-`, Git parses it as a flag.

  The prior mitigation is incomplete. There is path sanitization in place during creation:

  - internal/database/release.go
    `r.TagName = strings.TrimLeft(r.TagName, "-")`

  But it only covers one creation path and does not reliably protect tag deletions, such as tags added through `git push` or ref updates.

**Exploit Conditions**
1. An attacker can add a tag name that starts with a dash into the repository.
2. A user with permission to delete releases triggers it through the web UI or API.

### Recommended Fix

1. Add end-of-options in release deletion:
      - `git tag -d -- <tagName>`
2. It is better to use the safe git-module deletion helper since it handles options properly.
3. All Git commands should be audited for user input, ensuring that the end-of-options separator is always used.

### Impact
  - Option injection into `git tag -d`
  - Tag/release deletion can fail or behave unexpectedly
  - Operational denial of service in release cleanup workflows
  - Potential release metadata inconsistency
GitHub Security Advisory: GHSA-xrcr-gmf5-2r8j
Package: gogs.io/gogs (GO)
Severity: HIGH (CVSS 8.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 0.14.1
Patched in: 0.14.2

Summary: Gogs: Stored XSS via data URI in issue comments

Details:
### Summary
A Stored Cross-site Scripting (XSS) vulnerability exists in the comment and issue description functionality. The application's HTML sanitizer explicitly allows `data:` URI schemes, enabling authenticated users to inject arbitrary JavaScript execution via malicious links.

### Details
The vulnerability is located in `internal/markup/sanitizer.go`. The application uses the `bluemonday` HTML sanitizer but explicitly weakens the security policy by allowing the `data` URL scheme:

```go
// internal/markup/sanitizer.go
func NewSanitizer() {
    sanitizer.init.Do(func() {
        // ...
        // Data URLs
        sanitizer.policy.AllowURLSchemes("data")
        // ...
    })
}
```

While the Markdown renderer rewrites relative links (mitigating standard Markdown `[link](data:...)` attacks), Gogs supports **Raw HTML** input. Raw HTML anchor tags bypass the Markdown parser's link rewriting and are processed directly by the sanitizer. Since the sanitizer is configured to allow `data:` URIs, payloads like `<a href="data:text/html...">` are rendered as-is.

### PoC
1.  Create a file named `exploit.md` in a repository.
2.  Add the following content (Raw HTML):
    ```html
    <a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=">Click me for XSS</a>
    ```
3.  Commit and push the file.
4.  Navigate to the file in the Gogs web interface.
5.  Click the "Click me for XSS" link.
6.  **Result:** An alert box with "XSS" appears, executing the JavaScript payload.

### Impact
This is a **Stored XSS** vulnerability. Any user who views the malicious comment and clicks the link will execute the attacker-supplied JavaScript in their browser context. This allows attackers to:
*   Steal authentication cookies and session tokens.
*   Perform arbitrary actions on behalf of the victim (e.g., modifying repositories, adding collaborators).
*   Redirect users to malicious sites.
GitHub Security Advisory: GHSA-m2hx-wjxc-9fp4
Package: github.com/forceu/gokapi (GO)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 2.2.3
Patched in: 2.2.3

Summary: Gokapi has privilege escalation with auth token

Details:
### Impact
A registered user without privileges to create or modify file requests is able to create a short-lived API key that has the permission to do so.

The user must be registered with Gokapi. If you do not have any other users with access to the admin/upload menu, you are not  impacted.

### Patches
This CVE is patched in v2.2.3
GitHub Security Advisory: GHSA-3c22-5j5m-4jq7
Package: github.com/forceu/gokapi (GO)
Severity: HIGH (CVSS 8.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 2.2.3
Patched in: 2.2.3

Summary: Gokapi has Stored XSS in SVG Hotlinks

Details:
### Summary
If a malicious authenticated user uploads SVG and creates a hotlink for it, they achieve stored XSS.

### Details
The hotlinking functionality fails to properly handle scripts included in the SVGs, allowing authenticated attackers with the ability to upload and hotlink file to execute arbitrary JS.

*Issue found by [aisafe.io](https://aisafe.io/)*


### Impact
Authenticated attackers with the ability to upload and hotlink files can execute arbitrary JavaScript.
GitHub Security Advisory: GHSA-c36c-7pc2-f2ph
Package: github.com/forceu/gokapi (GO)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-284: Improper Access Control
Vulnerable versions: < 2.2.3
Patched in: 2.2.3

Summary: Gokapi has Data Leak in Upload Status Stream

Details:
## Description

The upload status SSE implementation on `/uploadStatus` publishes global upload state to any authenticated listener and includes `file_id` values that are not scoped to the requesting user. 

## Impact

Any authenticated user can observe other users' file identifiers and retrieve unauthorized content, causing cross-tenant data exposure and loss of confidentiality for uploaded documents.

*Issue found by [aisafe.io](https://aisafe.io)*
GitHub Security Advisory: GHSA-v2x6-wwfw-r2rq
Package: github.com/agentgateway/agentgateway (GO)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 0.12.0
Patched in: 0.12.0

Summary: Agentgateway is missing parameter sanitization in MCP to OpenAPI conversion

Details:
### Summary

When converting MCP `tools/call` request to OpenAPI request, input path, query, and header values are not sanitized.

### Details

When using the [MCP to OpenAPI](https://agentgateway.dev/docs/standalone/latest/mcp/connect/openapi/) feature, the proxy lacks proper sanitization of input parameters in the MCP call, allowing:
* Injection of additional path or query parameters.
* Injection of additional headers.

### Impacted Versions

This vulnerability is fixed in Agentgateway v0.12.0+. Users on older versions are recommended to upgrade to v0.12.0+.

This feature only impacts usage of the [MCP to OpenAPI](https://agentgateway.dev/docs/standalone/latest/mcp/connect/openapi/) feature

### Credits

Agentgateway extends its thanks to @spacewander for the report!
GitHub Security Advisory: GHSA-p436-gjf2-799p
Package: github.com/docker/cli (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-427: Uncontrolled Search Path Element
Vulnerable versions: >= 19.03.0, < 29.2.0
Patched in: 29.2.0

Summary: Docker CLI Plugins: Uncontrolled Search Path Element Leads to Local Privilege Escalation on Windows

Details:
This issue affects Docker CLI through 29.1.5

### Impact

Docker CLI for Windows searches for plugin binaries in `C:\ProgramData\Docker\cli-plugins`, a directory that does not exist by default. A low-privileged attacker can create this directory and place malicious CLI plugin binaries (docker-compose.exe, docker-buildx.exe, etc.) that are executed when a victim user opens Docker Desktop or invokes Docker CLI plugin features, and allow privilege-escalation if the `docker` CLI is executed as a privileged user.

This issue affects Docker CLI through v29.1.5 (fixed in v29.2.0). It impacts Windows binaries acting as a CLI plugin manager via the [`github.com/docker/cli/cli-plugins/manager`](https://pkg.go.dev/github.com/docker/cli@v29.1.5+incompatible/cli-plugins/manager) package, which is consumed by downstream projects such as Docker Compose.

Docker Compose became affected starting in v2.31.0, when it incorporated the relevant CLI plugin manager code (see https://github.com/docker/compose/pull/12300), and is fixed in v5.1.0.

This issue does not impact non-Windows binaries or projects that do not use the plugin manager code.

### Patches

Fixed version starts with 29.2.0

This issue was fixed in https://github.com/docker/cli/commit/13759330b1f7e7cb0d67047ea42c5482548ba7fa (https://github.com/docker/cli/pull/6713), which removed `%PROGRAMDATA%\Docker\cli-plugins` from the list of paths used for plugin-discovery on Windows.

### Workarounds

None

### Resources

- Pull request: "cli-plugins/manager: remove legacy system-wide cli-plugin path" (https://github.com/docker/cli/pull/6713)
- Patch: https://github.com/docker/cli/commit/13759330b1f7e7cb0d67047ea42c5482548ba7fa.patch

### Credits

Nitesh Surana (niteshsurana.com) of Trend Research of TrendAI
GitHub Security Advisory: GHSA-6rx5-m2rc-hmf7
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 7.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, < 4.12.0
Patched in: 4.12.0

Summary: ZITADEL: Stored XSS via Default URI Redirect Leads to Account Takeover

Details:
### Summary

A vulnerability in Zitadel's login V2 interface was discovered, allowing for possible account takeover.

### Impact

Zitadel allows organization administrators to change the default redirect URI for their organization. This setting enables them to redirect users to an arbitrary location after they log in.

Due to missing restrictions and improper handling, malicious javascrtipt code could be executed in Zitadel login UI (v2) using the users’ browser. 

An unauthenticated remote attacker can exploit this Stored XSS vulnerability, reset the password of their victims, and take over their accounts.

It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.Stored XSS vulnerability. 

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.11.1` (including RC versions)

### Patches

The vulnerability has been addressed in the latest releases. The login UI prevents execution of such code. Additionally, the page to change the password, now always requires the user's current password regardless of the state of the authenticated session.

4.x: Upgrade to >= [4.12.0](https://github.com/zitadel/zitadel/releases/tag/v4.12.0)

### Workarounds

The recommended solution is to upgrade to a patched version.

### Questions

If there are any questions or comments about this advisory, please send an email to [security@zitadel.com](mailto:security@zitadel.com)

### Credits

ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.
GitHub Security Advisory: GHSA-6rx5-m2rc-hmf7
Package: github.com/zitadel/zitadel/v2 (GO)
Severity: HIGH (CVSS 7.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, < 4.12.0
Patched in: 4.12.0

Summary: ZITADEL: Stored XSS via Default URI Redirect Leads to Account Takeover

Details:
### Summary

A vulnerability in Zitadel's login V2 interface was discovered, allowing for possible account takeover.

### Impact

Zitadel allows organization administrators to change the default redirect URI for their organization. This setting enables them to redirect users to an arbitrary location after they log in.

Due to missing restrictions and improper handling, malicious javascrtipt code could be executed in Zitadel login UI (v2) using the users’ browser. 

An unauthenticated remote attacker can exploit this Stored XSS vulnerability, reset the password of their victims, and take over their accounts.

It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.Stored XSS vulnerability. 

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.11.1` (including RC versions)

### Patches

The vulnerability has been addressed in the latest releases. The login UI prevents execution of such code. Additionally, the page to change the password, now always requires the user's current password regardless of the state of the authenticated session.

4.x: Upgrade to >= [4.12.0](https://github.com/zitadel/zitadel/releases/tag/v4.12.0)

### Workarounds

The recommended solution is to upgrade to a patched version.

### Questions

If there are any questions or comments about this advisory, please send an email to [security@zitadel.com](mailto:security@zitadel.com)

### Credits

ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.
GitHub Security Advisory: GHSA-25rw-g6ff-fmg8
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 8.2)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 4.0.0, <= 4.12.0
Patched in: 4.12.1

Summary: ZITADEL: Login V2 UI Policy Bypass Allows Unauthorized Self-Registration and Authentication

Details:
### Summary

A vulnerability in Zitadel's login V2 UI allowed users to bypass login behavior and security policies and self-register new accounts or sign in using password even if corresponding options were disabled in their organizaton.

### Impact

Zitadel enables administrators to configure their organization’s login behavior and security policies. As part of this functionality, they can disable user self-registration, enforce passwordless logins only, and more.

Due to improper enforcement an attacker could send direct HTTP requests to the login UI and create accounts in organizations that have disabled user self-registration, and gain unauthorized access to the system.
The same attack vector could be used to authenticate for example using username and password even when this login method was disabled.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.12.0` (including RC versions)

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by enforcing the policies on the logiin UI server.

4.x: Upgrade to >=[4.12.1](https://github.com/zitadel/zitadel/releases/tag/v4.12.1)

### Workarounds

The recommended solution is to upgrade to a patched version.

### Questions

If there are any questions or comments about this advisory, please send an email to [security@zitadel.com](mailto:security@zitadel.com)

### Credits 

ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.