<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-18T20:26:50.084672+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2026-8505</id>
    <title>CVE-2026-8505 — Authentication Bypass in Webhook Endpoints Allowed Unauthorized Flow Execution</title>
    <updated>2026-10-18T20:26:50.086434+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> IBM Langflow OSS</p>
<p>IBM Langflow OSS 1.0.0 through 1.10.0 has a vulnerability in Langflow's webhook authentication logic allows unauthenticated users to trigger the execution of any flow. The system incorrectly bypasses API key validation when the WEBHOOK_AUTH_ENABLE configuration is set to False (which is the default setting). This allows a remote attacker who knows a flow's UUID to execute it as if they were the owner, potentially leading to Remote Code Execution (RCE).</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-8505"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-cf6m-vc3m-7cgm</id>
    <title>GHSA-cf6m-vc3m-7cgm — Langflow: Unauthenticated Flow Execution via Webhook Authentication Bypass</title>
    <updated>2026-10-18T20:26:50.086491+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: langflow</p>
<p>### Summary
A vulnerability in Langflow's webhook authentication logic allows unauthenticated users to trigger the execution of any flow. The system incorrectly bypasses API key validation when the `WEBHOOK_AUTH_ENABLE` configuration is set to `False`. This allows a remote attacker who knows a flow's UUID to execute it as if they were the owner, potentially leading to Remote Code Execution (RCE) or Denial of Service (DoS).</p>
<p>### Details
The `WEBHOOK_AUTH_ENABLE` setting was introduced in v1.7.0 (#9139) with a default of `False`. The root cause is in the webhook authentication path, `AuthService.get_webhook_user` (`src/backend/base/langflow/services/auth/service.py`; the thin wrapper in `src/backend/base/langflow/services/auth/utils.py` just delegates to it):</p>
<p>```python
async def get_webhook_user(self, flow_id: str, request: Request) -&gt; UserRead:
    settings_service = self.settings
    ...
    # VULNERABILITY: If this setting is False (default in &lt;= 1.9.0), it returns
    # the flow owner WITHOUT checking the API Key in the request.
    if not settings_service.auth_settings.WEBHOOK_AUTH_ENABLE:
        try:
            flow_owner = await get_user_by_flow_id_or_endpoint_name(flow_id)
            return flow_owner
```</p>
<p>By default (v1.7.0 through v1.9.0), Langflow treats `WEBHOOK_AUTH_ENABLE` as `False`, meaning all webhook endpoints are public. This relies exclusively on the secrecy of the `flow_id` (UUID), which is an insecure practice (Security by Obscurity).</p>
<p>A related repor…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-cf6m-vc3m-7cgm"/>
  </entry>
</feed>
