The TigerGraph Community Edition image is a closed-source graph database published on Docker Hub as tigergraph/community:latest. In version 4.2.4, a remote attacker who can reach it gets command execution as the account that owns the engine, and none of the steps require a secret that is not already public.
The chain is four defaults
The shipped credentials are tigergraph / tigergraph, and nothing forces a change. A GSQL query parameter of type FILE passes straight into PRINT ... TO_CSV with no path validation, no base-directory confinement and no extension allowlist. REST++ invokes installed queries with no authentication by default, because RESTPP.Factory.EnableAuth ships set to False. And the free-form path is aimed at /home/tigergraph/.ssh/authorized_keys, a file the DBMS honours as an SSH credential store, since the product’s own entrypoint.sh starts sshd for that account.
Write a key into authorized_keys, log in, run what you like. The landing identity is uid=1001(tigergraph), the database user rather than root, which still owns the engine, the graph data and the configuration tree.
One precondition: a query that writes files has to exist in the catalog. It is not pre-installed. One HTTP call with the shipped credentials installs it, and any file-output query a legitimate user installed satisfies the same condition, after which the trigger itself is anonymous.
Reachability
Three surfaces matter. The web GUI on 14240 reverse-proxies the GSQL statements service on 8123, so an attacker who can reach the GUI needs no separate route to statements. REST++ runs on 9000 with its own binding and no auth. sshd on 22 is started by the entrypoint, so the container is not a one-service box.
The researchers published the chain, with a runnable proof of concept and a lab verification: they emptied authorized_keys first, then confirmed the write landed 410 bytes and logged in with the authored key. CVSS 3.1 scores it 9.8. The vendor was notified and a CVE ID is pending; there is no fix listed as of 22 September. Ten earlier TigerGraph CVEs exist, all in the 3.x line from 2022 and 2023.
The publisher is a shop called 0day Rubbish, which runs AI-driven discovery and discloses in two-week batches with working exploits, arguing that vendors only fix what is demonstrably exploitable. This arrived as part of a batch on 17 September.
What to do instead of patching
Their operator list is specific. Change the tigergraph account password after install, and treat any deployment still answering the shipped pair as compromised. Set RESTPP.Factory.EnableAuth = True in tg.cfg and require tokens. Audit the GSQL catalog for installed queries declaring FILE parameters and remove the ones nobody needs, and watch authorized_keys for changes. And keep 14240, 9000 and 22 off untrusted networks.
The vendor-side items they ask for are more telling: force rotation of the shipped password instead of printing a dismissal-able recommendation, default REST++ auth to on, confine TO_CSV writes to a configured directory, and require extra privilege to install a query that declares a file parameter. Those are the fixes the product does not have yet.
My read
The interesting thing is the arithmetic. A product that starts sshd on a database account has turned “arbitrary file write” into “log in as the database”, and a default password that only appears in a recommendation string was never a control in the first place.
The other half is the publisher. Advisories produced by automated pipelines, shipped with working exploits on a calendar, are going to keep arriving, and they are going to keep landing on defaults. The practical response is to stop running products whose default state assumes nobody will reach them, and to put published ports behind something that authenticates.
Sources: the full write-up at 0day-rubbish.com and the disclosure to the Full Disclosure list