#nodejs

### Impact There is a possibility to save XSS code in province field in the Checkout and Address Book and then execute it on these pages. The problem occurs when you open the address step page in the checkout or edit the address in the address book. This only affects the base UI Shop provided by Sylius. ### Patches The issue is fixed in versions: 1.12.16, 1.13.1 and above. ### Workarounds 1. Create new file `assets/shop/sylius-province-field.js`: ```js // assets/shop/sylius-province-field.js function sanitizeInput(input) { const div = document.createElement('div'); div.textContent = input; return div.innerHTML; // Converts text content to plain HTML, stripping any scripts } const getProvinceInputValue = function getProvinceInputValue(valueSelector) { return valueSelector == undefined ? '' : `value="${sanitizeInput(valueSelector)}"`; }; $.fn.extend({ provinceField() { const countrySelect = $('select[name$="[countryCode]"]'); countrySelect.on('change', (event) ...

### Impact There is a possibility to execute javascript code in the Admin panel. In order to perform an XSS attack input a script into `Name` field in which of the resources: Taxons, Products, Product Options or Product Variants. The code will be executed while using an autocomplete field with one of the listed entities in the Admin Panel. Also for the taxons in the category tree on the product form. ### Patches The issue is fixed in versions: 1.12.16, 1.13.1 and above. ### Workarounds 1. Create new file `assets/admin/sylius-lazy-choice-tree.js`: ```js // assets/admin/sylius-lazy-choice-tree.js function sanitizeInput(input) { const div = document.createElement('div'); div.textContent = input; return div.innerHTML; // Converts text content to plain HTML, stripping any scripts } const createRootContainer = function createRootContainer() { return $('<div class="ui list"></div>'); }; const createLeafContainerElement = function createLeafContainerElement() { return $('<di...

Red Hat Security Advisory 2024-2793-03 - An update for the nodejs:16 module is now available for Red Hat Enterprise Linux 8.6 Extended Update Support. Issues addressed include a denial of service vulnerability.

### Impact Inconsistent interpretation of a crafted HTTP request meant that requests are treated as both a single request, and two separate requests by Next.js, leading to desynchronized responses. This led to a response queue poisoning vulnerability in the affected Next.js versions. For a request to be exploitable, the affected route also had to be making use of the [rewrites](https://nextjs.org/docs/app/api-reference/next-config-js/rewrites) feature in Next.js. ### Patches The vulnerability is resolved in Next.js `13.5.1` and newer. This includes Next.js `14.x`. ### Workarounds There are no official workarounds for this vulnerability. We recommend that you upgrade to a safe version. ### References https://portswigger.net/web-security/request-smuggling/advanced/response-queue-poisoning

Gentoo Linux Security Advisory 202405-29 - Multiple vulnerabilities have been discovered in Node.js. Versions greater than or equal to 16.20.2 are affected.

### Impact XML External entity injections could be possible, when running the provided XML Validator on arbitrary input. #### POC ```js const { Spec: { Version }, Validation: { XmlValidator } } = require('@cyclonedx/cyclonedx-library'); const version = Version.v1dot5; const validator = new XmlValidator(version); const input = `<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE poc [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <bom xmlns="http://cyclonedx.org/schema/bom/1.5"> <components> <component type="library"> <name>testing</name> <version>1.337</version> <licenses> <license> <id>&xxe;</id><!-- << XML external entity (XXE) injection --> </license> </licenses> </component> </components> </bom>`; // validating this forged(^) input might lead to unintended behaviour // for the fact that the XML external entity would be taken into account. validator.validate(input).then(ve => { console.error('validation error', v...

### Summary If PDF.js is used to load a malicious PDF, and PDF.js is configured with `isEvalSupported` set to `true` (which is the default value), unrestricted attacker-controlled JavaScript will be executed in the context of the hosting domain. ### Patches [This patch](https://github.com/wojtekmaj/react-pdf/commit/671e6eaa2e373e404040c13cc6b668fe39839cad) forces `isEvalSupported` to `false`, removing the attack vector. ### Workarounds Set `options.isEvalSupported` to `false`, where `options` is `Document` component prop. ### References - [GHSA-wgrm-67xf-hhpq](https://github.com/mozilla/pdf.js/security/advisories/GHSA-wgrm-67xf-hhpq) - https://github.com/mozilla/pdf.js/pull/18015 - https://github.com/mozilla/pdf.js/commit/85e64b5c16c9aaef738f421733c12911a441cec6 - https://bugzilla.mozilla.org/show_bug.cgi?id=1893645

### Impact If pdf.js is used to load a malicious PDF, and PDF.js is configured with `isEvalSupported` set to `true` (which is the default value), unrestricted attacker-controlled JavaScript will be executed in the context of the hosting domain. ### Patches The patch removes the use of `eval`: https://github.com/mozilla/pdf.js/pull/18015 ### Workarounds Set the option `isEvalSupported` to `false`. ### References https://bugzilla.mozilla.org/show_bug.cgi?id=1893645

Red Hat Security Advisory 2024-2651-03 - An update for the nodejs:16 module is now available for Red Hat Enterprise Linux 8.8 Extended Update Support. Issues addressed include a denial of service vulnerability.

### Summary Default configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-CoreValidation. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a `<KeyInfo />` element, and pass `xml-crypto` default validation checks. ### Details Affected `xml-crypto` versions between versions `>= 4.0.0` and `< 6.0.0`. `xml-crypto` trusts by default any certificate provided via digitally signed XML document's `<KeyInfo />`. `xml-crypto` prefers to use any certificate provided via digitally signed XML document's `<KeyInfo />` even if library was configured to use specific certificate (`publicCert`) for signature verification purposes. Attacker can spoof signature verification by modifying XML document and replacing existing signature with signature generated with malicious pri...