CVE-2026-111690 is a hard-coded cryptographic key flaw (CWE-321) in Simple Admin Core through 1.8.7, scored 9.8 critical. The signing secret in the default config is public, so anyone can forge admin tokens. Set your own long random secret and rotate sessions. Check the project for a fixed release.
What's affected
Simple Admin Core through 1.8.7, per the CVE record. The weak value is the Auth.AccessSecret entry in api/etc/core.yaml, and the open pull request notes the same default in two example deployment configs for Docker Compose.
I could not confirm a fixed release. A pull request that replaces the default secret in the example configs was open when I looked. Deployments that already set their own secret are not affected by the default value, so the real question is what your running config contains.
How to check if you're exposed
Look at the configuration your service actually loads. Check core.yaml and any environment overrides, and find the value of Auth.AccessSecret. If it still matches the value from the project's example files, treat the deployment as exposed. Do not paste the value into tickets or chat.
Check your Docker Compose and Kubernetes files too, since the example deployments carry the same default.
Then review admin activity. Tokens signed with the public secret are valid in the eyes of the service, so look for unexpected users, roles, menus, API authorities or configuration changes.
You can also run the free in-browser dependency scan or browse the Gold directory to see where a package or product shows up in your stack.
What to do now
- Generate a new long random access secret and supply it through an environment variable or a secret store, not a file in version control.
- Restart the service so that all tokens signed with the old secret stop working, and ask users to sign in again.
- Review users, roles, menus, API authorities and tokens for changes you did not make.
- Search your repositories and images for the old default in committed config files and clean them up.
- Watch the project for a release that removes the default secret from the example configs, and upgrade when it ships.
Why it matters
A signed token is only as strong as the secret behind the signature. When the secret is the same for every install and is published in the repository, the signature proves nothing. The class is CWE-321. The record says an attacker can sign a token claiming the super administrator role and gain full control of users, roles, configuration and tokens.
This is a common failure with example configs. They are copied into production, and nobody changes the one line that matters. Making the service refuse to start without a custom secret closes the gap by design.
The record does not flag this CVE as exploited in the wild and it is not a CISA Known Exploited Vulnerability.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does an upgrade fix it?
I could not confirm a fixed release. Setting your own secret fixes your deployment either way.
Do I need to log everyone out?
Yes. Changing the secret makes the old tokens invalid, including any forged ones.
Sources
Last reviewed: 19 October 2026.
