Search: click.edit

The HT Mega Addons for Elementor – Elementor Widgets & Template Builder plugin for WordPress is vulnerable to Stored DOM-Based Cross-Site Scripting via the 'href attribute of <a> inside .htmega-tab-nav' parameter in all versions up to, and including, 3.2.7 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. Successful exploitation requires a co-installed plugin such as wpDiscuz with its rich editor enabled whose markup allowlist permits span[class] and a[href] storage, an HT Mega Tabs widget present on the same page as the comment section, and a victim user click on the injected anchor link.

CVE-2026-118255 is a high-severity vulnerability in Highcharts Grid where an attacker controlling the Grid configuration can set the credits.href property to a javascript: URL. This URL is not validated, allowing execution of arbitrary script in the context of the hosting page when a user clicks the credits link. The vulnerability requires that untrusted data reach the Grid configuration and that a user activates the link. Patched versions 3.2.0 and 4.0.0 address this issue.

Highcharts versions prior to 11.4.9, between 12.0.0 and 12.6.1, and between 13.0.0 and 13.1.0 contain a vulnerability where the credits.href property can be set to a javascript: URL. This causes the script to run in the context of the hosting page when the credits label is clicked. An attacker controlling chart configuration can exploit this if untrusted data reaches the chart and a user clicks the credits label. Patched versions 11.4.9, 12.6.1, and 13.1.0 fix this issue.

The UiChemy – Convert Figma, Prompts and AI Builds to Elementor, Gutenberg and Bricks plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'actions[save_builder][data][elements][...][settings][slot_{N}_link][url]' parameter in all versions up to, and including, 5.3.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The injected javascript: payload fires on click rather than on page load, making exploitation contingent on a privileged user such as an Editor or Administrator clicking the attacker-crafted link while reviewing or previewing the Contributor's post.

phpMyFAQ versions from 4.2.0-alpha up to but not including 4.2.0-beta contain a stored cross-site scripting (XSS) vulnerability in the SvgSanitizer component. This flaw allows users with FAQ_EDIT permission to bypass SVG sanitization by using XML DTD custom entities, enabling injection of JavaScript in anchor href attributes. When other users view the malicious SVG and click the link, the script executes, potentially hijacking admin sessions.

n8n versions before 1.123.80, from 2.0.0 before 2.39.6, and from 2.40.0 before 2.40.1 contain a stored DOM cross-site scripting vulnerability in Resource Locator parameter dropdown link handling. Workflow authors can inject malicious script URLs that execute arbitrary JavaScript in the editor origin when other users open the node dropdown and click the external-link icon, with the payload persisting across workflow imports and shares.

## Summary Three Livewire admin components in `shopper/framework` (latest master at commit `fcd0c59`, released as v2.8.0) gate state-mutating actions on the read-only `view_users` permission. This is the same class as the issue Shopper fixed in v2.8.0 / PR #511 / [GHSA-f946-9qp6-vgch](https://github.com/shopperlabs/shopper/security/advisories/GHSA-f946-9qp6-vgch) — the PR moved most write actions from `view_users` to `access_setting`, but three were missed (one of them is a brand-new file added by the security commit itself). A staff user holding only `view_users` + `access_dashboard` (a realistic "support" or "viewer" role per Shopper's own `PermissionsTableSeeder`) can: (1) self-escalate by granting any permission to their own role; (2) create a brand-new admin team member with a chosen password and the `admin` role and then log in as that user; (3) delete arbitrary `permissions` rows (RBAC DoS) or — when `can_be_removed=true` — delete entire roles. CVSS 3.1: `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` = 8.8 (High). CWE-285 (Improper Authorization) + CWE-862 (Missing Authorization). ## Vulnerable components (paths relative to repo root) ### 1) `packages/admin/src/Livewire/Components/Settings/Team/Permissions.php` - `togglePermission(int $id)` at line 28 calls `$this->authorize('view_users');` - `removePermission(int $id)` at line 55 calls `$this->authorize('view_users');` The Permissions blade at `packages/admin/resources/views/livewire/components/settings/team/permissions.blade.php` line 34 emits every permission's `id` directly in `wire:click` handlers, so the attacker does not even need to guess IDs — the page itself enumerates them. Net effect: any user who can mount the Permissions component (gated on `view_users`) can grant any permission row to the bound `$role`. Granting `access_setting` to the attacker's own role unlocks every action that PR #511 supposedly hardened with `->authorize('access_setting')`. Granting `delete_customers`, `edit_orders`, `edit_products`, `add_brands`, etc. is direct data-modification escalation. ### 2) `packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php` - `mount()` at line 53 calls `$this->authorize('view_users');` - `store()` at line 122 calls `$this->authorize('view_users');` This file is `new file mode 100755` in commit `fcd0c59` — it was created as part of the security fix and inherited the same misclassified gate. `store()` creates a `User` with `email_verified_at = now()`, the attacker's chosen password, and any selected `role_id`. The `Radio::make('role_id')` options filter only excludes `config('shopper.admin.roles.user')`, so the `admin` role is selectable. Log out, log in as the new account → full admin. ### 3) `packages/admin/src/Livewire/Pages/Settings/Team/RolePermission.php` - `deleteAction` at lines 81-90: only gated by `->visible($this->role->can_be_removed)`, with no `->authorize()` chain. Page-level `mount` (line 52) requires only `view_users`. For any role with `can_be_removed = true`, a `view_users`-only user can call the action and delete the role (cascading the loss of permissions for every assigned user). ## Self-confirmation in the project's own test suite The following tests are green on master @ `fcd0c59` — they ARE the PoC: ``` tests/Admin/Livewire/Components/Settings/Team/PermissionsTest.php line 14-16: `givePermissionTo('view_users')` only line 36-45: "can toggle permission to role" — passes line 74-85: "can remove permission" — passes tests/Admin/Livewire/SlideOvers/CreateTeamMemberTest.php line 16-18: `givePermissionTo('view_users')` only line 29-56: "can create new team member" — passes, asserts the new user `hasRole('manager')` ``` A `view_users`-only Livewire user actor successfully toggles permissions, removes permissions, and creates a new privileged user — verified by Shopper's own regression tests. ## Suggested fix Change `$this->authorize('view_users')` to `$this->authorize('access_setting')` in: - `Permissions::togglePermission` - `Permissions::removePermission` - `Permissions::mount` (defence in depth, matches `Team\Index`) - `CreateTeamMember::mount` - `CreateTeamMember::store` Add `->authorize('access_setting')` to `RolePermission::deleteAction` (matches the pattern already applied to `generatePermissionsAction`, `createPermissionAction`, and `Team\Index::DeleteAction`). Update the two regression tests to use `access_setting` instead of `view_users` so they accurately reflect the privilege boundary. ## Resources - Prior advisory of the same class: https://github.com/shopperlabs/shopper/security/advisories/GHSA-f946-9qp6-vgch - Fix commit that introduced these residual gaps: https://github.com/shopperlabs/shopper/commit/fcd0c5920588702df5b874f432b1042abd77a50b - CWE-285 Improper Authorization - CWE-862 Missing Authorization ### Credits Reported by Vishal Shukla(@shukla304) using sechub.dev AI Agent ### Support If this disclosure was useful and if users would like to support continued o

CVE-2026-17033 is a vulnerability in Grafana where an authenticated attacker with Editor access or alert.instances.external:write permission can submit an external Alertmanager alert containing a crafted generatorURL. This URL is rendered without proper URL-scheme sanitization or a safe-protocol allowlist, allowing bypass of click interception heuristics. When a user with read access clicks the 'See source' link, attacker-controlled JavaScript executes in the context of the Grafana origin with the user's permissions.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (7faefbcd9110b5e08b469d72d6541875ba4e2702c4490d1a24c37b313160f86b) env-local presents itself as a dotenv-compatible.env loader (README, keywords, and API mirror motdotla/dotenv), but lib/main.js unconditionally requires lib/tui-options.js, which activates a full-host spyware payload on module load. tui-options.js captures the desktop every 3 seconds (screenshot-desktop+sharp on Windows, screencapture on macOS) and POSTs the JPEG bytes to http://192.99.204.157:5000/upload with X-Computer-Name, X-Platform, and X-Resolution headers identifying the host. In parallel, a 1-second interval polls http://192.99.204.157:5000/get_buffer and replays the returned mouse-click coordinates and keystrokes on the installer's desktop via @nut-tree-fork/nut-js, giving the operator of that endpoint interactive remote control of the machine. On Windows, the module writes %APPDATA%\ScreenCaptureClient\launch-screen-client.vbs and registers HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ScreenCaptureClient via reg.exe to invoke the launcher with wscript.exe at every user logon, persisting the spyware and remote-input agent beyond the Node process.

Security experts have been sounding the alarm for years about the risks of using generic TV boxes that promise unlimited content streaming for a one-time fee, warning that they secretly rent the user’s Internet connection out to strangers. But a groundbreaking new analysis finds these devices also routinely spoof themselves as mobile phones clicking ads on AI-generated websites as part of a sprawling operation that seeks to defraud online merchants and advertising networks. Pedro Falé is a threat researcher with the security firm Bitsight . Falé told KrebsOnSecurity he was able to peer inside a vast and complex ad fraud network by registering an expired domain name that was used to coordinate fake ad clicks across a particularly popular brand of these streaming devices known as H96 . An H96 TV streaming device currently advertised for sale on Amazon. Falé said the domain he scooped up was previously used for telemetry, periodically collecting full hardware information and the entire list of installed apps from tens of thousands of H96 streaming sticks plugged into television sets around the globe. But upon inspecting the traffic being funneled to the domain, he discovered nearly all of the TV boxes transmitting data claimed to be mobile phone models from a variety of manufacturers, including Samsung, Vivo, Huawei, and Xiaomi. “We noticed something was wildly wrong,” Falé said. “Multiple devices reporting to this factory Android TV Box backdoor were ‘phones.'” Image: Bitsight. The researcher found all of the devices reported having the same two apps installed, and that those apps were made by a company called Zhejiang Fengwo IoT Technology Ltd , an entity founded in 2019 in mainland China which operates an ad-publishing portfolio under the name Fengwo Group . Further investigation into the Fengwo Group revealed it has registered multiple patents that match the inner workings of these apps. “Bitsight TRACE identified several Hong Kong, Singapore, and single person ‘legal’ shell identities used to collect the monetization and traced the operation back to a mainland China company known as Zhejiang Fengwo IoT Technology Co., Ltd, which operates under the Fengwo Group,” Falé wrote in a report released today about their findings. Falé said an analysis of the apps shows they help to coordinate an ad fraud network that uses these H96 devices as a captive traffic source to click on ads at AI-generated websites operated by the Fengwo Group. Bitsight discovered the websites contain machine-generated news articles and graphics across a range of categories, including finance, health, education, gaming, music and food blogs. But they also found none of those sites displayed ads unless the device visiting the page matched the spoofed mobile profile of these H96 devices. AI DIGITAL HUMANS The domain for the Fengwo Group — fwgcloud[.]com — claims the company is “redefining the boundaries of human-AI interaction,” and that it has created more than 120,000 “AI digital humans” available to rent for everything from emotional companionship to 24/7 customer service and creative design. The homepage for fwgcloud dot com. Falé said the Fengwo Group’s domain shared its SSL certificate data with other domains associated with the apps found on H96 devices, specifically the phone spoofing mechanism. He noted the domain also has an internal wiki platform that directly ties the Fengwo Group to a proprietary implementation of a Google-built visual programming language called Blockly , which was originally designed to help kids learn how to write software. According to Bitsight, the Fengwo Group’s employees use Blockly to build the sham websites, allowing low-skilled operators to drag blocks of code together in their Blockly editor — without any need to understand what the underlying code blocks do or how they work. The Blockly homepage. “An operator can drag blocks together in their Blockly editor, to define each fraud routine, given a task type,” reads Bitsi…

Grist is spreadsheet software using Python as its formula language. Prior to 1.7.15, Grist contained two cross-site scripting vulnerabilities where an attacker-controlled value reached a link's href without scheme validation, so a javascript URL could run in a victim's Grist origin on a single click. On the account-selection page, /welcome/select-account used its next query parameter as the account buttons' link target. In document tours, the GristDocTour table's Link_URL column became a clickable button, allowing an editor of a shared document to store a javascript URL there that ran when another user opened the document and clicked the tour link. Because the script runs in the victim's authenticated session, it can call Grist APIs as the victim, reading or modifying data and changing sharing settings and access rules. A document editor could therefore escalate to owner-level access. This issue is fixed in version 1.7.15.

The DuneSlide vulnerabilities enable zero-click prompt injection attacks that escape Cursor's sandbox and execute arbitrary code on the underlying operating system. The post Critical Cursor AI Code Editor Flaws Could Lead to OS-Level Remote Code Execution appeared first on SecurityWeek .

# Potential XSS in HTML session exports via Markdown URL handling Pi HTML exports render session Markdown into a static HTML file. Affected versions did not consistently reject unsafe Markdown link and image URL schemes. In versions with scheme filtering, C0 control characters in the URL scheme could bypass the check because browsers normalize those characters before navigation. ## Impact The realistic attack path is indirect. An attacker would need to get suitable Markdown into a session, for example through prompt injection that causes the model to include an unsafe link, or through other untrusted session content. The user would then need to export the session as HTML, open or share that file, and click the link. If triggered, script runs in the exported document, not in pi or the user's shell. The main risk is limited disclosure of data embedded in that exported session file. ## Affected versions - Affected: `@mariozechner/pi-coding-agent >= 0.27.5, <= 0.73.1` - Affected: `@earendil-works/pi-coding-agent >= 0.74.0, < 0.78.1` - Patched: `@earendil-works/pi-coding-agent 0.78.1` The old `@mariozechner/pi-coding-agent` package scope has no patched release. It was renamed to `@earendil-works/pi-coding-agent`; users of the old scope should migrate to the new package and upgrade to version 0.78.1 or later. ## Resolution Version 0.78.1 sanitizes Markdown link and image URLs with an allow-list after stripping C0 control characters. ## Recommendations Upgrade `@earendil-works/pi-coding-agent` to version 0.78.1 or later. Regenerate shared HTML exports after upgrading if the underlying sessions contained untrusted content. ## Timeline - 2026-05-29: Report received through GitHub Security Advisories - 2026-06-02: Fix committed - 2026-06-04: Fixed version 0.78.1 released - 2026-06-08: Advisory prepared for publication ## Credits Reported by Paul Urian and Cosmin Alexa of CrowdStrike.

## Overview of all XSS Reports Multiple stored XSS vulnerabilities were found in Craft CMS. They were split into **4 reports** as follows: | Report | What's Vulnerable | Why Separate | |--------|-------------------|--------------| | **This Report (1)** | Multiple settings names | Twig Template: `_includes/forms/checkbox.twig` | | **Report 2** | Entry Types Name | Twig Template: `_includes/forms/editableTable.twig` | | **Report 3** | Card Attributes in Field Layout | `helpers/Cp.php` | | **Report 4 (Commerce)** | Product Type Name | Source in Commerce, sink in CMS - will report this one via Commerce GHSA | Reports 2, 3, and 4 are clearly distinct locations. For this report (Report 1), it was not clear whether to split or consolidate these 7 bugs. The bug report was consolidated and the final categorization should be left to the judgement of the user. **Note:** This overview is only in this Report. Other reports only reference this one. --- ## Summary Stored XSS in multiple settings. Names/labels are rendered without sanitization via `checkbox.twig` template which uses `{{ label|raw }}`. --- ## Affected Sources | # | Source (injection point) | Sink (where payload reflects) | | --- | ------------------------------------------------------------------------ | --------------------------------------------- | | 1 | Section Name (`/admin/settings/sections`) | Entries field -> Sources checklist | | 2 | Volume Name (`/admin/settings/assets/volumes/{vol_id}`) | Assets field -> Sources checklist | | 3 | User Group Name (`/admin/settings/users/groups`) | Users field -> Sources, User permissions page | | 4 | Global Set Name (`/admin/settings/globals`) | User permissions page | | 5 | Generated Fields Name (Volumes, Users, etc.) | Card Attributes checkboxes | | 6 | Checkboxes & Radio Buttons Field Option Label (`/admin/settings/fields`) | User profile pages | | 7 | Custom Sources Label (`/admin/users` -> Customize Sources) | Users field -> Sources checklist | --- ## Proof of Concept ### Required Permissions (Attacker) - Admin access - `allowAdminChanges` is enabled in production, which is against our [security recommendations](https://craftcms.com/knowledge-base/securing-craft). ### Bugs 1-3: Section, Volume, User Group Names 1. Log in as admin. 2. Inject payload in one of these: - **Settings** -> **Sections** -> Create/edit section -> **Name** - **Settings** -> **Assets** -> **Volumes** -> Create/edit volume -> **Name** - **Settings** -> **Users** -> **User Groups** -> Create/edit group -> **Name** 3. Set **Name** to: ```html <img src=x onerror="alert('XSS')"> ``` 4. Save. 5. Go to **Settings** -> **Fields** -> Create new field. 6. To trigger the XSS payload: Set **Field Type** to "Entries" (for Sections), "Assets" (for Volumes), or "Users" (for User Groups). The alert fires when the Sources checkbox list renders. **Note:** User Group Name also reflects on **User permissions page** under **User Groups** section (`/admin/users/{id}/permissions`). --- ### Bug 4: Global Set Name 1. Go to **Settings** -> **Globals** (`/admin/settings/globals`). 2. Create/edit a Global Set, set **Name** to payload. 3. Save. 4. Go to **Users** -> Edit any user -> **Permissions** tab (`/admin/users/{id}/permissions`). 5. Alert fires because our payload got rendered in the "Global Sets" permissions section without encoding/sanitization. --- ### Bug 5: Generated Fields Name 1. Go to **Settings** -> **Assets** -> **Volumes** -> Create/Edit a volume. 2. Scroll to **Generated Fields** section. 3. Add a field, set **Name** to payload: ```html <img src=x onerror="alert('XSS')"> ``` 4. Save & Notice the alert. The payload renders in the **Card Attributes** checkbox list below it. --- ### Bug 6: Checkboxes/Radio Buttons Option Label 1. Go to **Settings** -> **Fields** (`/admin/settings/fields`). 2. Create new field, set **Field Type** to "Checkboxes" or "Radio Buttons". 3. In **Field Options**, add an option with **Label** set to payload. 4. Save the field. 5. Go to **Settings** -> **Users** -> **User Profile Fields** (`/admin/settings/users/fields`). 6. Add the created field to the layout and save. 7. Alert fires on any user profile page (`/admin/users/{id}`). --- ### Bug 7: Custom Sources Label 1. Go to **Users** (`/admin/users`). 2. Click the three dots icon -> **Customize Sources**. 3. Create a new custom source, set **Label** to payload. 4. Save. 5. Go to **Settings** -> **Fields** -> Create new field. 6. Set **Field Type** to "Users". 7. Alert fires in the Sources checkbox list. ## Resources https://github.com/craftcms/cms/commit/943152d2246b36f12adf161a03b8695b773d9276 https://github.com/cr

## Summary A stored XSS vulnerability exists in the User Permissions page. The User Group name is rendered without proper HTML escaping in the permissions section, allowing an attacker to execute arbitrary JavaScript when another user views or edits a user's permissions. > [!NOTE] > This is a separate vulnerability from the previously reported "[Stored XSS via User Group Name in User Settings Page](https://github.com/craftcms/cms/security/advisories/GHSA-2423-8xxj-wc3g)" and "[Multiple Stored XSS in User Group Edit Page](https://github.com/craftcms/cms/security/advisories/GHSA-vx7g-xw92-g4xj)". This affects a different sink: the individual user's permissions page. ## Proof of Concept ### Required Permissions - Admin access - `allowAdminChanges` is enabled in production, which is against our [security recommendations](https://craftcms.com/knowledge-base/securing-craft). ### Steps to Reproduce 1. Log in to the control panel as an admin 2. Navigate to **Settings → Users → User Groups** 3. Create or edit a user group and set the **Name** field to: ```html <img src=x onerror="alert('XSS')" hidden> ``` 4. Save the user group 5. Navigate to **Users** and edit any user (`/admin/users/{id}`) 6. Click on the **Permissions** tab 7. XSS executes ## Mitigation Sanitize user group names when rendering in the user permissions template. ## References https://github.com/craftcms/cms-ghsa-4mgv-366x-qxvx/pull/2

## Summary sanitize-html uses `allowedSchemesAppliedToAttributes` (default: `['href', 'src', 'cite']`) to gate the `naughtyHref()` function that blocks dangerous URI schemes like `javascript:` and `vbscript:`. The HTML specification defines 10+ attributes that accept URIs (`action`, `formaction`, `data`, `poster`, `background`, `ping`, `xlink:href`, `dynsrc`, `lowsrc`), but none of these are included in the default gate list. When a developer allows any of these attributes in their configuration, `javascript:` URIs pass through completely unmodified, enabling XSS. The library has zero awareness of these URI-bearing attributes — none appear anywhere in the 854-line source file (verified by grep). No warning mechanism exists, and the README provides no security guidance about expanding `allowedSchemesAppliedToAttributes` when allowing form or media attributes. ## Severity Exploitation requires non-default configuration: the developer must explicitly allow a non-default tag (e.g., `form`) AND a non-default attribute (e.g., `action`). Default configuration is NOT vulnerable. However, this is a common configuration pattern for CMS platforms, form builders, and rich content editors. ## Affected Versions All versions of sanitize-html from v1.18.0 (which introduced `allowedSchemesAppliedToAttributes`) through at least v2.17.2. The default list has been `['href', 'src', 'cite']` since introduction and has never been expanded. ## Root Cause **File**: `index.js:329` (sanitize-html 2.10.0, confirmed same in 2.17.x) ```javascript // Line 329 — The gate that controls scheme validation if (options.allowedSchemesAppliedToAttributes.indexOf(a) >= 0) { if (naughtyHref(name, value)) { delete frame.attribs[a]; return; } } ``` **Default list at line 829**: ```javascript allowedSchemesAppliedToAttributes: ['href', 'src', 'cite'], ``` The `naughtyHref()` function (lines 627-667) correctly blocks `javascript:`, `vbscript:`, and other dangerous schemes. However, it has exactly 2 call sites in the entire codebase (lines 330 and 395), both inside the `indexOf` gate. There is no ungated path. When attribute name is `action`, `formaction`, `data`, `poster`, `background`, etc.: - `indexOf('action')` returns `-1` - The `if` block is skipped entirely - `naughtyHref()` is never called - `javascript:alert(1)` passes through unmodified The `escapeHtml()` function at line 464 provides no defense — it only encodes `& < > "` characters, which are not present in `javascript:alert(1)`. **Data Flow**: ``` Attacker input: <form action="javascript:alert(document.cookie)"> 1. htmlparser2 parses → tag='form', attribs={action:'javascript:alert(document.cookie)'} 2. index.js:298 → allowedAttributes check: 'action' in developer config → PASS 3. index.js:329 → ['href','src','cite'].indexOf('action') → -1 → SKIP naughtyHref() 4. index.js:464 → escapeHtml('javascript:alert(document.cookie)') → unchanged 5. OUTPUT: <form action="javascript:alert(document.cookie)"> ``` ## Steps to Reproduce ```javascript const sanitize = require('sanitize-html'); // ===== VECTOR 1: form action (100% reliable, all modern browsers) ===== const v1 = sanitize( '<form action="javascript:alert(document.cookie)"><button>Submit</button></form>', { allowedTags: ['form', 'button'], allowedAttributes: { form: ['action'] } } ); console.log('V1 (action):', v1); // OUTPUT: <form action="javascript:alert(document.cookie)"><button>Submit</button></form> // XSS triggers when user submits the form // ===== VECTOR 2: button formaction (100% reliable) ===== const v2 = sanitize( '<button formaction="javascript:alert(1)">Click</button>', { allowedTags: ['button'], allowedAttributes: { button: ['formaction'] } } ); console.log('V2 (formaction):', v2); // OUTPUT: <button formaction="javascript:alert(1)">Click</button> // ===== VECTOR 3: object data ===== const v3 = sanitize( '<object data="javascript:alert(1)"></object>', { allowedTags: ['object'], allowedAttributes: { object: ['data'] } } ); console.log('V3 (data):', v3); // OUTPUT: <object data="javascript:alert(1)"></object> // ===== CONTROL: href IS scheme-checked (expected behavior) ===== const ctrl = sanitize( '<a href="javascript:alert(1)">click</a>', { allowedTags: ['a'], allowedAttributes: { a: ['href'] } } ); console.log('Control (href):', ctrl); // OUTPUT: <a>click</a> ← href correctly stripped by naughtyHref() ``` **Observed behavior**: `javascript:` preserved on `action`/`formaction`/`data` but correctly stripped on `href`. **Expected behavior**: `javascript:` should be stripped on ALL URI-bearing attributes, or at minimum, the library should warn developers when they allow URI-bearing attributes not covered by scheme validation. ## Impact An attacker can achieve XSS in applications that use sanitize-html with non-default configurations allowing URI-bearing attributes: - `<for

A large-scale phishing campaign has been targeting U. S.banking users since November 2025 by impersonating ESL Federal Credit Union and potentially other financial institutions. The campaign uses a multi-step phishing flow to steal usernames, passwords, one-time passwords (OTPs), and email verification data, increasing the risk of account takeover and fraud. It employs over 230 phishing domains with rotating infrastructure, primarily in . sbs, . cfd, and . click domains. Victim data is exfiltrated through chained POST requests and forwarded to attacker-controlled Telegram bots. The campaign remains active with reusable phishing page assets and endpoint structures, making it trackable despite frequent domain changes.

This CVE record was assigned not following CNA/CVE rules and is not considered a valid vulnerability by the Pallets Click project. The original CVE record description is preserved below: Pallets Click, versions 8.3.2 and below, contain a command injection vulnerability in the click.edit() function, allowing attackers to pass arbitrary OS commands from an unprivileged account.

GFI HelpDesk before 4.99.10 contains a stored cross-site scripting vulnerability in the Reports module where the title parameter is passed directly to SWIFT_Report::Create() without HTML sanitization. Attackers can inject arbitrary JavaScript into the report title field when creating or editing a report, and the payload executes when staff members view and click the affected report link in the Manage Reports interface.