#js

This week made one thing clear: small oversights can spiral fast. Tools meant to save time and reduce friction turned into easy entry points once basic safeguards were ignored. Attackers didn’t need novel tricks. They used what was already exposed and moved in without resistance. Scale amplified the damage. A single weak configuration rippled out to millions. A repeatable flaw worked again and

A cross-site scripting (XSS) vulnerabilities was identified in October CMS backend configuration forms: - **Branding and Appearances Styles** A user with the `Customize Backend Styles` permission could inject malicious HTML/JS into the stylesheet input at *Settings → Branding & Appearance → Styles*. A specially crafted input could break out of the intended `<style>` context, allowing arbitrary script execution across backend pages for all users. --- ### Impact - Persistent XSS across the backend interface. - Exploitable by lower-privileged accounts with the above permissions. - Potential consequences include privilege escalation, session hijacking, and execution of unauthorized actions in victim sessions. --- ### Patches The vulnerability has been patched in **v4.0.12** and **v3.7.13**. Stylesheet inputs are now sanitized to prevent injection of arbitrary HTML/JS. All users are strongly encouraged to upgrade to the latest patched version. --- ### Workaround...

### Summary An authentication bypass vulnerability allows any unauthenticated attacker to forge arbitrary JWT tokens by setting "alg": "none" in the token header. The library's verification functions immediately return `true` for such tokens without performing any cryptographic verification, enabling complete impersonation of any user and privilege escalation. ### Details The vulnerability exists in Sources/JSONWebSignature/JWS+Verify.swift at lines 34-37: ``` public func verify<Key>(key: Key?) throws -> Bool { guard SigningAlgorithm.none != protectedHeader.algorithm else { return true // <-- Vulnerability: returns true without verification } ``` When the JWT header contains "alg": "none", the verify() method returns true immediately without: 1. Checking if the signature is empty or present 2. Validating the token against any key 3. Requiring explicit opt-in from the caller The SigningAlgorithm enum in Sources/JSONWebAlgorithms/Signatures/Signi...

### Vulnerability **Description** --- **Vulnerability Overview** This issue is a command injection vulnerability (CWE-78) that allows authenticated users to inject stdio_config.command/args into MCP stdio settings, causing the server to execute subprocesses using these injected values. The root causes are as follows: - **Missing Security Filtering**: When transport_type=stdio, there is no validation on stdio_config.command/args, such as allowlisting, enforcing fixed paths/binaries, or blocking dangerous options. - **Functional Flaw (Trust Boundary Violation)**: The command/args stored as "service configuration data" are directly used in the /test execution flow and connected to execution sinks without validation. - **Lack of Authorization Control**: This functionality effectively allows "process execution on the server" (an administrative operation), yet no administrator-only permission checks are implemented in the code (accessible with Bearer authentication only). **Vulnerable...

### Impact Anyone who has view rights on the `Calendar.JSONService` page, including guest users can exploit this vulnerability by accessing database info or starting a DoS attack. ### Workarounds Remove the `Calendar.JSONService` page. This will however break some functionalities. ### References Jira issue: * [FULLCAL-80: SQL injection through Calendar.JSONService](https://jira.xwiki.org/browse/FULLCAL-80) * [FULLCAL-81: SQL injection through Calendar.JSONService still exists](https://jira.xwiki.org/browse/FULLCAL-81) ### For more information If there are any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email [Security Mailing List](mailto:security@xwiki.org)

### Impact Anyone who has view rights on the `Calendar.JSONService` page, including guest users can exploit this vulnerability by accessing database info, with the exception of passwords. ### Workarounds Remove the `Calendar.JSONService` page. This will however break some functionalities. ### References Jira issue: * [FULLCAL-82: Calendar.JSONService exposes emails of all users](https://jira.xwiki.org/browse/FULLCAL-82) ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@xwiki.org)

A cross-site scripting (XSS) vulnerabilities was identified in October CMS backend configuration forms: - **Editor Settings Markup Styles** A user with the `Global Editor Settings` permission could inject malicious HTML/JS into the stylesheet input at *Settings → Editor Settings → Markup Styles*. A specially crafted input could break out of the intended `<style>` context, allowing arbitrary script execution across backend pages for all users. --- ### Impact - Persistent XSS across the backend interface. - Exploitable by lower-privileged accounts with the above permissions. - Potential consequences include privilege escalation, session hijacking, and execution of unauthorized actions in victim sessions. --- ### Patches The vulnerability has been patched in **v4.0.12** and **v3.7.13**. Stylesheet inputs are now sanitized to prevent injection of arbitrary HTML/JS. All users are strongly encouraged to upgrade to the latest patched version. --- ### Workarounds I...

Fastjson before 1.2.48 mishandles autoType because, when an `@type` key is in a JSON document, and the value of that key is the name of a Java class, there may be calls to certain public methods of that class. Depending on the behavior of those methods, there may be JNDI injection with an attacker-supplied payload located elsewhere in that JSON document. This was exploited in the wild in 2023 through 2025. NOTE: this issue exists because of an incomplete fix for CVE-2017-18349. Also, a later bypass is covered by CVE-2022-25845.

The Security Labs team at Snyk is reporting a security issue affecting Authlib, which was identified during a recent research project. A vulnerability has been identified that can result in a 1-click Account Takeover in applications that use the Authlib library. (5.7 CVSS v3: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N) **Description** Cache-backed state/request-token storage is not tied to the initiating user session, so CSRF is possible for any attacker that has a valid state (easily obtainable via an attacker-initiated authentication flow). When a cache is supplied to the OAuth client registry, `FrameworkIntegration.set_state_data` writes the entire state blob under `_state_{app}_{state},` and `get_state_data` ignores the caller’s session altogether. \[1\]\[2\] ```py def _get_cache_data(self, key): value = self.cache.get(key) if not value: return None try: return json.loads(value) except (TypeError, ValueError): ret...

### Summary An Authenticated Insecure Direct Object Reference (IDOR) vulnerability was identified that allows an authenticated user to retrieve other users’ address information by modifying an existing order. By editing an order they legitimately own and manipulating address identifiers in the request, the backend server accepts and processes references to addresses belonging to other users, subsequently associating those addresses with the attacker’s order and returning them in the response. ### Details Affected Component(s) - Authenticated user order management - Address association logic - Order update endpoint(s) Affected Endpoint(s): - `/api/v2/storefront/checkout` The application fails to enforce proper object-level authorization when updating an existing order. While the user is authenticated and authorized to modify their own order, the backend does not verify that the supplied address identifiers belong to the same authenticated user. ### PoC Preconditions - Valid authentic...