IBM Concert

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 1.0 through 3.0.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.

IBM Concert

IBM Concert 1.0 through 3.0.0 is vulnerable to Improper Certificate Validation.

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.

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

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.

Impact

Lodash versions 4.0.0 through 4.17.22 are vulnerable to prototype pollution in the .unset and .omit functions. An attacker can pass crafted paths which cause Lodash to delete methods from global prototypes.

The issue permits deletion of properties but does not allow overwriting their original behavior.

Patches

This issue is patched on 4.17.23.

Issue summary: Some non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions

A timing based side-channel exists in the libgcrypt RSA implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve successful decryption an attacker would have to be able to send a large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OAEP, and RSASVE.

Accounts. The issue was addressed with improved checks.

Issue summary: An application using the OpenSSL HTTP client API functions may trigger an out-of-bounds read if the 'noproxy' environment variable is set and the host portion of the authority component of the HTTP URL is an IPv6 address.

Impact summary: An out-of-bounds read can trigger a crash which leads to Denial of Service for an application.

The OpenSSL HTTP client API functions can be used directly by applications but they are also used by the OCSP client functions and CMP (Certificate Management Protocol) client implementation in OpenSSL. However the URLs used by these implementations are unlikely to be controlled by an attacker.

In this vulnerable code the out of bounds read can only trigger a crash. Furthermore the vulnerability requires an attacker-controlled URL to be passed from an application to the OpenSSL function and the user has to have a 'noproxy' environment variable set. For the aforementioned reasons the issue was assessed as Low severity.

The vulnerable code was introduced in the following patch releases: 3.0.16, 3.1.8, 3.2.4, 3.3.3, 3.4.0 and 3.5.0.

The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue, as the HTTP client implementation is outside the OpenSSL FIPS module boundary.

An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for mgroupSize on 32-bit platforms (where UINTMAX equals SIZEMAX).

An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINTMAX equals SIZEMAX).

Accounts. A logic issue was addressed with improved file handling.

A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.

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

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

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

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

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

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

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

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.2

OpenSSL 3.2 users should upgrade to OpenSSL 3.2.3

OpenSSL 3.1 users should upgrade to OpenSSL 3.1.7

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.15

Summary

The ip-restriction middleware (hono/ip-restriction) compares incoming IP addresses against configured deny and allow rules using string equality after partial normalization. Non-canonical IPv6 representations of an address already listed in a static rule — such as compressed forms, explicit-zero forms, or hex-notation IPv4-mapped addresses — do not match the normalized rule entry, causing the rule to be silently skipped.

Details

When the rule matcher is built, each configured IP rule is normalized to a canonical string form. Incoming IP addresses received at request time are then compared against those canonical strings without applying the same normalization. Because IPv6 permits multiple syntactically different representations of the same numeric address, a non-canonical form of a denied address fails the string lookup and proceeds to the CIDR check, which also finds no match for rules registered as static (no prefix length). The request is then allowed.

Affected non-canonical forms include:

- Compressed versus expanded notation (2001:db8::1 vs 2001:db8:0:0:0:0:0:1) - Hex-notation IPv4-mapped addresses (::ffff:7f00:1 vs ::ffff:127.0.0.1) - Zone identifier suffixes (e.g., fe80::1%eth0)

Additionally, invalid IP address strings provided as the remote address are not rejected and may result in unexpected allow or deny behavior.

This issue arises when applications use ipRestriction() with static (non-CIDR) rules and the IP address source can supply addresses in non-canonical IPv6 form.

Impact

A request from an IP address covered by a static deny rule may bypass the restriction if the address is presented in a non-canonical IPv6 form.

This may lead to:

- Unauthorized access to endpoints intended to be restricted to specific IP addresses - Bypass of IP-based access controls in environments where the runtime or an upstream proxy provides source addresses in a form that differs from the canonical form used in the rule configuration

This issue affects applications using hono/ip-restriction with static deny rules for IPv4 or IPv6 addresses, particularly when the source address is derived from proxy headers or custom getIP implementations that may return non-canonical forms.

Summary

The jwt and jwk middlewares do not verify that the Authorization header value uses theBearer scheme. Any two-part header value — regardless of the scheme name in the first position — proceeds to JWT verification. A request presenting a valid JWT under a non-Bearer scheme identifier (such as Basic or Token) is authenticated identically to a correctly formed Bearer request.

Details

When processing an Authorization (or custom) header, the middleware splits the value on whitespace and uses the second token as the JWT to verify. It does not check that the first token is bearer (case-insensitively). RFC 6750 specifies that JWT bearer tokens must be presented using the Bearer scheme; other scheme identifiers carry distinct semantics and may be subject to different policies in network-layer security controls.

This discrepancy means that scheme-aware external controls — such as WAF rules, API gateways, or reverse proxies that apply policies specific to the Bearer scheme identifier — can be bypassed by presenting a valid JWT under a different scheme name.

This issue affects hono/jwt and hono/jwk middleware.

Impact

An attacker who possesses a valid JWT may present it under a non-Bearer scheme identifier and still pass middleware authentication.

This may lead to:

- Bypass of network-layer security controls that inspect or filter requests based on the authorization scheme identifier - Token reuse across authentication schemes in applications that use multiple authorization mechanisms

This issue affects applications where hono/jwt or hono/jwk authentication is combined with external controls that enforce scheme-based access policies.

Summary

app.mount() strips the mount prefix from the incoming request path using the raw URL pathname, while route matching is performed against the percent-decoded path. This inconsistency causes the prefix to be stripped at the wrong position when the path contains percent-encoded multi-byte characters, resulting in the mounted sub-application receiving an incorrect path.

Details

When app.mount(prefix, subApp) is called, Hono calculates the number of characters to strip based on the decoded mount prefix length, but then applies that slice to the raw URL pathname. When the URL contains percent-encoded characters that expand to fewer characters when decoded (such as encoded non-ASCII characters), the two representations have different lengths, so the prefix is stripped at the wrong byte offset.

As a result, the sub-application receives a path that does not correspond to the intended sub-path — it may receive a partial or garbled path instead of the expected value after the mount prefix is removed.

This issue arises when an application uses app.mount() with paths that contain percent-encoded characters, particularly when the mount prefix itself or the request path contains encoded non-ASCII characters.

Impact

A mounted sub-application may receive an incorrectly stripped path, causing requests to be routed to unintended handlers within the sub-application.

This may lead to:

- Middleware or route handlers in the sub-application being bypassed or incorrectly matched due to the malformed path - Requests reaching sub-application routes that the developer did not intend to be accessible via the mounted path

This issue affects applications that use app.mount() where the request URL may contain percent-encoded characters in the mount prefix or subsequent path segments.

Summary

The serialize() function in hono/cookie validates domain and path options against characters that corrupt Set-Cookie header syntax (;, \r, \n), but does not apply the same validation to sameSite and priority. An application that passes user-controlled input into either option may produce a Set-Cookie response header containing attacker-chosen additional attributes.

Details

When constructing a Set-Cookie header value, serialize() appends the sameSite and priority option values directly into the output string after a presentation-only transformation (capitalizing the first character). Although the TypeScript type signature constrains these options to specific string literals, that constraint is not enforced at runtime; any string value, including one containing ; or line-feed characters, passes through unchanged.

The validation guard that rejects ;, \r, and \n from domain and path is not applied to sameSite or priority. An application that passes a request-derived value to either option therefore provides an injection point into the header line.

This issue arises when an application passes user-controlled input to the sameSite or priority option of setCookie() or serialize().

Impact

An attacker who can control the sameSite or priority option value may inject additional attributes into a Set-Cookie response header.

This may lead to:

- Cookie attribute injection — overriding Domain, Path, HttpOnly, Secure, or Max-Age for the affected cookie - HTTP response header injection on runtimes that do not strictly validate header values, enabling a second attacker-controlled Set-Cookie header in the same response

This issue affects applications that pass user-derived input into the sameSite or priority option of hono/cookie serialization functions.

Summary

The arrayLimit option in qs does not enforce limits for bracket notation (a[]=1&a[]=2), allowing attackers to cause denial-of-service via memory exhaustion. Applications using arrayLimit for DoS protection are vulnerable.

Details

The arrayLimit option only checks limits for indexed notation (a[0]=1&a[1]=2) but completely bypasses it for bracket notation (a[]=1&a[]=2).

Vulnerable code (lib/parse.js:159-162): javascript if (root === '[]' && options.parseArrays) { obj = utils.combine([], leaf); // No arrayLimit check }

Working code (lib/parse.js:175): javascript else if (index <= options.arrayLimit) { // Limit checked here obj = []; obj[index] = leaf; }

The bracket notation handler at line 159 uses utils.combine([], leaf) without validating against options.arrayLimit, while indexed notation at line 175 checks index <= options.arrayLimit before creating arrays.

PoC

Test 1 - Basic bypass: bash npm install qs

javascript const qs = require('qs'); const result = qs.parse('a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6', { arrayLimit: 5 }); console.log(result.a.length); // Output: 6 (should be max 5)

Test 2 - DoS demonstration: javascript const qs = require('qs'); const attack = 'a[]=' + Array(10000).fill('x').join('&a[]='); const result = qs.parse(attack, { arrayLimit: 100 }); console.log(result.a.length); // Output: 10000 (should be max 100)

Configuration: - arrayLimit: 5 (test 1) or arrayLimit: 100 (test 2) - Use bracket notation: a[]=value (not indexed a[0]=value)

Impact

Denial of Service via memory exhaustion. Affects applications using qs.parse() with user-controlled input and arrayLimit for protection.

Attack scenario: 1. Attacker sends HTTP request: GET /api/search?filters[]=x&filters[]=x&...&filters[]=x (100,000+ times) 2. Application parses with qs.parse(query, { arrayLimit: 100 }) 3. qs ignores limit, parses all 100,000 elements into array 4. Server memory exhausted → application crashes or becomes unresponsive 5. Service unavailable for all users

Real-world impact: - Single malicious request can crash server - No authentication required - Easy to automate and scale - Affects any endpoint parsing query strings with bracket notation

Suggested Fix

Add arrayLimit validation to the bracket notation handler. The code already calculates currentArrayLength at line 147-151, but it's not used in the bracket notation handler at line 159.

Current code (lib/parse.js:159-162): javascript if (root === '[]' && options.parseArrays) { obj = options.allowEmptyArrays && (leaf === '' || (options.strictNullHandling && leaf === null)) ? [] : utils.combine([], leaf); // No arrayLimit check }

Fixed code: javascript if (root === '[]' && options.parseArrays) { // Use currentArrayLength already calculated at line 147-151 if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } // If limit exceeded and not throwing, convert to object (consistent with indexed notation behavior) if (currentArrayLength >= options.arrayLimit) { obj = options.plainObjects ? { proto: null } : {}; obj[currentArrayLength] = leaf; } else { obj = options.allowEmptyArrays && (leaf === '' || (options.strictNullHandling && leaf === null)) ? [] : utils.combine([], leaf); } }

This makes bracket notation behaviour consistent with indexed notation, enforcing arrayLimit and converting to object when limit is exceeded (per README documentation).

Summary

In versions of cryptography prior to 46.0.5, DNS name constraints were only validated against SANs within child certificates, and not the "peer name" presented during each validation. Consequently, cryptography would allow a peer named bar.example.com to validate against a wildcard leaf certificate for .example.com, even if the leaf's parent certificate (or upwards) contained an excluded subtree constraint for bar.example.com.

This behavior resulted from a gap between RFC 5280 (which defines Name Constraint semantics) and RFC 9525 (which defines service identity semantics): put together, neither states definitively whether Name Constraints should be applied to peer names. To close this gap, cryptography now conservatively rejects any validation where the peer name would be rejected by a name constraint if it were a SAN instead.

In practice, exploitation of this bypass requires an uncommon X.509 topology, one that the Web PKI avoids because it exhibits these kinds of problems. Consequently, we consider this a medium-to-low impact severity.

See CVE-2025-61727 for a similar bypass in Go's crypto/x509.

Remediation

Users should upgrade to 46.0.6 or newer.

Attribution

Reporter: @1seal

Last updated 1 May 2025

A vulnerability in the packageindex module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.

Last updated 24 February 2025