CVE-2025-54947 is a critical flaw in Apache StreamPark, where the system uses a fixed, built-in encryption key. Anyone who learns the key can decrypt protected data or forge encrypted values. Apache recommends upgrading to version 2.1.7, and says affected releases start at 2.0.0.
What's affected
- Product: Apache StreamPark.
- Affected: from 2.0.0, with an upper bound that the sources state two ways. The Apache announcement says "from 2.0.0 before 2.1.7" in its affected versions line, and also says "2.0.0 through 2.1.7" in the description.
- Fixed: Apache says users are recommended to upgrade to version 2.1.7.
Those two statements disagree about whether 2.1.7 itself is affected. The recommendation is to upgrade to 2.1.7, so take that literally and then confirm in the Apache release notes whether a later release exists and is safer. If you run exactly 2.1.7, check the project's own notes rather than assuming.
The finder is credited in the Apache announcement. Apache rates the issue as important.
How to check if you're exposed
Find out which StreamPark version each deployment runs.
ls -d apache-streampark* 2>/dev/null
docker ps --format "{{.Names}} {{.Image}}" | grep -i streampark
The first command finds unpacked distributions by directory name. The second lists container images, where the tag shows the version. The web console also shows version information once you log in. Check development, staging and test installs too, because they often hold copies of the same secrets as production.
Safeguard has a free in-browser dependency scan at gold.safeguard.sh/scan that checks a manifest or lockfile against known vulnerabilities, and the Gold directory lists affected packages for each CVE.
What to do now
- Inventory every StreamPark deployment and its version.
- Upgrade to 2.1.7 or later, following the project's upgrade notes.
- Treat anything protected by the built-in key as exposed. Rotate the credentials and tokens the platform stores, such as database and cluster passwords.
- Replace the built-in key with a securely configured one wherever the new version lets you set it, and keep that value out of source control.
- Limit network access to the console to administrators and review who holds accounts.
Why it matters
The weaknesses are a hard-coded cryptographic key and hard-coded credentials. A key baked into the product is the same on every installation. Anyone can read it out of the released code, so the encryption protects against casual viewing only. Forged values are the larger concern, because a system that trusts what it decrypts will accept an attacker's input encrypted with the known key.
The lasting fix for this class is per-installation secrets, generated at install time or supplied through configuration, plus a way to rotate them. Upgrading closes the product issue but does not undo any exposure that happened earlier. That is why rotating secrets is part of the response. The CVE is not on the CISA KEV list.
The weakness is classed as CWE-321 (Use of Hard-coded Cryptographic Key) and CWE-798 (Use of Hard-coded Credentials). Severity in the CVE record: critical, CVSS 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
Try it yourself
Not every flagged version is equally exposed. This demo walks through judging exploitability in context.
Click through it at your own pace, or open it full screen.
Quick check
Is 2.1.7 safe?
Apache recommends upgrading to 2.1.7, but its wording about the affected range is inconsistent. Read the release notes for your target version and confirm.
Do I need to rotate secrets after upgrading?
Yes if there is any chance the old key protected values stored on a reachable system. The key was public in the code, so rotation is the safe default.
Sources
- Apache announcement on the mailing list (listed in the CVE record; the page needed scripts, so the text was read from the oss-security copy)
- oss-security post
Last reviewed: 18 October 2026.
