deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-p52w-7rhw-9m67
Package: typo3/cms-recycler (COMPOSER)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 13.0.0, <= 13.4.22
Patched in: 13.4.23

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: >= 14.0.0, <= 14.0.1
Patched in: 14.0.2

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-6c46-p6j5-3f49
Package: typo3/cms-redirects (COMPOSER)
Severity: MODERATE (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 Redirects Module

Details:
### Problem
Backend users with access to the redirects module and write permission on the `sys_redirect` table were able to  read, create, and modify any redirect record - without restriction to the user’s own file‑mounts or web‑mounts. This allowed attackers to insert or alter redirects pointing to arbitrary URLs - facilitating phishing or other malicious redirect attacks.

### 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 Georg Dümmler for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

### References
* [TYPO3-CORE-SA-2026-002](https://typo3.org/security/advisory/typo3-core-sa-2026-002)
GitHub Security Advisory: GHSA-6c46-p6j5-3f49
Package: typo3/cms-redirects (COMPOSER)
Severity: MODERATE (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 Redirects Module

Details:
### Problem
Backend users with access to the redirects module and write permission on the `sys_redirect` table were able to  read, create, and modify any redirect record - without restriction to the user’s own file‑mounts or web‑mounts. This allowed attackers to insert or alter redirects pointing to arbitrary URLs - facilitating phishing or other malicious redirect attacks.

### 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 Georg Dümmler for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

### References
* [TYPO3-CORE-SA-2026-002](https://typo3.org/security/advisory/typo3-core-sa-2026-002)
GitHub Security Advisory: GHSA-6c46-p6j5-3f49
Package: typo3/cms-redirects (COMPOSER)
Severity: MODERATE (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 Redirects Module

Details:
### Problem
Backend users with access to the redirects module and write permission on the `sys_redirect` table were able to  read, create, and modify any redirect record - without restriction to the user’s own file‑mounts or web‑mounts. This allowed attackers to insert or alter redirects pointing to arbitrary URLs - facilitating phishing or other malicious redirect attacks.

### 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 Georg Dümmler for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

### References
* [TYPO3-CORE-SA-2026-002](https://typo3.org/security/advisory/typo3-core-sa-2026-002)
GitHub Security Advisory: GHSA-6c46-p6j5-3f49
Package: typo3/cms-redirects (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 13.0.0, <= 13.4.22
Patched in: 13.4.23

Summary: TYPO3 CMS Allows Broken Access Control in Redirects Module

Details:
### Problem
Backend users with access to the redirects module and write permission on the `sys_redirect` table were able to  read, create, and modify any redirect record - without restriction to the user’s own file‑mounts or web‑mounts. This allowed attackers to insert or alter redirects pointing to arbitrary URLs - facilitating phishing or other malicious redirect attacks.

### 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 Georg Dümmler for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

### References
* [TYPO3-CORE-SA-2026-002](https://typo3.org/security/advisory/typo3-core-sa-2026-002)
GitHub Security Advisory: GHSA-6c46-p6j5-3f49
Package: typo3/cms-redirects (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 14.0.0, <= 14.0.1
Patched in: 14.0.2

Summary: TYPO3 CMS Allows Broken Access Control in Redirects Module

Details:
### Problem
Backend users with access to the redirects module and write permission on the `sys_redirect` table were able to  read, create, and modify any redirect record - without restriction to the user’s own file‑mounts or web‑mounts. This allowed attackers to insert or alter redirects pointing to arbitrary URLs - facilitating phishing or other malicious redirect attacks.

### 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 Georg Dümmler for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

### References
* [TYPO3-CORE-SA-2026-002](https://typo3.org/security/advisory/typo3-core-sa-2026-002)
GitHub Security Advisory: GHSA-5j7q-wmh7-cqhg
Package: typo3/cms-backend (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 10.0.0, <= 10.4.54
Patched in: 10.4.55

Summary: TYPO3 CMS Allows Broken Access Control in Edit Document Controller

Details:
### Problem
By exploiting the `defVals` parameter, attackers could bypass field‑level access checks during record creation in the TYPO3 backend. This gave them the ability to insert arbitrary data into prohibited exclude fields of a database table for which the user already has write permission for a reduced set of fields.

### 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 Daniel Windloff for reporting this issue, and to TYPO3 core & security team member Benjamin Franzke for fixing it.

### References
* [TYPO3-CORE-SA-2026-001](https://typo3.org/security/advisory/typo3-core-sa-2026-001)
GitHub Security Advisory: GHSA-5j7q-wmh7-cqhg
Package: typo3/cms-backend (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 11.0.0, <= 11.5.48
Patched in: 11.5.49

Summary: TYPO3 CMS Allows Broken Access Control in Edit Document Controller

Details:
### Problem
By exploiting the `defVals` parameter, attackers could bypass field‑level access checks during record creation in the TYPO3 backend. This gave them the ability to insert arbitrary data into prohibited exclude fields of a database table for which the user already has write permission for a reduced set of fields.

### 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 Daniel Windloff for reporting this issue, and to TYPO3 core & security team member Benjamin Franzke for fixing it.

### References
* [TYPO3-CORE-SA-2026-001](https://typo3.org/security/advisory/typo3-core-sa-2026-001)
GitHub Security Advisory: GHSA-5j7q-wmh7-cqhg
Package: typo3/cms-backend (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 12.0.0, <= 12.4.40
Patched in: 12.4.41

Summary: TYPO3 CMS Allows Broken Access Control in Edit Document Controller

Details:
### Problem
By exploiting the `defVals` parameter, attackers could bypass field‑level access checks during record creation in the TYPO3 backend. This gave them the ability to insert arbitrary data into prohibited exclude fields of a database table for which the user already has write permission for a reduced set of fields.

### 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 Daniel Windloff for reporting this issue, and to TYPO3 core & security team member Benjamin Franzke for fixing it.

### References
* [TYPO3-CORE-SA-2026-001](https://typo3.org/security/advisory/typo3-core-sa-2026-001)
GitHub Security Advisory: GHSA-5j7q-wmh7-cqhg
Package: typo3/cms-backend (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 13.0.0, <= 13.4.22
Patched in: 13.4.23

Summary: TYPO3 CMS Allows Broken Access Control in Edit Document Controller

Details:
### Problem
By exploiting the `defVals` parameter, attackers could bypass field‑level access checks during record creation in the TYPO3 backend. This gave them the ability to insert arbitrary data into prohibited exclude fields of a database table for which the user already has write permission for a reduced set of fields.

### 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 Daniel Windloff for reporting this issue, and to TYPO3 core & security team member Benjamin Franzke for fixing it.

### References
* [TYPO3-CORE-SA-2026-001](https://typo3.org/security/advisory/typo3-core-sa-2026-001)
GitHub Security Advisory: GHSA-5j7q-wmh7-cqhg
Package: typo3/cms-backend (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 14.0.0, <= 14.0.1
Patched in: 14.0.2

Summary: TYPO3 CMS Allows Broken Access Control in Edit Document Controller

Details:
### Problem
By exploiting the `defVals` parameter, attackers could bypass field‑level access checks during record creation in the TYPO3 backend. This gave them the ability to insert arbitrary data into prohibited exclude fields of a database table for which the user already has write permission for a reduced set of fields.

### 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 Daniel Windloff for reporting this issue, and to TYPO3 core & security team member Benjamin Franzke for fixing it.

### References
* [TYPO3-CORE-SA-2026-001](https://typo3.org/security/advisory/typo3-core-sa-2026-001)
GitHub Security Advisory: GHSA-wvpq-h33f-8rp6
Package: october/system (COMPOSER)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, <= 4.0.11
Patched in: 4.0.12

Summary: October CMS Vulnerable to Stored XSS via Branding Styles

Details:
A cross-site scripting (XSS) vulnerabilities was identified in October CMS backend configuration forms:

- **Branding and Appearances Styles**  
   A user with the `Customize Backend Styles` permission could inject malicious HTML/JS into the stylesheet input at  
   *Settings → Branding & Appearance → Styles*.  

A specially crafted input could break out of the intended `<style>` context, allowing arbitrary script execution across backend pages for all users.

---

### Impact
- Persistent XSS across the backend interface.  
- Exploitable by lower-privileged accounts with the above permissions.  
- Potential consequences include privilege escalation, session hijacking, and execution of unauthorized actions in victim sessions.

---

### Patches
The vulnerability has been patched in **v4.0.12** and **v3.7.13**.  
Stylesheet inputs are now sanitized to prevent injection of arbitrary HTML/JS.  

All users are strongly encouraged to upgrade to the latest patched version.

---

### Workarounds
If upgrading immediately is not possible:  
- Restrict the permissions `Customize Backend Styles` to fully trusted administrators only.  

This reduces exposure but does not fully eliminate risk.

---

### Credits
- Reported by **[Nakkouch Tarek](https://github.com/nakkouchtarek)**
GitHub Security Advisory: GHSA-wvpq-h33f-8rp6
Package: october/system (COMPOSER)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 3.7.12
Patched in: 3.7.13

Summary: October CMS Vulnerable to Stored XSS via Branding Styles

Details:
A cross-site scripting (XSS) vulnerabilities was identified in October CMS backend configuration forms:

- **Branding and Appearances Styles**  
   A user with the `Customize Backend Styles` permission could inject malicious HTML/JS into the stylesheet input at  
   *Settings → Branding & Appearance → Styles*.  

A specially crafted input could break out of the intended `<style>` context, allowing arbitrary script execution across backend pages for all users.

---

### Impact
- Persistent XSS across the backend interface.  
- Exploitable by lower-privileged accounts with the above permissions.  
- Potential consequences include privilege escalation, session hijacking, and execution of unauthorized actions in victim sessions.

---

### Patches
The vulnerability has been patched in **v4.0.12** and **v3.7.13**.  
Stylesheet inputs are now sanitized to prevent injection of arbitrary HTML/JS.  

All users are strongly encouraged to upgrade to the latest patched version.

---

### Workarounds
If upgrading immediately is not possible:  
- Restrict the permissions `Customize Backend Styles` to fully trusted administrators only.  

This reduces exposure but does not fully eliminate risk.

---

### Credits
- Reported by **[Nakkouch Tarek](https://github.com/nakkouchtarek)**
GitHub Security Advisory: GHSA-gxxc-m74c-f48x
Package: october/system (COMPOSER)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, <= 4.0.11
Patched in: 4.0.12

Summary: October CMS Vulnerable to Stored XSS via Editor and Branding Styles

Details:
A cross-site scripting (XSS) vulnerabilities was identified in October CMS backend configuration forms:

- **Editor Settings Markup Styles**  
   A user with the `Global Editor Settings` permission could inject malicious HTML/JS into the stylesheet input at  
   *Settings → Editor Settings → Markup Styles*.  

A specially crafted input could break out of the intended `<style>` context, allowing arbitrary script execution across backend pages for all users.

---

### Impact
- Persistent XSS across the backend interface.  
- Exploitable by lower-privileged accounts with the above permissions.  
- Potential consequences include privilege escalation, session hijacking, and execution of unauthorized actions in victim sessions.

---

### Patches
The vulnerability has been patched in **v4.0.12** and **v3.7.13**.  
Stylesheet inputs are now sanitized to prevent injection of arbitrary HTML/JS.  

All users are strongly encouraged to upgrade to the latest patched version.

---

### Workarounds
If upgrading immediately is not possible:  
- Restrict the permissions `Global Editor Settings` to fully trusted administrators only.  

This reduces exposure but does not fully eliminate risk.

---

### Credits
- Reported by **[Nakkouch Tarek](https://github.com/nakkouchtarek)**
GitHub Security Advisory: GHSA-gxxc-m74c-f48x
Package: october/system (COMPOSER)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 3.7.12
Patched in: 3.7.13

Summary: October CMS Vulnerable to Stored XSS via Editor and Branding Styles

Details:
A cross-site scripting (XSS) vulnerabilities was identified in October CMS backend configuration forms:

- **Editor Settings Markup Styles**  
   A user with the `Global Editor Settings` permission could inject malicious HTML/JS into the stylesheet input at  
   *Settings → Editor Settings → Markup Styles*.  

A specially crafted input could break out of the intended `<style>` context, allowing arbitrary script execution across backend pages for all users.

---

### Impact
- Persistent XSS across the backend interface.  
- Exploitable by lower-privileged accounts with the above permissions.  
- Potential consequences include privilege escalation, session hijacking, and execution of unauthorized actions in victim sessions.

---

### Patches
The vulnerability has been patched in **v4.0.12** and **v3.7.13**.  
Stylesheet inputs are now sanitized to prevent injection of arbitrary HTML/JS.  

All users are strongly encouraged to upgrade to the latest patched version.

---

### Workarounds
If upgrading immediately is not possible:  
- Restrict the permissions `Global Editor Settings` to fully trusted administrators only.  

This reduces exposure but does not fully eliminate risk.

---

### Credits
- Reported by **[Nakkouch Tarek](https://github.com/nakkouchtarek)**
GitHub Security Advisory: GHSA-mhpg-hpj5-73r2
Package: drupal/core (COMPOSER)
Severity: LOW (CVSS 3.7)
CWE: CWE-525: Use of Web Browser Cache Containing Sensitive Information
Vulnerable versions: >= 7.0, < 7.103
Patched in: 7.103

Summary: Drupal core allows Exploiting Incorrectly Configured Access Control Security Levels

Details:
Use of Web Browser Cache Containing Sensitive Information vulnerability in Drupal Drupal core allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Drupal core: from 8.0.0 before 10.4.9, from 10.5.0 before 10.5.6, from 11.0.0 before 11.1.9, from 11.2.0 before 11.2.8, from 7.0 before 7.103.
GitHub Security Advisory: GHSA-4j78-4xrm-cr2f
Package: getkirby/cms (COMPOSER)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 5.0.0, <= 5.2.1
Patched in: 5.2.2

Summary: Kirby is missing permission checks in the content changes API

Details:
### TL;DR

This vulnerability affects all Kirby sites where user permissions are configured to prevent specific role(s) from performing write actions, specifically by disabling the `update` permission with the intent to prevent modifications to site content.

If developers haven't configured any user permissions that deviate from the default of allowing all actions, their site is *not* affected.

----

### Introduction

Kirby allows to restrict the permissions of specific user roles. Users of that role can only perform permitted actions.

Permissions for updating content have already existed and could be configured for each model type, but were not enforced by Kirby's API backend code during operations to the changes version.

The changes version is the content version that contains unsaved changes of existing models (pages, users, files or the site).

### Impact

The missing permission checks allowed attackers with Panel access to create or discard a changes version or update the content fields in an existing changes version. All of these actions could affect arbitrary models.

This could cause the following impact:

- Attackers could maliciously create changes versions for all models of the site, creating editing locks that would prevent other authenticated users from making content changes until those locks were cleared.
- Attackers could update the content in a malicious way, for example by adding defamatory or spam content or by including malicious links or scripts. While this updated content would not immediately be published to the site, an inattentive editor with update permissions could inadvertently publish these changes in the belief that an authorized user has made them.
- Attackers could discard extensive changes, making editors lose their content work.

### Patches

The problem has been patched in [Kirby 5.2.2](https://github.com/getkirby/kirby/releases/tag/5.2.2). Please update to this or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability.

In the mentioned release, we have added checks for the model `update` permissions that ensure that users without this permission cannot create, edit or discard the changes version of the respective model.

A future Kirby release will add separate `edit` and `save` permissions that will make it possible to control write actions to model content more granularly.

### Credits

Thanks to Lukas Kleinschmidt (@lukaskleinschmidt) for responsibly reporting the identified issue.
GitHub Security Advisory: GHSA-rgmp-4873-r683
Package: pterodactyl/panel (COMPOSER)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 1.12.0
Patched in: 1.12.0

Summary: Pterodactyl TOTPs can be reused during validity window

Details:
### Summary
When a user signs into an account with 2FA enabled they are prompted to enter a token. When that token is used, it is not sufficiently marked as used in the system allowing an attacker that intercepts that token to then use it in addition to a known username/password during the token validity window.

This vulnerability requires that an attacker already be in possession of a valid username and password combination, and intercept a valid 2FA token (for example, during a screen share). The token must then be provided in addition to the username and password during the limited token validity window. The validity window is ~60 seconds as the Panel allows at most one additional window to the current one, each window being 30 seconds.