SteemVM Security Maintenance Update — v0.0.4-1 Images Published

We've published a security maintenance rebuild of the SteemVM node and oracle images. This one
is housekeeping rather than drama: no exploit, no incident, and nothing wrong with the chain.
It is routine dependency hygiene, done before it becomes urgent rather than after.

Every validator can pick it up whenever convenient. There is no upgrade height, no governance
vote, and no coordinated halt.

---

What this is

Back when we shipped v0.0.4, that was a genuine emergency: a balance-underflow bug in cosmos/evm
that had already been used to drain three other chains. This is the opposite kind of release.

Container images bundle a lot more than the code we write — a Linux base, the Go standard library,
and every third-party library our dependencies pull in. Those accumulate published
vulnerabilities over time even when our own code never changes. So we audited the published
images and rebuilt them against current versions of everything underneath.

No application code changed. No consensus logic changed. No state-machine dependency changed.
It is the same v0.0.4 chain software, recompiled on a patched foundation.

The result

Scanning the published images before and after (via Docker Scout):

Image	Before	After
steemvmd (the node)	12 Critical / 35 High	0 Critical / 13 High
steemvm-oracle-js	2 Critical / 17 High	0 Critical / 3 High
steemvm-oracle-go	not previously scanned	0 Critical / 6 High
steemvm-oracle-python	not previously scanned	0 Critical / 3 High

Zero Critical-severity findings remain across all four published images.

The bulk of it came from an unexpected place. Roughly eleven of the node image's twelve Critical
findings were not in SteemVM at all — they were inside cosmovisor, the small supervisor
process that swaps binaries at upgrade heights. It ships its own frozen dependency tree, which
had drifted years out of date. It is not part of consensus and never touches chain state, so
refreshing it was safe, and it accounted for almost the entire problem.

What actually changed under the hood:

• Go toolchain 1.26.5 → 1.26.8
• cosmovisor v1.7.0 → v1.7.3, rebuilt against current cryptography and networking libraries
  (golang.org/x/crypto 0.29.0 → 0.56.0)
• SteemVM's own golang.org/x/crypto 0.53.0 → 0.56.0
• The JavaScript oracle moved to a Debian 13 base and dropped the bundled npm CLI it never runs

A remaining handful of lower-severity items are either already fixed upstream and waiting on
Debian, or belong to libraries that can only move during a proper coordinated upgrade. Those are
tracked openly in SECURITY.md in the repository, and are queued for the next coordinated
upgrade rather than quietly bundled into a release we're telling you is safe to apply casually.

Verification we ran before publishing

• Full test suite — all packages pass
• A throwaway devnet boot on the patched binary: genesis validated, 8 blocks produced, no panics
• All three oracle clients start correctly on the new images

What validators need to do

Pull and restart. That's the whole procedure:

docker compose pull
docker compose up -d

Or use the update script, which also refreshes peers and restarts your oracle client:

./update.sh

Your keys, your stake, and your validator identity are completely untouched. Nothing needs
re-registering, re-staking, or re-confirming. There is no deadline — the chain runs fine with a
mix of old and new images, because nothing about consensus changed.

Checking which build you're on

The patched image still reports version 0.0.4. That is deliberate: the version string has to
keep matching the on-chain upgrade record, so we didn't touch it. To tell the builds apart:

docker exec steemvm-node /root/go/bin/steemvmd version --long

go1.26.8 means you're on the patched build. go1.26.5 means you're not yet.

Also new: prebuilt oracle images

Until now, running an oracle client meant building it from source on your own machine. All three
are now published, so a validator just pulls one:

• steemblazer/steemvm-oracle-go
• steemblazer/steemvm-oracle-python
• steemblazer/steemvm-oracle-js

Pick whichever language you're comfortable operating — they are functionally identical, and you
should only ever run one at a time.

---

To be clear once more, since security posts tend to get read with alarm: nothing was exploited,
no funds were ever at risk from this, and no user action is urgent. We rebuilt on a patched
foundation because keeping the gap at zero is cheaper than closing it under pressure later.

Questions welcome in the comments or the validator channel.