A vulnerability has been identified in the Flight SQL API and Query UI introduced in KurrentDB 26.1.0. A user who is authorized to read the $all stream — a user who can already read the entire contents of the database — can use these interfaces to read (but not modify) arbitrary files on the host that the KurrentDB process can access, including directory listings, and to make the server issue outbound HTTP GET requests. Environment variables are not exposed.
Severity: Moderate — CVSS v4.0 base score 6.9 (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N).
Am I affected?
You are affected if all of the following are true:
- Your instance is running KurrentDB 26.1.0,
- Your instance has secondary indexing enabled
- Your instance has granted read access to the
$allstream to one or more users.
Note: By default, only administrators can read $all, and they can already read the entire database — so a default configuration faces no meaningful escalation.
Impact
Self-hosted KurrentDB
On an affected instance, a user who can read the $all stream can:
- Read sensitive files that the KurrentDB process can access — e.g. private keys, configuration and credential files — including directory listings.
- Make the server issue outbound HTTP GET requests to any reachable endpoint (SSRF).
Kubernetes Operator
On an affected instance, a user who can read the $all stream can:
- Read sensitive files that the KurrentDB process can access — e.g. private keys, configuration and credential files — including directory listings.
- Make the server issue outbound HTTP GET requests to any reachable endpoint (SSRF).
- Read the additional sensitive files the Operator mounts to disk, such as private keys and credentials.
- Read the pod's Kubernetes ServiceAccount token and use it to authenticate to the Kubernetes API as that ServiceAccount.
- Where IAM-based archiving (IRSA) is configured, use that ServiceAccount token to read the cloud storage bucket used for archiving.
Kurrent Cloud
None. Customer data was not exposed or corrupted.
Recommended action
Self-hosted KurrentDB
- Upgrade to KurrentDB 26.1.1. If you cannot upgrade immediately, see the Workarounds below.
- Consider to rotate secrets in sensitive files readable by the KurrentDB service account if those secrets were not already known to users with
$allread access. - Consider to assess SSRF exposure — treat any data that could be retrieved over HTTP GET by the KurrentDB node as potentially exposed to users who can read
$all.
Workarounds:
A deployment can also be secured by disabling secondary indexing with yaml configuration:
SecondaryIndexing:
Enabled: falseor by setting environment variable KURRENTDB__SECONDARYINDEXING__ENABLED to false.
Secondary indexing will be confirmed disabled in the log on startup:
SecondaryIndexes 26.1.0.0 plugin disabled. To enable Second Level Indexing Set 'KurrentDB:SecondaryIndexing:Enabled' to 'true'Kubernetes Operator
- Upgrade to KurrentDB 26.1.1 (or disable secondary indexing using the Workarounds above).
- Rotate the secrets in the sensitive files the Operator mounts to disk.
- If authenticating as the KurrentDB pod's ServiceAccount would offer a meaningful escalation path in your environment, rotate the relevant secrets as well.
- If IRSA + ServiceAccount is used for IAM-based archiving, review the integrity of the associated storage bucket.
Kurrent Cloud
No customer action is required. Affected clusters have already been automatically upgraded to 26.1.1.
Contact us
If you encounter any issues, please don’t hesitate to open an issue on GitHub if there isn’t one already.
We also have an official Discord Server for discussions, questions and for giving us feedback.
If you have any questions that aren't covered in these release notes or the docs, please feel free to reach out .
