A Security Hardening Release for Blocklet Server
We have published a security hardening release for Blocklet Server. Every release up to and including 1.17.12 is affected. The fixes are in 1.17.13-beta-20261019-082907-fe71de61 and every later beta.
- Affected: all releases up to and including
1.17.12 - Fixed in:
1.17.13-beta-20261019-082907-fe71de61and later - If we host your apps: nothing to do, our servers already run the fixed build.
- If you self-host: install the beta CLI and restart the server.
Updating is all that is needed. The optional steps at the end are there for operators who ask for them. None of them is required.
What the review found
We used AI assistance to review far more of the Blocklet Server codebase than a manual pass allows. We traced every kind of credential the server accepts through every path that accepts it, and we reviewed what the server writes to its logs. Each issue was fixed within days of being identified. The findings fell into three groups:
- Authorization scope. On some paths a credential could be accepted for actions beyond the scope it was issued for. Those paths now check the credential against what is actually stored and permitted.
- Logging detail. Some internal values went into logs and webhook payloads in more detail than they needed to. They are now redacted where they are produced.
- Input validation. Several endpoints did not sufficiently constrain URLs and identifiers supplied by callers. Those constraints are now in place.
Every fix is a separate fix(security) commit in the public repository, so you can read exactly what changed and when.
Alongside the code changes, we refreshed credentials on our own infrastructure, narrowed network access to our servers and improved monitoring. That is ordinary hygiene, and worth doing whenever authentication code changes.
If we host your apps
There is nothing for you to do. Our servers already run the fixed build.
As part of the update we rotated session signing keys, which is routine after a change to authentication code. Sessions and refresh tokens issued before the rotation are no longer valid, so the next time you open the dashboard or one of your apps you will be asked to sign in once. After that, everything continues as before. Your apps, data, domains and app identities are unchanged.
If you self-host Blocklet Server
Move to the beta channel. The current stable release, 1.17.12, does not contain these fixes, so install the beta CLI explicitly. The fixes will be folded into the next stable release. All published versions are listed on npm.
You run an official release
npm i -g @blocklet/cli@beta
blocklet server stop
blocklet server start
blocklet --version # expect 1.17.13-beta-20261019-082907-fe71de61 or newer
blocklet server statusInstalling the package does not change a running server. The new code takes effect after the restart, so check blocklet --version once the server is back up.
You build from source
Pull the latest code from the default branch of the public repository and rebuild. Each fix is its own fix(security) commit, so you can review them before you ship. As with an official release, restart the server after you deploy the new build.
Known limitations
- Stable does not carry the fixes yet. Until the next stable release,
npm i -g @blocklet/cliwithout@betainstalls1.17.12, which is still affected. - A restart is required. A server that has the new package installed but has not been restarted is still running the old code.
- Everyone signs in again once on hosted servers. The session key rotation invalidates sessions issued before it, for the dashboard and for apps.
Optional: extra assurance
Operators sometimes ask about these steps, and they are good practice to know regardless.
Rotate session keys
This invalidates every session and refresh token already issued, for the server and for every installed app. Everyone signs in again.
blocklet server rotate --dry-run # lists what would be rotated, changes nothing
blocklet server rotate
blocklet server stop
blocklet server start # the new keys take effect after the restartRotate an application's key pair
To give an application a fresh key pair, whether it was launched with DID Wallet or with a server-managed wallet, open the application in the Blocklet Server dashboard, go to the Global Settings tab and use Change DID. The app owner approves the change with DID Wallet, and the key migration is recorded on the ArcBlock chain. Any assets held by the application's account are carried over automatically, so there is nothing to move by hand.
Before you start:
- Only the application's owner can perform the rotation.
- The application must be on the latest application structure. If it is not, migrate it first. The dashboard will tell you.
- The application restarts once when the rotation completes, so expect a brief interruption for that app.
Rebuild the server
Some operators prefer to rebuild a server from scratch from time to time. The new server can live on a fresh machine or on the same machine: blocklet server init creates a server in the current directory, so a second copy only needs its own empty directory. Several copies can exist side by side, but only one can run at a time. Move apps across one by one:
- Install the same version wherever the new server will live:
npm i -g @blocklet/cli@beta - In an empty directory, initialize the new server, which creates a new server identity:
blocklet server init - With the old server running, export each application:
blocklet export --app-did <appDid> --out-dir /path/to/bundle - Stop the old server, start the new one, and import each bundle while the new server is running. If the new server is on another machine, copy the bundle there first.
blocklet import /path/to/bundle - If the new server is on a different machine, point DNS at it and re-issue certificates. With DID Domain and DID DNS this should happen automatically.
- Recreate server-level settings by hand: owner, trusted passports, access keys.
- Verify the new server fully before you retire the old one, and keep the old copy and its data intact until you are satisfied.
What travels with the bundle: the application's DID, its key pair, its encryption key, its session salt, and all in-app user accounts and data. Users of your apps are not affected and keep their accounts.
What does not travel: anything at the server level, including the owner, trusted passports, routing rules, access keys and certificates. Expect to set these up again on the new server.
Questions and reports
If you have questions, or something looks wrong after you update, reply in the community thread for this release. If you would rather report something privately, email support@arcblock.io and we will respond quickly.
Thank you to everyone running Blocklet Server. Work like this is how we keep it worth your trust.