Unauthenticated Sensitive Data Exposure in Complianz <= 7.5.0 versions.

Contributor Sensitive Data Exposure in TinyMCE Templates <= 4.8.1 versions.

Unauthenticated Cross Site Scripting (XSS) in Product Enquiry for WooCommerce <= 2.2.34.43 versions.

Joomla Extension - regularlabs.com - Inconsistent CSRF token checks / privilege checks in Cache Cleaner extension - Administrator URL purges did not consistently require a valid token and cache-management permission.

Pronetiqs IntraVUE versions 3.2.1a14 and prior have an exposure of sensitive system information to an unauthorized control sphere vulnerability which could allow for asset discovery by unauthenticated users.

The FormCraft plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the '[parameter name]' parameter in all versions up to, and including, 3.9.14 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The exploit chain combines a server-side gap — where composite matrix sub-field keys such as field2_0 and field2_1 are never passed through the sanitization loop and are stored raw via $wpdb->insert() — with a client-side gap where DOMPurify is only invoked when typeof field.value === 'string', but matrix values arrive from the server as arrays, bypassing the check before being mapped to strings and injected into the DOM. Additionally, the same sink is reachable via a second attack vector: array-typed field values are passed through htmlentities() on submission but later reversed by html_entity_decode() at formcraft-main.php:2608 and :2122, restoring the malicious payload before storage and rendering.

Shopware is an open commerce platform. Versions 6.7.3.0 through 6.7.10.0 have an open redirect in Shopware's public SSO entry point at `GET /api/oauth/sso/auth`. When the endpoint is reached without the expected SSO session state, the application falls back to the request's `Referer` header and uses that value as the redirect destination. In the validated behavior, the server does not restrict that fallback target to same-origin URLs, does not require a relative path, and does not reject dangerous schemes such as `javascript:`. As a result, an unauthenticated request can turn this endpoint into a reusable redirect primitive whose destination is fully controlled by attacker-supplied request metadata. The security problem is not limited to a harmless navigation mismatch. The endpoint sits under `/api/oauth/`, which gives the redirect a trustworthy application-controlled origin and makes it suitable for phishing chains, branded redirect abuse, and cases where client software automatically follows redirects issued by a trusted host. The attached evidence also shows that the response is not only an HTTP `302` with a user-controlled `Location` header. The HTML body contains a matching meta refresh tag and redirect link built from the same attacker-controlled value. In the validated proof, the endpoint redirects to `https://attacker.example/poc` when that URL is supplied through `Referer`, and it also reflects `javascript:alert(1)` into `Location` and the HTML redirect body without any scheme filtering. This report therefore stays conservative and claims an open redirect with arbitrary redirect targets, while noting that the lack of scheme restrictions makes the behavior materially worse than a same-scheme external redirect. Version 6.7.10.1 fixes the issue.

In JetBrains IntelliJ IDEA before 2026.2 hTML injection was possible in an IDE notification, allowing silent user activity tracking

Improper neutralization of special elements used in an OS command ('OS command injection') vulnerability in TUBITAK BILGEM Software Technologies Research Institute pardus-update allows OS Command Injection. This issue affects pardus-update: from 0.6.6 before 0.7.0.

When initializing an RSA public key from DER or PEM bytes throws an error, the EVP_PKEY* is double-freed: first in the catch block, then in the deinit. This can lead to a crash on future memory allocations. This double-free manifests when BoringSSL cannot decode the public key from the bytes provided. This vulnerability is addressed in swift-crypto version 4.5.1.