Source
ghsa
A stored cross-site scripting (XSS) vulnerability in the Create Article function of MoonShine v3.12.3 allows attackers to execute arbitrary web scripts or HTML via injecting a crafted payload into the Link parameter.
A stored cross-site scripting (XSS) vulnerability in the Create Admin function of MoonShine v3.12.3 allows attackers to execute arbitrary web scripts or HTML via injecting a crafted payload into the Name parameter.
An arbitrary file upload vulnerability in MoonShine v3.12.4 allows attackers to execute arbitrary code via uploading a crafted SVG file.
MoonShine v3.12.5 was discovered to contain a SQL injection vulnerability via the Data parameter under the Blog module.
A Stored cross-site scripting vulnerability in the Liferay Portal 7.4.3.120 through 7.4.3.132, and Liferay DXP 2025.Q2.0 through 2025.Q2.8, 2025.Q1.0 through 2025.Q1.15, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.1 through 2024.Q2.13 and 2024.Q1.9 through 2024.Q1.19 allows an remote authenticated attacker to inject JavaScript through the message boards feature available via the web interface. Liferay Portal is fixed on the master branch from commit c1b7c6b.
Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q1.0 through 2025.Q1.6, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.16 and 7.4 GA through update 92 allow any authenticated user to modify the content of emails sent through the calendar portlet, allowing an attacker to send phishing emails to any other user in the same organization. Liferay Portal is fixed on the master branch from commit ff18e7d.
### Summary A stored Cross-Site Scripting (XSS) vulnerability exists in LibreNMS (<= 25.6.0) in the Alert Template creation feature. This allows a user with the **admin role** to inject malicious JavaScript, which will be executed when the template is rendered, potentially compromising other admin accounts. --- ### Details In the LibreNMS web UI, when a user with the **admin role** visits `/templates` and clicks **"Create new alert template"**, the **"Template name"** field fails to properly sanitize input. By inserting a payload like: ``` <script>alert(document.cookie)</script> ``` and filling the other fields with arbitrary content (e.g., `test`), once the template is saved, the script is executed. This confirms that user input is stored and later rendered without proper output encoding. This vulnerability can be exploited for session hijacking, data theft, or other malicious actions targeting other admin users. --- ### PoC 1. Log in to LibreNMS using an account with t...
A reflected cross-site scripting (XSS) vulnerability in the Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q1.0 through 2025.Q1.8, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.16 and 7.4 GA through update 92 allows an remote authenticated user to inject JavaScript in message board threads and categories.
### Impact Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use [unsafe](https://copier.readthedocs.io/en/stable/configuring/#unsafe) features like custom Jinja extensions which would require passing the `--UNSAFE,--trust` flag. As it turns out, a safe template can currently write files outside the destination path where a project shall be generated or updated. This is possible when rendering a [generated directory structure](https://copier.readthedocs.io/en/stable/configuring/#generating-a-directory-structure) whose rendered path is either a relative parent path or an absolute path. Constructing such paths is possible using Copier's builtin `pathjoin` Jinja filter and its builtin `_copier_conf.sep` variable, which is the platform-native path separator. This way, a malicious template author can create a template that overwrites arbitrary files (according to the user's write permissions), e.g., to cause havoc. #### Write access via gener...
### Overview OpenFGA v1.9.3 to v1.9.4 ( openfga-0.2.40 <= Helm chart <= openfga-0.2.41, v1.9.3 <= docker <= v.1.9.4) are vulnerable to improper policy enforcement when certain Check and ListObject calls are executed. ### Am I Affected? You are affected by this vulnerability if you are using OpenFGA v1.9.3 to v1.9.4, specifically under the following preconditions: - Calling Check API or ListObjects with an [authorization model](https://openfga.dev/docs/concepts#what-is-an-authorization-model) that has a relationship directly assignable by more than 1 [userset](https://openfga.dev/docs/modeling/building-blocks/usersets) with same [type](https://openfga.dev/docs/concepts#what-is-a-type), and - There are check or list object queries that rely on the above relationship, and - You have userset tuples that are assigned to the above relationship ### Fix Upgrade to v1.9.5. This upgrade is backwards compatible. ### Workaround Downgrade to v1.9.2 with enable-check-optimizations removed from O...