<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from pysec</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 08 Jul 2026 12:32:10 +0000</lastBuildDate>
    <item>
      <title>pysec-2026-2081</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2081</link>
      <description>Apache IoTDB DataNode’s internal RPC interface for creating Trigger instances uses the uploaded Trigger JAR name to build a file path without sufficient validation. If the internal DataNode RPC port is exposed to an untrusted network, an attacker may use path traversal sequences in the JAR name to write files outside the intended Trigger installation directory. This could allow arbitrary file write with the permissions of the IoTDB process.

This issue affects Apache IoTDB: from 1.3.3 before 2.0.8.

Users are recommended to upgrade to version 2.0.8, which fixes the issue.</description>
      <content:encoded>Apache IoTDB DataNode’s internal RPC interface for creating Trigger instances uses the uploaded Trigger JAR name to build a file path without sufficient validation. If the internal DataNode RPC port is exposed to an untrusted network, an attacker may use path traversal sequences in the JAR name to write files outside the intended Trigger installation directory. This could allow arbitrary file write with the permissions of the IoTDB process.

This issue affects Apache IoTDB: from 1.3.3 before 2.0.8.

Users are recommended to upgrade to version 2.0.8, which fixes the issue.</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2081</guid>
      <pubDate>Mon, 06 Jul 2026 09:16:35 +0000</pubDate>
    </item>
    <item>
      <title>pysec-2026-2080</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2080</link>
      <description>Authentication Bypass by Spoofing vulnerability in Apache IoTDB.
Certain Thrift RPC query handlers lack strict validation of the sessionId
parameter. An attacker can construct requests with a forged sessionId and,
without performing openSession authentication, receive valid query results.
This allows authentication bypass and unauthorized reading of time-series
data.


This issue affects Apache IoTDB: from 1.3.3 before 2.0.8.

Users are recommended to upgrade to version 2.0.8, which fixes the issue.</description>
      <content:encoded>Authentication Bypass by Spoofing vulnerability in Apache IoTDB.
Certain Thrift RPC query handlers lack strict validation of the sessionId
parameter. An attacker can construct requests with a forged sessionId and,
without performing openSession authentication, receive valid query results.
This allows authentication bypass and unauthorized reading of time-series
data.


This issue affects Apache IoTDB: from 1.3.3 before 2.0.8.

Users are recommended to upgrade to version 2.0.8, which fixes the issue.</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2080</guid>
      <pubDate>Mon, 06 Jul 2026 09:16:35 +0000</pubDate>
    </item>
    <item>
      <title>pysec-2026-2079</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2079</link>
      <description>Uncontrolled Resource Consumption vulnerability in Apache IoTDB. 

Some interface fails to impose reasonable
limits on the time span and aggregation interval of the query. An attacker
can construct a request with extreme parameters (e.g., a very large time
range combined with a minimal interval). This forces the DataNode to build
an enormous result set in memory, which exhausts the Java heap and causes
the DataNode process to crash.

This issue affects Apache IoTDB: from 1.3.3 before 2.0.8.

Users are recommended to upgrade to version 2.0.8, which fixes the issue.</description>
      <content:encoded>Uncontrolled Resource Consumption vulnerability in Apache IoTDB. 

Some interface fails to impose reasonable
limits on the time span and aggregation interval of the query. An attacker
can construct a request with extreme parameters (e.g., a very large time
range combined with a minimal interval). This forces the DataNode to build
an enormous result set in memory, which exhausts the Java heap and causes
the DataNode process to crash.

This issue affects Apache IoTDB: from 1.3.3 before 2.0.8.

Users are recommended to upgrade to version 2.0.8, which fixes the issue.</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2079</guid>
      <pubDate>Mon, 06 Jul 2026 09:16:35 +0000</pubDate>
    </item>
    <item>
      <title>pysec-2026-2078</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2078</link>
      <description>NLTK (Natural Language Toolkit) is a suite of open source Python modules, data sets, and tutorials supporting research and development in Natural Language Processing. Prior to 3.10.0-rc1, nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK's SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. This vulnerability is fixed in 3.10.0-rc1.</description>
      <content:encoded>NLTK (Natural Language Toolkit) is a suite of open source Python modules, data sets, and tutorials supporting research and development in Natural Language Processing. Prior to 3.10.0-rc1, nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK's SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. This vulnerability is fixed in 3.10.0-rc1.</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2078</guid>
      <pubDate>Mon, 22 Jun 2026 19:17:20 +0000</pubDate>
    </item>
    <item>
      <title>pysec-2026-2077</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2077</link>
      <description>### Impact
There is a stored cross site scripting vulnerability for SVG images.

Note that an image tag with an SVG image as source is never vulnerable, even when the SVG image contains malicious code. To exploit the vulnerability, an attacker would first need to upload an image, and then trick a user into following a specially crafted link.

All versions of Zope are impacted on sites that allow untrusted users to upload images.


### Patches
Patches will be released in Zope 4.8.10 and 5.8.5.

### Workarounds
Make sure the "Add Documents, Images, and Files" permission is only assigned to trusted roles. By default only the Manager has this permission.</description>
      <content:encoded>### Impact
There is a stored cross site scripting vulnerability for SVG images.

Note that an image tag with an SVG image as source is never vulnerable, even when the SVG image contains malicious code. To exploit the vulnerability, an attacker would first need to upload an image, and then trick a user into following a specially crafted link.

All versions of Zope are impacted on sites that allow untrusted users to upload images.


### Patches
Patches will be released in Zope 4.8.10 and 5.8.5.

### Workarounds
Make sure the "Add Documents, Images, and Files" permission is only assigned to trusted roles. By default only the Manager has this permission.</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2077</guid>
      <pubDate>Tue, 07 Jul 2026 11:45:24 +0000</pubDate>
    </item>
    <item>
      <title>pysec-2026-2076</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2076</link>
      <description>### Impact
Anonymous users can delete the user data maintained by an `AccessControl.userfolder.UserFolder` which may prevent any privileged access.

### Patches
The problem is fixed in version 7.2.

### Workarounds
The problem can be fixed by adding `data__roles__ = ()` to `AccessControl.userfolder.UserFolder`.

### References
https://github.com/zopefoundation/AccessControl/issues/159</description>
      <content:encoded>### Impact
Anonymous users can delete the user data maintained by an `AccessControl.userfolder.UserFolder` which may prevent any privileged access.

### Patches
The problem is fixed in version 7.2.

### Workarounds
The problem can be fixed by adding `data__roles__ = ()` to `AccessControl.userfolder.UserFolder`.

### References
https://github.com/zopefoundation/AccessControl/issues/159</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2076</guid>
      <pubDate>Tue, 07 Jul 2026 14:34:43 +0000</pubDate>
    </item>
    <item>
      <title>pysec-2026-2075</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2075</link>
      <description>### Impact
Python's "format" functionality allows someone controlling the format string to "read" objects accessible (recursively) via attribute access and subscription from accessible objects. Those attribute accesses and subscriptions use Python's full blown `getattr` and `getitem`, not the policy restricted `AccessControl` variants `_getattr_` and `_getitem_`. This can lead to critical information disclosure.

`AccessControl` already provides a safe variant for `str.format` and denies access to `string.Formatter`. However, `str.format_map` is still unsafe.

Affected are all users who allow untrusted users to create `AccessControl` controlled Python code and execute it.

### Patches
A fix will be introduced in the versions 4.4, 5.8 and 6.2.

### Workarounds
There are no workarounds.

### References
https://github.com/zopefoundation/RestrictedPython/security/advisories/GHSA-xjw2-6jm9-rf67 describes the corresponding problem for `RestrictedPython`.
</description>
      <content:encoded>### Impact
Python's "format" functionality allows someone controlling the format string to "read" objects accessible (recursively) via attribute access and subscription from accessible objects. Those attribute accesses and subscriptions use Python's full blown `getattr` and `getitem`, not the policy restricted `AccessControl` variants `_getattr_` and `_getitem_`. This can lead to critical information disclosure.

`AccessControl` already provides a safe variant for `str.format` and denies access to `string.Formatter`. However, `str.format_map` is still unsafe.

Affected are all users who allow untrusted users to create `AccessControl` controlled Python code and execute it.

### Patches
A fix will be introduced in the versions 4.4, 5.8 and 6.2.

### Workarounds
There are no workarounds.

### References
https://github.com/zopefoundation/RestrictedPython/security/advisories/GHSA-xjw2-6jm9-rf67 describes the corresponding problem for `RestrictedPython`.
</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2075</guid>
      <pubDate>Tue, 07 Jul 2026 11:45:23 +0000</pubDate>
    </item>
    <item>
      <title>pysec-2026-2074</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2074</link>
      <description>A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library, affecting all versions prior to 3.19.1. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding. The vulnerability was addressed in version 3.19.1 of jaraco/zipp.</description>
      <content:encoded>A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library, affecting all versions prior to 3.19.1. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding. The vulnerability was addressed in version 3.19.1 of jaraco/zipp.</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2074</guid>
      <pubDate>Tue, 07 Jul 2026 14:34:36 +0000</pubDate>
    </item>
    <item>
      <title>pysec-2026-2073</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2073</link>
      <description>### Impact

The Python package "zhmcclient" writes password-like properties in clear text into its HMC and API logs in the following cases:

* The 'boot-ftp-password' and 'ssc-master-pw' properties when creating or updating a partition in DPM mode, in the zhmcclient API and HMC logs
* The 'ssc-master-pw' and 'zaware-master-pw' properties when updating an LPAR in classic mode, in the zhmcclient API and HMC logs
* The 'ssc-master-pw' and 'zaware-master-pw' properties when creating or updating an image activation profile in classic mode, in the zhmcclient API and HMC logs
* The 'password' property when creating or updating an HMC user, in the zhmcclient API log
* The 'bind-password' property when creating or updating an LDAP server definition, in the zhmcclient API and HMC logs

This issue affects only users of the zhmcclient package that have enabled the Python loggers named "zhmcclient.api" (for the API log) or "zhmcclient.hmc" (for the HMC log) and that use the functions listed above.

### Patches

Has been fixed in zhmcclient version 1.18.1

### Workarounds

Not applicable, since fix is available.

### References

None
</description>
      <content:encoded>### Impact

The Python package "zhmcclient" writes password-like properties in clear text into its HMC and API logs in the following cases:

* The 'boot-ftp-password' and 'ssc-master-pw' properties when creating or updating a partition in DPM mode, in the zhmcclient API and HMC logs
* The 'ssc-master-pw' and 'zaware-master-pw' properties when updating an LPAR in classic mode, in the zhmcclient API and HMC logs
* The 'ssc-master-pw' and 'zaware-master-pw' properties when creating or updating an image activation profile in classic mode, in the zhmcclient API and HMC logs
* The 'password' property when creating or updating an HMC user, in the zhmcclient API log
* The 'bind-password' property when creating or updating an LDAP server definition, in the zhmcclient API and HMC logs

This issue affects only users of the zhmcclient package that have enabled the Python loggers named "zhmcclient.api" (for the API log) or "zhmcclient.hmc" (for the HMC log) and that use the functions listed above.

### Patches

Has been fixed in zhmcclient version 1.18.1

### Workarounds

Not applicable, since fix is available.

### References

None
</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2073</guid>
      <pubDate>Tue, 07 Jul 2026 14:34:46 +0000</pubDate>
    </item>
    <item>
      <title>pysec-2026-2072</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2072</link>
      <description>ZenML Server in the ZenML package before 0.46.7 for Python allows remote privilege escalation because the `/api/v1/users/{user_name_or_id}/activate` REST API endpoint allows access on the basis of a valid username along with a new password in the request body. These are also patched versions: 0.44.4, 0.43.1, and 0.42.2.</description>
      <content:encoded>ZenML Server in the ZenML package before 0.46.7 for Python allows remote privilege escalation because the `/api/v1/users/{user_name_or_id}/activate` REST API endpoint allows access on the basis of a valid username along with a new password in the request body. These are also patched versions: 0.44.4, 0.43.1, and 0.42.2.</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2072</guid>
      <pubDate>Tue, 07 Jul 2026 11:45:33 +0000</pubDate>
    </item>
  </channel>
</rss>
