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

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.

An unrecovered panic in the event stream header decoder in Amazon AWS SDK for Go v2 before release-2026-03-23 might allow an unauthenticated remote actor to terminate the consuming application process via a crafted event stream response frame containing a header value type outside the valid range.

To remediate this issue, users should upgrade to release-2026-03-23 or later, and patch any forked or derivative code.

Impact An unauthenticated remote attacker can initiate a gRPC stream and purposefully fragment their payload into millions of tiny (e.g., 1-byte) HTTP/2 DATA frames. Even if the total payload volume falls within the configured connection and stream flow-control windows, each independent fragment incurs memory overhead due to internal tracking structures and queue allocation.

Repeated fragmentation massively inflates the heap space consumed by the stream. An attacker multiplexing multiple concurrent streams can exhaust the memory bounds of the runtime, forcing a runtime panic or OutOfMemory condition and leading to a remote Denial of Service (DoS).

Patches The change to fix this issue is merged in master and a patch release, 1.83.1, has been published that contains this fix.

Workarounds This vulnerability is mitigated by implementing receive buffer compaction. Consecutive small data buffers are automatically coalesced into larger buffers from a shared pool once the overhead is perceived to be excessive relative to actual payload data, drastically minimizing per-frame memory overheads.

This behavior is enabled by default. A temporary escape hatch is provided via the environment variable GRPCGOEXPERIMENTALENABLERECEIVEBUFFERCOMPACTION=false to disable the feature if unforeseen issues arise, but it will be removed in a future release.

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 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 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 access or modify unauthorized resources due to the use of wildcards in RBAC permission definitions.

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 allows an unauthenticated remote attacker can supply specially crafted input that is incorporated into OS commands, resulting in arbitrary command execution on the underlying system. Successful exploitation allows remote code execution with the privileges of the affected application.

IBM Concert 1.0.0 through 3.0.0 is vulnerable to a buffer overflow, caused by improper bounds checking. A local user could overflow the buffer and execute arbitrary code on the system.

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 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.

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.

IBM Concert 1.0.0 through 3.0.0 references or accesses memory after it has been freed. This allows an attacker who can influence program execution or input may exploit this condition to corrupt memory, cause application crashes, or execute arbitrary code.