IBM Concert 1.0.0 through 3.0.0 has a double free vulnerability that exists due to incorrect memory management. A local attacker can exploit this flaw to corrupt heap memory and execute arbitrary code in the context of the affected process.

IBM Concert 1.0.0 through 3.0.0 invokes operating system commands without fully qualifying executable paths or adequately restricting search path resolution. As a result, an attacker with local system access can manipulate the search path environment to execute untrusted or malicious code.

A malicious GOSUMDB was capable of serving arbitrary module content not contained within the transparency log. This attack allows for a coordinating GOPROXY and GOSUMDB to serve a client malicious module content that cannot be detected by evaluating the transparency log. In order to determine if you have been affected: rm -r go.sum go.work.sum vendor/ && go mod tidy

A malicious GOPROXY was previously capable of forging up to two sumdb tiles that allow for a requested module to bypass the GOSUMDB check and persist attacker-controlled module content to a local Go module cache. This attack allows for a malicious GOPROXY to serve malicious module content that cannot be detected by evaluating the transparency log. All tiles are now correctly verified against their parents. In order to determine if you have been affected: rm -r go.sum go.work.sum vendor/ && go mod tidy

Summary

Address4 accepts an octet written with a leading zero and decodes it as decimal, while the WHATWG URL host parser, inetaton, and getaddrinfo all decode a leading zero as octal. The library and the network stack therefore disagree about which host a string names. new Address4('012.0.0.1') reports correctForm() of 12.0.0.1 and isPrivate() of false, but fetch('http://012.0.0.1/') connects to 10.0.0.1.

An application that builds a network trust-boundary decision on these checks (for example a filter intended to block Server-Side Request Forgery, or SSRF) will classify an internal target as external and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata endpoint.

Details

Address4.parse gates untrusted input on READDRESS (src/v4/constants.ts:5), whose per-octet alternative is:

(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)

The [01]?[0-9][0-9]? branch matches a leading zero, so 012 passes validation. Every downstream decode then reads the octet with parseInt(part, 10) (src/common.ts:87), yielding 12. A resolver reading the same string treats the leading 0 as base 8 and yields 10.

The defect is in the parse gate rather than in any one classifier, so every consumer of Address4 inherits it: isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), and correctForm() are all computed from the mis-decoded octets.

Address6 already rejects this notation on its IPv4-in-IPv6 path, throwing "IPv4 addresses can't have leading zeroes." (src/ipv6.ts:751-762), so Address4 is the outlier within the library.

Affected versions

<= 10.3.0. Unlike GHSA-22jq-vg5j-6vgg and GHSA-4xrf-jv44-h6hh, which were bounded below by the is classification API introduced in 10.1.1, this defect is in parse and reaches every release: a guard built on isInSubnet() against the RFC 1918 ranges is affected in versions predating that API.

Impact

The disagreement runs in both directions. Under-blocking is the security-relevant case; over-blocking is a correctness and availability problem.

| Input | correctForm() | Classified as | Resolver reaches | Effect | |---|---|---|---|---| | 012.0.0.1 | 12.0.0.1 | public | 10.0.0.1 | internal target allowed | | 012.012.012.012 | 12.12.12.12 | public | 10.10.10.10 | internal target allowed | | 010.0.0.1 | 10.0.0.1 | private | 8.0.0.1 | public target blocked |

Reachable targets are those whose leading octet is expressible as a three-character octal literal, which covers the whole of 10.0.0.0/8 and 0.0.0.0/8. A four-character octet such as 0177 for 127 is rejected by the regex, so loopback is not reachable through this path; see the note on rejection below for why rejection is not the same as safety.

Reachability

A leading-zero address is a legal URL host, so this is reachable through the ordinary URL path with no unusual application shape required:

js new URL('http://012.0.0.1/').hostname // '10.0.0.1'

This distinguishes it from GHSA-4xrf-jv44-h6hh, where the /0 CIDR suffix could not survive URL parsing and exploitation therefore required an application that accepted a bare suffix-bearing string. Here the attack rides the same code path a normal user-supplied URL takes.

Proof of concept

npm i ip-address@10.3.0, then:

js const { Address4 } = require('ip-address');

// A guard of the shape the library documents. function isBlocked(host) { return Address4.isValid(host) && new Address4(host).isPrivate(); }

for (const h of ['10.0.0.1', '012.0.0.1', '012.012.012.012']) { console.log(isBlocked(h) ? 'BLOCK' : 'ALLOW', h, '-> resolver reaches', new URL('http://' + h + '/').hostname); }

On affected versions:

BLOCK 10.0.0.1 -> resolver reaches 10.0.0.1 ALLOW 012.0.0.1 -> resolver reaches 10.0.0.1 ALLOW 012.012.012.012 -> resolver reaches 10.10.10.10

The literal RFC 1918 address is blocked as expected; the octal-ambiguous spellings of the same destinations are allowed through.

Remediation

Upgrade to the patched release. In the fix, Address4.parse rejects any octet with a leading zero followed by further digits, mirroring the check Address6 already applies at src/ipv6.ts:751, and READDRESS is tightened so those forms no longer appear in the valid corpus. After upgrading, Address4.isValid('012.0.0.1') returns false and the constructor throws AddressError.

This rejects input that previous releases accepted. An application that deliberately feeds zero-padded addresses such as 010.010.010.010 from a legacy system must strip the padding before parsing.

If you cannot upgrade immediately, reject any host whose octets carry a leading zero before you parse it:

js if (host.split('.').some((octet) => /^0\d/.test(octet))) throw new Error('ambiguous address');

A note on SSRF defense

These methods are address classifiers, not a complete SSRF defense. Regardless of this fix, a robust SSRF guard must resolve the hostname and validate the resolved IP against the socket it connects to, and account for DNS rebinding and redirects. Treat these checks as one layer, not the only one.

One specific pitfall is worth naming, because the fix above does not remove it. Address4.isValid() returning false means "this is not a dotted-quad IPv4 literal"; it does not mean "this is not an address that will reach an internal host". Every one of the following is rejected by isValid() and still resolves to loopback:

0177.0.0.1 0x7f.0.0.1 0x7f000001 2130706433 127.1 127.0.1 127.0.0.1. １２７.0.0.1

A guard shaped if (Address4.isValid(h)) { check() } else { treatAsHostname() } therefore routes all of them past the IP check. Rejecting these is correct behavior for an IPv4 parser and is not changed by this advisory, but a guard must treat "not a valid literal" as a case to resolve and re-check, never as a case to allow.

A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular compiler's internationalization (i18n) pipeline. Although Angular disallows binding to event-handler attributes such as onclick and onerror through standard attribute validation (validateAttribute() / validateProperty()), the i18n metadata collection path allowed these same attribute names to be marked for translation using i18n-on attributes (e.g., i18n-onerror).

When exploited, a lower-trust translation file could replace a benign static handler such as onerror="void 0" with arbitrary executable JavaScript in the localized build.

The following example illustrates a vulnerable pattern: html <img src="foo.jpg" onerror="void 0" i18n-onerror />

Impact

When exploited, this vulnerability allows arbitrary JavaScript execution within the context of the vulnerable application's domain if an attacker can control or influence the translation files used during localization. This can lead to: - Session Hijacking: Accessing session cookies, tokens, or sensitive user data. - Unauthorized Actions: Performing actions on behalf of the authenticated user.

Patched Versions

- 22.0.1 - 21.2.19 - 20.3.27

Workarounds

Ensure that static event-handler attributes (e.g., onerror, onclick) are never marked for internationalization (i18n-on) in application templates, and ensure translation files are sourced from trusted origins.

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.27, 21.2.19, and 22.0.2, HttpTransferCache comma-joins repeated request parameters, allowing semantically distinct HttpClient requests to use the same transfer-cache key and reuse a wrong backend response. This issue is fixed in versions 20.3.27, 21.2.19, and 22.0.2.

Impact Remotely triggerable DoS in find-my-way when it is used with Node's HTTP/2 server.

The short version is that lookup() passes req.method into find(), and find() indexes this.trees[method]. Since this.trees is a normal object, HTTP/2 method values like constructor, toString, or proto can resolve inherited object properties instead of returning undefined. The code then treats that value like a router node and crashes when it reaches currentNode.prefix.length.

Patches

Upgrade to v9.7.0.

Workarounds

Do not use find-my-way with HTTP/2 servers, or validate that the http method is valid beforehand.

Improper certificate validation in Apache MINA SSHD (server-side). Apache MINA SSHD is a Java library for client-side and server-side SSH.

Server-side OpenSSH user certificate validation during user authentication in an Apache MINA SSHD server did not check for the unsupported force-command or verify-required options that could be embedded in the certificate, nor did it validate these options. As a result it was possible that a user could authenticate with such a certificate that included a force-command option but still was able to execute other commands. What other command exactly would be available to the user depends on the implementation of the server.

This issue is fixed in Apache MINA SSHD 2.19.0 and 3.0.0-M5. Applications are advised to upgrade to these versions.

The fix rejects OpenSSH user certificates that include these options, since Apache MINA SSHD implements neither force-command nor sk--cert-v01 user certificates (which are the only ones for which verify-required would make sense).

adm-zip before 0.5.18 is vulnerable to denial of service via a crafted ZIP file with a manipulated uncompressed size header field. In zipEntry.js line 103, Buffer.alloc(centralHeader.size) allocates memory based on the declared uncompressed size from the ZIP central directory header without validating it against the actual compressed data size or imposing any upper bound. The size value is read directly from the binary header at entryHeader.js line 266 with no bounds check. An attacker can craft a ~120-byte ZIP file that declares ~4GB uncompressed size, causing a memory allocation amplification ratio of over 33 million to 1. The allocation occurs before CRC validation, so the malicious payload cannot be rejected early. All extraction and read methods are affected: readFile(), readAsText(), extractEntryTo(), extractAllTo(), extractAllToAsync(), test(), and entry.getData(). Any application accepting untrusted ZIP files via adm-zip is vulnerable to immediate process crash.

Summary

@opentelemetry/propagator-jaeger decodes incoming HTTP header values with decodeURIComponent() without handling decode errors. A single request carrying a malformed percent-encoded value (for example a bare %) in an uber-trace-id or uberctx- header throws an uncaught URIError, terminating any Node.js process that uses JaegerPropagator as its active propagator.

Impact

Denial of Service: Any unauthenticated remote attacker who can send an HTTP request to a service that has JaegerPropagator registered as the global propagator (e.g. via OTELPROPAGATORS=jaeger or propagation.setGlobalPropagator(new JaegerPropagator())) can terminate the process with a single request. Confidentiality and integrity are not affected.

Am I affected?

This issue affects only a specific, opt-in configuration. If you use OpenTelemetry's default propagators (W3C TraceContext and Baggage), you are not affected.

You are affected only if you have registered JaegerPropagator as the active propagator. Check for:

- @opentelemetry/propagator-jaeger in your dependency tree, and - OTELPROPAGATORS set to jaeger (Jaeger only), or a direct propagation.setGlobalPropagator(new JaegerPropagator()) call in your code.

Note: if JaegerPropagator is combined with other propagators through a CompositePropagator (for example OTELPROPAGATORS=jaeger,tracecontext), the process does not terminate - the composite propagator catches the error - but affected requests silently fail to extract context. You should still upgrade.

Patched versions

- @opentelemetry/propagator-jaeger 2.9.0

Remediation

Update @opentelemetry/propagator-jaeger to 2.9.0 or later. The propagator now ignores header values it cannot decode instead of throwing.

Interim mitigation (if you cannot update): Trace-context headers should never be accepted unfiltered from untrusted callers. Until you can upgrade, strip or validate the uber-trace-id and uberctx- headers on inbound requests at your edge - for example with a reverse proxy, API gateway, or load balancer (nginx, Envoy, etc.) - so that only trusted upstream services can set them.

Details

JaegerPropagator.extract() calls decodeURIComponent() on raw header values at two unguarded call sites: the uber-trace-id trace header and each uberctx- baggage value. decodeURIComponent() throws URIError: URI malformed on invalid percent-encoding. Because the HTTP instrumentation extracts context before its request-handler error wrapper, and a single configured propagator is not wrapped in a CompositePropagator (which would otherwise catch the error), the exception propagates as an uncaughtException and terminates the process.

Proof of concept

Against a service using JaegerPropagator:

bash curl -H 'uberctx-user: %' http://target/ or curl -H 'uber-trace-id: %' http://target/

The Node.js process exits with URIError: URI malformed and subsequent requests are refused.

Summary linkify-it's schema-scan loop (.test() / .match(), the documented public API) invokes the mailto: schema validator at every mailto: occurrence in the input text. For each occurrence the validator does text.slice(pos) (an O(n) copy) and runs an email regex whose local-part class srcemailname greedily scans the entire remaining tail (O(n)) before failing. With N mailto: occurrences that is N × O(n) = O(n²). Because linkify-it runs on arbitrary user text (markdown-it feeds it whole documents when linkify:true), an unauthenticated attacker can block the single-threaded event loop for many seconds with a small input. No length bound (unlike an HTTP header).

Root cause — index.mjs + lib/re.mjs js // index.mjs (mailto validator) — runs at every "mailto:" hit 'mailto:': { validate: function (text, pos, self) { const tail = text.slice(pos) // O(n) copy per hit if (!self.re.mailto) self.re.mailto = new RegExp('^' + self.re.srcemailname + '@' + self.re.srchoststrict, 'i') if (self.re.mailto.test(tail)) { ... } // scans the whole O(n) tail return 0 }} // lib/re.mjs:91-93 — every char of "mailto:" (incl. ':','-',';') is in this class: re.srcemailname = '[\\-;:&=\\+\\$,\\.a-zA-Z0-9][\\-;:&=\\+\\$,\\"\\.a-zA-Z0-9]' The while ((m = re.exec(text)) !== null) { …testSchemaAt… } scan loop calls the validator at each mailto: hit; srcemailname greedily consumes the whole tail (all chars are in its class) then fails for lack of @. http:/https: do NOT blow up — their validator requires the tail to start with //, failing in O(1) per hit.

Proof of Concept (confirmed, linkify-it 5.0.1, Node v24) js const LinkifyIt = require('linkify-it'); const lf = new LinkifyIt(); lf.match('mailto:'.repeat(48000)); // ~336 KB of "mailto:mailto:…" -> seconds of blocked event loop | input (same bytes) | 56 KB | 112 KB | 224 KB | 336 KB | |---|---:|---:|---:|---:| | mailto: contiguous | 97 ms | 357 ms | 1438 ms | 3272 ms | | mailto: space-separated | 2 ms | 3 ms | 5 ms | 8 ms | | http:// contiguous | 12 ms | 17 ms | 33 ms | 49 ms |

×~4 per 2× input ⇒ O(n²); equal-byte controls stay flat ⇒ algorithmic, not a GC/allocation artifact. Real-world via markdown-it 14.x ({linkify:true}), md.render('mailto:'.repeat(n)): 219 KB ≈ ~5 s. <img width="737" height="161" alt="image" src="https://github.com/user-attachments/assets/b5d390f3-68d0-4861-9c47-ad8aff0203d5" />

Impact Reachable on arbitrary user text via the documented .test()/.match() API and through markdown-it's linkifier — comment systems, chat, forums, wikis, note apps that render user markdown with linkify enabled. A ~220 KB post hangs the event loop ~5 s; a few hundred KB → tens of seconds. Availability only.

Suggested remediation Bound the email local-part per RFC 5321 (≤64) so per-hit work is O(1), and avoid the full-tail slice: js // lib/re.mjs — cap the greedy run: re.srcemailname = '[\\-;:&=\\+\\$,\\.a-zA-Z0-9][\\-;:&=\\+\\$,\\"\\.a-zA-Z0-9]{0,63}' // index.mjs — prefer a sticky regex anchored at pos over text.slice(pos).

Affected / disclosure All versions through 5.0.1 (latest); same code on master. cve-mcp/OSV report no known vulnerability for linkify-it. Distinct from markdown-it's own -run ReDoS (CVE-2026-2327, different package/path) and the recent markdown-it DoS. Reported privately; happy to test a patch against the PoC.

Summary

protobufjs parsed option names by advancing through schema tokens until it reached an = token, without checking for end of input. A crafted .proto schema that opens an option declaration but ends prematurely could cause the option parser to loop without ever terminating.

This affects the reflection parsing path (parse, Root.load, Root.loadSync).

Impact

An attacker who can provide or influence .proto schema text parsed by an application may be able to cause the parsing call to never return. Because Node.js is single-threaded, the blocked event loop prevents all other work in the process, resulting in a denial of service that persists until the process is externally terminated.

Applications that only encode or decode protobuf binary data with trusted schemas are not directly affected.

Preconditions

- The application must parse .proto schema text influenced by an attacker. - The schema must be parsed through APIs such as parse, Root.load, or Root.loadSync. - The crafted input must begin an option declaration that ends before its = assignment.

Workarounds

Do not parse .proto schemas from untrusted sources with affected versions. If untrusted schema text must be accepted, isolate parsing in a process or worker that can be safely terminated and bound it with a timeout, so a non-returning parse call cannot deny service to the rest of the application.

Uncontrolled Resource Consumption vulnerability in the HTTP/1.1 message parser in Apache HttpComponents Core (5.4.2 and earlier, 5.5-beta1 and earlier) allows an remote attacker to cause a denial of service through memory exhaustion by sending messages with excessive number of headers / excessive header length

Allocation of resources without limits or throttling in the HTTP/2 HPACK decoder in Apache HttpComponents Core (5.4.2 and earlier, 5.5-beta1 and earlier) allows an remote attacker to cause a denial of service through memory exhaustion by sending oversized compressed header blocks before the HTTP/2 SETTINGS acknowledgement causes the configured header list size limit to be applied.

Summary shell-quote's parse() finalizes its token list with a reduce that uses Array.prototype.concat as the accumulator. Each prev.concat(arg) copies the entire growing array, so parse() runs in O(n²) in the number of tokens. An unauthenticated attacker who can submit a string to any code path that calls parse() on it can block the single-threaded Node.js event loop for tens of seconds with a small input — a denial of service. The trigger needs no shell metacharacters (plain space-separated words suffice), so input filters that only screen for ;, |, $, or backticks do not help.

Root cause parse.js (lines 200–203), in parseInternal — this path runs on every parse() call:

js }).reduce(function (prev, arg) { // finalize parsed arguments // TODO: replace this whole reduce with a concat return typeof arg === 'undefined' ? prev : prev.concat(arg); }, []);

prev.concat(arg) allocates a new array and copies all of prev on every iteration, so producing an N-token result costs 1 + 2 + … + N = O(N²) copies. A second acc.concat(s) reduce in the module.exports wrapper (lines 211–224, reached only when env is a function) has the same shape. The maintainer's own // TODO: replace this whole reduce with a concat already flags the construct.

Proof of Concept js const { parse } = require('shell-quote'); const ms = fn => { const t = process.hrtime.bigint(); fn(); return Number(process.hrtime.bigint()-t)/1e6; }; for (const N of [16000, 32000, 64000, 128000]) { console.log(N, 'tokens ->', ms(() => parse('x '.repeat(N))).toFixed(0), 'ms'); }

Measured on shell-quote@1.8.4, Node v24:

| input (N tokens) | bytes | parse() | ratio vs prev (2× input) | |-----------------:|-------:|----------:|:------------------------:| | 16 000 | 32 KB | 678 ms | — | | 32 000 | 64 KB | 4 169 ms | ×6.2 | | 64 000 | 128 KB | 14 914 ms | ×3.6 | | 128 000 | 256 KB | 57 319 ms | ×3.8 |

Time grows ~×4 per 2× input → confirmed O(n²). A ~128 KB input blocks the event loop ~15 s; ~256 KB → ~57 s; a few hundred KB more → minutes. <img width="656" height="214" alt="image" src="https://github.com/user-attachments/assets/e8955b0e-0527-45ca-94b7-c3a2d8c0c82e" /> poc.js

Impact parse() is synchronous on the main thread; while it copies arrays quadratically the entire event loop is blocked and the process serves no other requests. Any service that calls parse() on attacker-influenced input (command parsers, chat-ops / bot command handlers, REPLs, build-script / arg-string splitters) can be driven to a sustained DoS with a single small request. No code execution and no data disclosure — availability only.

End-to-end confirmation: a minimal HTTP server that calls parse() on the request body, hit with one POST of 'x '.repeat(32000) (~63 KB), froze for ~4.5 s. An out-of-process probe client issuing harmless GET /ping requests (normally ~1 ms) observed 27 consecutive pings stalled by up to 4374 ms during that single request — i.e. every concurrent client was denied service for the whole parse. Scaling the body to a few hundred KB extends the outage to minutes.

This is the same class as several accepted 2026 advisories for quadratic-parser DoS on untrusted input (e.g. markdown-it CVE-2026-48988, js-yaml CVE-2026-53550, python-multipart CVE-2026-53539). It is distinct from the known shell-quote command-injection issues (CVE-2021-42740, CVE-2016-10541, CVE-2026-9277), which are all in quote(), not parse().

Suggested remediation Replace the O(n²) concat-in-reduce with a linear flatten that pushes into the accumulator instead of reallocating and copying it on every iteration. Apply the same shape to the wrapper's acc.concat(s) reduce. A defensive input-length cap on parse() is a cheap additional stop-gap.

Maintainer note (edit): the originally-suggested Array.prototype.flat() is ES2019 / Node 11+, but shell-quote declares engines: node >= 0.4, so .flat() would silently drop support for older runtimes. The fix instead flattens one-level array tokens with forEach/push — and deliberately not push.apply(...), since spreading a large array into function arguments can exceed the engine's argument count limit. Output is byte-identical to the current code across strings, undefined holes, one-level array tokens, and {op}/{comment}/{op:'glob'} objects, and finalizing is now linear (1,024,000 tokens in ~150 ms vs ~57 s for 128,000 before). Thanks for the clear report and PoC — the analysis and reproduction were spot on.

Disclosure Found by source audit + wall-clock confirmation against 1.8.4 (and verified the same code is present on main). Reported privately here; no public disclosure until a fix is available.

ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.36 in Java applications, allows an attacker to execute arbitrary code circumventing existing protections against CVE-2025-11226 by compromising an existing logback configuration file or by injecting an environment variable before program execution.

A successful attack requires the presence of Janino library to be present on the user's class path. In addition, the attacker must  have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege.

Please note that in logack version 1.5.37 conditional processing using Janino was removed.

jackson-databind's PolymorphicTypeValidator (PTV) is the primary safety mechanism guarding polymorphic deserialization. When polymorphic typing is enabled and a type identifier contains generic parameters (i.e. the type ID string contains <), DatabindContext.resolveAndValidateGeneric() validates only the raw container class name (the substring before <) against the configured PTV.

If the container type is approved, the method parses the full canonical type string via TypeFactory.constructFromCanonical() and returns the fully parameterized type without ever validating the nested type arguments against the PTV. The nested type arguments are then resolved, instantiated, and populated as beans during deserialization.

An attacker who controls the type ID can therefore place a denied class as a generic type parameter of an allowed container — for example java.util.ArrayList<com.evil.Gadget> when only java.util.ArrayList is allow-listed. The container passes the PTV check; com.evil.Gadget is loaded via Class.forName(name, true, loader), instantiated, and its properties are set from attacker-controlled JSON. This completely bypasses an explicitly configured PTV allow-list.

This is the same vulnerability class responsible for the historical sequence of jackson-databind deserialization CVEs; here it manifests as a validator bypass rather than a missing deny-list entry.

Impact

- Bypass of the PTV allow-list, including the recommended BasicPolymorphicTypeValidator configured with name-prefix allow rules. - Arbitrary class instantiation of any type assignable to the container's element/parameter position, with attacker-controlled property values (setter/field injection). - Potential unauthenticated remote code execution when a class with exploitable side effects (JNDI lookup, JDBC/connection-pool gadgets,TemplatesImpl-style loaders, etc.) is present on the classpath.

Applications that accept untrusted JSON and rely on a configured PTV — the documented, security-conscious configuration — are affected.

Proof of Concept

Configuration restricting polymorphic deserialization to a single safe container:

java BasicPolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder() .allowIfSubType("java.util.ArrayList") .build();

ObjectMapper mapper = JsonMapper.builder() .polymorphicTypeValidator(ptv) .build();

Malicious payload (Wrapper.value is Object with @JsonTypeInfo(use = Id.CLASS, include = As.WRAPPERARRAY)):

json {"value":["java.util.ArrayList<com.evil.EvilGadget>",[{"cmd":"calc.exe"}]]}

On vulnerable versions, com.evil.EvilGadget is instantiated and its cmd property is set, despite only java.util.ArrayList being allow-listed. On 2.18.8 / 2.21.4 / 3.1.4 the deserialization throws InvalidTypeIdException before instantiation.

Variant payloads (all bypass an ArrayList/HashMap allow-list):

| Type ID | Smuggled type position | |---|---| | java.util.ArrayList<Evil> | list element | | java.util.HashMap<Evil,String> | map key | | java.util.HashMap<String,Evil> | map value | | java.util.ArrayList<java.util.ArrayList<Evil>> | nested element | | java.util.ArrayList<Evil[]> | array element |

---

Patches

Fixed in 2.18.8, 2.21.4 and 3.1.4 via the changes for FasterXML/jackson-databind#5988, commit 434d6c511. The fix adds recursive validation of each non-trivial type parameter (and array element types appearing as parameters) through the full PTV chain, with documented exemptions for Object (wildcard resolution) and Enum types.

PolymorphicTypeValidator was added in 2.10.0 so vulnerability N/A for versions prior to that.

Summary BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() allowlists any array type based only on clazz.isArray(), without validating the array's component (element) type against the configured allowlist. A PTV built with allowIfSubTypeIsArray() plus an explicit concrete-type allowlist therefore still permits EvilType[] even though EvilType is not allowlisted. When Jackson deserializes the elements and no per-element type IDs are present, it instantiates the component type directly with no further PTV check, bypassing the allowlist.

Impact Applications using BasicPolymorphicTypeValidator with allowIfSubTypeIsArray() as a safeguard get no protection for concrete array component types; an attacker controlling JSON can instantiate non-allowlisted types via an array wrapper, re-opening the gadget-instantiation risk PTV is meant to prevent.

Affected / Patched (verified via git tag --contains) - 2.18 line: >= 2.10.0, < 2.18.8 -> fixed in 2.18.8 - 2.19-2.21 line: >= 2.19.0, < 2.21.4 -> fixed in 2.21.4 - 3.x line: >= 3.0.0, < 3.1.4 -> fixed in 3.1.4

PolymorphicTypeValidator was added in 2.10.0 so vulnerability N/A for versions prior to that.

Severity / CWE Maintainer: significant. Reporter: HIGH. CWE-184 (Incomplete List of Disallowed Inputs); related CWE-502.

Upstream fix FasterXML/jackson-databind#5981; fix PR #5983 (24529da), 2.18 backport PR #5984 (01d1692). Released 2026-06-04 in 2.18.8 / 2.21.4 / 3.1.4.

Credits Omkhar Arasaratnam (@omkhar) - finder.

Summary

When serving static files on Windows, StaticFiles resolves the requested path with os.path.realpath. If a UNC path (such as \\attacker.com\share) reaches the resolver, realpath causes the process to open a connection to the remote host over SMB (port 445). This is a server-side request forgery (SSRF) that leaks the service account's NTLMv2 credentials to the attacker-controlled host, which can then be cracked offline or relayed to other hosts.

Details

StaticFiles.lookuppath() joins the requested path onto the served directory and calls os.path.realpath on the result before checking containment with os.path.commonpath. On Windows, a UNC path is absolute, so os.path.join discards the served directory and realpath resolves the bare UNC path, triggering the outbound SMB connection and NTLM authentication before the containment check rejects the path. The HTTP response is a benign 404, but the credential disclosure has already happened. POSIX systems are not affected.

This only affects the default configuration (followsymlink=False), which uses os.path.realpath. The followsymlink=True branch uses os.path.abspath, which performs no I/O.

Impact

Applications running on Windows that serve files with StaticFiles (directly, or via a framework built on Starlette such as FastAPI) in the default configuration are affected. StaticFiles is typically unauthenticated, so any client can trigger the SMB connection and leak the service account's NTLMv2 hash. A secondary impact is discovering internal hosts reachable over SMB by timing responses for valid versus invalid addresses.

Mitigation

Applications not running on Windows are not affected. On Windows, serving static files through a dedicated web server (such as nginx or IIS) instead of StaticFiles avoids the issue. Blocking outbound SMB (port 445) from the application host prevents the credential disclosure even if a UNC path is resolved.

Summary

protobufjs could recurse without a depth limit while converting decoded messages to plain objects or JSON. This affected generated toObject() conversion and the custom google.protobuf.Any JSON conversion path.

A crafted protobuf binary payload containing deeply nested Any values could cause the JavaScript call stack to be exhausted during conversion to JSON.

Impact

An attacker who can provide protobuf binary data decoded by an application may be able to crash the process or otherwise cause message conversion to fail with a stack overflow.

This affects applications that decode untrusted protobuf input containing google.protobuf.Any values and then convert decoded messages to JSON or plain objects with JSON conversion enabled, for example through JSON.stringify(message), Message#toJSON(), or Type.toObject(message, { json: true }).

Applications that only decode and re-encode protobuf binary data without converting decoded messages to JSON are not directly affected by this issue.

Preconditions

The application must decode protobuf binary data influenced by an attacker. The application schema must include google.protobuf.Any, and the referenced typeurl must resolve to a message type in the loaded protobuf root. The application must convert the decoded message to JSON or a plain object through an affected conversion path. The crafted input must contain deeply nested Any values that are expanded during conversion.

Workarounds

Avoid converting untrusted protobuf messages containing google.protobuf.Any values to JSON with affected versions. If immediate upgrade is not possible, reject or limit messages with deeply nested Any payloads at an outer protocol boundary where feasible, avoid JSON conversion of untrusted Any values, or isolate message conversion in a process that can be safely restarted.

A Denial of Service (DoS) vulnerability exists in the @angular/common package of the Angular framework. The formatDate function, which is also utilized by the standard Angular DatePipe, does not properly limit or validate the length of the format parameter.

When parsing a maliciously crafted, excessively long date format string (e.g., a repeating pattern or very large string), the internal parser splits the string iteratively using a regular expression loop. This results in uncontrolled resource consumption (high CPU utilization and excessive memory allocations), leading to a Denial of Service (DoS).

Impact

1. Server-Side Rendering (SSR) In Angular applications that leverage Server-Side Rendering, an attacker can supply a malicious payload with an excessively long date format string. Processing this on the server causes high CPU usage and triggers a JavaScript heap out of memory crash, rendering the application unavailable to all users.

2. Client-Side Rendering (CSR) In standard client-side applications, executing the vulnerable function with an excessively long format string blocks the browser's main thread, causing the browser tab to freeze and become completely unresponsive.

Patched Versions 22.0.1 21.2.17 20.3.25

Attack Preconditions For this vulnerability to be exploitable, both of the following conditions must be met: 1. Vulnerable Component Usage: The application must format dates using the formatDate utility or the DatePipe. 2. Attacker-Controlled Parameter: The date format string passed to these utilities must be customizable or directly controlled by untrusted user input (e.g., parsed from query parameters, user preferences, or API responses).

If the date format is hardcoded (e.g., 'mediumDate', 'shortTime', or static strings) or properly validated to be within a reasonable length limit, the application is not vulnerable.

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 22.0.1, 21.2.17, and 20.3.25, Angular's HttpTransferCache caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. This avoids repeating the same HTTP requests on the client. The cached responses are stored in TransferState using a cache key generated by hashing request properties (method, response type, mapped URL, serialized body, and sorted query parameters). The cache keys are generated using a weak 32-bit DJB2-like polynomial rolling hash. The 32-bit hash space is extremely small, allowing attackers to find hash collisions. An attacker can easily find a query parameter string (e.g., q=aaCAZMMM for a search request) that produces the exact same 32-bit hash as a sensitive endpoint (e.g., /api/user/profile). When a victim visits a crafted link containing the colliding parameter, the SSR process executes both the search request and the profile request. Due to the hash collision, the search response overwrites the profile response in the TransferState cache. This vulnerability is fixed in 22.0.1, 21.2.17, and 20.3.25.

A Denial of Service (DoS) vulnerability exists in the @angular/common package of Angular. The formatNumber function, which is also utilized by DecimalPipe, PercentPipe, and CurrencyPipe, does not properly validate the upper bounds of the digitsInfo parameter. Specifically, the minimum and maximum fraction digits parsed from the digitsInfo string (e.g., 1.2-4) are converted to integers and used without limits.

When parsing a maliciously crafted digitsInfo string with excessively large fraction digit values (e.g., 1.200000000-200000000), the internal roundNumber function attempts to pad the digits array to match the requested fraction size. This results in an unbounded loop that repeatedly pushes elements into an array.

Impact

Successful exploitation of this vulnerability allows an attacker to trigger resource exhaustion, leading to a Denial of Service (DoS):

Server-Side Rendering (SSR): In applications using SSR (e.g., @angular/ssr), an attacker can crash the Node.js server process due to a JavaScript heap out of memory error. This affects the availability of the application for all users. Client-Side Rendering (CSR): In standard client-side applications, the unbounded loop will block the main thread, freezing the user's browser tab and making it unresponsive.

Attack Preconditions

For this vulnerability to be exploitable, the following conditions must be met:

1. Vulnerable Component Usage: The application must use Angular's number formatting utilities, such as the formatNumber function directly, or via template pipes (DecimalPipe, PercentPipe, CurrencyPipe). 2. Attacker-Controlled Parameter: The digitsInfo parameter passed to these utilities must be customizable or directly controlled by untrusted user input (e.g., parsed from query parameters, user preference settings, or API responses that accept user-defined formatting options). If digitsInfo is trusted or limited to a known, defined range for its value, the vulnerability is not exploitable by external attackers.

Patches - 22.0.0-rc.2 - 21.2.15 - 20.3.22 - 19.2.23

Credits This vulnerability was discovered and reported by CodeMender from Google DeepMind.

A vulnerability was discovered in @angular/common when Server-Side Rendering (SSR) and hydration are enabled. The HttpTransferCache utility optimizes hydration by caching outgoing HTTP requests performed during SSR and transferring the cached state to the client-side application via TransferState.

However, the caching mechanism fails to inspect the withCredentials flag or the Cookie header of outgoing requests. As a result, credentialed, user-specific responses may be cached by default in the shared TransferState payload. When these responses are serialized into the HTML, any caching layer (such as a CDN, reverse proxy, or shared server cache) that caches the SSR-rendered HTML page could inadvertently cache and leak one user's private data to other users, leading to a high-severity information disclosure vulnerability.

Impact

Successful exploitation allows an unauthenticated attacker to obtain sensitive, user-specific information of other authenticated users. This occurs when:

The SSR-rendered HTML containing the cached private data is stored in a shared cache (e.g., CDN, reverse proxy). Subsequent requests for the same page receive the cached HTML containing the first user's private data.

Attack Preconditions

SSR and Hydration Enabled: The Angular application must be configured to use Server-Side Rendering and hydration (e.g., using provideClientHydration()). Credentialed Requests during SSR: The application must perform HTTP requests that require user-specific authentication (using cookies or withCredentials: true) during the initial server-side render. Shared Caching: The application's HTML responses must be cached by a shared caching layer (CDN, reverse proxy, or server-side cache) without proper cache-control headers to distinguish authenticated users.

Patches - 22.0.0-rc.2 - 21.2.15 - 20.3.22 - 19.2.23

Impact

A high volume of exceptionally small fragments and data chunks can be sent by a peer, with modest network traffic, to force the remote peer into allocating and holding structural wrappers that consume far more memory than the default documented message-size limit, leading to process termination due to OOM.

Proof of concept

js import { WebSocket, WebSocketServer } from 'ws';

const wss = new WebSocketServer({ port: 0 }, function () { const data = Buffer.alloc(1); const options = { fin: false }; const { port } = wss.address(); const ws = new WebSocket(ws://localhost:${port});

ws.on('open', function () { (function send() { ws.send(data, options, function (err) { if (err) return; send(); }); })(); });

ws.on('error', console.error); ws.on('close', function (code, reason) { console.log(client close - code: ${code} reason: ${reason.toString()}); }); });

wss.on('connection', function (ws) { ws.on('error', console.error); ws.on('close', function (code, reason) { console.log(server close - code: ${code} reason: ${reason.toString()}); }); });

Patches

The vulnerability was fixed in ws@8.21.0 (https://github.com/websockets/ws/commit/bca91adf15677e47dbe4f959653452727be28b94) and backported to ws@7.5.11 (https://github.com/websockets/ws/commit/fd36cd864fcdf62a08273a99e19a7d975401fee8), ws@6.2.4 (https://github.com/websockets/ws/commit/86d3e8a5fb0246ed373860c5fbb0de88824a27f7), and ws@5.2.5 (https://github.com/websockets/ws/commit/b5372ac67bb97a773727b8e9f5035a8123556d53).

Workarounds

In vulnerable versions, the issue can be mitigated by lowering the value of the maxPayload option if possible.

Credits

The vulnerability was responsibly disclosed and fixed by Nadav Magier.

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 22.0.1, 21.2.17, and 20.3.25, to optimize client-side bootstrap in Server-Side Rendered (SSR) environments, Angular supports Hydration via provideClientHydration(). During SSR, Angular serializes the application's runtime state (such as cached HttpClient responses) and outputs it into the HTML stream as a <script> tag with a predictable identifier. During client bootstrap, Angular recovers this state by looking up the element via document.getElementById('ng-state') and parsing its text content. Because the DOM element lookup for the state container is predictable and relies solely on the ID selector (ng-state), it is susceptible to DOM Clobbering. If the application binds untrusted user input or CMS content to element properties such as id (e.g., <div [id]="userInput"> or <a id="ng-state">) before the genuine <script> tag is parsed by the browser, the attacker-controlled element takes precedence in the DOM lookup. During hydration, when Angular calls document.getElementById('ng-state'), the browser returns the attacker's clobbered element. Angular then attempts to parse the text content or attributes of this clobbered element as JSON. This vulnerability is fixed in 22.0.1, 21.2.17, and 20.3.25.

Impact

A vulnerability in Multer allows an attacker to trigger a Denial of Service (DoS) by aborting or sending malformed multipart uploads, causing orphaned partial files to accumulate on disk when using diskStorage.

Patches

Users should upgrade to 2.2.0, 3.0.0-alpha.2 or higher

Workarounds

None

Impact

Multer is vulnerable to a Denial of Service (DoS) via deeply nested field names in multipart form data. The append-field dependency parses bracket notation in field names (e.g., a[b][c]) with no limit on nesting depth, allowing an attacker to force allocation of deeply nested object structures that consume CPU and memory. A single HTTP request with a crafted multipart body is sufficient to exploit this.

Patches

Users should upgrade to 2.2.0 and configure limits.fieldNestingDepth to the minimum depth their application requires.

Workarounds

Set limits.fields to a reasonable value to reduce the number of fields an attacker can send per request. This does not fully mitigate the issue but limits the impact.

Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager) performs no hostname verification at all. Versions 4.1.135.Final and 4.2.15.Final patch the issue.