<?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 all</title>
    <link>https://cve.radiocsirt.org</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>Tue, 06 Oct 2026 19:08:59 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-25645 — Requests has Insecure Temp File Reuse in its extract_zipped_paths() utility function</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-25645</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; psf requests&lt;/p&gt;
&lt;p&gt;Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; psf requests&lt;/p&gt;
&lt;p&gt;Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2026-25645</guid>
    </item>
    <item>
      <title>GHSA-752w-5fwx-jx9f — PyJWT accepts unknown `crit` header extensions</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-752w-5fwx-jx9f</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: PyJWT&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;PyJWT does not validate the `crit` (Critical) Header Parameter defined in
RFC 7515 §4.1.11. When a JWS token contains a `crit` array listing
extensions that PyJWT does not understand, the library accepts the token
instead of rejecting it. This violates the **MUST** requirement in the RFC.&lt;/p&gt;
&lt;p&gt;This is the same class of vulnerability as CVE-2025-59420 (Authlib),
which received CVSS 7.5 (HIGH).&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## RFC Requirement&lt;/p&gt;
&lt;p&gt;RFC 7515 §4.1.11:&lt;/p&gt;
&lt;p&gt;&amp;gt; The &amp;#34;crit&amp;#34; (Critical) Header Parameter indicates that extensions to this
&amp;gt; specification and/or [JWA] are being used that **MUST** be understood and
&amp;gt; processed. [...] If any of the listed extension Header Parameters are
&amp;gt; **not understood and supported** by the recipient, then the **JWS is invalid**.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Proof of Concept&lt;/p&gt;
&lt;p&gt;```python
import jwt  # PyJWT 2.8.0
import hmac, hashlib, base64, json&lt;/p&gt;
&lt;p&gt;# Construct token with unknown critical extension
header = {&amp;#34;alg&amp;#34;: &amp;#34;HS256&amp;#34;, &amp;#34;crit&amp;#34;: [&amp;#34;x-custom-policy&amp;#34;], &amp;#34;x-custom-policy&amp;#34;: &amp;#34;require-mfa&amp;#34;}
payload = {&amp;#34;sub&amp;#34;: &amp;#34;attacker&amp;#34;, &amp;#34;role&amp;#34;: &amp;#34;admin&amp;#34;}&lt;/p&gt;
&lt;p&gt;def b64url(data):
    return base64.urlsafe_b64encode(data).rstrip(b&amp;#34;=&amp;#34;).decode()&lt;/p&gt;
&lt;p&gt;h = b64url(json.dumps(header, separators=(&amp;#34;,&amp;#34;, &amp;#34;:&amp;#34;)).encode())
p = b64url(json.dumps(payload, separators=(&amp;#34;,&amp;#34;, &amp;#34;:&amp;#34;)).encode())
sig = b64url(hmac.new(b&amp;#34;secret&amp;#34;, f&amp;#34;{h}.{p}&amp;#34;.encode(), hashlib.sha256).digest())
token = f&amp;#34;{h}.{p}.{sig}&amp;#34;&lt;/p&gt;
&lt;p&gt;# Should REJECT — x-custom-policy is not understood by PyJWT
try:
    result = jwt.decode(token, &amp;#34;secret&amp;#34;, algorithms=[&amp;#34;HS256&amp;#34;])
    print(f&amp;#34;AC…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: PyJWT&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;PyJWT does not validate the `crit` (Critical) Header Parameter defined in
RFC 7515 §4.1.11. When a JWS token contains a `crit` array listing
extensions that PyJWT does not understand, the library accepts the token
instead of rejecting it. This violates the **MUST** requirement in the RFC.&lt;/p&gt;
&lt;p&gt;This is the same class of vulnerability as CVE-2025-59420 (Authlib),
which received CVSS 7.5 (HIGH).&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## RFC Requirement&lt;/p&gt;
&lt;p&gt;RFC 7515 §4.1.11:&lt;/p&gt;
&lt;p&gt;&amp;gt; The &amp;#34;crit&amp;#34; (Critical) Header Parameter indicates that extensions to this
&amp;gt; specification and/or [JWA] are being used that **MUST** be understood and
&amp;gt; processed. [...] If any of the listed extension Header Parameters are
&amp;gt; **not understood and supported** by the recipient, then the **JWS is invalid**.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Proof of Concept&lt;/p&gt;
&lt;p&gt;```python
import jwt  # PyJWT 2.8.0
import hmac, hashlib, base64, json&lt;/p&gt;
&lt;p&gt;# Construct token with unknown critical extension
header = {&amp;#34;alg&amp;#34;: &amp;#34;HS256&amp;#34;, &amp;#34;crit&amp;#34;: [&amp;#34;x-custom-policy&amp;#34;], &amp;#34;x-custom-policy&amp;#34;: &amp;#34;require-mfa&amp;#34;}
payload = {&amp;#34;sub&amp;#34;: &amp;#34;attacker&amp;#34;, &amp;#34;role&amp;#34;: &amp;#34;admin&amp;#34;}&lt;/p&gt;
&lt;p&gt;def b64url(data):
    return base64.urlsafe_b64encode(data).rstrip(b&amp;#34;=&amp;#34;).decode()&lt;/p&gt;
&lt;p&gt;h = b64url(json.dumps(header, separators=(&amp;#34;,&amp;#34;, &amp;#34;:&amp;#34;)).encode())
p = b64url(json.dumps(payload, separators=(&amp;#34;,&amp;#34;, &amp;#34;:&amp;#34;)).encode())
sig = b64url(hmac.new(b&amp;#34;secret&amp;#34;, f&amp;#34;{h}.{p}&amp;#34;.encode(), hashlib.sha256).digest())
token = f&amp;#34;{h}.{p}.{sig}&amp;#34;&lt;/p&gt;
&lt;p&gt;# Should REJECT — x-custom-policy is not understood by PyJWT
try:
    result = jwt.decode(token, &amp;#34;secret&amp;#34;, algorithms=[&amp;#34;HS256&amp;#34;])
    print(f&amp;#34;AC…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-752w-5fwx-jx9f</guid>
    </item>
  </channel>
</rss>
