CVE-2026-32311 is a critical command injection in Flowsint, the open source OSINT graph tool, scored CVSS 9.8. A remote user could run operating system commands through the org_to_asn transform, and a mounted Docker socket made root on the host reachable. Update to v1.2.3.
What's affected
The GitHub advisory lists affected versions as anything before commit 859315731c0f5f8dfd7e4c02d3bfe291b230d057 and names v1.2.3 as the patched version. The advisory does not list a package registry entry, so Flowsint is usually deployed from source or from the project's container setup.
The flaw is in a transformer that looks up an autonomous system number for an organization name. The advisory says the name supplied by the user was placed into a shell command string and run with shell mode on.
How to check if you're exposed
Work out which release or commit you deploy:
git describe --tags
git log -1 --format=%H
If you run from a release tag, compare it with v1.2.3. If you track a branch, check that your commit includes the fix commit b52cbbb904c8013b74308d58af88bc7dbb1b055c from the record's references.
Then look at your compose files for a mounted Docker socket:
grep -rn "docker.sock" docker-compose*.yml
The advisory says the mounted socket is what turned command injection inside a container into control of the host.
What to do now
- Update Flowsint to v1.2.3 or later and redeploy every instance.
- Remove the Docker socket mount from the containers unless you truly need it. If you do, restrict who can reach the application.
- Keep Flowsint off the public internet. Put it behind a VPN or an identity aware proxy, because sign up and investigations are open to any registered user.
- Review the host for unfamiliar containers, processes or accounts if the instance was ever reachable by people you did not trust.
- Rotate API keys and tokens that the Flowsint environment holds if you suspect misuse.
Flowsint investigates hostile material by design. Usernames, domains and organization names come from the outside world, so every transformer that hands one of them to another program is worth a second look.
Search your copy of the code, and any custom transformers you wrote, for subprocess calls that use shell mode with a formatted string. Replace them with argument lists so that user text is never parsed as shell syntax. The advisory shows this pattern in one transformer file, and the project's fix commit is linked from the record.
Finally, review what the application container can reach. Even without the socket mount, a container that holds API keys for lookup services is a useful target, so keep those keys scoped and rotate them on a schedule.
Why it matters
The class is CWE-78, OS command injection. The advisory describes a command built by string interpolation of user input and passed to a shell. Anything the shell treats as syntax, such as command substitution, is then run as code.
The second half is a deployment choice. A container that can talk to the host's Docker socket can start new containers with host paths mounted, so a bug inside the container becomes a host compromise. The record's KEV flag is false and the advisory does not report exploitation in the wild.
The lesson applies beyond this tool. Pass arguments to subprocesses as a list, and never mount the Docker socket into an application that handles untrusted input.
Quick check
Is the container boundary enough protection?
Not here. The advisory says the mounted Docker socket allowed an escape from the container to the host with root rights.
Does the fix remove the need to review the socket mount?
No. Patching removes this injection point, but a mounted socket still raises the cost of any future bug, so review it.
Sources
Last reviewed: 19 October 2026.
