Langflow, Mailpit, Outerbase, Miniflux, and render-boundary checks¶

Source: hourly offensive-security scan, 2026-06-19; updated 2026-06-23 for the Langflow monitor API ownership issue, 2026-07-07 for Langflow CVE-2026-55255 KEV user-controlled-key authorization bypass, and 2026-07-20 for public-playground and knowledge-base boundaries. Primary entries: GitHub advisories GHSA-wwf9-7jrc-rv4q, GHSA-ccv6-r384-xp75, GHSA-qrpv-q767-xqq2, GHSA-9c59-2mvc-vfr8, GHSA-w4mc-hhc6-xp28, GHSA-m999-j542-5w3r, GHSA-7h5p-637f-jfr7, and GHSA-c29q-5xm7-5p62.

This batch is durable because each issue maps to a repeatable web-app or AI-workflow boundary: user-controlled dashboard widgets rendered with application tokens in scope, Langflow node configuration crossing into local file reads and execution-capable flows, response and monitor IDs crossing tenant/user ownership checks, mail-link preview APIs missing address-canonicalization coverage, redirect targets bypassing URL policy, and MediaWiki extension template variables crossing into stored HTML.

What changed¶

Operator triage¶

1. Find whether the data is passive or executable in context. Widgets, flow nodes, embed classes, provider names, and exception text are often treated as metadata until rendered or interpreted in a privileged origin.
2. Use two-user ownership tests. Langflow response and monitor APIs need a positive owner, negative non-owner, and preferably a separate flow/workspace control before claiming IDOR/BOLA.
3. Canonicalize before SSRF or redirect claims. Record the raw URL, parsed host, normalized address, DNS result, redirect decision, and final callback hit. Parser differentials are the core evidence.
4. Keep AI-workflow file proofs synthetic. Use canary files created for the assessment. Never read environment files, SSH keys, model credentials, uploaded datasets, or cloud tokens.
5. Skip adjacent availability-only items. Langflow multipart upload DoS and py7zr resource-exhaustion entries were not promoted here because they do not add a stronger offensive validation workflow without a target-specific chain.

Replayable validation boundaries¶

Dashboard/widget content to application-origin token scope¶

• Create a lab Outerbase Studio workspace with a disposable user and no production data sources.
• Add text/widget content containing inert HTML/DOM markers that prove escaping and origin context. Do not use token-exfiltration JavaScript.
• Load the dashboard as another disposable user if collaboration is in scope and record whether the marker renders in a token-bearing origin.
• Negative controls: sanitized widget renderer, isolated preview origin, CSP that blocks script execution, and widgets rendered without application tokens.

Langflow file components, response ownership, and monitor ownership¶

• Build a disposable Langflow instance with two users, two flows, and a synthetic file such as /tmp/langflow-canary.txt owned by the test environment.
• For file-component boundaries, identify nodes inheriting from or wrapping file-read behavior and set only the synthetic canary path. Positive evidence is marker content reaching the flow result or a controlled downstream node.
• For execution-capable chains, stop at a visible inert marker or no-op node. Do not run shell payloads, read secrets, or touch production flow storage.
• For response IDOR, create response records as user A, then request the same IDs as user B. Capture status, owner fields, and marker text with all secrets redacted.
• For monitor API ownership, create two disposable users and two flows. Generate synthetic prompt/response messages and build artifacts only; then test user B against user A's flow_id, message IDs, and session IDs on the monitor read/update paths.
• Safe positive evidence is limited to a synthetic transaction marker, a build-artifact marker, or a controlled session rename visible in the lab. Do not delete production conversations, collect real prompts, or copy model responses from live tenants.

Mailpit link-check SSRF canonicalization¶

• Use an owned callback server and a lab Mailpit instance with no access to production networks.
• Test the same destination represented as hostname, IPv4, IPv6 bracket literal, IPv4-mapped IPv6, 6to4/Teredo-like representation, decimal/octal/hex IPv4, URL-encoded host, and redirect chain.
• Positive evidence is a callback or route-status change for a representation that should have been blocked by the configured policy.
• Do not target cloud metadata endpoints, internal services, RFC1918 production addresses, or tenant infrastructure.

Redirect URL-policy differentials¶

• Use owned domains for allowed and disallowed destinations.
• Build a matrix covering scheme case, userinfo, backslashes, encoded slashes, control characters, double-encoded components, punycode, suffix hosts, and nested redirect parameters.
• Record both parser output and browser-followed destination. A redirect bypass report needs a concrete security boundary such as login flow, OAuth return, feed action, or privileged navigation.

Wiki/CMS extension render sinks¶

• Use a lab wiki/CMS and a page or embed record controlled by the test account.
• Test variables that feed CSS classes, service/provider names, captions, exception messages, and fallback templates with harmless DOM markers.
• Include unsupported-service and validation-error paths; many render bugs live in error output rather than normal templates.
• Do not publish payloads that steal cookies, administrator tokens, or cross-site request tokens; show marker rendering and context instead.

July 7 Langflow user-controlled-key auth-bypass KEV follow-up¶

CISA added CVE-2026-55255 to KEV on 2026-07-07 as a Langflow authorization-bypass issue through a user-controlled key. Treat this as an adjacent Langflow API ownership/key-binding workflow rather than a separate generic alert.

Operator validation stays inside the existing two-user Langflow lab:

• Create user A and user B, each with separate flows, sessions, response history, monitor entries, API keys or share keys, and any workspace-scoped objects exposed by the target version.
• For every endpoint that accepts a caller-supplied key, ID, token, flow_id, message ID, session ID, project/workspace ID, or share key, test whether the server derives ownership from trusted session context or from the user-controlled parameter.
• Safe positive evidence is a synthetic object marker, controlled route-state change, or redacted metadata field from user A becoming visible or mutable to user B.
• Negative controls should include a patched version, an unrelated random key, a valid key bound to the wrong user, and a valid key with a mismatched flow/workspace ID.
• Do not collect real prompts, model outputs, uploaded documents, vector-store contents, API keys, environment variables, or tenant data.

Add this boundary name to reports when it applies: caller-controlled Langflow key to cross-user or cross-workspace authorization context.

July 20 public-playground and knowledge-base follow-up¶

Three updated Langflow advisories add a useful distinction between a flow being intentionally public and every execution-time field being trusted:

• GHSA-v5ff-9q35-q26f / CVE-2026-48519: the unauthenticated /api/v1/build_public_tmp path accepted attacker-supplied custom component code in the public execution graph. A shared flow therefore crossed from public invocation to caller-controlled server-side code.
• GHSA-rcjh-r59h-gq37 / CVE-2026-48520: the same public execution request accepted a files list that could name local or configured S3 objects and feed their bytes into the model path. Exposure depended on the flow and model configuration, so prove the complete return path rather than claiming universal file disclosure.
• GHSA-79ph-745m-6wxq / CVE-2026-42867: authenticated knowledge-base creation used the caller-controlled name in filesystem paths, allowing traversal or absolute paths to place Langflow-generated metadata outside the caller's knowledge-base root.

Shareable-playground differential¶

1. Create a disposable Langflow lab, a minimal public flow, and a unique public flow ID. Keep the instance isolated from production networks and credentials.
2. Capture one normal /api/v1/build_public_tmp/<flow-id>/flow request from the shareable playground. Preserve it as the positive control rather than reconstructing undocumented request fields from memory.
3. For graph integrity, alter only a custom-component code field in the submitted graph so it returns a fixed marker or raises a recognizable exception. Do not run shell commands, import process/network helpers, or access environment data.
4. For file handling, create a synthetic local image/text canary and, if S3 storage is part of scope, a disposable canary object. Change only the request's files entry and observe whether the marker reaches the model input or returned flow output.
5. Record three separate facts: whether the path was accepted, whether the file was opened, and whether bytes were returned to the unauthenticated caller. Do not infer disclosure from a successful request alone.
6. Negative controls: a non-public flow ID, an unrelated random ID, a patched release, an out-of-root path that should be denied, and a public request whose submitted graph differs from the stored graph.

Knowledge-base path containment¶

1. Use two disposable Langflow users and a temporary storage root. Seed each user's knowledge-base directory with distinct non-sensitive markers.
2. Submit normal, ../ traversal, sibling-prefix, encoded-separator, and absolute-path name values to POST /api/v1/knowledge_bases. Target only a disposable canary directory outside the expected knowledge-base root.
3. Check whether directories, embedding_metadata.json, or schema.json appear at the canary target. Capture path resolution and before/after directory listings; do not overwrite an existing knowledge base or application file.
4. Compare the affected behavior with a patched version that performs component-aware containment, not string-prefix matching.

Report these as public invocation to caller-supplied execution graph, public file selector to model-mediated file return, or knowledge-base name to outside-root metadata write. Include the exact route, public/authenticated state, storage backend, flow composition, marker-only evidence, and negative controls. Never read real local files, buckets, prompts, API keys, model credentials, or another tenant's knowledge-base data.

July 21 unauthenticated exec_globals validation-route KEV follow-up¶

CISA added CVE-2026-0770 to KEV on 2026-07-21. The primary ZDI advisory identifies an unauthenticated Langflow validation endpoint whose exec_globals parameter can include attacker-controlled functionality and execute in the server context. Langflow 1.9.0 is the vendor release referenced by CISA.

Keep validation marker-only because this route is unauthenticated and exploitation has been observed:

1. Use an isolated Langflow lab with no production credentials, mounted secrets, cloud role, sensitive flows, or unrestricted egress.
2. Capture the normal request schema for the affected validation route from the exact lab version. Confirm authentication state with no cookie/header, a malformed credential, and a disposable authenticated user.
3. Change only exec_globals so the validation result exposes a fixed in-memory marker or benign type/value. Do not import process, filesystem, socket, package-loader, or environment helpers and do not run a shell command.
4. Record whether the field is accepted, whether the marker becomes available to evaluated code, and which service identity handles the request. A validation error alone does not prove execution.
5. Compare Langflow 1.9.0 or later and a control that strips the field or binds globals server-side.

Report unauthenticated validation input -> caller-controlled exec_globals -> inert server-side evaluation marker. Do not publish executable payloads, read environment variables, or test an internet-facing production instance.

July 30 MCP environment and build-job ownership follow-up¶

Two IBM Langflow OSS records covering 1.0.0 through 1.10.1 extend the existing execution and two-user authorization workflows:

• GHSA-gx45-8jc3-gqqr / CVE-2026-12940 states that the MCP stdio launcher used a dangerous-environment-variable blocklist that omitted SHELLOPTS, BASHOPTS, and PS4. Treat this as request-controlled environment to interpreter startup behavior, not as a reason to run a shell payload.
• GHSA-xxrp-rxf8-3mmx / CVE-2026-12945 states that authenticated users could access or manipulate another user's build jobs through log retrieval and unauthenticated build endpoints.

MCP stdio environment recorder¶

1. Run an isolated Langflow build with no credentials, sensitive environment, network egress, or production MCP servers. Replace the stdio child program with a recorder that serializes received argv and environment-key names, writes one temp marker, and exits; it must not invoke a shell.
2. Capture a normal MCP stdio launch from the product UI/API. Change only benign values for ordinary variables and the three named shell-control variables. Use fixed strings with no commands, substitutions, paths, or callbacks.
3. Record request field, validation/blocklist decision, environment map reaching the child-process API, selected executable, argv, and recorder marker. Never print inherited environment values.
4. Compare omitted variables, a blocked named variable, direct env object input versus nested configuration, and a corrected build or allowlist-only wrapper.
5. A bounded positive is unauthenticated/request-controlled MCP launch field -> named shell-control variable survives policy -> recorder child receives it. This proves policy reachability; do not claim code execution unless an approved no-op interpreter harness separately proves a startup behavior change.

Build-job ownership matrix¶

Create build jobs for users A and B with synthetic logs and artifact markers. Test list, status, log retrieval, cancellation, update, and unauthenticated build routes independently. As B, submit A's already known lab job ID; then repeat without credentials, with a random ID, wrong flow/workspace, owner A, administrator, and corrected build. Capture route, authentication state, actor, job owner, action, marker returned, state transition, and handler authorization decision.

Strong evidence is foreign build-job ID -> ownership is not joined to actor/flow/workspace -> synthetic log marker is returned or harmless job state changes. Do not retrieve real prompts, generated code, environment output, build artifacts, credentials, or another tenant's production jobs.

Reporting notes¶

• Name the crossed boundary precisely: widget content to token-bearing dashboard origin, AI file-node parameter to server file read, flow response ID to another user's history, monitor flow_id to another user's transaction/build logs, message/session ID to cross-user history mutation, caller-controlled Langflow key to cross-user authorization context, unauthenticated exec_globals to server-side validation context, IPv6 transition URL to link-check SSRF, redirect parser bypass to privileged navigation, embed class to stored HTML, or provider error text to stored HTML.
• Include version, authentication role, workspace/tenant IDs, URL parser normalization, network callback evidence, and negative controls. Keep evidence to synthetic markers and owned infrastructure.

July 28 FAISS namespace ownership follow-up¶

GHSA-668j-2f6w-gqwr / CVE-2026-13442 extends the same two-user Langflow method to FAISS vector namespaces. The reviewed record covers Langflow OSS 1.0.0 through 1.10.1 and states that one user can reuse another user's namespace to read owner-only vector content and persist entries that influence later results.

Use two disposable users and two namespaces containing unique synthetic documents. Establish each owner's search/add baseline, then have user B submit user A's namespace through the exact component/API reached by the target workflow. Test read and write separately: the read proof stops after one synthetic marker appears; the integrity proof inserts one benign POISON-CANARY record and then has user A query for that exact marker. Add random, nonexistent, own-namespace, wrong-workspace, and fixed-build controls.

Report caller-controlled FAISS namespace -> owner binding omitted -> synthetic cross-user vector returned or persisted. Include user/workspace/flow identity, namespace source, vector-store backend, operation, marker hashes, and post-write cleanup. Never collect real embeddings, prompts, documents, API keys, model output, or another tenant's production namespace.

July 30 file-route, traversal, and Chroma namespace follow-up¶

Three additional IBM Langflow records extend the existing file and two-user vector-store workflows:

• GHSA-c6gg-2q9r-m9jw describes missing authentication on /api/v1/files/images/{flow_id}/{file_name} and insufficient ownership binding on /api/v1/files/download/{flow_id}/{file_name};
• GHSA-rmxx-p7v6-pmfp describes URL path traversal using dot-segment variants; and
• GHSA-vrqm-44rp-59j5 describes cross-user Chroma reads and writes when a caller reuses another flow's persist_directory and collection_name.

File route and path matrix¶

1. Create users A and B, separate flows, and uniquely named synthetic image/text files. Keep a third temporary sibling directory containing one random canary.
2. Test image and download routes as owner A, non-owner B, anonymous, random flow ID, wrong filename, and administrator. Record whether the server joins flow_id and filename back to the authenticated owner.
3. Test canonical path, repeated dot segments, encoded separators, mixed slash forms accepted by the stack, absolute paths, sibling-prefix paths, and a symlink only against the disposable canary root.
4. Capture raw request target, proxy-decoded target, framework route parameters, normalized filesystem path, owner lookup, file-open target, and returned marker.
5. Report unauthenticated route coverage, cross-user object access, and filesystem traversal separately. Never retrieve real uploads, prompts, model artifacts, credentials, or tenant files.

Chroma two-user namespace matrix¶

Reuse the FAISS fixture above, but record both persist_directory and collection_name as authority-bearing selectors. Establish that user B cannot discover user A's namespace through normal list/UI paths; then submit the already known synthetic pair through B's own flow. Prove read and write independently with one random owner marker and one reversible POISON-CANARY record. Include mismatched directory/collection pairs, nonexistent values, same-user values, wrong workspace, and fixed-build controls.

Report caller-controlled Chroma storage pair -> owner binding omitted -> synthetic cross-user vector returned or persisted. Do not claim arbitrary filesystem access unless the path itself escapes the configured Chroma root and a separate canary proves that edge.

August 5 provider, MCP, environment, and host-authority follow-up¶

Nine IBM Langflow OSS records covering 1.0.0 through 1.10.3 extend the same file, outbound-fetch, and MCP-launch methods. Primary IBM bulletins include node 7282147 and node 7282650. The GitHub records are GHSA-fqv5-gx59-2xgv / CVE-2026-9081, GHSA-94h9-q657-456h / CVE-2026-7657, GHSA-47c3-vjq8-vj9m / CVE-2026-10128, GHSA-qvrp-rpmf-prw4 / CVE-2026-17625, GHSA-x37c-x545-wrmw / CVE-2026-7646, GHSA-wq3q-gcx9-xvm2 / CVE-2026-9077, GHSA-5jpf-5j69-486q / CVE-2026-17630, GHSA-f93f-mcp7-xm47 / CVE-2026-17626, and GHSA-7rx7-4wfr-4qqv / CVE-2026-17623.

Use one isolated Langflow instance with no inherited credentials or unrestricted egress. Replace requests.get, MCP resource readers, IDE-config writers, Docker launch, and child-process creation with recorders before supplying canaries.

For provider SSRF, capture validation-time DNS, every redirect, connection-time DNS, and final socket peer; never use metadata or real internal services. For MCP paths, preserve raw, URL-decoded, normalized, and real paths, and distinguish file selection from returned bytes. For process and Docker controls, record argv/runtime configuration without starting a shell, container, or mount. For environment access, expose only a generated fake variable and never inspect inherited values.

Report each edge independently. Do not collapse MCP config write, file read, host mount selection, and command execution into one RCE claim unless separate denied-sink evidence proves every transition.

August 5 second follow-up: validation, cache, memory, and filesystem authority¶

An adjacent IBM Langflow OSS wave covering 1.0.0 through 1.10.3 adds seven operator-relevant boundaries: GHSA-994g-w9jv-hxcv / CVE-2026-8182, GHSA-x252-wm2h-6mf4 / CVE-2026-8478, GHSA-wq52-m42w-xg45 / CVE-2026-9201, GHSA-4q62-cj5w-qmfx / CVE-2026-9196, GHSA-7xr9-m7x2-5wqq / CVE-2026-7869, GHSA-vph6-jp7f-x3cx / CVE-2026-9130, and GHSA-f7wm-r5v3-mxr4 / CVE-2026-10547.

Treat the sparse traversal record GHSA-p865-qggm-g9qx / CVE-2026-8183 as a route-discovery seed, not proof that every Langflow path is readable. Preserve the raw request target, proxy decoding, framework route parameters, canonical file target, and denied open call. Use only a lab canary file.

Report the edges separately as unauthenticated request sequence to denied interpreter sink, truncated component digest to trust decision, generated component to pre-approval validator, knowledge-base name to outside-root denied write, session id to foreign synthetic memory, or foreign flow id to shared cache entry. Do not infer universal RCE, arbitrary file access, or cross-user disclosure from an advisory title alone.