ghsa

### Summary When product data that begins with a spreadsheet formula character (for example =, +, -, or @) is accepted and later exported or saved into a CSV and opened in spreadsheet software, the spreadsheet will interpret that cell as a formula. This allows an attacker to supply a CSV field (e.g., product name) that contains a formula which may be evaluated by a victim’s spreadsheet application — potentially leading to data exfiltration and remote command execution (via older Excel exploits / OLE/cmd constructs or Excel macros). ### Details Spreadsheet applications treat cell text that begins with characters =, +, -, @ as formulas. If unescaped, spreadsheet will interpret and evaluate the content when the file is opened. The application fails to neutralize/escape leading formula characters when generating CSV or when accepting CSV import fields for display/export. ### PoC Insert CSV formula to the product name field, and save the changes. Export it to CSV file, open it and the cal...

### Summary In Bagisto v2.3.7, the TinyMCE image upload functionality allows an attacker with sufficient privileges (e.g. admin) to upload a crafted SVG file containing embedded JavaScript. When viewed, the malicious code executes in the context of the admin/user’s browser. ### Details The underlying problem is that SVG is XML/markup, so when it is uploaded and then directly rendered or embedded, script or event handlers within are allowed to run unless sanitized. In Bagisto, the integration of TinyMCE’s image upload (or media manager) may accept SVG files without sanitizing or rejecting unsafe content. When the SVG is later included (inline or via object/embed) in content displayed in admin or UI, the browser may execute the script portion of the SVG. The application might not validate the file content (i.e. inspect the SVG XML) or strip <script>, onload, onclick, foreignObject, xlink:href injection, objects/embed tags, etc. ### PoC Navigate to any forms with TinyMCE editor. Attempt...

### Summary Bagisto v2.3.7 is vulnerable to Server-Side Template Injection (SSTI) due to unsanitized user input being processed by the server-side templating engine when rendering product descriptions. This allows an attacker with product creation privileges to inject arbitrary template expressions that are evaluated by the backend — potentially leading to Remote Code Execution (RCE) on the server. ### Details In Bagisto, product descriptions are rendered through Laravel’s Blade templating engine in various front-end and admin views. The product description field is not sanitized or escaped before being passed to the view, which means user-supplied data can break out of the expected string context and execute arbitrary template code. ### PoC Create a product and enter the payload to the description. <img width="679" height="669" alt="image" src="https://github.com/user-attachments/assets/1e5dac3f-4043-4b31-98ed-f4346feb5477" /> Preview the page, observed that the template expressions...

## Executive Summary **Product:** LibreNMS **Vendor:** LibreNMS **Vulnerability Type:** Cross-Site Scripting (XSS) **CVSS Score:** 4.3 (AV:N/AC:L/PR:H/UI:R/S:U/C:L/I:L/A:L) **Affected Version:** 25.8.0 (latest at time of discovery) **POC File:** [Download POC](https://trendmicro-my.sharepoint.com/:u:/p/kholoud_altookhy/EQYQOiGddUtOtz6739YUFU4B5FkNob_TvKBYEA8P6lSRQw?e=lDOR5W) **Ticket:** ZDI-CAN-28105: LibreNMS Alert Rules Cross-Site Scripting Vulnerability ## Vulnerability Details ### Description Trend Micro's Zero Day Initiative has identified a Cross-Site Scripting vulnerability in LibreNMS. The vulnerability exists in the Alert Rules functionality where the alert rule name is not properly sanitized, allowing injection of HTML code. ### Technical Details **Version Tested:** 25.8.0 **Installer File:** 25.8.0.tar.gz **Download Link:** https://github.com/librenms/librenms/archive/refs/tags/25.8.0.tar.gz **Platform:** N/A ### Attack Vector When browsing to **Alerts ...

### Impact Wrong usage of the PHP `array_search()` allows bypass of validation. ### Patches The problem has been patched in versions: - v4.4.1 for PrestaShop 1.7 (build number: 7.4.4.1) - v4.4.1 for PrestaShop 8 (build number: 8.4.4.1) - v5.0.5 for PrestaShop 1.7 (build number: 7.5.0.5) - v5.0.5 for PrestaShop 8 (build number: 8.5.0.5) - v5.0.5 for PrestaShop 9 (build number: 9.5.0.5) Read the [Versioning policy](https://github.com/PrestaShopCorp/ps_checkout/wiki/Versioning) to learn more about the build number. ### Credits [Léo CUNÉAZ](https://github.com/inem0o) reported this issue.

# Impact Missing validation on input vulnerable to directory traversal. # Patches The problem has been patched in versions: v4.4.1 for PrestaShop 1.7 (build number: 7.4.4.1) v4.4.1 for PrestaShop 8 (build number: 8.4.4.1) v5.0.5 for PrestaShop 1.7 (build number: 7.5.0.5) v5.0.5 for PrestaShop 8 (build number: 8.5.0.5) v5.0.5 for PrestaShop 9 (build number: 9.5.0.5) Read the [Versioning policy](https://github.com/PrestaShopCorp/ps_checkout/wiki/Versioning) to learn more about the build number. # Credits [Léo CUNÉAZ](https://github.com/inem0o) for reportied this issue.

# Impact Missing validation on Express Checkout feature allows silent log-in. # Patches The problem has been patched in versions - v4.4.1 for PrestaShop 1.7 (build number: 7.4.4.1) - v4.4.1 for PrestaShop 8 (build number: 8.4.4.1) - v5.0.5 for PrestaShop 1.7 (build number: 7.5.0.5) - v5.0.5 for PrestaShop 8 (build number: 8.5.0.5) - v5.0.5 for PrestaShop 9 (build number: 9.5.0.5) Read the [Versioning policy](https://github.com/PrestaShopCorp/ps_checkout/wiki/Versioning) to learn more about the build number. # Credits [Léo CUNÉAZ](https://github.com/inem0o) reported this issue.

### Summary A CORS misconfiguration vulnerability exists in default installations of Strapi where attacker-controlled origins are improperly reflected in API responses. ### Technical Details By default, Strapi reflects the value of the Origin header back in the Access-Control-Allow-Origin response header without proper validation or whitelisting. Example: `Origin: http://localhost:8888` `Access-Control-Allow-Origin: http://localhost:8888` `Access-Control-Allow-Credentials: true` This allows an attacker-controlled site (on a different port, like 8888) to send credentialed requests to the Strapi backend on 1337. ### Suggested Fix 1. Explicitly whitelist trusted origins 2. Avoid reflecting dynamic origins

## Summary Strapi's password hashing implementation using bcryptjs lacks maximum password length validation. Since bcryptjs truncates passwords exceeding 72 bytes, this creates potential vulnerabilities such as authentication bypass and performance degradation. ## POC Create an admin user with a password exceeding 72 characters like 85, Log in using only the first 72 characters of the password. Authentication is successful, confirming the issue. Proposed Solution Based on discussions: Add a maximum password length validation (72 characters) during password creation and updates for both Admin and U&P users. Truncate passwords exceeding 72 bytes on the server before passing them to bcryptjs during login. Optionally, issue a warning to users with passwords longer than 72 bytes during login, informing them of truncation. ## Impact This issue affects all Strapi installations using bcryptjs for password hashing. Until resolved, it can lead to: Authentication Bypass: Users may unknowing...

A security vulnerability has been detected in Shazwazza Smidge up to 4.5.1. The impacted element is an unknown function of the component Bundle Handler. The manipulation of the argument Version leads to path traversal. Remote exploitation of the attack is possible. Upgrading to version 4.6.0 is sufficient to resolve this issue. It is recommended to upgrade the affected component.