deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-95wr-3f2v-v2wh
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 5.0.0-RC1, <= 5.9.14
Patched in: 5.9.15

Summary: Craft CMS has a host header injection leading to SSRF via resource-js endpoint

Details:
### Summary

The `resource-js` endpoint in Craft CMS allows unauthenticated requests to proxy remote JavaScript resources. 
When `trustedHosts` is not explicitly restricted (default configuration), the application trusts the client-supplied Host header. 

This allows an attacker to control the derived `baseUrl`, which is used in prefix validation inside `actionResourceJs()`. 
By supplying a malicious Host header, the attacker can make the server issue arbitrary HTTP requests, leading to Server-Side Request Forgery (SSRF).

### Details

The vulnerability exists in `AppController::actionResourceJs()`.

The function validates that the `url` parameter starts with `assetManager->baseUrl`. However, `baseUrl` is derived from the current request host. If `trustedHosts` is not configured, the Host header is fully attacker-controlled.

Attack chain:

1. Attacker sends request with controlled `Host` header.
2. Application derives `baseUrl` from the malicious Host.
3. `url` parameter is required to start with this `baseUrl`.
4. Validation passes.
5. Guzzle performs a server-side HTTP request to the attacker-controlled host.
6. SSRF occurs.

This does not rely on string parsing bypass. It relies on Host header trust.

### PoC (safe reproduction steps)

Environment:
- Craft CMS 5.9.12
- Default configuration (no trustedHosts restriction)
- Docker deployment

1. Start a listener inside the container:
   python3 -m http.server 9999

2. Send a request to resource-js with a controlled Host header.

3. Observe that the internal listener receives a request (OOB confirmation).
GitHub Security Advisory: GHSA-3m9m-24vh-39wx
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 4.0.0-RC1, <= 4.17.8
Patched in: 4.17.9

Summary: Server-Side Request Forgery (SSRF) in Craft CMS with Asset Uploads Mutations

Details:
## Required Permissions

The exploitation requires a few permissions to be enabled in the used GraphQL schema:

* "Edit assets in the <VolumeName> volume"
* "Create assets in the <VolumeName> volume"

## Details

The implementation fails to restrict the URL Scheme. While the application is intended to "upload assets", there is no whitelist forcing `http` or `https`. This allows attackers to use the Gopher protocol to wrap raw TCP commands.

**Impact:** Combined with the DWORD bypass, an attacker can hit internal services without triggering any "127.0.0.1" string-matching filters.

**Example Payload:** gopher://[PII_REDACTED]:6379/_FLUSHALL (Targets local Redis via DWORD).

**Remediation Strategy**

To prevent mathematical IP obfuscation, the application must normalize the hostname before validation.
GitHub Security Advisory: GHSA-3m9m-24vh-39wx
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 5.0.0-RC1, <= 5.9.14
Patched in: 5.9.15

Summary: Server-Side Request Forgery (SSRF) in Craft CMS with Asset Uploads Mutations

Details:
## Required Permissions

The exploitation requires a few permissions to be enabled in the used GraphQL schema:

* "Edit assets in the <VolumeName> volume"
* "Create assets in the <VolumeName> volume"

## Details

The implementation fails to restrict the URL Scheme. While the application is intended to "upload assets", there is no whitelist forcing `http` or `https`. This allows attackers to use the Gopher protocol to wrap raw TCP commands.

**Impact:** Combined with the DWORD bypass, an attacker can hit internal services without triggering any "127.0.0.1" string-matching filters.

**Example Payload:** gopher://[PII_REDACTED]:6379/_FLUSHALL (Targets local Redis via DWORD).

**Remediation Strategy**

To prevent mathematical IP obfuscation, the application must normalize the hostname before validation.
GitHub Security Advisory: GHSA-jq2f-59pj-p3m3
Package: craftcms/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 5.6.0, < 5.9.15
Patched in: 5.9.15

Summary: Craft CMS has a Missing Authorization Check on User Group Removal via save-permissions Action

Details:
## Summary

The `actionSavePermissions()` endpoint allows a user with only `viewUsers` permission to remove arbitrary users from all user groups. While `_saveUserGroups()` enforces per-group authorization for additions, it performs no equivalent authorization check for removals, so submitting an empty `groups` value removes all existing group memberships.

## Affected Versions

- Craft CMS 5.6.0 through 5.9.14 (latest release at time of report)
- Regression introduced in 5.6.0 when the `viewUsers` permission was added
- Prior to 5.6.0, `editedUser()` required `editUsers`, which implicitly protected this endpoint
- Requires Pro edition or higher (the vulnerable code path is gated by `CmsEdition::Pro`)

## Vulnerability Details

### Root Cause

This is a **regression** introduced in Craft CMS 5.6.0 when the `viewUsers` permission was added. Before that change, `editedUser()` required `editUsers` permission for accessing other users’ data, which implicitly protected `actionSavePermissions()`. After the change, `actionSavePermissions()` became reachable for users with read-only access to other users, but the underlying group-saving logic still lacked authorization for group removals.

The vulnerability has two components:

1. **`actionSavePermissions()` reachable with read-only access**: The action only requires a control panel request and delegates to `editedUser()`, which now only checks `viewUsers` — a permission explicitly documented as "read-only access to user elements."

2. **Asymmetric authorization in `_saveUserGroups()`**: The method checks `assignUserGroup` permission only when **adding** a user to a new group. When the `groups` parameter is an empty string (resulting in an empty array), the loop is skipped entirely, no authorization checks are run, and all group memberships are removed.

### Prerequisites

- Attacker has a control panel account with `accessCp` and `viewUsers` permissions only
- Target user belongs to one or more user groups that grant additional permissions
- Pro edition or higher

### Attack Steps

1. Attacker authenticates to the Control Panel
2. Attacker sends a POST request to `actions/users/save-permissions` with:
   - `userId` = target user's ID
   - `groups` = `` (empty string)
3. All group memberships for the target user are removed
4. All permissions inherited from those groups are immediately revoked

### Impact

- **Privilege revocation**: An attacker can strip group-based permissions from arbitrary users, including accounts whose effective access derives from group membership
- **Denial of access**: Users lose access to sections, volumes, and features that were granted through group membership
- **Bypass of elevated session requirement**: Group removal does not trigger `requireElevatedSession()` (which is only triggered when new groups are added)
GitHub Security Advisory: GHSA-7549-ggpq-22w8
Package: librenms/librenms (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 26.3.0
Patched in: 26.3.0

Summary: Duplicate Advisory: LibreNMS is Vulnerable to Remote Code Execution by Arbitrary File Write

Details:
## Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-pr3g-phhr-h8fh. This link is maintained to preserve external references.

## Original Description
LibreNMS versions before 26.3.0 are affected by an authenticated remote code execution vulnerability by abusing the Binary Locations config and the Netcommand feature. Successful exploitation requires administrative privileges. Exploitation could result in compromise of the underlying web server.
GitHub Security Advisory: GHSA-rp7w-624x-95qv
Package: librenms/librenms (COMPOSER)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 26.3.0
Patched in: 26.3.0

Summary: LibreNMS affected by an authenticated Cross-site Scripting vulnerability on the showconfig page

Details:
LibreNMS versions before 26.3.0 are affected by an authenticated Cross-site Scripting vulnerability on the showconfig page. Successful exploitation requires administrative privileges. Exploitation could result in XSS attacks being performed against other users with access to the page.
GitHub Security Advisory: GHSA-458g-q4fh-mj6r
Package: s9y/serendipity (COMPOSER)
Severity: HIGH (CVSS 7.2)
CWE: CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
Vulnerable versions: < 2.6.0
Patched in: 2.6.0

Summary: Serendipity has a Host Header Injection allows SMTP header injection via unvalidated HTTP_HOST in Message-ID email header

Details:
### Summary
Serendipity inserts `$_SERVER['HTTP_HOST']` directly into the `Message-ID` SMTP header without any validation beyond CRLF stripping. An attacker who can control the `Host` header during an email-triggering action can inject arbitrary SMTP headers into outgoing emails, enabling spam relay, BCC injection, and email spoofing.

### Details
In `include/functions.inc.php:548`:
```php
$maildata['headers'][] = 'Message-ID: <' 
    . bin2hex(random_bytes(16)) 
    . '@' . $_SERVER['HTTP_HOST']  // ← unsanitized, attacker-controlled
    . '>';
```

The existing sanitization function only blocks `\r\n` and URL-encoded variants:
```php
function serendipity_isResponseClean($d) {
    return (strpos($d, "\r") === false && strpos($d, "\n") === false 
        && stripos($d, "%0A") === false && stripos($d, "%0D") === false);
}
```

Critically, `serendipity_isResponseClean()` is **not even called** on `HTTP_HOST` before embedding it into the mail headers — making this exploitable with any character that SMTP interprets as a header delimiter.

Email is triggered by actions such as:
- New comment notifications to blog owner
- Comment subscription notifications to subscribers
- Password reset emails (if configured)

### PoC
```bash
# Trigger comment notification email with injected header
curl -s -X POST \
  -H "Host: attacker.com>\r\nBcc: victim@evil.com\r\nX-Injected:" \
  -d "serendipity[comment]=test&serendipity[name]=hacker&serendipity[email]=a@b.com&serendipity[entry_id]=1" \
  http://[TARGET]/comment.php
```
Resulting malicious `Message-ID` header in outgoing email:
```
Message-ID: <deadbeef@attacker.com>
Bcc: victim@evil.com
X-Injected: >
```

### Impact
An attacker can control the domain portion of the `Message-ID` header in all outgoing emails sent by Serendipity (comment notifications, subscriptions). 
This enables:
- **Identity spoofing** — emails appear to originate from attacker-controlled domain
- **Reply hijacking** — some mail clients use Message-ID for threading, pointing replies toward attacker infrastructure
- **Email reputation abuse** — attacker's domain embedded in legitimate mail headers
### Suggested Fix
Sanitize `HTTP_HOST` before embedding in mail headers, and restrict to valid hostname characters only:
```php
$safe_host = preg_replace('/[^a-zA-Z0-9.\-]/', '', 
    parse_url('http://' . $_SERVER['HTTP_HOST'], PHP_URL_HOST)
);
$maildata['headers'][] = 'Message-ID: ';
```
GitHub Security Advisory: GHSA-4m6c-649p-f6gf
Package: s9y/serendipity (COMPOSER)
Severity: MODERATE (CVSS 6.9)
CWE: CWE-565: Reliance on Cookies without Validation and Integrity Checking
Vulnerable versions: < 2.6.0
Patched in: 2.6.0

Summary: Serendipity has a Host Header Injection allows authentication cookie scoping to attacker-controlled domain in functions_config.inc.php

Details:
### Summary
The `serendipity_setCookie()` function uses `$_SERVER['HTTP_HOST']` without validation as the `domain` parameter of `setcookie()`. An attacker can force authentication cookies — including session tokens and auto-login tokens — to be scoped to an attacker-controlled domain, facilitating session hijacking.

### Details
In `include/functions_config.inc.php:726`:
```php
function serendipity_setCookie($name, $value, $securebyprot = true, ...) {
    $host = $_SERVER['HTTP_HOST']; // ← attacker-controlled, no validation

    if ($securebyprot) {
        if ($pos = strpos($host, ":")) {
            $host = substr($host, 0, $pos); // strips port only
        }
    }

    setcookie("serendipity[$name]", $value, [
        'domain'   => $host,   // ← poisoned domain
        'httponly' => $httpOnly,
        'samesite' => 'Strict'
    ]);
}
```

This function is called during login with sensitive cookies:
```php
// functions_config.inc.php:455-498
serendipity_setCookie('author_autologintoken', $rnd, true, false, true);
serendipity_setCookie('author_username', $user);
serendipity_setCookie('author_token', $hash);
```

If an attacker can influence the `Host` header at login time (e.g. via MITM, reverse proxy misconfiguration, or load balancer), authentication cookies are issued scoped to the attacker's domain instead of the legitimate one.

### PoC
```bash
curl -v -X POST \
  -H "Host: attacker.com" \
  -d "serendipity[user]=admin&serendipity[pass]=admin" \
  http://[TARGET]/serendipity_admin.php 2>&1 | grep -i "set-cookie"
```

Expected output:
```http
Set-Cookie: serendipity[author_token]=; domain=attacker.com; HttpOnly
```

### Impact
- **Session fixation** — attacker pre-sets a cookie scoped to their domain, then tricks the victim into authenticating, inheriting the poisoned token
- **Token leakage** — `author_autologintoken` scoped to wrong domain may be sent to attacker-controlled infrastructure
- **Privilege escalation** — if admin logs in under a poisoned Host header, their admin token is compromised

### Suggested Fix
Validate `HTTP_HOST` against the configured `$serendipity['url']` before use:
```php
function serendipity_setCookie($name, $value, ...) {
    global $serendipity;
    $configured = parse_url($serendipity['url'], PHP_URL_HOST);
    $host = preg_replace('/:[0-9]+$/', '', $_SERVER['HTTP_HOST']);
    $host = ($host === $configured) ? $host : $configured;

    setcookie("serendipity[$name]", $value, [
        'domain' => $host,
        ...
    ]);
}
```
GitHub Security Advisory: GHSA-gcqv-f29m-67gr
Package: october/rain (COMPOSER)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 3.7.13
Patched in: 3.7.14

Summary: October Rain has Stored XSS via SVG Filter Bypass

Details:
A stored cross-site scripting (XSS) vulnerability was identified in the SVG sanitization logic. The regex pattern used to strip `on*` event handler attributes could be bypassed using a crafted payload that exploits how the pattern matches attribute boundaries.

### Impact
- Stored XSS via malicious SVG files uploaded through the Media Manager
- Could allow privilege escalation if a superuser views or embeds the malicious SVG
- Requires authenticated backend access with media upload permissions (`media.library.create`)
- SVG must be viewed or embedded in a page to trigger

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Disable SVG uploads by adding `svg` to the blocked extensions in media configuration
- Set `media.clean_vectors` to `true` in configuration (enabled by default)

### References
- Reported by Pentest-Tools.com
GitHub Security Advisory: GHSA-gcqv-f29m-67gr
Package: october/rain (COMPOSER)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, <= 4.1.9
Patched in: 4.1.10

Summary: October Rain has Stored XSS via SVG Filter Bypass

Details:
A stored cross-site scripting (XSS) vulnerability was identified in the SVG sanitization logic. The regex pattern used to strip `on*` event handler attributes could be bypassed using a crafted payload that exploits how the pattern matches attribute boundaries.

### Impact
- Stored XSS via malicious SVG files uploaded through the Media Manager
- Could allow privilege escalation if a superuser views or embeds the malicious SVG
- Requires authenticated backend access with media upload permissions (`media.library.create`)
- SVG must be viewed or embedded in a page to trigger

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Disable SVG uploads by adding `svg` to the blocked extensions in media configuration
- Set `media.clean_vectors` to `true` in configuration (enabled by default)

### References
- Reported by Pentest-Tools.com
GitHub Security Advisory: GHSA-g6v3-wv4j-x9hg
Package: october/rain (COMPOSER)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 3.7.13
Patched in: 3.7.14

Summary: October Rain has Environment Variable Exfiltration via INI Parser Interpolation

Details:
A server-side information disclosure vulnerability was identified in the INI settings parser. PHP's `parse_ini_string()` function supports `${}` syntax for environment variable interpolation. Attackers with Editor access could inject `${APP_KEY}`, `${DB_PASSWORD}`, or similar patterns into CMS page settings fields, causing sensitive environment variables to be resolved and stored in the template. These values were then returned to the attacker when the page was reopened.

### Impact
- Exfiltration of sensitive environment variables (APP_KEY, DB credentials, AWS keys, etc.)
- Could enable further attacks: database access, cookie forgery, AWS resource access
- Requires authenticated backend access with Editor permissions
- Only relevant when `cms.safe_mode` is enabled (otherwise direct PHP injection is already possible)

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Restrict Editor tool access to fully trusted administrators only
- Ensure database and cloud service credentials are not accessible from the web server's network

### References
- Reported by Pentest-Tools.com
GitHub Security Advisory: GHSA-g6v3-wv4j-x9hg
Package: october/rain (COMPOSER)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 4.0.0, <= 4.1.9
Patched in: 4.1.10

Summary: October Rain has Environment Variable Exfiltration via INI Parser Interpolation

Details:
A server-side information disclosure vulnerability was identified in the INI settings parser. PHP's `parse_ini_string()` function supports `${}` syntax for environment variable interpolation. Attackers with Editor access could inject `${APP_KEY}`, `${DB_PASSWORD}`, or similar patterns into CMS page settings fields, causing sensitive environment variables to be resolved and stored in the template. These values were then returned to the attacker when the page was reopened.

### Impact
- Exfiltration of sensitive environment variables (APP_KEY, DB credentials, AWS keys, etc.)
- Could enable further attacks: database access, cookie forgery, AWS resource access
- Requires authenticated backend access with Editor permissions
- Only relevant when `cms.safe_mode` is enabled (otherwise direct PHP injection is already possible)

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Restrict Editor tool access to fully trusted administrators only
- Ensure database and cloud service credentials are not accessible from the web server's network

### References
- Reported by Pentest-Tools.com
GitHub Security Advisory: GHSA-wg36-wvj6-r67p
Package: composer/composer (COMPOSER)
Severity: HIGH (CVSS 7.8)
CWE: CWE-20: Improper Input Validation, CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: >= 2.3.0, < 2.9.6
Patched in: 2.9.6

Summary: Composer has a command injection via malicious perforce repository

Details:
### Impact
The `Perforce::generateP4Command()` method constructed shell commands by interpolating user-supplied Perforce connection parameters (port, user, client) without proper escaping. An attacker controlling a repository configuration in a malicious composer.json declaring a Perforce VCS repository could inject arbitrary commands through these values, leading to command execution in the context of the user running Composer. Composer would execute these injected commands even if Perforce is not installed.

VCS repositories are only loaded from the root composer.json file located in the directory you execute Composer commands in and from the composer config directory (e.g. `~/.config/composer/composer.json`). So this vulnerability cannot be exploited through composer.json files of packages installed as dependencies.

You are at risk of command execution if you run Composer commands on untrusted projects with attacker supplied composer.json files, regardless of whether you or any of your dependencies use Perforce.

### Patches
Fixed in Composer 2.2.27 (2.2 LTS) and 2.9.6 (mainline)

### Workarounds
- Carefully inspect composer.json files before running Composer on them. Verify that Perforce-related fields contain valid values.
- Only run Composer commands on projects from trusted sources.
GitHub Security Advisory: GHSA-j4j5-9x6g-rgxc
Package: october/system (COMPOSER)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 3.7.13
Patched in: 3.7.14

Summary: October CMS has Stored XSS in Event Log Mail Preview

Details:
A stored cross-site scripting (XSS) vulnerability was identified in the Event Log mail preview feature. When viewing logged mail messages, HTML content was rendered in an iframe without proper sandboxing, allowing JavaScript execution in the viewer's browser context.

### Impact
- Stored XSS via mail template content rendered in Event Log
- Could allow privilege escalation if a superuser views a malicious log entry
- Requires authenticated backend access with mail template editing permissions
- Requires a superuser to view the specific Event Log entry to trigger

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Restrict mail template editing permissions to fully trusted administrators only
- Restrict Event Log viewing permissions to minimize exposure

### References
- Reported by [Chris Alupului](https://github.com/neosprings)