#xss

New York, United States, 15th January 2026, CyberNewsWire

### Impact html2pdf.js contains a cross-site scripting (XSS) vulnerability when given a text source rather than an element. This text is not sufficiently sanitized before being attached to the DOM, allowing malicious scripts to be run on the client browser and risking the confidentiality, integrity, and availability of the page's data. Example attack vector: ```js import html2pdf from 'html2pdf.js/src/index.js'; const maliciousHTML = '<img src=x onerror="alert(document.cookie)">'; html2pdf(maliciousHTML); // or html2pdf().from(maliciousHTML); ``` ### Patches This vulnerability has been fixed in html2pdf.js@0.14.0 to sanitize text sources using DOMPurify. There are no other breaking changes in this version. ### Workarounds Users of earlier versions of html2pdf.js must safely sanitize any text before using it as a source in html2pdf.js. ### References - Initial report: https://github.com/eKoopmans/html2pdf.js/issues/865 - Fix: https://github.com/eKoopmans/html2pdf.js/pull/877, [v0....

### Summary A malicious website can abuse the server URL override feature of the OpenCode web UI to achieve cross-site scripting on `http://localhost:4096`. From there, it is possible to run arbitrary commands on the local system using the `/pty/` endpoints provided by the OpenCode API. ### Code execution via OpenCode API - The OpenCode API has `/pty/` endpoints that allow spawning arbitrary processes on the local machine. - When you run `opencode` in your terminal, OpenCode automatically starts an HTTP server on `localhost:4096` that exposes the API along with a web interface. - JavaScript can make arbitrary same-origin `fetch()` requests to the `/pty/` API endpoints. Therefore, JavaScript execution on `http://localhost:4096` gets you code execution on local the machine. ### JavaScript execution on localhost:4096 The markdown renderer used for LLM responses will insert arbitrary HTML into the DOM. There is no sanitization with DOMPurify or even a CSP on the web interface to pre...

### Summary Stored XSS Leading to Account Takeover ### Details The Exploit Chain: 1.Upload: The attacker uploads an `.html` file containing a JavaScript payload. 2.Execution: A logged-in administrator is tricked into visiting the URL of this uploaded file. 3.Token Refresh: The JavaScript payload makes a `fetch` request to the `/system/api/refreshAccessToken` endpoint. Because the administrator is logged in, their browser automatically attaches the `haxcms_refresh_token` cookie to this request. 4.JWT Theft: The server validates the refresh token and responds with a new, valid JWT access token in the JSON response. 5.Exfiltration: The JavaScript captures this new JWT from the response and sends it to an attacker-controlled server. 6.Account Takeover: The attacker now possesses a valid administrator JWT and can take full control of the application. Vulnerability recurrence: <img width="1198" height="756" alt="image" src="https://github.com/user-attachments/assets/7062d542-702e-4cbe-849...

Improper neutralization of input during web page generation ('cross-site scripting') in Microsoft Office SharePoint allows an authorized attacker to perform spoofing over a network.

### Prologue These vulnerabilities have been found and chained by DCODX-AI. Validation of the exploit chain has been confirmed manually. ### Summary A persistent stored cross-site scripting (XSS) vulnerability exists in the custom_hotkeys functionality of the application. An authenticated attacker (or one who can trick a user/administrator into updating their custom_hotkeys) can inject JavaScript code that executes in other users’ browsers when those users load any page using the `templates/base.html` template. Because the application exposes an API token endpoint (`/api/current-user/token`) to the browser and lacks robust CSRF protection on some API endpoints, the injected script may fetch the victim’s API token or call token reset endpoints — enabling full account takeover and unauthorized API access. This vulnerability is of critical severity due to the broad impact, minimal requirements for exploitation (authenticated user), and the ability to escalate privileges to full accoun...

A security flaw has been discovered in questdb ui up to 1.11.9. Impacted is an unknown function of the component Web Console. The manipulation results in cross site scripting. The attack can be executed remotely. The exploit has been released to the public and may be used for attacks. Upgrading to version 1.1.10 is recommended to address this issue. The patch is identified as b42fd9f18476d844ae181a10a249e003dafb823d. You should upgrade the affected component. The vendor confirmed early that the fix "is going to be released as a part of QuestDB 9.3.0" as well.

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

A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular Template Compiler. The vulnerability exists because Angular’s internal sanitization schema fails to recognize the `href` and `xlink:href` attributes of SVG `<script>` elements as a **Resource URL** context. In a standard security model, attributes that can load and execute code (like a script's source) should be strictly validated. However, because the compiler does not classify these specific SVG attributes correctly, it allows attackers to bypass Angular's built-in security protections. When template binding is used to assign user-controlled data to these attributes for example, `<script [attr.href]="userInput">` the compiler treats the value as a standard string or a non-sensitive URL rather than a resource link. This enables an attacker to provide a malicious payload, such as a `data:text/javascript` URI or a link to an external malicious script. ### Impact When successfully exploited, this vulnerabili...

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