Conductor's 9.8 was patched 27 days before it had a CVE, and CISA's exploited list still has no entry

The fix shipped before the flaw had a name

Orkes Conductor 3.30.2 was published on 3 June 2026. Its release notes list eight changes. The one that closed an unauthenticated remote code execution flaw now scored at 9.8 is described, in full, as Restrict graaljs further (#1123). No security label. No CVE number. No advisory link.

The CVE arrived 27 days later, on 30 June 2026, and it was assigned by VulnCheck acting as a CNA, not by the project. Counting from the patch to today, 19 September 2026, is 108 days. In that time Fortinet has published exploitation telemetry, Empirical Security has published sensor telemetry, and Previdian has published honeypot telemetry. The CISA Known Exploited Vulnerabilities catalogue, version 2026.09.18, still has no entry for it. I checked the catalogue JSON directly: 1,716 entries, 151 of them 2026 CVEs, none for Conductor, none for Orkes.

That arithmetic does not establish that your Conductor is exposed, and it does not establish that anyone has been compromised. A blocked attempt is a blocked attempt. A honeypot hit is a scan that found a honeypot. The absence of a KEV entry is not evidence that exploitation is not happening, because KEV has its own evidentiary bar and its own timing, and a great deal of exploited software never reaches it.

What the gap does establish is narrower and considerably more useful. For any organisation whose patching is driven by advisory feeds, severity labels and KEV dates, this flaw was close to invisible for its first month, and it is still absent from the one list most UK boards have heard of. And the software it affects is the kind a platform team stands up quietly, which means the people who would act on the advisory often do not know the asset exists.

What the flaw is, read from the source rather than the coverage

Conductor is a workflow engine. A workflow is a list of tasks, and several task types let the workflow author write a small expression that is evaluated at run time: to pick a branch, transform a value, or decide whether a loop has finished. The four task types that do this are INLINE, LAMBDA, DO_WHILE and SWITCH, and the expression can be JavaScript or Python.

Conductor runs those expressions on GraalVM. I read the code at tag v3.21.23, which sits inside the affected range, rather than taking the CVE text on trust. The JavaScript context is built like this, and the Python evaluator like the line beneath it.

// ScriptEvaluator.java, tag v3.21.23
Context.newBuilder("js")
        .allowHostAccess(HostAccess.ALL)

// PythonEvaluator.java, tag v3.21.23
Context.newBuilder("python").allowAllAccess(true).build()

HostAccess.ALL grants the guest script access to every public member of every host object it can see. allowAllAccess(true) is broader still, and turns on file, process and native access alongside it. From an object bound into the script, an attacker reaches Java reflection, and from reflection reaches java.lang.Runtime and ProcessBuilder. The expression stops being an expression and becomes an operating system command.

That command runs with the privileges of the Conductor process. I checked the official server Dockerfile in the repository: it contains no USER instruction at any stage, so the container runs as root unless the operator overrides it. That is my own reading of the build file, not a vendor statement.

The coverage calls this a pre-auth flaw, and the CVE text says the request arrives prior to authentication. That phrasing flatters the product. Pre-auth normally means an attacker reaches vulnerable code before an authentication check that exists. In the open-source Conductor server there is no check to be before.

I went looking for one. The server's shipped application.properties contains no authentication settings of any kind. The server build file declares no Spring Security dependency. The project's own command line tool defaults to a server type of OSS, and marks secrets management and the API gateway, which is where routes and authentication are configured, as Enterprise only. Authentication is not a control that failed here. In the free edition it is not a control that is present.

CVE-2026-58138 read against the NVD record, the VulnCheck advisory and the CISA KEV catalogue JSON, all retrieved 19 September 2026.

Question	On the record	Not stated
Are credentials needed?	No. CVSS vector gives privileges required: none, user interaction: none	Whether any given deployment enforces authentication at a proxy
What does the attacker get?	Arbitrary operating system commands as the Conductor process	What any actual attacker did after landing
Affected versions	3.21.21 up to but not including 3.30.2	Whether the 3.21.x line will ever receive a backport
Who reported it?	Credited to seqradev in the VulnCheck advisory	Any disclosure date, report date or coordination timeline
Indicators of compromise	None published by the project, the CNA or either telemetry vendor	Any hash, payload name, command string or attacker IP list
CISA KEV status	Not listed in catalogue version 2026.09.18	Whether CISA has assessed the exploitation reports at all

A denylist is not a sandbox, and 3.30.0 is not the fix

The CVE record cites two commits. Both are by the same contributor, Vasilii Pankov. They are 17 days apart, and they are not the same kind of fix.

The first, dated 5 May 2026, kept HostAccess.ALL as the starting point and subtracted from it: deny Class, ClassLoader, Method, Field, Constructor, Array, Runtime, ProcessBuilder, Process, System, Thread and ThreadGroup. The Python evaluator dropped allowAllAccess(true) entirely. The commit also added a test that fires the reflection chain at the evaluator and asserts that the task fails.

The second, dated 22 May 2026, changed the shape of the thing rather than the contents of a list. It disabled host class loading, native access, thread creation, process creation, file access and environment access on the GraalVM context, and switched off the JavaScript load, print and console builtins at the engine level.

The two commits named in the CVE record, read from the conductor-oss repository on 19 September 2026.

Commit	What it changed	Still default-allow?
5 May 2026, pull request 1057	Kept HostAccess.ALL and denied twelve named classes. Python evaluator dropped allowAllAccess(true).	Yes, for JavaScript
22 May 2026, pull request 1123	Turned off host class loading, native access, thread and process creation, file access and environment access. Disabled the js load, print and console builtins.	No

This is the part worth carrying away from the technical detail. A denylist built on top of HostAccess.ALL is still default-allow. It closes the route the published test case takes and leaves open every route nobody has written a test for. The second commit is the one that turns the capabilities off rather than enumerating the ways they might be misused.

That distinction has a version number attached. Release 3.30.0 went out on 21 May 2026 and 3.30.1 the following morning at 06:21 UTC. The second commit landed at 18:09 UTC on 22 May, after 3.30.1 was cut. That is why the fixed version is 3.30.2 and not 3.30.0. Empirical Security makes the same point in its write-up, warning readers not to stop at 3.30.0 or 3.30.1 because those shipped only a partial blocklist. Anyone who reads "fixed in the 3.30 line" and lands on 3.30.1 has not fixed it.

There is one more date that ought to give a security team pause. CVE-2025-26074 was published on 30 June 2025, exactly 365 days before this one. Its description reads: Orkes Conductor v3.21.11 allows remote attackers to execute arbitrary OS commands through unrestricted access to Java classes. Same component, same mechanism, same outcome, one year earlier. The new CVE's own reference list points at it.

What the record does not contain is any statement from the project about why the 2025 issue did not result in the evaluator being locked down then. The affected range of the 2026 CVE begins at 3.21.21, which is ten releases after the version named in 2025, and the vulnerable line was still there when I read it at 3.21.23 in January 2026's release. Draw the obvious inference if you like, but label it as inference: the public record shows a fix that did not arrive for a year, not a documented decision to defer one.

What Conductor is, and why the orchestrator is the prize

Conductor was built at Netflix to orchestrate microservices and open sourced in 2016. The repository states the lineage in its own FAQ: Conductor OSS is the "continuation of the original Netflix Conductor repository after Netflix contributed the project" to an open-source foundation. The Java package namespace is still com.netflix.conductor, which is a useful thing to know when you go looking for it in a build file.

The project is Apache 2.0 and carries 32,212 GitHub stars as of today. It is maintained by Orkes, a company founded by engineers who led the work at Netflix, which raised a 60 million dollar Series B on 23 April 2026 led by AVP. Orkes says Conductor now runs inside more than 3,000 enterprises and publicly names LinkedIn, Twilio and Quest Diagnostics; its funding announcement names Netflix, JP Morgan Chase, Atlassian, Tesla, Oracle, American Express and GE Healthcare among users of the open-source project. Those are the vendor's figures in the vendor's funding announcement. Treat them as an indication of reach, not a census.

The reach is the point, and it is the reason this CVE deserves more attention than its KEV status suggests. A workflow engine is not an application sitting at the edge of an estate. It is the component that knows how to talk to everything else.

Four things follow from that, and each is checkable in Conductor's own documentation and source rather than inferred. Workers poll the server for tasks, so control of the server is control of what every worker is told to do. Every task's inputs and outputs pass through the server and are persisted, so the business data in flight is readable at rest. The HTTP system task takes a URI and a header map, and the documented patterns put bearer tokens, API keys and basic auth pairs into those headers, resolved from workflow input at run time. And the definitions and the execution history of everything the estate automates live in the same place.

Put plainly: compromise the orchestrator and you do not need to compromise the systems it orchestrates. You ask them, using the credentials and the patterns they already accept.

Separating method from interest matters here, because almost everyone with a number to offer sells something adjacent to it. Fortinet counts attempts blocked by Fortinet devices, which is a measure of Fortinet's estate as much as of the attack. Empirical Security's piece is a monthly column promoting a vulnerability prioritisation model, and it closes by inviting the reader to see how their portfolio ranks. Orkes sells the edition that has authentication and a secrets store.

None of that makes the figures wrong, and Fortinet's and Empirical's are the only exploitation figures anyone has published, so the alternative to using them is having none. It does mean the numbers describe the shape of each sensor network at least as much as they describe the shape of the campaign.

One absence is worth naming without accusation. The project's SECURITY.md asks researchers to report issues through GitHub security advisories. The repository has published none: I queried its security advisories endpoint and it returned an empty list. The CVE was raised by a third party CNA, the GitHub advisory that resulted is of the unreviewed type, and neither the project site nor the Orkes blog mentions the CVE. A patch that shipped on time is worth more than an advisory that did not, but a defender cannot subscribe to a commit message.

What is actually known about exploitation

The three published exploitation datasets, retrieved 19 September 2026. Previdian's figures reach this piece through The Hacker News; I could not find them on Previdian's own feed.

Source	What it reports	What it does not show
Fortinet FortiGuard, alert dated 15 September 2026	1,290 attempts blocked in 24 hours to 9 September, a 132 per cent daily rise; 6,696 in the seven days to 9 September, a 17 per cent weekly rise; top sources Germany, Hong Kong, Indonesia, the UAE and India	Distinct targets, distinct attackers, or a single confirmed compromise
Previdian honeypots, via The Hacker News	Three attempts since 24 July 2026, from two IP addresses in France and the United States	Anything about real estates. A honeypot measures who scans, not who lands
Empirical Security sensors, article dated 1 September 2026	Activity in each of the last three observation windows, most recently 21 August 2026	Volume, targets or outcome. No counts are given

Do the division. 6,696 blocked attempts across seven days is an average of 957 a day, and the 1,290 on the final day is 1.35 times that average. That is the profile of a commodity scanning campaign following a public exploit, not of a targeted operation. FortiGuard dates the public exploit to 9 August 2026, 24 days before the start of that seven day window, and SecurityWeek reports the same sequence: proof of concept code in early August, exploitation shortly afterwards.

Set that beside Previdian's three attempts in the 57 days since 24 July, from two addresses. Both figures can be true. Fortinet's sensors sit in front of real production estates in many countries; a honeypot sits where a scanner will trip over it. The honeypot number is the better guide to how indiscriminate the scanning is, and three hits in eight weeks says: not very. The Fortinet number is the better guide to how many real services are being probed, and 957 a day says: quite a lot.

Every one of those figures counts attempts. None of them counts victims. Across the CVE record, the CNA advisory, both telemetry vendors and the trade coverage, there is no named victim, no incident report, no dwell time, and no published indicator of compromise. That is the honest state of the evidence on 19 September 2026, and it should shape the response: this is a patch-and-hunt exercise driven by a credible capability and observed probing, not an incident response driven by known intrusion.

The signals that did not fire

Most UK remediation programmes are automated on a handful of inputs: a KEV date, a CVSS band, an EPSS threshold, a dependency scanner and an authenticated vulnerability scan. It is worth walking through what each of those inputs says about this CVE, because the pattern is instructive well beyond Conductor.

Automated inputs checked against CVE-2026-58138 on 19 September 2026, from the KEV catalogue JSON, the NVD record and the GitHub Advisory Database API.

Signal	What it says	Why that misleads
CISA KEV	Not listed, catalogue 2026.09.18	KEV dates drive most remediation clocks, so no clock started
CISA ADP decision, 1 July 2026	Exploitation: none. Automatable: yes. Technical impact: total	Accurate when written, never revisited, and still the record
EPSS	0.0926, at the 95th percentile	Nine per cent reads as low beside a 9.8, yet exploitation is observed
GitHub advisory GHSA-7x5q-8f6h-rjrc	Type unreviewed, affected-package list empty	With no package range, Dependabot has nothing to match and stays silent
FortiGuard outbreak alert	Affected: v3.23.0 and earlier	Disagrees with the CVE and would wrongly clear 3.30.0 and 3.30.1

Two of those rows deserve expanding. The EPSS score is not wrong and it is not a contradiction: EPSS estimates the probability that a vulnerability will be exploited in the next thirty days, and 0.0926 sitting at the 95th percentile mostly tells you how brutally skewed the distribution is. But a rule that says "escalate above 0.1" would not escalate this, and a rule that says "escalate on KEV" would not escalate it either.

The GitHub row is the one that will bite hardest. An unreviewed advisory with an empty affected-package list gives Dependabot nothing to match against, so no automatic alert fires. And even a fully reviewed advisory would usually miss this deployment, because Conductor is normally run as a container or a standalone server, not pulled in as a library that appears in an application's dependency file. Empirical Security also reports that as of 1 September there was no credentialed Tenable or Qualys plugin for the CVE. I could not verify that independently and it may well have changed since, but it matches the rest of the picture: a clean scan report is not evidence of absence here.

How to tell whether you run it

Conductor is rarely bought. It is adopted, usually by a platform, data or machine learning team that needed durable orchestration and picked the Apache 2.0 engine with the Netflix pedigree. It then does its job quietly for years. That is why the discovery problem here is larger than the patching problem, and why the first four items below are questions rather than queries.

Server identity, from the shipped REST path constants and configuration
  /api/version              server version
  /api/metadata/workflow    register a workflow definition (POST)
  /api/workflow             start a workflow (POST)
  /api/tasks                poll, update, complete or fail tasks
  /api-docs                 OpenAPI document (springdoc.api-docs.path)

Default ports from the project README
  8080  API, and the bundled UI when run via the CLI
  5000  UI, when run from the official container image

Names worth grepping for
  conductoross/conductor          official container image
  com.netflix.conductor           Java package and Maven group
  @conductor-oss/conductor-cli    npm package that installs a server

What to check in logs, and what to rotate

Workflow definitions persist. A definition registered in July is still sitting in the metadata store in September whether or not it ever ran, which makes the definition store the single best place to start a hunt on an instance that was reachable and unpatched.

If you find evidence of execution, or if the instance was internet reachable on an affected version for a meaningful period and you cannot rule execution out, the rotation list follows from what the orchestrator holds rather than from what the attacker was seen to take.

The question that exposes the gap

The interesting failure in this story is not the HostAccess.ALL line. That was a real mistake, it was found, and it was fixed properly on the second attempt within three weeks, which is a better record than most. The interesting failure is that everything built to tell a UK security team about it stayed quiet: no project advisory, an unreviewed GitHub record with no package range, an EPSS value below most thresholds, a stale exploitation field in the CISA record, no KEV entry 81 days after publication, and a scanner ecosystem that had nothing to say.

So the question to put to your platform team this week is not whether Conductor is patched. It is this. If someone stood up a workflow engine in this estate eighteen months ago to move data between two systems, and it has worked perfectly ever since, who owns it, what credentials does it hold for other systems, and on whose risk register does it appear? Everything in this briefing follows from the answer, and for most organisations the honest answer to the last part is: nobody's.

Key facts