deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-hqrp-m84v-2m2f
Package: pimcore/admin-ui-classic-bundle (COMPOSER)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-284: Improper Access Control
Vulnerable versions: <= 1.7.15
Patched in: 1.7.16

Summary: Pimcore's Admin Classic Bundle is Missing Function Level Authorization on "Predefined Properties" Listing

Details:
### Summary
The API endpoint for listing Predefined Properties in the Pimcore platform lacks adequate server-side authorization checks. Predefined Properties are configurable metadata definitions (e.g., name, key, type, default value) used across documents, assets, and objects to standardize custom attributes and improve editorial workflows, as documented in Pimcore's official properties guide. Testing confirmed that an authenticated backend user without explicit permissions for property management could successfully call the endpoint and retrieve the complete list of these configurations. This exemplifies Broken Access Control (OWASP Top 10 A01:2021), enabling unauthorized access to administrative features and potentially violating role-based access controls inherent to Pimcore's multi-user environment.

### Details
The backend user without permission was still able to list "Predefined Properties" item

### Step to Reproduce the issue 
login as Admin (full permission) and clicked "Predefined Properties"
<img width="1493" height="862" alt="Screenshot 2025-12-10 at 10 11 31 PM" src="https://github.com/user-attachments/assets/005d2704-347c-4aa1-b415-d52ab3794c99" />

Then, captured and saved the request:
- List API
<img width="922" height="797" alt="Screenshot 2025-12-10 at 10 39 53 PM" src="https://github.com/user-attachments/assets/2ee3e0e1-06da-442f-b2c7-0dfa8360c04a" />


Next, login a backend user with no permission
<img width="1219" height="744" alt="Screenshot 2025-12-10 at 9 06 12 PM" src="https://github.com/user-attachments/assets/1dada4c4-d907-4477-9773-70dea3ef5816" />

The copy the "Cookie" and "X-Pimcore-Csrf-Token"
<img width="1902" height="971" alt="Screenshot 2025-12-10 at 9 10 47 PM" src="https://github.com/user-attachments/assets/63221682-fa14-429b-8665-fc9dd8bed890" />

After that, pasted the copied "Cookie" and "X-Pimcore-Csrf-Token" to captured request

-List API
![Uploading Screenshot 2025-12-10 at 10.55.23 PM.png…]()


### Impact
Exploitation allows low-privileged users to enumerate all Predefined Properties, exposing internal metadata schemas, default values, and configuration details that may reveal business logic, data classification strategies, or sensitive defaults (e.g., proprietary keys or select options). In a PIM system like Pimcore, this could facilitate reconnaissance for further attacks, such as targeted data manipulation or privilege escalation, leading to unauthorized alterations of asset/object properties. For organizations handling regulated content (e.g., e-commerce catalogs under GDPR or PCI DSS), such exposure risks compliance breaches, intellectual property leakage, and operational inconsistencies from unintended property overrides.
GitHub Security Advisory: GHSA-hqrp-m84v-2m2f
Package: pimcore/admin-ui-classic-bundle (COMPOSER)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-284: Improper Access Control
Vulnerable versions: >= 2.0.0-RC1, <= 2.2.2
Patched in: 2.2.3

Summary: Pimcore's Admin Classic Bundle is Missing Function Level Authorization on "Predefined Properties" Listing

Details:
### Summary
The API endpoint for listing Predefined Properties in the Pimcore platform lacks adequate server-side authorization checks. Predefined Properties are configurable metadata definitions (e.g., name, key, type, default value) used across documents, assets, and objects to standardize custom attributes and improve editorial workflows, as documented in Pimcore's official properties guide. Testing confirmed that an authenticated backend user without explicit permissions for property management could successfully call the endpoint and retrieve the complete list of these configurations. This exemplifies Broken Access Control (OWASP Top 10 A01:2021), enabling unauthorized access to administrative features and potentially violating role-based access controls inherent to Pimcore's multi-user environment.

### Details
The backend user without permission was still able to list "Predefined Properties" item

### Step to Reproduce the issue 
login as Admin (full permission) and clicked "Predefined Properties"
<img width="1493" height="862" alt="Screenshot 2025-12-10 at 10 11 31 PM" src="https://github.com/user-attachments/assets/005d2704-347c-4aa1-b415-d52ab3794c99" />

Then, captured and saved the request:
- List API
<img width="922" height="797" alt="Screenshot 2025-12-10 at 10 39 53 PM" src="https://github.com/user-attachments/assets/2ee3e0e1-06da-442f-b2c7-0dfa8360c04a" />


Next, login a backend user with no permission
<img width="1219" height="744" alt="Screenshot 2025-12-10 at 9 06 12 PM" src="https://github.com/user-attachments/assets/1dada4c4-d907-4477-9773-70dea3ef5816" />

The copy the "Cookie" and "X-Pimcore-Csrf-Token"
<img width="1902" height="971" alt="Screenshot 2025-12-10 at 9 10 47 PM" src="https://github.com/user-attachments/assets/63221682-fa14-429b-8665-fc9dd8bed890" />

After that, pasted the copied "Cookie" and "X-Pimcore-Csrf-Token" to captured request

-List API
![Uploading Screenshot 2025-12-10 at 10.55.23 PM.png…]()


### Impact
Exploitation allows low-privileged users to enumerate all Predefined Properties, exposing internal metadata schemas, default values, and configuration details that may reveal business logic, data classification strategies, or sensitive defaults (e.g., proprietary keys or select options). In a PIM system like Pimcore, this could facilitate reconnaissance for further attacks, such as targeted data manipulation or privilege escalation, leading to unauthorized alterations of asset/object properties. For organizations handling regulated content (e.g., e-commerce catalogs under GDPR or PCI DSS), such exposure risks compliance breaches, intellectual property leakage, and operational inconsistencies from unintended property overrides.
GitHub Security Advisory: GHSA-q433-j342-rp9h
Package: pimcore/pimcore (COMPOSER)
Severity: HIGH (CVSS 8.6)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: <= 11.5.13
Patched in: 11.5.14

Summary: Pimcore ENV Variables and Cookie Informations are exposed in http_error_log

Details:
### Summary
The http_error_log file stores the $_COOKIE and $_SERVER variables, which means sensitive information such as database passwords, cookie session data, and other details can be accessed or recovered through the Pimcore backend.

### Details
It’s better to remove both lines, as this information makes little sense in this context anyway.

https://github.com/pimcore/pimcore/blob/12.x/bundles/SeoBundle/src/EventListener/ResponseExceptionListener.php#L92
https://github.com/pimcore/pimcore/blob/12.x/bundles/SeoBundle/src/EventListener/ResponseExceptionListener.php#L93

### PoC
In the Pimcore backend, navigate to "Search Engine Optimization" and click on "HTTP Errors." Double-click on an entry to view its details. Here, you may find sensitive data exposed.

### Impact
Pimcore backend users can access sensitive environment variables, potentially exposing critical information.
GitHub Security Advisory: GHSA-q433-j342-rp9h
Package: pimcore/pimcore (COMPOSER)
Severity: HIGH (CVSS 8.6)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 12.0.0-RC1, <= 12.3
Patched in: 12.3.1

Summary: Pimcore ENV Variables and Cookie Informations are exposed in http_error_log

Details:
### Summary
The http_error_log file stores the $_COOKIE and $_SERVER variables, which means sensitive information such as database passwords, cookie session data, and other details can be accessed or recovered through the Pimcore backend.

### Details
It’s better to remove both lines, as this information makes little sense in this context anyway.

https://github.com/pimcore/pimcore/blob/12.x/bundles/SeoBundle/src/EventListener/ResponseExceptionListener.php#L92
https://github.com/pimcore/pimcore/blob/12.x/bundles/SeoBundle/src/EventListener/ResponseExceptionListener.php#L93

### PoC
In the Pimcore backend, navigate to "Search Engine Optimization" and click on "HTTP Errors." Double-click on an entry to view its details. Here, you may find sensitive data exposed.

### Impact
Pimcore backend users can access sensitive environment variables, potentially exposing critical information.
GitHub Security Advisory: GHSA-595p-g7xc-c333
Package: algolia/algoliasearch-magento-2 (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: <= 3.16.1
Patched in: 3.16.2

Summary: Algolia Search & Discovery for Magento 2 Has Untrusted Data Handling

Details:
### Impact

Versions of the Algolia Search & Discovery extension for Magento 2 prior to **3.17.2** and **3.16.2** contain a vulnerability where data read from the database was treated as a trusted source during job execution.

If an attacker is able to modify records used by the extension’s indexing queue, this could result in **arbitrary PHP code execution** when the affected job is processed.

Exploitation requires the ability to write malicious data to the Magento database and for the indexing queue to be enabled.

---

### Patches

This vulnerability has been fixed in the following versions:

- **3.17.2**
- **3.16.2**

Merchants should upgrade to a supported patched version immediately.

Versions outside the supported maintenance window do **not** receive security updates and remain vulnerable.

---

### Workarounds

Upgrading to a patched version is the only recommended remediation.

If an immediate upgrade is not possible, the following temporary risk mitigations may reduce exposure:

- Disable the Algolia indexing queue to prevent queued jobs from being executed.
- Restrict job execution logic to an explicit allowlist of permitted operations.
- Review the contents of the `algoliasearch_queue` table for unexpected or unrecognized entries.
- If queue archiving is enabled, review historical records in `algoliasearch_queue_archive`.

These mitigations are provided as guidance only and do not replace upgrading to a patched version.

---

### References

- Algolia Search & Discovery for Magento 2 releases:
  - [3.16.2](https://github.com/algolia/algoliasearch-magento-2/releases/tag/3.16.2)
  - [3.17.2](https://github.com/algolia/algoliasearch-magento-2/releases/tag/3.17.2)
GitHub Security Advisory: GHSA-595p-g7xc-c333
Package: algolia/algoliasearch-magento-2 (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: >= 3.17.0-beta.1, <= 3.17.1
Patched in: 3.17.2

Summary: Algolia Search & Discovery for Magento 2 Has Untrusted Data Handling

Details:
### Impact

Versions of the Algolia Search & Discovery extension for Magento 2 prior to **3.17.2** and **3.16.2** contain a vulnerability where data read from the database was treated as a trusted source during job execution.

If an attacker is able to modify records used by the extension’s indexing queue, this could result in **arbitrary PHP code execution** when the affected job is processed.

Exploitation requires the ability to write malicious data to the Magento database and for the indexing queue to be enabled.

---

### Patches

This vulnerability has been fixed in the following versions:

- **3.17.2**
- **3.16.2**

Merchants should upgrade to a supported patched version immediately.

Versions outside the supported maintenance window do **not** receive security updates and remain vulnerable.

---

### Workarounds

Upgrading to a patched version is the only recommended remediation.

If an immediate upgrade is not possible, the following temporary risk mitigations may reduce exposure:

- Disable the Algolia indexing queue to prevent queued jobs from being executed.
- Restrict job execution logic to an explicit allowlist of permitted operations.
- Review the contents of the `algoliasearch_queue` table for unexpected or unrecognized entries.
- If queue archiving is enabled, review historical records in `algoliasearch_queue_archive`.

These mitigations are provided as guidance only and do not replace upgrading to a patched version.

---

### References

- Algolia Search & Discovery for Magento 2 releases:
  - [3.16.2](https://github.com/algolia/algoliasearch-magento-2/releases/tag/3.16.2)
  - [3.17.2](https://github.com/algolia/algoliasearch-magento-2/releases/tag/3.17.2)
GitHub Security Advisory: GHSA-7cw6-7h3h-v8pf
Package: shopware/core (COMPOSER)
Severity: HIGH (CVSS 7.2)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 6.7.0.0, < 6.7.6.1
Patched in: 6.7.6.1

Summary: Shopware Has Improper Control of Generation of Code in Twig rendered views

Details:
### Impact
We fixed with [CVE-2023-2017](https://github.com/advisories/GHSA-7v2v-9rm4-7m8f) Twig filters to only be executed with allowed functions. However there was a regression that lead to an array and array crafted PHP Closure not checked being against allow list for the map(...) override

### Patches
Patched in 6.7.6.1

### Workarounds
Install the security plugin
GitHub Security Advisory: GHSA-7cw6-7h3h-v8pf
Package: shopware/shopware (COMPOSER)
Severity: HIGH (CVSS 7.2)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 6.7.0.0, < 6.7.6.1
Patched in: 6.7.6.1

Summary: Shopware Has Improper Control of Generation of Code in Twig rendered views

Details:
### Impact
We fixed with [CVE-2023-2017](https://github.com/advisories/GHSA-7v2v-9rm4-7m8f) Twig filters to only be executed with allowed functions. However there was a regression that lead to an array and array crafted PHP Closure not checked being against allow list for the map(...) override

### Patches
Patched in 6.7.6.1

### Workarounds
Install the security plugin
GitHub Security Advisory: GHSA-r7vr-wg3f-8hr9
Package: concrete5/concrete5 (COMPOSER)
Severity: MODERATE (CVSS 9.8)
CWE: CWE-643: Improper Neutralization of Data within XPath Expressions ('XPath Injection')
Vulnerable versions: = 9.1.3
Patched in: unpatched

Summary: Concrete5 CMS contains an XPath injection vulnerability

Details:
Concrete5 CMS version 9.1.3 contains an XPath injection vulnerability that allows attackers to manipulate URL path parameters with malicious payloads. Attackers can flood the system with crafted requests to potentially extract internal content paths and system information.
GitHub Security Advisory: GHSA-7vp9-x248-9vr9
Package: typo3/cms-core (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 10.0.0, <= 10.4.54
Patched in: 10.4.55

Summary: TYPO3 CMS Allows Insecure Deserialization via Mailer File Spool

Details:
### Problem
Local platform users who can write to TYPO3’s mail‑file spool directory can craft a file that the system will automatically deserialize without any class restrictions. This flaw allows an attacker to inject and execute arbitrary PHP code in the public scope of the web server.

The vulnerability is triggered when TYPO3 is configured with `$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_spool_type'] = 'file';` and a scheduler task or cron job runs the command `mailer:spool:send`. The spool‑send operation performs the insecure deserialization that is at the core of this issue.

### Solution
Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.

### Credits
Thanks to Vitaly Simonovich for reporting this issue, and to TYPO3 security team members Elias Häußler and Oliver Hader for fixing it.

### References
* [TYPO3-CORE-SA-2026-004](https://typo3.org/security/advisory/typo3-core-sa-2026-004)
GitHub Security Advisory: GHSA-7vp9-x248-9vr9
Package: typo3/cms-core (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 11.0.0, <= 11.5.48
Patched in: 11.5.49

Summary: TYPO3 CMS Allows Insecure Deserialization via Mailer File Spool

Details:
### Problem
Local platform users who can write to TYPO3’s mail‑file spool directory can craft a file that the system will automatically deserialize without any class restrictions. This flaw allows an attacker to inject and execute arbitrary PHP code in the public scope of the web server.

The vulnerability is triggered when TYPO3 is configured with `$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_spool_type'] = 'file';` and a scheduler task or cron job runs the command `mailer:spool:send`. The spool‑send operation performs the insecure deserialization that is at the core of this issue.

### Solution
Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.

### Credits
Thanks to Vitaly Simonovich for reporting this issue, and to TYPO3 security team members Elias Häußler and Oliver Hader for fixing it.

### References
* [TYPO3-CORE-SA-2026-004](https://typo3.org/security/advisory/typo3-core-sa-2026-004)
GitHub Security Advisory: GHSA-7vp9-x248-9vr9
Package: typo3/cms-core (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 12.0.0, <= 12.4.40
Patched in: 12.4.41

Summary: TYPO3 CMS Allows Insecure Deserialization via Mailer File Spool

Details:
### Problem
Local platform users who can write to TYPO3’s mail‑file spool directory can craft a file that the system will automatically deserialize without any class restrictions. This flaw allows an attacker to inject and execute arbitrary PHP code in the public scope of the web server.

The vulnerability is triggered when TYPO3 is configured with `$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_spool_type'] = 'file';` and a scheduler task or cron job runs the command `mailer:spool:send`. The spool‑send operation performs the insecure deserialization that is at the core of this issue.

### Solution
Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.

### Credits
Thanks to Vitaly Simonovich for reporting this issue, and to TYPO3 security team members Elias Häußler and Oliver Hader for fixing it.

### References
* [TYPO3-CORE-SA-2026-004](https://typo3.org/security/advisory/typo3-core-sa-2026-004)
GitHub Security Advisory: GHSA-7vp9-x248-9vr9
Package: typo3/cms-core (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 13.0.0, <= 13.4.22
Patched in: 13.4.23

Summary: TYPO3 CMS Allows Insecure Deserialization via Mailer File Spool

Details:
### Problem
Local platform users who can write to TYPO3’s mail‑file spool directory can craft a file that the system will automatically deserialize without any class restrictions. This flaw allows an attacker to inject and execute arbitrary PHP code in the public scope of the web server.

The vulnerability is triggered when TYPO3 is configured with `$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_spool_type'] = 'file';` and a scheduler task or cron job runs the command `mailer:spool:send`. The spool‑send operation performs the insecure deserialization that is at the core of this issue.

### Solution
Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.

### Credits
Thanks to Vitaly Simonovich for reporting this issue, and to TYPO3 security team members Elias Häußler and Oliver Hader for fixing it.

### References
* [TYPO3-CORE-SA-2026-004](https://typo3.org/security/advisory/typo3-core-sa-2026-004)
GitHub Security Advisory: GHSA-7vp9-x248-9vr9
Package: typo3/cms-core (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 14.0.0, <= 14.0.1
Patched in: 14.0.2

Summary: TYPO3 CMS Allows Insecure Deserialization via Mailer File Spool

Details:
### Problem
Local platform users who can write to TYPO3’s mail‑file spool directory can craft a file that the system will automatically deserialize without any class restrictions. This flaw allows an attacker to inject and execute arbitrary PHP code in the public scope of the web server.

The vulnerability is triggered when TYPO3 is configured with `$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_spool_type'] = 'file';` and a scheduler task or cron job runs the command `mailer:spool:send`. The spool‑send operation performs the insecure deserialization that is at the core of this issue.

### Solution
Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.

### Credits
Thanks to Vitaly Simonovich for reporting this issue, and to TYPO3 security team members Elias Häußler and Oliver Hader for fixing it.

### References
* [TYPO3-CORE-SA-2026-004](https://typo3.org/security/advisory/typo3-core-sa-2026-004)
GitHub Security Advisory: GHSA-p52w-7rhw-9m67
Package: typo3/cms-recycler (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 10.0.0, <= 10.4.54
Patched in: 10.4.55

Summary: TYPO3 CMS Allows Broken Access Control in Recycler Module

Details:
### Problem
Backend users who had access to the recycler module could delete arbitrary data from any database table defined in the TCA - regardless of whether they had permission to that particular table. This allowed attackers to purge and destroy critical site data, effectively rendering the website unavailable.

### Solution
Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.

### Credits
Thanks to Sven Jürgens and Daniel Windloff for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

### References
* [TYPO3-CORE-SA-2026-003](https://typo3.org/security/advisory/typo3-core-sa-2026-003)
GitHub Security Advisory: GHSA-p52w-7rhw-9m67
Package: typo3/cms-recycler (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 11.0.0, <= 11.5.48
Patched in: 11.5.49

Summary: TYPO3 CMS Allows Broken Access Control in Recycler Module

Details:
### Problem
Backend users who had access to the recycler module could delete arbitrary data from any database table defined in the TCA - regardless of whether they had permission to that particular table. This allowed attackers to purge and destroy critical site data, effectively rendering the website unavailable.

### Solution
Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.

### Credits
Thanks to Sven Jürgens and Daniel Windloff for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

### References
* [TYPO3-CORE-SA-2026-003](https://typo3.org/security/advisory/typo3-core-sa-2026-003)
GitHub Security Advisory: GHSA-p52w-7rhw-9m67
Package: typo3/cms-recycler (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 12.0.0, <= 12.4.40
Patched in: 12.4.41

Summary: TYPO3 CMS Allows Broken Access Control in Recycler Module

Details:
### Problem
Backend users who had access to the recycler module could delete arbitrary data from any database table defined in the TCA - regardless of whether they had permission to that particular table. This allowed attackers to purge and destroy critical site data, effectively rendering the website unavailable.

### Solution
Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.

### Credits
Thanks to Sven Jürgens and Daniel Windloff for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

### References
* [TYPO3-CORE-SA-2026-003](https://typo3.org/security/advisory/typo3-core-sa-2026-003)