Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows authenticated attackers with low privileges to inject malicious scripts into form fields, which execute in the browsers of users viewing those pages. The vulnerability requires user interaction and has limited scope of impact, affecting confidentiality and integrity but not availability. No patch is currently available for this medium-severity issue.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows authenticated attackers to inject malicious scripts into form fields that execute when other users view the affected pages. An attacker with low privileges and user interaction can compromise the confidentiality and integrity of victim sessions. No patch is currently available.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows authenticated attackers to inject malicious scripts into form fields that execute when other users view the affected pages. A low-privileged user can exploit this to perform actions in victim browsers or steal sensitive information, though no patch is currently available.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows authenticated attackers to inject malicious scripts into form fields that execute in victims' browsers when the affected pages are viewed. The vulnerability requires user interaction and is limited to low-impact information disclosure and modification, though it can affect multiple users due to its stored nature. No patch is currently available for this issue.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows authenticated attackers with low privileges to inject malicious scripts into form fields, which execute in victims' browsers when they access affected pages. The vulnerability requires user interaction and can result in session hijacking, credential theft, or malware distribution. No patch is currently available.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows low-privileged authenticated users to inject malicious scripts into form fields that execute in victims' browsers, potentially leading to session hijacking or credential theft. The vulnerability requires user interaction and is currently unpatched, with no active exploitation reported.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows authenticated attackers to inject malicious scripts into form fields that execute in users' browsers when the affected pages are accessed. An attacker with login credentials can craft payloads that persist in the application and compromise victim sessions or steal sensitive data. No patch is currently available.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows low-privileged authenticated users to inject malicious scripts into form fields that execute in other users' browsers when they access affected pages. An attacker can exploit this to steal session tokens, perform unauthorized actions, or deface content with minimal user interaction required. No patch is currently available for this vulnerability.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows authenticated attackers to inject malicious scripts into form fields, which execute in victims' browsers when the affected pages are accessed. An attacker with login credentials can exploit this vulnerability to steal session tokens, credentials, or perform actions on behalf of users viewing the compromised forms. No patch is currently available for this vulnerability.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows authenticated attackers to inject malicious scripts into form fields that execute when other users view the affected pages. An attacker with low privileges can exploit this vulnerability to steal session tokens, credentials, or perform actions on behalf of victims through their browsers. No patch is currently available.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows authenticated attackers to inject malicious scripts through form fields, which execute in victims' browsers when they view affected pages. The vulnerability requires user interaction and network access but can impact confidentiality and integrity across security domains. No patch is currently available.
Adobe Experience Manager 6.5.23 and earlier contains a stored XSS vulnerability in form fields that allows low-privileged authenticated users to inject malicious scripts affecting other users who view the compromised pages. When a victim browses to a page containing the injected payload, the malicious JavaScript executes in their browser context, potentially enabling session hijacking or credential theft. No patch is currently available.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier allows authenticated attackers to inject malicious scripts into form fields, which execute in victims' browsers when they view affected pages. This requires user interaction and an authenticated attacker, but could compromise the confidentiality and integrity of user sessions. No patch is currently available.
Stored XSS in Adobe Experience Manager 6.5.23 and earlier enables authenticated attackers to inject malicious scripts into form fields that execute when users view affected pages. An attacker with login credentials can compromise victim browsers and steal sensitive data or perform actions on their behalf. No patch is currently available.
Stored cross-site scripting in OpenEMR versions prior to 8.0.0.1 allows authenticated users with Track Anything feature access to inject malicious scripts into item names that execute in the browsers of all users viewing the corresponding Dygraph charts. An attacker with create or edit permissions can craft payloads that run in victims' sessions without their knowledge, potentially enabling session hijacking or unauthorized actions within the application. No patch is currently available for affected versions.
Stored cross-site scripting (XSS) in OpenEMR prior to 8.0.0.1 allows administrators or users with code management privileges to inject malicious scripts into code descriptions that execute in the browsers of all users accessing the dynamic code picker. All OpenEMR instances running affected versions are at risk, as any authenticated admin can inject payloads affecting the entire user base. No patch is currently available for this vulnerability.
Stored XSS in OpenEMR's Pain Map form prior to version 8.0.0.1 allows authenticated users to inject malicious JavaScript into encounter records that executes when other clinicians view the affected form. Since session cookies lack HttpOnly protection, attackers can hijack sessions of other users including administrators. This vulnerability requires user interaction and network access but poses significant risk in multi-user healthcare environments.
Plunk is an open-source email platform built on top of AWS SES. versions up to 0.7.1 is affected by cross-site scripting (xss) (CVSS 5.4).
Stored XSS in Notesnook Mobile and Desktop versions prior to 3.3.9 allows authenticated users to execute arbitrary JavaScript by injecting malicious code into Twitter/X embed URLs through the editor component. An attacker with user account access can craft a malicious note containing a specially crafted embed URL that executes when the note is viewed, potentially compromising user data or session tokens. No patch is currently available for affected versions.
Improper access control in the Discover Splunk Observability Cloud app allows low-privileged users without admin or power roles to retrieve Observability Cloud API access tokens in Splunk Enterprise versions below 10.2.1/10.0.4 and Splunk Cloud Platform versions below 10.2.2510.5/10.1.2507.16/10.0.2503.12. An attacker with low-level credentials could leverage this to obtain API tokens for unauthorized access to Observability Cloud resources. No patch is currently available.
Security feature bypass in Adobe Commerce and Magento versions 2.4.4-p16 through 2.4.9-alpha3 results from improper input validation, allowing unauthenticated remote attackers to compromise the integrity of affected systems without user interaction. The vulnerability affects multiple product lines including Commerce B2B, with no patch currently available. The medium severity rating reflects limited impact scope, though the network-accessible attack vector presents a meaningful risk to exposed instances.
Denial-of-service attacks against Adobe Commerce and Magento B2B versions 2.4.4 through 2.4.9-alpha3 are possible through improper input validation that fails to sanitize malicious payloads. An unauthenticated remote attacker can trigger application unavailability by sending specially crafted requests without requiring user interaction. No security patch is currently available for this vulnerability.
Incorrect authorization controls in Adobe Commerce versions 2.4.9-alpha3 through 2.4.4-p16 allow unauthenticated remote attackers to bypass security features and gain unauthorized read access to sensitive data without user interaction. The vulnerability stems from improper access restrictions and could expose confidential information across affected Magento Commerce and Commerce B2B deployments. No patch is currently available to remediate this issue.
Parse Server versions before 8.6.34 and 9.6.0-alpha.8 leak user registration status through differential error responses on the email verification endpoint, enabling attackers to enumerate valid email addresses in the system when email verification is enabled. Deployments with verifyUserEmails set to true are vulnerable to this user enumeration attack, which allows an attacker to systematically identify registered accounts by analyzing response codes from the /verificationEmailRequest endpoint. No patch is currently available for affected installations.
Shopware's Store API login endpoint (POST /store-api/account/login) leaks information about registered customer accounts by returning distinct error messages and echoing email addresses based on whether credentials belong to known users, enabling unauthenticated attackers to enumerate valid customer accounts. The vulnerability affects versions prior to 6.7.8.1 and 6.6.10.15, while the storefront login controller properly mitigates this issue, indicating inconsistent security controls. No patch is currently available.
### Summary The ha-mcp OAuth consent form (beta feature) accepts a user-supplied `ha_url` and makes a server-side HTTP request to `{ha_url}/api/config` with no URL validation. An unauthenticated attacker can submit arbitrary URLs to perform internal network reconnaissance via an error oracle. Two additional code paths in OAuth tool calls (REST and WebSocket) are affected by the same primitive. The primary deployment method (private URL with pre-configured `HOMEASSISTANT_TOKEN`) is not affected. ### Details **Code path 1 - Consent form validation** (reported) When a user submits the OAuth consent form, `_validate_ha_credentials()` (`provider.py`) makes a server-side GET request to `{ha_url}/api/config` with no scheme, IP, or domain validation. Different exception types produce distinct error messages, creating an error oracle: | Outcome | Message returned | Information leaked | |---------|------------------|--------------------| | `ConnectError` | "Could not connect..." | Host down or port closed | | `TimeoutException` | "Connection timed out..." | Host up, port filtered | | HTTP 401 | "Invalid access token..." | Service alive, requires auth | | HTTP 403 | "Access forbidden..." | Service alive, forbidden | | HTTP ≥ 400 | "Failed to connect: HTTP {N}" | Service alive, exact status | An attacker can drive the flow programmatically: register a client via open DCR (`POST /register`), initiate authorization, extract a `txn_id`, and submit arbitrary `ha_url` values. No user interaction required. **Code path 2 - REST tool calls with forged token** OAuth access tokens are stateless base64-encoded JSON payloads (`{"ha_url": "...", "ha_token": "..."}`). Since tokens are not signed, an attacker can forge a token with an arbitrary `ha_url`. REST tool calls then make HTTP requests to hardcoded HA API paths on that host (`/config`, `/states`, `/services`, etc.). JSON responses are returned to the caller. In practice, path control is limited - most endpoints use absolute paths that ignore the `ha_url` path component. Useful exfiltration requires the target to return JSON at HA API paths, which is unlikely for non-HA services. **Code path 3 - WebSocket tool calls with forged token** The same forged token triggers WebSocket connections to `ws://{ha_url}/api/websocket`. The client follows the HA WebSocket handshake protocol (waits for `auth_required`, sends `auth`, expects `auth_ok`). Non-HA targets fail at the protocol level and return nothing useful. Realistic exploitation is limited to pivoting to another HA instance on the internal network. ### Impact **Confirmed:** Internal network reconnaissance via error oracle (all 3 code paths). An attacker can map reachable hosts and open ports from the server's network position. ### Scope OAuth mode is a **beta** feature, documented separately in `docs/OAUTH.md` and not part of the main setup instructions. The standard deployment method (pre-configured `HOMEASSISTANT_URL` and `HOMEASSISTANT_TOKEN`) is not affected. ### Fix Upgrade to 7.0.0
Insufficient policy enforcement in DevTools in Google Chrome versions up to 146.0.7680.71 contains a security vulnerability.
Insufficient policy enforcement in PDF in Google Chrome versions up to 146.0.7680.71 contains a security vulnerability.
Unsafe navigation in Navigation in Google Chrome on iOS versions up to 146.0.7680.71 contains a security vulnerability.
Unbounded memory consumption in Quill's Apple notarization process allows denial of service when HTTP responses lack size validation, affecting environments with TLS-intercepting proxies or compromised certificate authorities where response manipulation is possible. An attacker positioned to intercept or modify notarization API responses can return arbitrarily large payloads to exhaust memory and crash the signing process. This impacts corporate networks and environments with trust boundary violations, though exploitation is not feasible under standard HTTPS conditions with proper certificate validation.
Lenovo Filez fails to properly validate SSL/TLS certificates, enabling network-positioned attackers to intercept encrypted communications and extract sensitive user information. The vulnerability requires an adjacent network position and specific conditions to exploit, but affects all users of the application. No patch is currently available.
Quill before v0.7.1 contains a server-side request forgery vulnerability in its Apple notarization log retrieval functionality that fails to validate URL schemes and destination hosts. Exploitation requires an attacker to intercept or modify API responses, making it primarily a threat in environments with TLS-intercepting proxies, compromised certificate authorities, or other trust boundary violations. An attacker could redirect notarization requests to internal or multicast addresses, potentially exposing sensitive information or accessing restricted resources.
Frappe is a full-stack web application framework. versions up to 14.100.1 is affected by server-side request forgery (ssrf) (CVSS 5.0).
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 8.11 versions up to 18.7.6 contains a security vulnerability (CVSS 5.0).
Stored XSS in Adobe Commerce versions 2.4.9-alpha3 through 2.4.4-p16 allows high-privileged attackers to inject malicious scripts into form fields that execute when victims view the affected pages. The vulnerability requires attacker credentials and user interaction but could compromise session security and steal sensitive data across multiple Commerce deployments. No patch is currently available for affected versions.
Craft Commerce versions prior to 4.11.0 and 5.6.0 contain an IDOR vulnerability in the cart functionality that allows unauthenticated attackers to access and modify arbitrary shopping carts by guessing or knowing their 32-character identifiers. The CartController fails to validate cart ownership, enabling attackers to hijack active shopping sessions and potentially access sensitive customer information. No patch is currently available for affected versions.
Supabase Auth allows remote attackers to hijack user sessions by crafting fraudulent ID tokens when Apple or Azure OAuth providers are configured, enabling unauthorized access to victim accounts without requiring user interaction. An attacker can forge a valid JWT token for any target email address and exchange it at the token endpoint to obtain legitimate session credentials, effectively impersonating arbitrary users. This affects organizations using Supabase with Apple or Azure authentication enabled, with no patch currently available to remediate the vulnerability.
Incorrect authorization controls in Adobe Commerce versions 2.4.9-alpha3 through 2.4.4-p16 permit attackers to bypass security features and degrade data integrity and availability with no user interaction required. The vulnerability affects multiple Adobe Commerce and Magento B2B product lines, though exploitation requires specific conditions outside the attacker's direct control. No patch is currently available for this medium-severity flaw.
## Summary The REST API `createUser` endpoint uses string-based rank checks that only block creating `owner` accounts, while the Dashboard API uses `indexOf`-based rank comparison that prevents creating users at or above your own rank. This inconsistency allows an admin to create additional admin accounts via the REST API, enabling privilege proliferation and persistence. ## Details The REST API handler in `packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts:1365-1378`: ```typescript // REST API - only blocks creating 'owner' if (newUserRank === 'owner' && rank !== 'owner') { return yield* new RestAPIError({ error: 'Unauthorized to create user with owner rank', }); } if (rank === 'admin' && newUserRank === 'owner') { return yield* new RestAPIError({ error: 'Unauthorized to create user with owner rank', }); } // Missing: no check preventing admin from creating admin // newUserRank='admin' passes all checks ``` The Dashboard API handler in `_handlers/dashboard/create.ts` uses the correct approach: ```typescript // Dashboard API - blocks creating users at or above own rank const callerPerm = availablePermissionRanks.indexOf(userData.permissionLevel); const targetPerm = availablePermissionRanks.indexOf(rank); if (targetPerm >= callerPerm) { return yield* new DashboardAPIError({ error: 'Unauthorized: insufficient permissions to assign target rank', }); } ``` With `availablePermissionRanks = ['unknown', 'visitor', 'editor', 'admin', 'owner']`: - Admin (index 3) creating admin (index 3): `3 >= 3` = blocked in Dashboard - In REST API: no such check - allowed ## PoC ```bash # 1. Use an admin-level API token # 2. Create a new admin user via REST API curl -X POST 'http://localhost:4321/studiocms_api/rest/v1/secure/users' \ -H 'Authorization: Bearer <admin-api-token>' \ -H 'Content-Type: application/json' \ -d '{ "username": "rogue_admin", "email": "rogue@attacker.com", "displayname": "Rogue Admin", "rank": "admin", "password": "StrongP@ssw0rd123" }' # Expected: 403 Forbidden (admin should not create peer admin accounts) # Actual: 200 with new admin user created ``` ## Impact - A compromised or rogue admin can create additional admin accounts as persistence mechanisms that survive password resets or token revocations - Inconsistent security model between Dashboard API and REST API creates confusion about intended authorization boundaries - Note: requires admin access (PR:H), which limits practical severity ## Recommended Fix Replace string-based checks with `indexOf` comparison in `packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts`: ```typescript // Before: if (newUserRank === 'owner' && rank !== 'owner') { ... } if (rank === 'admin' && newUserRank === 'owner') { ... } // After: const availablePermissionRanks = ['unknown', 'visitor', 'editor', 'admin', 'owner']; const callerPerm = availablePermissionRanks.indexOf(rank); const targetPerm = availablePermissionRanks.indexOf(newUserRank); if (targetPerm >= callerPerm) { return yield* new RestAPIError({ error: 'Unauthorized: insufficient permissions to assign target rank', }); } ```
### Impact An attacker with access to the master key can inject malicious SQL via crafted field names used in query constraints when Parse Server is configured with PostgreSQL as the database. The field name in a `$regex` query operator is passed to PostgreSQL using unparameterized string interpolation, allowing the attacker to manipulate the SQL query. While the master key controls what can be done through the Parse Server abstraction layer, this SQL injection bypasses Parse Server entirely and operates at the database level. This vulnerability only affects Parse Server deployments using PostgreSQL. ### Patches The fix applies proper SQL identifier escaping to field names in the query handler and hardens query field name validation to reject malicious field names for all query types. ### Workarounds There is no known workaround. ### References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-c442-97qw-j6c6 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.10 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.36
OpenClaw versions before 2026.2.17 allow privileged users with config modification access to read arbitrary files on the system through path traversal in the $include directive. An attacker in this position can exploit absolute paths, directory traversal sequences, or symlinks to access sensitive data like API keys and credentials that the OpenClaw process can read. No patch is currently available for this medium-severity vulnerability.
Improper authorization controls in Adobe Commerce versions 2.4.9-alpha3 through 2.4.4-p16 allow authenticated attackers to bypass security features and access restricted functionality without requiring user interaction. The vulnerability affects multiple Commerce and B2B product lines, enabling low-privileged users to gain unauthorized access to sensitive features. No patch is currently available for this issue.
Incorrect authorization controls in Adobe Commerce 2.4.9-alpha3 through 2.4.4-p16 permit low-privileged authenticated users to bypass security features and access restricted functionality without user interaction. The vulnerability stems from improper authorization checks that fail to enforce proper access controls. No patch is currently available for affected versions.
Incorrect authorization in Adobe Commerce 2.4.4 through 2.4.9-alpha3 allows authenticated attackers to bypass security controls and view sensitive data without user interaction. The vulnerability stems from improper access control checks that enable low-privileged users to access information they should not be able to view. Currently, no patch is available for affected versions.
Incorrect security UI in PictureInPicture in Google Chrome versions up to 146.0.7680.71 is affected by user interface (ui) misrepresentation of critical information (CVSS 4.3).
Insufficient policy enforcement in Clipboard in Google Chrome versions up to 146.0.7680.71 contains a security vulnerability.
Incorrect security UI in PictureInPicture in Google Chrome versions up to 146.0.7680.71 contains a security vulnerability.
Incorrect security UI in LookalikeChecks in Google Chrome on Android versions up to 146.0.7680.71 is affected by user interface (ui) misrepresentation of critical information (CVSS 4.3).
OpenProject prior to 17.2.0 fails to validate project membership when calculating labor costs in budget planning, allowing authenticated users to enumerate non-member employees' default billing rates. This exposure occurs both when editing budgets directly and through the cost preview calculation endpoint, potentially revealing sensitive salary information to unauthorized project users.
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 12.6 versions up to 18.7.6 contains a security vulnerability (CVSS 4.3).