#js

### 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...

## LFS Lock Force-Delete Authorization Bypass ### Summary An authorization bypass in the LFS lock deletion endpoint allows any authenticated user with repository write access to delete locks owned by other users by setting the `force` flag. The vulnerable code path processes force deletions before retrieving user context, bypassing ownership validation entirely. ### Severity - **CWE-863:** Incorrect Authorization - **CVSS 3.1:** 5.4 (Medium) — `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L` ### Affected Code **File:** `pkg/web/git_lfs.go` **Function:** `serviceLfsLocksDelete` (lines 831–945) **Endpoint:** `POST /<repo>.git/info/lfs/locks/:lockID/unlock` The control flow processes `req.Force` at line 905 before retrieving user context at line 919: ```go // Line 905-916: Force delete executes immediately without authorization if req.Force { if err := datastore.DeleteLFSLock(ctx, dbx, repo.ID(), lockID); err != nil { // ... } renderJSON(w, http.StatusOK, l) ...

A XSS vulnerability exists in in React Router's `meta()`/`<Meta>` APIs in [Framework Mode](https://reactrouter.com/start/modes#framework) when generating `script:ld+json` tags which could allow arbitrary JavaScript execution during SSR if untrusted content is used to generate the tag. > [!NOTE] > This does not impact applications using [Declarative Mode](https://reactrouter.com/start/modes#declarative) (`<BrowserRouter>`) or [Data Mode](https://reactrouter.com/start/modes#data) (`createBrowserRouter`/`<RouterProvider>`).

## Summary A flawed `deny_only` short-circuit in RustFS IAM allows a restricted service account or STS credential to self-issue an unrestricted service account, inheriting the parent’s full privileges. This enables privilege escalation and bypass of session/inline policy restrictions. ## Details **akin to MinIO CVE-2025-62506** - Policy evaluation: `Policy::is_allowed` returns true when `deny_only=true` if no explicit Deny is hit, skipping all Allow checks (`crates/policy/src/policy/policy.rs:66-74`). - Service account creation path sets `deny_only=true` when the target user equals the caller or its parent (`rustfs/src/admin/handlers/service_account.rs:114-127`). - Service accounts are created without `session_policy` by default, so claims lack `SESSION_POLICY_NAME`; combined with `deny_only`, self-operations are allowed without Allow statements. - Result: a limited service account/STS can create a new service account without policy and obtain the parent’s full rights (even root), ...