CVE-2026-108598: Floci Velocity SSTI Code Injection Vulnerability — Analysis & Mitigation

Floci, the open-source AWS API Gateway emulator, shipped version 2.2.0 this month to fix CVE-2026-108598, a critical server-side template injection vulnerability that hands unauthenticated attackers full operating-system command execution on the host. An attacker creates a REST API with a MOCK integration, drops in a Velocity mapping template that uses $util reflection, and walks straight into Java's Runtime or ProcessBuilder. It is also a textbook failure of identity access management: the endpoint that creates APIs and writes executable templates asks for no identity at all.

Summary

Floci emulates AWS API Gateway for local development and testing, letting teams build and test API definitions without touching real AWS infrastructure. Its VtlTemplateEngine component renders Apache Velocity mapping templates for MOCK integrations — the feature that lets a fake API return canned responses. CVE-2026-108598 is a CWE-94 code injection flaw: Floci 1.1.0 before 2.2.0 placed no restrictions on those Velocity templates, and creating a REST API with a MOCK integration required no authentication.

The attack needs exactly one unauthenticated request: create a REST API whose MOCK integration carries a mapping template. Velocity templates expose a $util object, and through reflection the template can reach java.lang.Runtime or ProcessBuilder — at which point the "template" is simply a shell command, and the Floci JVM executes it with the service account's privileges. Full OS command execution, no credentials, no user interaction.

A public proof-of-concept has been published, which compresses the window between disclosure and weaponization to nearly zero. If your Floci instance is reachable from any network you do not fully trust, treat it as an exposed remote shell until proven otherwise.

Severity

  • CVE ID: CVE-2026-108598
  • CVSS: 9.8 Critical — VulnCheck CNA scoring
  • CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
  • Weakness: CWE-94 — Improper Control of Generation of Code ('Code Injection'); also tagged CWE-78 (OS Command Injection)
  • Attack requirements: none — unauthenticated, remote, low complexity, no user interaction
  • Impact: arbitrary OS command execution on the host running the Floci JVM — full system compromise of that box
  • Exploited in the wild: no confirmed reports; a public PoC exists, which historically accelerates exploitation

The vector is the maximum-severity shape: network, low complexity, zero privileges, total impact on confidentiality, integrity, and availability. There is no interaction gate and no privilege gate — the only gate is network reachability.

Affected Versions

  • Floci 1.1.0 before 2.2.0 — every release in that range is affected
  • Fixed in: 2.2.0 (restricts the Velocity template engine)
  • Component: VtlTemplateEngine — the Velocity mapping-template renderer for MOCK integrations
  • Exposure: any Floci instance reachable over the network — developer laptops on shared networks, shared test servers, CI runners, and any deployment bound to 0.0.0.0 instead of localhost

The dangerous misconception is "it's just a local dev tool." Dev tools run with developer privileges, on machines holding cloud credentials, SSH keys, and source code — and they are routinely left listening on shared or corporate networks. "Local" describes the intent, not the exposure.

Technical Analysis

From $util to Shell: The Classic Velocity Escalation

Server-side template injection in Apache Velocity follows a well-worn escalation path. Velocity templates are meant to be presentation logic — $variable substitution and simple directives — but the engine historically exposes enough of the Java object graph to escape the sandbox. The $util object in a mapping template is the foothold: through it, the template can obtain a Class reference, and from there use reflection to load java.lang.Runtime and call getRuntime().exec(), or instantiate ProcessBuilder directly. Each step is "legitimate" template functionality; the chain as a whole is arbitrary command execution.

Here is the part that should unsettle emulator authors: in a MOCK integration, the template is not smuggled in through a user profile field or a comment box — it is the integration definition itself. The attacker is using the product's documented feature exactly as designed. The vulnerability is not that Velocity can reach Runtime (that is a known, hard-to-fully-sandbox property of the engine); it is that an unauthenticated stranger is allowed to author integrations. The template engine is the weapon, but the missing authorization check is the unlocked armory door.

An Identity Access Management Failure, Not Just a Template Bug

Strip away the template details and CVE-2026-108598 is an identity access management failure. In real AWS API Gateway, creating a REST API and defining its integrations is a privileged operation gated by IAM policies — you prove who you are, and the policy decides what you may do. Floci emulates the API surface of API Gateway but emulated none of the authorization boundary: anyone who could reach the service could create APIs and write executable templates, with no identity presented and no policy evaluated.

This is the recurring sin of developer emulators and local service mocks: they reproduce the functionality of the cloud service faithfully while silently dropping the security model. The developer tests against the emulator, the emulator says "works," and nobody notices that the real service would have demanded credentials at step one. Every emulator, mock, and localstack-style tool in your stack deserves one hard question: which authorization checks did the emulation leave out, and who can reach the ports where those checks are missing? As a pentest finding, "emulator reachable without authentication" writes itself — the only work is checking which ones your target runs.

Dev Tools With Server Privileges

Consider where Floci actually runs. On a developer laptop, a compromise means the attacker's code executes alongside the developer's AWS credentials, SSH keys, and source checkouts — a straight path to cloud and code-infrastructure takeover. On a shared test server or CI runner, it means execution on a box that likely holds deployment tokens and pipeline secrets. Emulators are frequently started with permissive network bindings (0.0.0.0 for container access or team sharing) and then forgotten, and they rarely appear in asset inventories because "it's just a dev tool."

The data-integrity angle is what incident responders will feel first. A MOCK integration's template controls what the fake API returns — which means a compromised Floci can silently serve manipulated responses to every developer and test suite pointed at it. Poison the mock and you poison the tests: passing builds against lying APIs, integration tests that validate attacker-shaped data, and a false sense of correctness that survives long after the compromise. When the tool that tells you "everything works" is owned, your quality gates become the attacker's camouflage.

Why This Matters

Unauthenticated remote code execution on network-reachable infrastructure is the season's dominant pattern. I analyzed the same shape in CVE-2026-104935 (Ivanti Connect Secure) — a perimeter box owned without credentials — and CVE-2026-102255 (SonicWall SMA1000), where a pre-auth flaw turned a gateway into a launchpad. Floci extends the pattern somewhere defenders rarely look: the development toolchain. The perimeter is no longer just the firewall and the VPN — it is every service listening on your laptop, your test server, and your CI network.

What does vulnerable mean in the context of CVE-2026-108598? It means a tool you installed to pretend to be AWS can be turned into a real shell on your machine by anyone on your network, with no password and no phishing required. What is data integrity worth when a template can run shell commands? Nothing — once the mock server is owned, every "passing" test it serves is evidence manufactured by the attacker. Patch the emulator, then question everything it told you while it was exposed.

Mitigation

  • Upgrade immediately to Floci 2.2.0 — the release restricts the Velocity template engine and closes the injection path
  • Kill the network exposure: bind Floci to localhost only; never run it on 0.0.0.0 on shared, corporate, or CI networks. A dev emulator has no business being reachable by strangers.
  • Inventory every instance: search developer laptops, shared test servers, containers, and CI runners for Floci — un-inventoried dev tools are unpatched dev tools
  • Assume breach if it was exposed: any instance reachable from an untrusted network should be treated as compromised — rotate credentials and tokens that lived on that host, and rebuild rather than just patching
  • Distrust its recent answers: if the instance served MOCK responses while exposed, re-run affected test suites against a patched instance — a compromised mock can make failing code look green
  • No workaround short of the patch besides strict network isolation — restricting who can reach the service is the only mitigation on affected versions

References

More from this blog: about Faizan Akhtar.

Report by Faizan Akhtar — The Cyber Security Researcher

Comments

Post a Comment

Popular posts from this blog

CVE-2026-97229: GitLab CI/CD Regex Compiler Integer Overflow Vulnerability — Analysis & Mitigation

Image
Summary On October 12, 2026, GitLab shipped an emergency patch release — versions 19.4.2, 19.3.4, and 19.2.8 — to fix CVE-2026-97229 , a maximum-severity CVSS 10.0 vulnerability in the CI/CD Regular Expression Compiler that could allow an unauthenticated attacker to execute arbitrary code on the GitLab server . No login. No account. Just a specially crafted regular expression smuggled into a CI/CD configuration, slipping past insufficient validation and tripping an integer overflow deep in the regex engine. GitLab itself is urging every self-managed installation to upgrade immediately — and this is the third regex-engine flaw in GitLab in a single month , after two CVSS 9.9 regex bugs patched on September 23. The pattern is unmistakable: attackers now know exactly which component of GitLab to keep probing. Severity CVE ID: CVE-2026-97229 Title: GitLab CI/CD Regular Expression Compiler integer overflow — unauthenticated remote code execution CVSS 3.1: 10.0 (Critical) — AV:N/AC...
Read more

CVE-2026-80381: IBM Guardium Data Protection SQL Injection Vulnerability (CVSS 9.8) — Analysis & Mitigation

Image
IBM Guardium Data Protection is the product enterprises deploy to watch their databases — it monitors traffic, audits access, and enforces the policies that protect the organization's most sensitive data. On October 8, 2026, IBM published a security bulletin revealing that the very component tasked with sniffing database traffic was itself vulnerable to SQL injection , rated CVSS 9.8 and tracked as CVE-2026-80381 . A remote attacker could execute unauthorized SQL statements against the security product guarding the databases. Here is the full technical breakdown of what happened, why the location of this bug makes it especially serious, and exactly how to remediate it. Summary CVE-2026-80381 is a SQL injection vulnerability (CWE-89) in the Sniffer component of IBM Guardium Data Protection. IBM's bulletin states that a remote attacker could execute unauthorized SQL statements due to improper neutralization of input in SQL commands — the textbook definition of SQL injection, sit...
Read more

CVE-2026-76482: Cisco License On-Prem Signature Verification Vulnerability (CVSS 10.0) — Analysis & Mitigation

Image
On October 7, 2026, Cisco published one of the most serious security bulletins of the year: a hardening release for Cisco License On-Prem that fixed eight internally discovered vulnerabilities, including a maximum-severity cryptographic signature verification flaw tracked as CVE-2026-76482 . With a CVSS score of 10.0 out of 10, it is the highest-rated flaw in Cisco's entire October 2026 release, and it sits on one of the most sensitive systems a Cisco customer can run — the server that manages software licensing for their entire fleet of Cisco products. In this post I break down exactly what went wrong, why a signature verification bug is so dangerous in this particular product, and what you need to do about it. Summary CVE-2026-76482 is an improper verification of cryptographic signature (CWE-347) vulnerability in Cisco License On-Prem, formerly known as Cisco Smart Software Manager On-Prem (SSM On-Prem). Cisco's engineering team found the flaw during an internal security rev...
Read more