deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-f7xc-5852-fj99
Package: saloonphp/saloon (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-125: Out-of-bounds Read, CWE-787: Out-of-bounds Write
Vulnerable versions: < 4.0.0
Patched in: 4.0.0

Summary: Saloon has a Fixture Name Path Traversal Vulnerability

Details:
### Impact
Users with MockResponse fixtures that use path traversal.

### Patches
Upgrade to Saloon v4+

Upgrade guide: https://docs.saloon.dev/upgrade/upgrading-from-v3-to-v4

### Description
Fixture names were used to build file paths under the configured fixture directory without validation. A name containing path segments (e.g. ../traversal or ../../etc/passwd) resulted in a path outside that directory. When the application read a fixture (e.g. for mocking) or wrote one (e.g. when recording responses), it could read or write files anywhere the process had access. If the fixture name was derived from user or attacker-controlled input (e.g. request parameters or config), this constituted a path traversal vulnerability and could lead to disclosure of sensitive files or overwriting of critical files. The fix adds validation in the fixture layer (rejecting names with /, \, .., or null bytes, and restricting to a safe character set) and defence-in-depth in the storage layer (ensuring the resolved path remains under the base directory before any read or write).

### Credits
Saloon thanks @HuajiHD for finding the issue and recommending solutions and @JonPurvis for applying the fix.
GitHub Security Advisory: GHSA-c83f-3xp6-hfcp
Package: saloonphp/saloon (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-522: Insufficiently Protected Credentials, CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 4.0.0
Patched in: 4.0.0

Summary: Saloon is vulnerable to SSRF and credential leakage via absolute URL in endpoint overriding base URL

Details:
### Impact
Users providing user generated input into the `resolveEndpoint` method on requests.

### Patches
Upgrade to Saloon v4+

Upgrade guide: https://docs.saloon.dev/upgrade/upgrading-from-v3-to-v4

### Description
When building the request URL, Saloon combined the connector's base URL with the request endpoint. If the endpoint was a valid absolute URL (e.g. https://attacker.example.com/callback), the code used that URL as-is and ignored the base URL. The request—and any authentication headers, cookies, or tokens attached by the connector—was then sent to the attacker-controlled host. If the endpoint could be influenced by user input or configuration (e.g. redirect_uri, callback URL), this allowed server-side request forgery (SSRF) and/or credential leakage to a third-party host. The fix (in the next major version) is to reject absolute URLs in the endpoint: URLHelper::join() throws InvalidArgumentException when the endpoint is a valid absolute URL, unless explicitly allowed, requiring callers to opt-in to the functionality on a per-connector or per-request basis.

### Credits
Saloon thanks @HuajiHD for finding the issue and recommending solutions and @JonPurvis for applying the fix.
GitHub Security Advisory: GHSA-p2gh-cfq4-4wjc
Package: google/protobuf (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 4.33.6
Patched in: 4.33.6

Summary: Protobuf: Denial of Service issue through malicious messages containing negative varints or deep recursion

Details:
### Impact
A Denial of Service (DoS) vulnerability exists in the Protobuf PHP library during the parsing of untrusted input. Maliciously structured messages—specifically those containing negative `varint`s or deep recursion—can be used to crash the application, impacting service availability.

### Patches
Patches have been released to 5.34.0-RC1 and 4.33.6.
GitHub Security Advisory: GHSA-cpv7-q2wx-m8rw
Package: statamic/cms (COMPOSER)
Severity: HIGH (CVSS 8.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 6.0.0-alpha.1, < 6.7.2
Patched in: 6.7.2

Summary: Statamic vulnerable to remote code execution via Antlers-enabled control panel inputs

Details:
### Impact
An authenticated control panel user with access to Antlers-enabled inputs may be able to achieve remote code execution in the application context. That can lead to full compromise of the application, including access to sensitive configuration, modification or exfiltration of data, and potential impact on availability.

Exploitation is only possible where Antlers runs on user-controlled content—for example, content fields with Antlers explicitly enabled (requiring permission to configure fields and to edit entries), built-in config that supports Antlers such as Forms email notification settings (requiring configuration permission), or third-party addons that add Antlers-enabled fields to entries (for example, the SEO Pro addon). In each case the attacker must have the relevant control panel permissions.

### Patches
This has been fixed in 5.73.16 and 6.7.2.

Note that a follow-up report showed that the original 5.73.11 & 6.4.0 fixes were insufficient.

If you use addons that depend on Statamic, ensure that after updating you are running a patched Statamic version.
GitHub Security Advisory: GHSA-cpv7-q2wx-m8rw
Package: statamic/cms (COMPOSER)
Severity: HIGH (CVSS 8.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 5.73.16
Patched in: 5.73.16

Summary: Statamic vulnerable to remote code execution via Antlers-enabled control panel inputs

Details:
### Impact
An authenticated control panel user with access to Antlers-enabled inputs may be able to achieve remote code execution in the application context. That can lead to full compromise of the application, including access to sensitive configuration, modification or exfiltration of data, and potential impact on availability.

Exploitation is only possible where Antlers runs on user-controlled content—for example, content fields with Antlers explicitly enabled (requiring permission to configure fields and to edit entries), built-in config that supports Antlers such as Forms email notification settings (requiring configuration permission), or third-party addons that add Antlers-enabled fields to entries (for example, the SEO Pro addon). In each case the attacker must have the relevant control panel permissions.

### Patches
This has been fixed in 5.73.16 and 6.7.2.

Note that a follow-up report showed that the original 5.73.11 & 6.4.0 fixes were insufficient.

If you use addons that depend on Statamic, ensure that after updating you are running a patched Statamic version.
GitHub Security Advisory: GHSA-73vx-49mv-v8w5
Package: mantisbt/mantisbt (COMPOSER)
Severity: HIGH (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: = 2.28.0
Patched in: 2.28.2

Summary: MantisBT has Stored HTML Injection/XSS when displaying Tags in Timeline

Details:
Improper escaping of tag names retrieved from History in Timeline (my_view_page.php) allows an attacker to inject HTML and, if CSP settings permit, achieve execution of arbitrary JavaScript, when displaying a tag that has been renamed or deleted.

### Impact
Cross-site scripting (XSS).

### Patches
f32787c14d4518476fe7f05f992dbfe6eaccd815

### Workarounds
* Edit offending History entries (using SQL)
* Wrap `$this->tag_name` in a string_html_specialchars() call in IssueTagTimelineEvent::html()

### Credits
MantisBT thanks Vishal Shukla for discovering and responsibly reporting the issue.
GitHub Security Advisory: GHSA-9ffq-6457-8958
Package: code16/sharp (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 9.20.0
Patched in: 9.20.0

Summary: Sharp is Vulnerable to Path Traversal via Unsanitized Extension in FileUtil

Details:
### Summary
A path traversal vulnerability exists in the FileUtil class of the code16/sharp package. The application fails to sanitize file extensions properly, allowing path separators to be passed into the storage layer.

### Detail
In `src/Utils/FileUtil.php`, the `FileUtil::explodeExtension()` function extracts a file's extension by splitting the filename at the last dot. However, the extracted extension is never sanitized. While the application uses a `normalizeName()` function, this function only cleans the base filename, meaning any path separators (such as /) injected into the extension will survive and be passed into the `storeAs()` function.

### Impact
Exploiting this flaw allows an authenticated attacker to manipulate file paths:
- Files can be written outside of the intended tmp directory via path traversal. For more details on the package, visit: https://github.com/code16/sharp
- Existing critical files (such as .env or configuration files) could potentially be overwritten. Review the CWE definition here: https://cwe.mitre.org/data/definitions/22.html (Note: This vulnerability was successfully chained with CWE-434 in a local Proof of Concept to confirm the traversal.)

### Patches
This issue has been patched by properly sanitizing the extension using `pathinfo(PATHINFO_EXTENSION)` instead of `strrpos()`, alongside applying strict regex replacements to both the base name and the extension. The fix is available in pull request #715

### Credits
Reported by [zaurgsynv](https://github.com/zaurgsynv).
GitHub Security Advisory: GHSA-fr76-5637-w3g9
Package: code16/sharp (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: < 9.20.0
Patched in: 9.20.0

Summary: Sharp has Unrestricted File Upload via Client-Controlled Validation Rules

Details:
### Summary 
The `code16/sharp` Laravel admin panel package contains a vulnerability in its file upload endpoint that allows authenticated users to bypass all file type restrictions.

### Details
The upload endpoint within the `ApiFormUploadController` accepts a client-controlled `validation_rule` parameter. This parameter is directly passed into the Laravel validator without sufficient server-side enforcement. By intercepting the request and sending `validation_rule[]=file`, an attacker can completely bypass all MIME type and file extension restrictions. The vulnerable code is located in `src/Http/Controllers/Api/ApiFormUploadController.php` at line 24.

### Impact
This vulnerability leads to several critical security risks:

Attackers can upload arbitrary files, including PHP webshells, to the server. For more details on the package, visit: https://github.com/code16/sharp

MIME type and extension validation can be bypassed entirely via client-controlled rules. Review the CWE definition here: https://cwe.mitre.org/data/definitions/434.html

If the storage disk is configured to be publicly accessible, this can lead to Remote Code Execution (RCE). See the vendor repository: https://github.com/code16/sharp

(Note: Under default configurations, executing uploaded PHP files directly is not possible unless a public disk configuration is in place.)

### Patches
This issue has been addressed by removing the client-controlled validation rules and strictly defining upload rules server-side. The fix is available in pull request https://github.com/code16/sharp/pull/714.

### Workarounds
- Restrict Disk Access: Ensure that the storage disk used for Sharp uploads is strictly private. Under default configurations, an attacker cannot directly execute uploaded PHP files unless a public disk configuration is explicitly used. For more details on Laravel disk configurations, visit: https://laravel.com/docs/13.x/filesystem

### Credits
Reported by [zaurgsynv](https://github.com/zaurgsynv).
GitHub Security Advisory: GHSA-m59h-42jf-cphr
Package: putyourlightson/craft-sprig (COMPOSER)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-489: Active Debug Code
Vulnerable versions: >= 3.0.0, < 3.7.2
Patched in: 3.7.2

Summary: Sprig Plugin for Craft CMS potentially discloses sensitive information via Sprig Playground

Details:
Admin users, and users with explicit permission to access the Sprig Playground, could potentially expose the security key, credentials, and other sensitive configuration data, in addition to running the `hashData()` signing function.

This issue was mitigated in versions 3.7.2 and 2.15.2 by disabling access to the Sprig Playground entirely when `devMode` is disabled, by default. It is possible to override this behaviour using a new `enablePlaygroundWhenDevModeDisabled` that defaults to `false`.

References:

- https://github.com/putyourlightson/craft-sprig/commit/db18c46f6dc5603828aa321a3a615adbd677d475
- https://github.com/putyourlightson/craft-sprig/commit/09c9da2ffb45a8857829f3390ae2578e26cfe03b
GitHub Security Advisory: GHSA-fh48-f69w-7vmp
Package: mantisbt/mantisbt (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: = 2.28.0
Patched in: 2.28.1

Summary: MantisBT Vulnerable to Stored HTML Injection in Tag Delete Confirmation

Details:
Improper escaping of Tag name when deleting it in tag_delete.php allows an attacker to inject HTML and, if CSP settings permit, achieve execution of arbitrary JavaScript.

### Impact
Cross-site scripting (XSS).

### Patches
80990f43153167c73f11eb4b2bc7108d0c3d6b46

### Workarounds
* Revert commit d[PII_REDACTED]ecf37bd74d11fe14fe7dc12335be9
* Manually edit language files to remove the sprintf placeholder `%1$s` from *$s_tag_delete_message*  string, for example with `sed -r -i '/tag_delete_message/s/.%1\$s.//' -- lang/`

### Credits
MantisBT hanks Vishal Shukla for discovering and responsibly reporting the issue.
GitHub Security Advisory: GHSA-8p2x-5cpm-qrqw
Package: wwbn/avideo (COMPOSER)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-348: Use of Less Trusted Source
Vulnerable versions: <= 26.0
Patched in: unpatched

Summary: AVideo vulnerable to IP Address Spoofing via Untrusted HTTP Headers in getRealIpAddr()

Details:
## Summary

The `getRealIpAddr()` function in `objects/functions.php` trusts user-controlled HTTP headers to determine the client's IP address. 
An attacker can spoof their IP address by sending forged headers, bypassing any IP-based access controls or audit logging.

## Vulnerable Code

File: `objects/functions.php`
```php
$headers = [
    'HTTP_X_REAL_IP',      
    'HTTP_CLIENT_IP',    
    'HTTP_X_FORWARDED_FOR',
    'REMOTE_ADDR'
];

foreach ($headers as $header) {
    if (!empty($_SERVER[$header])) {
        $ips = explode(',', $_SERVER[$header]);
        foreach ($ips as $ipCandidate) {
            $ipCandidate = trim($ipCandidate);
            if (filter_var($ipCandidate, FILTER_VALIDATE_IP, 
                           FILTER_FLAG_IPV4)) {
                return $ipCandidate; 
            }
        }
    }
}
```

## Attack Scenario

1. Attacker sends request with forged header:
```
X-Client-IP: 127.0.0.1
```
or
```
X-Real-IP: 192.168.1.1
```

2. `getRealIpAddr()` returns the forged IP
3. Any IP-based rate limiting, access control, or audit 
   log that relies on this function is bypassed

## Proof of Concept
```bash
curl -H "X-Client-IP: 127.0.0.1" \
     https://target.com/any_endpoint.php
```

The server now believes the request came from localhost.

## Impact
- Bypass IP-based rate limiting
- Bypass IP-based access controls
- Forge audit log entries
- Potential privilege escalation if localhost is trusted
GitHub Security Advisory: GHSA-29r8-gvx4-r9w3
Package: ralffreit/mfa-email (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: = 2.0.0
Patched in: 2.0.1

Summary: Authentication Bypass in extension "E-Mail MFA Provider" (mfa_email)

Details:
The extension fails to properly reset the generated MFA code after successful authentication. This leads to a possible MFA bypass for future login attempts by providing an empty string as MFA code to the extensions MFA provider.
GitHub Security Advisory: GHSA-29r8-gvx4-r9w3
Package: ralffreit/mfa-email (COMPOSER)
Severity: HIGH (CVSS 8.8)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 1.0.7
Patched in: 1.0.7

Summary: Authentication Bypass in extension "E-Mail MFA Provider" (mfa_email)

Details:
The extension fails to properly reset the generated MFA code after successful authentication. This leads to a possible MFA bypass for future login attempts by providing an empty string as MFA code to the extensions MFA provider.
GitHub Security Advisory: GHSA-35pf-37c6-jxjv
Package: prestashop/prestashop (COMPOSER)
Severity: HIGH (CVSS 7.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 8.2.5
Patched in: 8.2.5

Summary: PrestaShop has multiple stored XSS vulnerabilities via unprotected Template variables

Details:
### Impact
Multiple stored Cross-Site Scripting (stored XSS) vulnerabilities in the BO: an attacker who can inject data into the database, via limited back-office access or a previously existing vulnerability, can exploit unprotected variables in back-office templates.

### Patches
Patched on 8.2.5 and 9.1.0

### Workarounds
None

### References
None
GitHub Security Advisory: GHSA-35pf-37c6-jxjv
Package: prestashop/prestashop (COMPOSER)
Severity: HIGH (CVSS 7.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 9.0.0-alpha.1, < 9.1.0
Patched in: 9.1.0

Summary: PrestaShop has multiple stored XSS vulnerabilities via unprotected Template variables

Details:
### Impact
Multiple stored Cross-Site Scripting (stored XSS) vulnerabilities in the BO: an attacker who can inject data into the database, via limited back-office access or a previously existing vulnerability, can exploit unprotected variables in back-office templates.

### Patches
Patched on 8.2.5 and 9.1.0

### Workarounds
None

### References
None
GitHub Security Advisory: GHSA-283w-xf3q-788v
Package: prestashop/prestashop (COMPOSER)
Severity: LOW (CVSS 2.0)
CWE: CWE-1173: Improper Use of Validation Framework
Vulnerable versions: >= 9.0.0-alpha.1, < 9.1.0
Patched in: 9.1.0

Summary: PrestaShop: Improper Use of Validation Framework

Details:
### Impact
Fix improper use of validation framework

### Patches
Patched in 8.2.5 and 9.1.0

### Workarounds
None

### References
none
GitHub Security Advisory: GHSA-283w-xf3q-788v
Package: prestashop/prestashop (COMPOSER)
Severity: LOW (CVSS 2.0)
CWE: CWE-1173: Improper Use of Validation Framework
Vulnerable versions: < 8.2.5
Patched in: 8.2.5

Summary: PrestaShop: Improper Use of Validation Framework

Details:
### Impact
Fix improper use of validation framework

### Patches
Patched in 8.2.5 and 9.1.0

### Workarounds
None

### References
none
GitHub Security Advisory: GHSA-q938-ghwv-8gvc
Package: yansongda/pay (COMPOSER)
Severity: HIGH (CVSS 8.6)
CWE: CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: <= 3.7.19
Patched in: 3.7.20

Summary: WeChat Pay callback signature verification bypassed when Host header is localhost

Details:
## Summary

The `verify_wechat_sign()` function in `src/Functions.php` unconditionally **skips all signature verification** when the PSR-7 request reports `localhost` as the host. An attacker can exploit this by sending a crafted HTTP request to the WeChat Pay callback endpoint with a `Host: localhost` header, bypassing the RSA signature check entirely.

This allows forging fake WeChat Pay payment success notifications, potentially causing applications to mark orders as paid without actual payment.

## Vulnerable Code

**`src/Functions.php` lines 243-246:**
```php
function verify_wechat_sign(ResponseInterface|ServerRequestInterface $message, array $params): void
{
    // BYPASS: Returns without any signature check if Host header is localhost
    if ($message instanceof ServerRequestInterface && 'localhost' === $message->getUri()->getHost()) {
        return;  // No signature verified!
    }

    // ... openssl_verify() only reached when Host != localhost
    $wechatSerial = $message->getHeaderLine('Wechatpay-Serial');
    $sign = $message->getHeaderLine('Wechatpay-Signature');
    $result = 1 === openssl_verify($content, base64_decode($sign), $public, 'sha256WithRSAEncryption');
}
```

In PSR-7 implementations (Nyholm, Guzzle PSR-7, etc.), `$request->getUri()->getHost()` reads the `Host` HTTP header, which is fully attacker-controlled.

## Proof of Concept

```bash
curl -X POST https://merchant.example.com/payment/wechat/callback \
  -H "Host: localhost" \
  -H "Content-Type: application/json" \
  -H "Wechatpay-Serial: any" \
  -H "Wechatpay-Timestamp:[PII_REDACTED]" \
  -H "Wechatpay-Nonce: abc" \
  -H "Wechatpay-Signature: AAAA" \
  -d '{"id":"fake-order","event_type":"TRANSACTION.SUCCESS"}'
```

`verify_wechat_sign()` returns immediately without verifying the signature. The application marks the order as paid.

## Impact

- **Payment fraud**: Attacker receives goods/services without actual payment by forging WeChat Pay callbacks
- **No authentication required**: Pure network attack, zero privileges needed
- **Wide reach**: Affects any application using `yansongda/pay` for WeChat Pay callback validation. However, in most environments, Nginx/Ingress/Cloudflare/WAF will directly reject the forgery of this request header, so there is no need to worry too much.
GitHub Security Advisory: GHSA-98wm-cxpw-847p
Package: invoiceninja/invoiceninja (COMPOSER)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-116: Improper Encoding or Escaping of Output, CWE-184: Incomplete List of Disallowed Inputs
Vulnerable versions: < 5.13.4
Patched in: 5.13.4

Summary: Invoice Ninja Denylist Bypass may Lead to Stored XSS via Invoice Line Items

Details:
## Vulnerability Details

Invoice line item descriptions in Invoice Ninja v5.13.0 bypass the XSS denylist filter, allowing stored XSS payloads to execute when invoices are rendered in the PDF preview or client portal.

The line item description field was not passed through `purify::clean()` before rendering.

## Steps to Reproduce

1. Login as any authenticated user
2. Create or edit an invoice
3. In a line item description, enter: `<img src=x onerror=alert(document.cookie)>`
4. Save the invoice and preview it
5. The XSS payload executes in the browser

## Impact

- **Attacker**: Any authenticated user who can create invoices
- **Victim**: Any user viewing the invoice (including clients via the portal)
- **Specific damage**: Session hijacking, account takeover, data exfiltration

## Proposed Fix

Fixed in v5.13.4 by the vendor by adding `purify::clean()` to sanitize line item descriptions.