IBM Concert 1.0 through 3.0.0 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files.

IBM Concert

IBM Concert 1.0 through 3.0.0 allows information disclosure through exposure of schema suggestions.

IBM Concert 1.0 through 3.0.0 allows web page cache to be stored locally which can be read by another user on the system.

IBM Concert 1.0 through 3.0.0 is vulnerable to Information Disclosure via Heap Inspection.

Summary

On Windows, a TemplateLookup URI beginning with a drive designator (e.g. C:/../../secret.txt or C:\..\..\secret.txt) bypasses the directory traversal check in Template.init, allowing reads of files outside the configured template directory.

This is a third, independent instance of the root cause behind CVE-2026-41205 (the // prefix) and CVE-2026-44307 (the backslash form). Both of those fixes normalized a separator spelling. Neither addressed the other way posixpath and ntpath disagree: the drive designator. Both prior fixes remain effective on their own terms; this variant survives them for an independent reason.

Details

The root cause is the same posixpath / os.path mismatch: resolution is done with posixpath, confinement is checked with os.path, which is ntpath on Windows.

mako/lookup.py -- resolution 247: srcfile = posixpath.normpath(posixpath.join(dir, u)) # posixpath, always 248: if os.path.isfile(srcfile): # ntpath on Windows

mako/template.py -- confinement 268: unorm = os.path.normpath(unorm) # ntpath on Windows 269: if unorm.startswith(".."): # never true for a drive URI

posixpath has no concept of a drive, so it treats C: as an ordinary path component; the .. segments pop C: and then escape the template root. ntpath, by contrast, splits the drive off and treats the remainder as rooted, discarding the .. entirely -- so the guard on line 269 inspects a string from which the evidence has already been removed:

| URI | ntpath.normpath (what the guard sees) | guard fires | |---|---|---| | //../secret.txt | ..\secret.txt | yes | | \..\secret.txt | ..\secret.txt | yes | | C:/../../secret.txt | C:\secret.txt | no |

Because the guard cannot fire for any URI beginning with a single-letter drive designator, the traversal is unconstrained, and its depth does not have to be guessed. posixpath.normpath() saturates excess .. segments at the root rather than erroring, so a URI carrying more .. than the template root is deep reaches the volume root and descends from there. A single fixed payload therefore works regardless of where the template directory sits:

template root = <base>/srv/app/templates

'C:/../../../../boot.ini' -> reads <base>/boot.ini 'C:/' + '../'40 + 'etc/hostname' -> reads /etc/hostname (no depth guess) 'C:/../../../../../etc/hostname' -> TopLevelLookupException (wrong depth)

On Windows the equivalent is C:/../../../../../../../../Windows/win.ini, which reads that file for any template root depth. Only a target addressed relative to the template root needs the .. count to be exact; anything reachable from the volume root does not.

Affected code

- mako/template.py: Template.init() URI validation uses os.path.normpath(), which on Windows strips the drive and discards the .. segments before the startswith("..") guard is applied. - mako/lookup.py: TemplateLookup.gettemplate() resolves with posixpath.normpath/posixpath.join, where C: is an ordinary component, then performs the existence check with os.path.isfile().

Reproduction

Windows is emulated with the technique already used by the project's own test suite (test/testtemplate.py:1398-1401):

python import os, ntpath os.path = ntpath

from mako.lookup import TemplateLookup lookup = TemplateLookup(directories=["root/tpl"])

for uri in ["ok.html", "//../../secret.txt", "\\..\\..\\secret.txt", "../../secret.txt", "C:/../../../secret.txt", "C:\\..\\..\\..\\secret.txt", "d:/../../../secret.txt"]: try: t = lookup.gettemplate(uri) print(repr(uri), "-> filename=", t.filename, repr(t.render())) except Exception as e: print(repr(uri), "-> REFUSED", type(e).name)

Against 1.4.1, with a sentinel file written outside the configured directory:

'ok.html' -> root/tpl/ok.html 'OK' (positive control) '//../../secret.txt' -> REFUSED (CVE-2026-41205 fix works) '\..\..\secret.txt' -> REFUSED (CVE-2026-44307 fix works) '../../secret.txt' -> REFUSED 'C:/../../../secret.txt' -> reads the sentinel 'C:\..\..\..\secret.txt' -> reads the sentinel 'd:/../../../secret.txt' -> reads the sentinel

On POSIX the same URIs are refused, because posixpath.normpath keeps C: as an ordinary component and the .. survive to be inspected. The issue is Windows-only.

Note that d:/../../../secret.txt resolves relative to the template root, not to drive D: -- this is not a cross-drive read. Reaching another drive would require a leading .., which ntpath.normpath renders as ..\..\D:\x and the existing guard catches.

Impact

If an application on Windows passes user-controlled template names or include paths to TemplateLookup.gettemplate(), an attacker may load and disclose any file readable by the application process on the same volume as the template directory, not merely files adjacent to it. The primary impact is local file disclosure. If the targeted file contains Mako/Python template syntax, it may also be parsed and executed as a template.

As with CVE-2026-41205, the URI is not generally reachable through a raw URL path, since a conforming URL normalizer collapses C:/../.. first. The relevant vectors are query strings, form and JSON bodies, route parameters, and <%include file="${...}"/>.

Remediation

Normalize both sides with the same module. The resolution side already commits to posixpath, so the confinement check should as well:

python unorm = posixpath.normpath(self.uri.replace("\\", "/").lstrip("/")) if unorm.startswith(".."): raise exceptions.TemplateLookupException(...)

This closes the drive case for the same reason it closes //: posixpath treats C: as an ordinary component, so the .. segments survive to be inspected. Verified to block all three drive forms with the full test suite passing.

Credit

Reported by Eurico Nicacio under coordinated disclosure.

IBM Concert 1.0.0 through 3.0.0 could allow a local attacker to obtain sensitive information due to recursive copying of build context directories into container images.

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

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

IBM Concert 1.0.0 through 3.0.0 could allow a remote attacker to traverse directories on the system. An attacker could send a specially crafted URL request containing "dot dot " sequences ( /.. /) to view arbitrary files on the system.

IBM Concert 1.0.0 through 3.0.0 could allow a remote authenticated attacker to cause a denial of service due to improper enforcement of storage limits.

IBM Concert 1.0.0 through 3.0.0 is vulnerable to improper access control which allows unauthorized modification of application files.

IBM Concert 1.0.0 through 3.0.0 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system.

IBM Concert 1.0.0 through 3.0.0 allows recursive copying of directories without proper controls which can lead to unintentional inclusion of sensitive or unnecessary files and increased attack surface.

IBM Concert 1.0.0 through 3.0.0 could allow an unauthorized user to inject data into log messages due to improper neutralization of special elements when written to log files.

IBM Concert 1.0.0 through 3.0.0 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.

Summary A vulnerability in the xDS RBAC HTTP filter implementation in grpc-go allows remote attackers to bypass authorization policies (specifically DENY rules) by using mixed-case or canonical-case header matchers (e.g., X-Role instead of x-role). Additionally, the safety guards introduced by gRFC A41 to block grpc- prefixed headers can be evaded via variations in casing (e.g., Grpc-Status).

Impact When an operator defines an RBAC policy referencing headers containing uppercase letters (e.g. X-Role), grpc-go fails to match incoming metadata keys because they are unconditionally lowercased. Because of this case-sensitivity mismatch, a policy designed to block requests containing specific header values fails open: the rule is evaluated as a non-match, and traffic that should have been rejected is served.

Furthermore, gRFC A41 requires rejecting configuration schemas specifying header matchers starting with grpc-. Because this check is executed case-sensitively in grpc-go, attackers can bypass the validation by specifying titles like Grpc-Status.

Patches The problem is fixed in master and in the 1.83.1 release.

IBM Concert 1.0.0 through 2.3.1 could allow a remote attacker to perform unauthorized actions using man in the middle techniques due to improper certificate validation.

adm-zip 0.5.9 through 0.6.0 follows symbolic links at the extraction destination. Utils.sanitize in util/utils.js enforces containment by comparing only the string form of an archive entry name against the resolved extraction root, and Utils.writeFileTo opens the computed destination with fs.openSync(path, "w", 0o666), which resolves symbolic links and carries neither ONOFOLLOW nor a pre-write fs.lstatSync check. When a path component at the destination already exists as a symbolic link pointing outside the extraction root, extractAllTo, extractAllToAsync and extractEntryTo write the entry contents through that link and then chmod its target, placing attacker-controlled content in a file outside the root without any traversal sequence appearing in the archive. Reaching the write requires overwrite to be enabled, because the preceding fs.existsSync check also resolves the link and otherwise declines. An attacker able to create a symbolic link inside a shared, reused or predictable extraction directory, such as a temporary directory or a continuous integration workspace, can overwrite any file the extracting process is permitted to write.

Impact

The fix for CVE-2026-3635 (GHSA-444r-cwp2-x5xf) added a proxyFn(socket.remoteAddress, 0) guard on the X-Forwarded- reads in request.host, request.protocol, request.hostname, request.ip, and request.ips. That guard closes the IP, CIDR, and custom-function forms of trustProxy correctly because those forms compile to predicates that inspect the connecting address. The hop-count form (trustProxy: <number>) compiles to a predicate that structurally ignores the address argument, so the guard reduces to 0 < tp, always true for any tp >= 1.

Applications configured with trustProxy: <number> (documented as "behind N reverse proxies", trustProxy: 1 being the canonical single-proxy setting) remain vulnerable. An attacker who can reach the Fastify origin directly, bypassing the front-facing proxy, can spoof the request fields exactly as in the unpatched version. Impact class matches the parent CVE-2026-3635: host injection in generated URLs, HTTPS-enforcement bypass, secure-cookie / CSRF-origin bypass, host-based routing and cache poisoning.

Patches

Patched in fastify 5.12.1. The numeric form of trustProxy is now disabled at runtime and removed from the TypeScript type union.

Workarounds

- Migrate to an IP / CIDR / custom-function trustProxy value that validates the connecting address. Custom functions must inspect the address argument, not only the hop index. - Ensure the Fastify origin is only reachable through the trusted proxy chain (no direct network path).

Impact

fastify before 5.12.1, when a route uses a root-level primitive body schema (for example an integer with a minimum and maximum) and the default type coercion, validates the coerced value but exposes the original, uncoerced value to the route handler. For example, a JSON body "10" is coerced to the number 10 and passes an integer 1 to 10 schema, but request.body stays the string "10". An application that trusts the validated type is handed a value that did not satisfy the schema, which can bypass limits the application enforces on that typed value. Object and array body schemas are not affected, they coerce their members in place.

Patches

Upgrade to fastify 5.12.1.

Workarounds

Until you can upgrade, avoid relying on the validated type of a root primitive body. Wrap the value in an object schema (object properties are coerced in place), for example accept { "value": 10 } and read request.body.value, or re-check the type in the handler.

TypeORM is a TypeScript and JavaScript ORM for Node.js that supports PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, Oracle, and other databases. Prior to versions 0.3.31 and 1.1.0, typeorm migration:generate embeds database schema metadata into JavaScript or TypeScript template literals in src/commands/MigrationGenerateCommand.ts, escaping backticks but not ${...} interpolation. An attacker with database schema write access can place a payload in column COMMENT or DEFAULT metadata, or another introspected schema string, and the JavaScript engine evaluates the payload when the generated migration is loaded through migration:run, import, or require. This issue is fixed in versions 0.3.31 and 1.1.0.

Summary

Every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target.

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) may therefore treat 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

isInSubnet in src/common.ts opens with a guard that compares the two prefix lengths:

js export function isInSubnet(this, address) { if (this.subnetMask < address.subnetMask) { return false; // <-- reached before any bit comparison }

if (this.mask(address.subnetMask) === address.mask()) { return true; }

return false; }

That guard is correct for the question isInSubnet is named for — whether one network is contained in another, where a /0 network genuinely is not inside a /8. It is wrong for classification, which asks a question about the address itself and must not depend on the prefix the caller happened to write. /0 is shorter than every reference prefix in the special-use tables (loopback /8, link-local /16, CGNAT /10, ULA /7, multicast /4), so for a classification call the bit comparison is never reached and the method returns false.

The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask — the defect is solely that the containment guard sits in the classification path. Host bits are retained through parsing, so correctForm() still yields the real target and the address remains fully usable for connecting.

/0 is the universal case because it is shorter than every reference prefix, but any suffix shorter than the specific range being tested has the same effect: 10.0.0.5/7 defeats isPrivate() for 10.0.0.0/8.

Affected versions

>= 10.1.1, <= 10.2.1. The is classification API was introduced for Address4 in 10.1.1 and extended to Address6 in 10.2.0; releases before 10.1.1 do not expose it and are not affected through this vector. The containment guard itself is much older, but isInSubnet alone is a subnet-containment predicate whose behavior here is correct.

This also defeats the fix released in 10.2.1 for GHSA-22jq-vg5j-6vgg: that release classifies IPv4-mapped and NAT64 addresses by their embedded IPv4 address, but the normalization is reached through isInSubnet, so ::ffff:127.0.0.1/0 reverts to being reported as non-internal.

Impact

Every classifier is affected on both Address4 and Address6. The sole exception is Address6.isLinkLocal() for native fe80::/10 addresses, which compares raw bits directly; its IPv4-mapped path is still affected.

| Address | Reported as | Actually points at | |---|---|---| | 127.0.0.1/0 | not loopback | loopback (127.0.0.0/8) | | 10.0.0.1/0, 10.0.0.5/7 | not private | RFC 1918 10/8 | | 172.16.5.5/0 | not private | RFC 1918 172.16/12 | | 192.168.1.1/0 | not private | RFC 1918 192.168/16 | | 169.254.169.254/0 | not link-local | link-local / cloud metadata (IMDS) | | 100.64.0.1/0 | not CGNAT | CGNAT 100.64/10 | | 0.0.0.0/0, 255.255.255.255/0 | not unspecified / not broadcast | unspecified / broadcast | | ::1/0 | not loopback | IPv6 loopback | | fc00::1/0 | not ULA, not private | IPv6 ULA fc00::/7 | | ff02::1/0 | not multicast | IPv6 multicast | | ::ffff:127.0.0.1/0 | not loopback | loopback, via IPv4-mapped | | ::ffff:169.254.169.254/0 | not link-local | IMDS, via IPv4-mapped | | 64:ff9b::7f00:1/0 | not loopback | loopback, via NAT64 |

getType() returns Global unicast for all of the IPv6 cases above, and getScope() follows it.

Reachability

A CIDR suffix is not legal in a URL host, so this is not reachable through the most common SSRF shape. new URL('http://127.0.0.1/0') parses hostname as 127.0.0.1 and pathname as /0, and a guard that classifies the extracted hostname is unaffected. Exploitation requires an application that accepts a bare address string that may carry a suffix and passes it to the constructor before classifying — for example an allow/deny field, a webhook target, or a proxy destination taken as a plain host rather than parsed out of a URL.

Proof of concept

npm i ip-address@10.2.1, then:

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

// true => block as internal, false => allow outbound function isBlocked(host) { try { const a = new Address4(host); return a.isPrivate() || a.isLoopback() || a.isLinkLocal() || a.isCGNAT() || a.isMulticast() || a.isUnspecified() || a.isBroadcast(); } catch {} try { const a = new Address6(host); return a.isPrivate() || a.isLoopback() || a.isLinkLocal() || a.isULA() || a.isMulticast() || a.isUnspecified(); } catch {} return false; }

for (const h of ['127.0.0.1', '10.0.0.1', '::1', '127.0.0.1/0', '10.0.0.5/7', '169.254.169.254/0', '::1/0', '::ffff:127.0.0.1/0', '64:ff9b::7f00:1/0']) { console.log(isBlocked(h) ? 'BLOCK ' : 'ALLOW ', h, '->', new (h.includes(':') ? Address6 : Address4)(h).correctForm()); }

On affected versions every suffixed internal target is allowed, and correctForm() shows the request would reach the real internal address:

BLOCK 127.0.0.1 -> 127.0.0.1 BLOCK 10.0.0.1 -> 10.0.0.1 BLOCK ::1 -> ::1 ALLOW 127.0.0.1/0 -> 127.0.0.1 ALLOW 10.0.0.5/7 -> 10.0.0.5 ALLOW 169.254.169.254/0 -> 169.254.169.254 ALLOW ::1/0 -> ::1 ALLOW ::ffff:127.0.0.1/0 -> ::ffff:7f00:1 ALLOW 64:ff9b::7f00:1/0 -> 64:ff9b::7f00:1

The first three lines are blocked as expected; the same destinations with a CIDR suffix are allowed through.

Remediation

Upgrade to the patched release. In the fix, classification no longer consults the address's own prefix: a new isHostInSubnet() compares the address's host bits against the reference range only, and every classifier (isLoopback, isPrivate, isLinkLocal, isCGNAT, isMulticast, isUnspecified, isBroadcast, isULA, isMapped4, isTeredo, is6to4, isDocumentation, getType, and the IPv4-mapped/NAT64 normalization behind embeddedIPv4) uses it. isInSubnet keeps its subnet-containment semantics unchanged, including the guard that a wider network is not contained in a narrower one. After upgrading, new Address4('127.0.0.1/0').isLoopback() returns true.

If you cannot upgrade immediately, strip the suffix before classifying by re-parsing addressMinusSuffix:

js const parsed = new Address4(userInput); const host = new Address4(parsed.addressMinusSuffix); // classify this one

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.

Credit

Reported by @hi-im-glitchless.

pip absolute path traversal during download from malicious package indexes

@fastify/forwarded resolves client addresses from the X-Forwarded-For header. In versions before 3.0.2, when the header contains two or more comma separated entries, the parser trims only space characters and does not strip horizontal tabs, even though RFC 7230 defines optional whitespace as both space and tab. As a result, an entry padded with a tab keeps the literal tab in the resolved address string. Applications that make exact string match security decisions on the resolved client IP, such as an allowlist, a blocklist, a per IP rate limit key, or audit log correlation, can be evaded because the tab corrupted string no longer matches the expected value. This does not cross the trust boundary, since a tab corrupted string is not a valid IP and cannot be mistaken for a trusted proxy. The issue is fixed in @fastify/forwarded 3.0.2.

In DOMPurify through 3.3.3, function predicates supplied via ADDATTR or ADDTAGS to DOMPurify.sanitize() persist in internal state (EXTRAELEMENTHANDLING) across subsequent sanitize() calls on the same instance. If a later call on the same instance provides ADDATTR or ADDTAGS as an array rather than a function, the previously set function handler is neither cleared nor overwritten, so it continues to approve attacker-controlled attributes or tags. This can allow dangerous event-handler attributes or forbidden tags (bypassing FORBIDTAGS) to survive sanitization, resulting in cross-site scripting. The vendor (Cure53) considers this an edge case outside DOMPurify's threat model; the referenced advisory lists 3.4.0 as the patched version.

fflate through 0.8.2 is vulnerable to denial of service via an infinite loop in unzipSync(). A crafted ZIP archive with a central directory entry declaring compressedsize=0xFFFFFFFF (ZIP64 sentinel) but missing the required ZIP64 extra field tag 0x0001 causes z64e() to loop indefinitely due to out-of-bounds reads returning undefined, which coerces to 0, keeping the loop condition permanently true.

Improper encoding of non-finite floating-point values during MapMessage JSON serialization in Apache Log4j API produces output that is not valid JSON. This issue affects Apache Log4j API versions 2.13.1 through 2.25.4 and version 2.26.0.

The fix for CVE-2026-34481 did not cover all code paths: when a MapMessage contains a non-finite IEEE 754 value (NaN, Infinity, or -Infinity), MapMessage.asJson() emits the corresponding bare token. RFC 8259 does not permit these tokens, so a conformant parser rejects the resulting document.

The defect is reachable only when both of the following conditions hold:

The application uses the message resolver

Summary

cx() in hono/css composes class names from plain strings but marks the result as already-escaped without HTML-escaping the input. When the result is used as a JSX class attribute during server-side rendering, the value is written into the attribute unescaped, so untrusted input can break out of the class attribute and inject arbitrary markup, leading to Cross-Site Scripting (XSS).

Details

Because the composed value is treated as pre-escaped, the HTML attribute escaping normally applied to interpolated values is skipped, and characters such as " pass through unescaped — allowing a value to terminate the attribute and add further attributes or elements. This arises when an application passes untrusted, user-controlled input as a class name to cx(), for example when merging a base class with an externally provided className.

Impact

During server-side rendering, an attacker who controls a value passed to cx() can inject arbitrary HTML into the page, resulting in stored or reflected XSS in the victim's browser.

This may lead to:

- Execution of attacker-controlled script in the victim's browser session. - Session hijacking, credential theft, or actions performed on behalf of the victim.

Applications are affected only if they render JSX server-side and pass untrusted input as a class name to cx().

Summary

hono/jsx did not isolate context values per request during server-side rendering. While an async component was suspended on await, its provided context value stayed observable to other requests rendering concurrently, so useContext() could return a value from a different in-flight request.

Details

During server-side rendering, context values were kept in a process-wide structure rather than scoped to each request's render. While an async component awaited, another request entering the same provider could observe or replace the value; when the first render resumed, it could read the other request's context.

This affects the usual ways request-scoped data is passed through a server-rendered JSX tree:

- createContext() / useContext() - the jsxRenderer middleware and useRequestContext()

It arises only when context is read after an await inside an async component while requests render concurrently. Reading context synchronously (before any await), purely synchronous rendering, and client-side (DOM) rendering are not affected.

Impact

Under concurrent requests, a response could be rendered with another request's context. A user may receive HTML rendered for a different user, and an authorization check performed after an await may be evaluated against another user's data.

This may lead to:

- disclosure of rendered output intended for another user - authorization decisions made with the wrong request's context - cross-request mixing of session or other request-scoped state