Loading story…
Flytohub patched Flyto2 Core in version 2.26.7 to fix several high-severity server-side request forgery flaws that could let remote attackers reach internal services and cloud metadata endpoints. One issue, tracked as CVE-2026-67428, affected multiple HTTP-capable modules and inline base_url handling that accepted caller-controlled URLs without applying the platform’s validate_url_with_env_config safeguard. Another, CVE-2026-67424, allowed modules including http.get, http.request, and http.batch to validate only the initial URL and then follow redirects into internal address space without rechecking each hop, potentially exposing internal response data.
A separate flaw, CVE-2026-67426, exposed the standalone flyto-verification service through an unauthenticated POST /run endpoint on 0.0.0.0:8344 that trusted a user-supplied callback_url and sent an outbound request containing the X-Internal-Key header populated from $FLYTO_RUNNER_SECRET, enabling SSRF and secret exfiltration. Flytohub’s remediation adds per-request and per-redirect URL validation, blocks access to internal and metadata targets across HTTP, GraphQL, webhook, browser, vision, and monitoring modules, and now requires an X-Internal-Key shared secret for /run, with the service failing closed if no secret is configured.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
A Flytohub code commit remediated multiple SSRF issues in Flyto Core and hardened the verification service by requiring an X-Internal-Key on /run, adding per-redirect SSRF revalidation, and expanding outbound URL validation across affected modules. The commit also added protections against requests to internal or metadata endpoints and included tests for the new controls.
Flytohub released Flyto Core version 2.26.7 to fix three disclosed vulnerabilities: redirect-based SSRF in guarded HTTP modules, unauthenticated callback_url SSRF with runner-secret exfiltration in flyto-verification, and missing SSRF validation in multiple HTTP-capable modules. The disclosures reference the release, advisory material, and the fixing commit as the remediation for affected versions earlier than 2.26.7.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. See the values in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
7 references tracked. Mallory keeps watching after this page renders.
cvereports.com
Open sourcecvereports.com
Open sourcecvereports.com
Open sourcecvefeed.io
Open sourcecvefeed.io
Open sourcecvefeed.io
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Flytohub disclosed and fixed three vulnerabilities in **Flyto Core**, the execution kernel for automation and AI-agent workflows, affecting versions earlier than `2.26.6`. The most severe issue, **`CVE-2026-67429`**, allowed unauthenticated attackers to write attacker-controlled response data to arbitrary filesystem paths because file-writing modules such as `image.download` trusted a caller-supplied `output_dir` instead of enforcing confinement to `FLYTO_SANDBOX_DIR`. Two additional high-severity flaws, **`CVE-2026-67427`** and **`CVE-2026-67425`**, allowed workflows to read arbitrary host environment variables through `${env.VAR}` interpolation and leak environment-derived LLM or API keys such as `OPENAI_API_KEY` and `ANTHROPIC_API_KEY` to attacker-controlled `base_url` endpoints. Flyto Core **`2.26.6`** was released as a security update with a central path guard for file writes, deny-by-default handling for `${env.*}` with optional allowlisting via `FLYTO_ENV_VAR_ALLOWLIST`, and trusted-host restrictions for forwarding environment-derived credentials through `FLYTO_TRUSTED_LLM_HOSTS`. GitHub and CVE records indicate proof-of-concept exploitation and automatable attack paths, and one report noted the credential-forwarding flaw could expose high-privilege API keys through outbound `Authorization: Bearer` headers even when SSRF protections blocked only private or metadata targets. Users were advised to upgrade from `2.26.5` or earlier immediately.
Jul 31, 2026
Traefik disclosed and patched multiple vulnerabilities that let unauthenticated attackers bypass authentication and authorization controls by abusing forwarded-header handling. The most severe issue, **`CVE-2026-54763`** with a **CVSS 10.0**, allows BasicAuth, DigestAuth, and ForwardAuth protections to be bypassed through underscore-variant header injection that can spoof identity or authorization context. Two related flaws, **`CVE-2026-54764`** and **`CVE-2026-54765`**, respectively enable bypass of port-based authorization checks in ForwardAuth via injected `X-Forwarded-Proto` values and leak backend context across Kubernetes Gateway API routes that share the same `Service:port`. The disclosures build on earlier high-severity Traefik ForwardAuth bugs, **`CVE-2026-35051`** and **`CVE-2026-39858`**, which exposed protected routes when Traefik was deployed behind an upstream proxy or when downstream systems normalized underscore-form headers such as `X_Forwarded_Proto` and `X_Forwarded_User`. Affected versions span Traefik v2 and v3 releases prior to the vendor fixes, including **2.11.51**, **3.6.22**, and **3.7.6** for the latest issues, with the newer bugs described as evidence that earlier header-sanitization fixes were incomplete. The flaws put services commonly protected by ForwardAuth—such as Grafana, Kibana, Portainer, Kubernetes Dashboard, internal APIs, and admin panels—at risk, although no public exploits were reported at disclosure.
Jul 10, 2026
ToolJet disclosed two serious vulnerabilities affecting versions prior to `3.20.178-lts`, including a critical marketplace plugin poisoning flaw tracked as **CVE-2026-55413**. The bug lets an authenticated user with the builder role overwrite a globally shared marketplace plugin with attacker-controlled JavaScript, which then executes server-side with full Node.js access whenever any user runs a query through the poisoned plugin. The advisory said the weakness stems from weak authorization on the plugin update path, unsafe execution with exposed `require` and `process` objects, and missing integrity checks for plugin code pulled from arbitrary GitHub repositories, creating an instance-wide supply-chain style compromise that persists until the plugin is reverted or reinstalled. ToolJet also fixed **CVE-2026-55412**, a high-severity SSRF issue in the RestAPI data source for ToolJet Cloud that allowed any authenticated user, including free-tier users, to bypass private IP filtering through DNS tricks such as `169.254.169.254.nip.io`. Successful exploitation could reach the Azure Instance Metadata Service and expose managed identity tokens for the production AKS cluster. ToolJet patched both issues in `3.20.178-lts` and advised customers to upgrade, remove or reinstall potentially compromised marketplace plugins, review plugin integrity and source repositories, and verify RestAPI data source IP filtering.
Jun 29, 2026