IBM Concert 1.0.0 through 2.1.0 for Z hub component is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts.

IBM Concert 1.0.0 through 2.1.0 for Z hub framework is vulnerable to cross-site scripting. This vulnerability allows an unauthenticated attacker to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.

IBM Concert 1.0.0 through 2.1.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 2.1.0 could allow an attacker to obtain sensitive information using man in the middle techniques due to improper clearing of heap memory.

IBM Concert 1.0.0 through 2.1.0 stores potentially sensitive information in log files that could be read by a local user.

IBM Concert 1.0.0 through 2.1.0 is vulnerable to HTTP header injection, caused by improper validation of input by the HOST headers. This could allow an attacker to conduct various attacks against the vulnerable system, including cross-site scripting, cache poisoning or session hijacking.

IBM Concert 1.0.0 through 2.1.0 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system.

IBM Concert 1.0.0 through 2.1.0 stores sensitive information in cleartext during recursive docker builds which could be obtained by a local user.

A flaw was found in the Keycloak LDAP User Federation provider. This vulnerability allows an authenticated realm administrator to trigger deserialization of untrusted Java objects via a malicious LDAP server configuration.

SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.

SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.

Impact

A bug was found in containerd's CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks.

Repetitive calls of CRI Attach (e.g., kubectl attach) could increase the memory usage of containerd.

Patches

This bug has been fixed in the following containerd versions:

2.2.0 2.1.5 2.0.7 1.7.29

Users should update to these versions to resolve the issue.

Workarounds

Set up an admission controller to control accesses to pods/attach resources. e.g., Validating Admission Policy.

Credits

The containerd project would like to thank @Wheat2018 for responsibly disclosing this issue in accordance with the containerd security policy.

References

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-64329

For more information

If you have any questions or comments about this advisory:

Open an issue in containerd Email us at security@containerd.io

To report a security issue in containerd:

Report a new vulnerability

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in markdown-it allows Cross-Site Scripting (XSS). This vulnerability is associated with program files lib/renderer.mjs.

This issue affects markdown-it: 14.1.0. NOTE: the Supplier does not consider this issue to be a vulnerability.

A vulnerability in Python-Future modules 0.14.0 and above allows for arbitrary code execution via the unintended import of a file named test.py. When the module is loaded, it automatically imports test.py, if present in the same directory or in the sys.path. This behavior can be exploited by an attacker who has the ability to write files to the server, allowing the execution of arbitrary code.

Impact

In versions 0.8.5 and earlier of uv, remote ZIP archives were handled in a streamwise fashion, and file entries were not reconciled against the archive's central directory. This enabled two parser differentials against other Python package installers:

1. An attacker could contrive a ZIP archive that would extract with legitimate contents on some package installers, and malicious contents on others due to multiple local file entries. The attacker could choose which installer to target. 2. An attacker could contrive a "stacked" ZIP input with multiple internal ZIPs, which would be handled differently by different package installers. The attacker could choose which installer to target.

In both cases, the outcome is that an attacker can produce a ZIP with a consistent digest that expands differently with different installers.

The ZIP standard is ambiguous with respect to these behavior differentials. Consequently, these same differentials may be accepted ZIP parsers other than those used in uv. This advisory is for uv in particular, but all consumers of ZIP-based Python package distributions, e.g., pip, are potentially susceptible to similar parser differentials in other ZIP parsers.

The practical impact of these differentials is limited by a number of factors:

- To be compromised via this vulnerability, user interaction of some sort is required. In particular, the user must run uv install $package with an attacker-controlled $package. - When using wheel distributions, installation of the malicious package is not sufficient for execution of malicious code, the vicim would need to perform a separate invocation, e.g., python -c "import $package". - If a ZIP-based source distribution (which are less common than tarball source distributions), is encountered, malicious code can be executed during package resolution or installation. uv may invoke the malicious code when building the source distribution into a wheel. - The practical impact of these differentials is limited by a coordinated fix to Warehouse, PyPI's backend: Warehouse now rejects ZIPs exhibiting these differentials, limiting the ability of an attacker to distribute malicious ZIP distributions via PyPI. As part of that coordinated fix, a review of Warehouse revealed no evidence of exploitation.

Patches

Versions 0.8.6 and newer of uv address both of the parser differentials above, by refusing to process ZIPs with duplicated local file entries or stacked contents.

Workarounds

Users are advised to upgrade to 0.8.6 or newer to address this advisory.

Most users should experience no breaking changes as a result of the patch above. However, users who do experience breakage should carefully review their distributions for signs of malicious intent. Users may choose to set UVINSECURENOZIPVALIDATION=1 to revert to the previous behavior.

Attribution

This vulnerability was discovered separately by two different individuals: Caleb Brown (Google) and Tim Hatch (Netflix).

Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. In versions 28.2.0 through 28.3.2, when the firewalld service is reloaded it removes all iptables rules including those created by Docker. While Docker should automatically recreate these rules, versions before 28.3.3 fail to recreate the specific rules that block external access to containers. This means that after a firewalld reload, containers with ports published to localhost (like 127.0.0.1:8080) become accessible from remote machines that have network routing to the Docker bridge, even though they should only be accessible from the host itself. The vulnerability only affects explicitly published ports - unpublished ports remain protected. This issue is fixed in version 28.3.3.

Summary When parsing a multi-part form with large files (greater than the default max spool size) starlette will block the main thread to roll the file over to disk. This blocks the event thread which means we can't accept new connections.

Details Please see this discussion for details: https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403. In summary the following UploadFile code (copied from here) has a minor bug. Instead of just checking for self.inmemory we should also check if the additional bytes will cause a rollover.

python

@property def inmemory(self) -> bool: # check for SpooledTemporaryFile.rolled rolledtodisk = getattr(self.file, "rolled", True) return not rolledtodisk

async def write(self, data: bytes) -> None: if self.size is not None: self.size += len(data)

if self.inmemory: self.file.write(data) else: await runinthreadpool(self.file.write, data)

I have already created a PR which fixes the problem: https://github.com/encode/starlette/pull/2962

PoC See the discussion here for steps on how to reproduce.

Impact To be honest, very low and not many users will be impacted. Parsing large forms is already CPU intensive so the additional IO block doesn't slow down starlette that much on systems with modern HDDs/SSDs. If someone is running on tape they might see a greater impact.

Impact

Vert.x 4.5.12 has changed the semantics of the duplication of duplicated context.

Duplicated context is an object used to propagate data through a processing (synchronous or asynchronous). Each "transaction" or "processing" runs on its own isolated duplicated context.

Initially, duplicating a duplicated context was creating a fresh (empty) new context, meaning that the new duplicated context can be used to managed a separated transaction.

In Vert.x 4.5.12, this semantics has changed, and since the content of the parent duplicated context is copied into the new one, potentially leaking data.

This CVE is especially for Quarkus as Quarkus extensively uses the Vert.x duplicated context to implement context propagation. With the new semantic data from one transaction can leak to the data from another transaction. From a Vert.x point of view, this new semantic clarifies the behavior.

A significant amount of data is stored in the duplicated context, including request scope, security details, and metadata. Duplicating a duplicated context is rather rare and is only done in a few places:

- Quarkus REST Client when using OTel (but it's the same transaction, so no leak) - Quarkus Messaging connectors - Quarkus SmallRye Health (same transaction, so no leak)

Patches

After discussion with the Vert.x team, the change will be rolled back in Vert.x 4.x. A new API will be added to Vert.x 5 do distinguish the 2 cases.

Workarounds

When duplicating a duplicated context, the following code can be done to avoid the potential leak:

java ((ContextInternal) VertxContext.getRootContext(ctx)).duplicate()

This workaround would not be required once the Vert.x version containing the fix will be included. Note that the workaround would still work.

References

This issue have been reported in https://github.com/quarkusio/quarkus/issues/48227.

Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information.

Description A flaw was found in Keycloak. The org.keycloak.authorization package may be vulnerable to circumventing required actions, allowing users to circumvent requirements such as setting up two-factor authentication.

Incorrect Neutralization of Input During Web Page Generation in x/net in golang.org/x/net

HTTP Proxy bypass using IPv6 Zone IDs in golang.org/x/net

An attacker can craft an input to the Parse functions that would be processed non-linearly with respect to its length, resulting in extremely slow parsing. This could cause a denial of service.

1. Impacted Products Streamilt Open Source versions before 1.37.0.

2. Introduction Snowflake Streamlit open source addressed a security vulnerability via the static file sharing feature. The vulnerability was patched on Jul 25, 2024, as part of Streamlit open source version 1.37.0. The vulnerability only affects Windows.

3. Path Traversal Vulnerability 3.1 Description On May 12, 2024, Streamlit was informed via our bug bounty program about a path traversal vulnerability in the open source library. We fixed and merged a patch remediating the vulnerability on Jul 25, 2024. The issue was determined to be in the moderate severity range with a maximum CVSSv3 base score of 5.9 3.2 Scenarios and attack vector(s) Users of hosted Streamlit app(s) on Windows were vulnerable to a path traversal vulnerability when the static file sharing feature is enabled. An attacker could utilize the vulnerability to leak the password hash of the Windows user running Streamlit. 3.3 Resolution The vulnerability has been fixed in all Streamlit versions released since Jul 25, 2024. We recommend all users upgrade to Version 1.37.0.

4. Contact Please contact security@snowflake.com if you have any questions regarding this advisory. If you discover a security vulnerability in one of our products or websites, please report the issue to HackerOne. For more information, please see our Vulnerability Disclosure Policy.

Denial of Service in Temporal Server prior to version 1.20.5, 1.21.6, and 1.22.7 allows an authenticated user who has permissions to interact with workflows and has crafted an invalid UTF-8 string for submission to potentially cause a crashloop. If left unchecked, the task containing the invalid UTF-8 will become stuck in the queue, causing an increase in queue lag. Eventually, all processes handling these queues will become stuck and the system will run out of resources. The workflow ID of the failing task will be visible in the logs, and can be used to remove that workflow as a mitigation. Version 1.23 is not impacted. In this context, a user is an operator of Temporal Server.

Impact xml files like ".project" are parsed vulnerable against all sorts of XXE attacks. The user just needs to open any evil project or update an open project with a vulnerable file (for example for review a foreign repository or patch).

Vulnerablility was found by static code analysis (SonarLint).

Example .project file: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE price [ <!ENTITY xxe SYSTEM "http://127.0.0.1:49416/evil">]> <projectDescription> <name>p</name> <comment>&xxe;</comment> </projectDescription>

Patches Similar patches including junit test that shows the vulnerability have already applied to PDE (see https://github.com/eclipse-pde/eclipse.pde/pull/667). A solution to platform should be the same: just reject parsing any XML that contains any DOCTYPE.

Workarounds No known workaround. User can only avoid to get/open any foreign files with eclipse. Firewall rules against loss of data (but not against XML bomb).

References https://cwe.mitre.org/data/definitions/611.html https://rules.sonarsource.com/java/RSPEC-2755 https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/8 (Report for multiple projects affected)