<?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://db.gcve.eu</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>Fri, 02 Oct 2026 05:46:42 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-57126</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-57126</link>
      <description>&lt;p&gt;PraisonAI is a multi-agent teams system. Prior to praisonaiagents 1.6.58, SpiderTools._validate_url calls _host_is_blocked, which checks literal host encodings but does not resolve DNS names before scrape_page, crawl, extract_links, extract_text, or URL-mention fetches connect. An attacker-controlled hostname resolving to a loopback, private, link-local, or cloud-metadata address therefore bypasses the SSRF policy without a rebinding race and can expose internal responses to the agent. This issue is fixed in praisonaiagents 1.6.58.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;PraisonAI is a multi-agent teams system. Prior to praisonaiagents 1.6.58, SpiderTools._validate_url calls _host_is_blocked, which checks literal host encodings but does not resolve DNS names before scrape_page, crawl, extract_links, extract_text, or URL-mention fetches connect. An attacker-controlled hostname resolving to a loopback, private, link-local, or cloud-metadata address therefore bypasses the SSRF policy without a rebinding race and can expose internal responses to the agent. This issue is fixed in praisonaiagents 1.6.58.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-57126</guid>
    </item>
    <item>
      <title>GHSA-vxgj-xg5c-p4h7 — praisonaiagents: SSRF guard validates literal IPs only and never resolves DNS</title>
      <link>https://db.gcve.eu/vuln/ghsa-vxgj-xg5c-p4h7</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonaiagents&lt;/p&gt;
&lt;p&gt;# praisonaiagents: SSRF guard validates literal IPs only and never resolves DNS&lt;/p&gt;
&lt;p&gt;**Researcher:** Kai Aizen — SnailSploit (@SnailSploit), Adversarial &amp;amp; Offensive Security Research
**Target:** https://github.com/MervinPraison/PraisonAI
**Weakness:** CWE-918 Server-Side Request Forgery (SSRF).&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The SSRF guard shared by PraisonAI&amp;#39;s web tools (`SpiderTools._validate_url` → `_host_is_blocked` in `praisonaiagents/tools/spider_tools.py`) inspects only **literal IP-address encodings** of the URL host. It never resolves DNS names. Any hostname whose A/AAAA record points at an internal, loopback, link-local, or cloud-metadata address passes validation and the request is issued to that target. A static internal A record is sufficient — no DNS-rebinding race is required.&lt;/p&gt;
&lt;p&gt;The guard&amp;#39;s own docstring claims it returns `True` &amp;#34;when hostname **resolves to** loopback/private/internal targets,&amp;#34; but no resolution is performed. The fix for CVE-2026-47390 added more *encodings of literal IPs* (decimal integer, `0x` hex, `inet_aton`); it did not address the *class* &amp;#34;host is a name that resolves to a forbidden address.&amp;#34;&lt;/p&gt;
&lt;p&gt;The same guard is reached through two tool surfaces:
- `scrape_page` / `crawl` / `extract_links` / `extract_text` (spider tools)
- the `@url` mention fetch in `praisonaiagents/tools/mentions.py` (which calls the identical `SpiderTools._validate_url` then `urllib.request.urlopen`)&lt;/p&gt;
&lt;p&gt;The correct pattern already exists in the same package: `file_tools.py` resolves the h…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonaiagents&lt;/p&gt;
&lt;p&gt;# praisonaiagents: SSRF guard validates literal IPs only and never resolves DNS&lt;/p&gt;
&lt;p&gt;**Researcher:** Kai Aizen — SnailSploit (@SnailSploit), Adversarial &amp;amp; Offensive Security Research
**Target:** https://github.com/MervinPraison/PraisonAI
**Weakness:** CWE-918 Server-Side Request Forgery (SSRF).&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The SSRF guard shared by PraisonAI&amp;#39;s web tools (`SpiderTools._validate_url` → `_host_is_blocked` in `praisonaiagents/tools/spider_tools.py`) inspects only **literal IP-address encodings** of the URL host. It never resolves DNS names. Any hostname whose A/AAAA record points at an internal, loopback, link-local, or cloud-metadata address passes validation and the request is issued to that target. A static internal A record is sufficient — no DNS-rebinding race is required.&lt;/p&gt;
&lt;p&gt;The guard&amp;#39;s own docstring claims it returns `True` &amp;#34;when hostname **resolves to** loopback/private/internal targets,&amp;#34; but no resolution is performed. The fix for CVE-2026-47390 added more *encodings of literal IPs* (decimal integer, `0x` hex, `inet_aton`); it did not address the *class* &amp;#34;host is a name that resolves to a forbidden address.&amp;#34;&lt;/p&gt;
&lt;p&gt;The same guard is reached through two tool surfaces:
- `scrape_page` / `crawl` / `extract_links` / `extract_text` (spider tools)
- the `@url` mention fetch in `praisonaiagents/tools/mentions.py` (which calls the identical `SpiderTools._validate_url` then `urllib.request.urlopen`)&lt;/p&gt;
&lt;p&gt;The correct pattern already exists in the same package: `file_tools.py` resolves the h…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-vxgj-xg5c-p4h7</guid>
    </item>
    <item>
      <title>PYSEC-2026-3535 — praisonaiagents: SSRF guard validates literal IPs only and never resolves DNS</title>
      <link>https://db.gcve.eu/vuln/pysec-2026-3535</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonaiagents&lt;/p&gt;
&lt;p&gt;# praisonaiagents: SSRF guard validates literal IPs only and never resolves DNS&lt;/p&gt;
&lt;p&gt;**Researcher:** Kai Aizen — SnailSploit (@SnailSploit), Adversarial &amp;amp; Offensive Security Research
**Target:** https://github.com/MervinPraison/PraisonAI
**Weakness:** CWE-918 Server-Side Request Forgery (SSRF).&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The SSRF guard shared by PraisonAI&amp;#39;s web tools (`SpiderTools._validate_url` → `_host_is_blocked` in `praisonaiagents/tools/spider_tools.py`) inspects only **literal IP-address encodings** of the URL host. It never resolves DNS names. Any hostname whose A/AAAA record points at an internal, loopback, link-local, or cloud-metadata address passes validation and the request is issued to that target. A static internal A record is sufficient — no DNS-rebinding race is required.&lt;/p&gt;
&lt;p&gt;The guard&amp;#39;s own docstring claims it returns `True` &amp;#34;when hostname **resolves to** loopback/private/internal targets,&amp;#34; but no resolution is performed. The fix for CVE-2026-47390 added more *encodings of literal IPs* (decimal integer, `0x` hex, `inet_aton`); it did not address the *class* &amp;#34;host is a name that resolves to a forbidden address.&amp;#34;&lt;/p&gt;
&lt;p&gt;The same guard is reached through two tool surfaces:
- `scrape_page` / `crawl` / `extract_links` / `extract_text` (spider tools)
- the `@url` mention fetch in `praisonaiagents/tools/mentions.py` (which calls the identical `SpiderTools._validate_url` then `urllib.request.urlopen`)&lt;/p&gt;
&lt;p&gt;The correct pattern already exists in the same package: `file_tools.py` resolves the h…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonaiagents&lt;/p&gt;
&lt;p&gt;# praisonaiagents: SSRF guard validates literal IPs only and never resolves DNS&lt;/p&gt;
&lt;p&gt;**Researcher:** Kai Aizen — SnailSploit (@SnailSploit), Adversarial &amp;amp; Offensive Security Research
**Target:** https://github.com/MervinPraison/PraisonAI
**Weakness:** CWE-918 Server-Side Request Forgery (SSRF).&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The SSRF guard shared by PraisonAI&amp;#39;s web tools (`SpiderTools._validate_url` → `_host_is_blocked` in `praisonaiagents/tools/spider_tools.py`) inspects only **literal IP-address encodings** of the URL host. It never resolves DNS names. Any hostname whose A/AAAA record points at an internal, loopback, link-local, or cloud-metadata address passes validation and the request is issued to that target. A static internal A record is sufficient — no DNS-rebinding race is required.&lt;/p&gt;
&lt;p&gt;The guard&amp;#39;s own docstring claims it returns `True` &amp;#34;when hostname **resolves to** loopback/private/internal targets,&amp;#34; but no resolution is performed. The fix for CVE-2026-47390 added more *encodings of literal IPs* (decimal integer, `0x` hex, `inet_aton`); it did not address the *class* &amp;#34;host is a name that resolves to a forbidden address.&amp;#34;&lt;/p&gt;
&lt;p&gt;The same guard is reached through two tool surfaces:
- `scrape_page` / `crawl` / `extract_links` / `extract_text` (spider tools)
- the `@url` mention fetch in `praisonaiagents/tools/mentions.py` (which calls the identical `SpiderTools._validate_url` then `urllib.request.urlopen`)&lt;/p&gt;
&lt;p&gt;The correct pattern already exists in the same package: `file_tools.py` resolves the h…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/pysec-2026-3535</guid>
    </item>
  </channel>
</rss>
