CVE-2025-15099 is a high severity improper authentication flaw in Sim (simstudioai/sim) up to 0.5.27, in the CRON secret handler. When the expected secret was not set, the check could be satisfied without it. NVD scores it 7.3. Upgrade to a release that includes commit e359dc2 and set both secrets.
What's affected
The record lists simstudioai sim up to version 0.5.27. The affected code is apps/sim/lib/auth/internal.ts, the CRON secret handler, together with the INTERNAL_API_SECRET comparison in the workflow middleware. The fix is commit e359dc2946b12ed5e45a0ec9c95ecf91bd18502a, merged through pull request 2343 titled to reject CRON requests when the CRON secret is not set. We did not confirm which release number first contains that commit, so check the project's release notes or tags, or test your checkout with the git command below.
How to check if you're exposed
If you run Sim from a git checkout, check whether the fix is in your history.
git merge-base --is-ancestor e359dc2946b12ed5e45a0ec9c95ecf91bd18502a HEAD && echo patched || echo not patched
If you deploy from images or release archives, compare your version with the project's releases and confirm that the one you use postdates the commit. Then check that both secrets are actually configured in the running environment, without printing them.
[ -n "$CRON_SECRET" ] && echo CRON_SECRET set || echo CRON_SECRET missing
[ -n "$INTERNAL_API_SECRET" ] && echo INTERNAL_API_SECRET set || echo INTERNAL_API_SECRET missing
The vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L) shows the issue is reachable over the network with no account at all, so any instance reachable from untrusted networks and missing a secret deserves priority.
What to do now
- Find every Sim instance you run and note the version or commit it was built from.
- Upgrade to a release that contains commit e359dc2, and confirm the release notes or tags before closing the task.
- Set a long random value for both
CRON_SECRETandINTERNAL_API_SECRETin every environment, and keep them in your secrets manager, not in source control. - Make sure scheduled jobs send the matching secret after the change, and test that a call without it is rejected.
- Review logs of CRON and workflow endpoints for calls that did not come from your scheduler.
- Rotate the two secrets if there is any chance the instance ran without them while exposed.
Why it matters
The weakness is CWE-287, improper authentication. From the patch, the logic compared a request header against an environment variable. If the variable was never set, the comparison could be satisfied by a request that also lacked the header, since two empty values look alike. The fix rejects the request outright when the secret is not configured, and adds a check that the internal secret exists before comparing.
This is a common pattern called failing open. A missing configuration value should make the system refuse requests, not accept them. The record scores the issue 7.3 and says the exploit is public. It is not on the CISA KEV list.
Going further
Automation endpoints deserve the same scrutiny as user facing ones. A cron route often runs privileged jobs, so a weak check there can matter more than a weak login page.
A useful test for any service you run is a startup check that refuses to boot, or at least logs loudly, when a required secret is missing.
The pull request is small, which is typical for this class of bug. Two short guards close the gap, one in the cron check and one in the workflow middleware. That also makes it a good model for a code review rule: whenever code compares a request value with a configured value, ask what happens if the configured value is empty.
For your own services, add a test for that case. A unit test that sets the secret to nothing and sends a request with no header should expect a refusal. It takes minutes to write and catches a whole class of mistakes.
If you track open source projects like this one in your SBOM, Safeguard Gold lists the CVE and the free in-browser scan at https://gold.safeguard.sh/scan checks the dependencies in your manifests. Use reachability analysis to separate the exposed endpoints from the noise.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is setting the secrets enough on its own?
It closes the missing secret case, but you should still upgrade, because the patch adds the explicit rejection and the guard on the internal secret.
How do I confirm the fix is in my build?
Use the git ancestry check above for a checkout, or compare your release against the project's release notes if you deploy packaged builds.
Sources
- Safeguard Gold record for CVE-2025-15099
- NVD entry for CVE-2025-15099
- Fetched reference on github.com
- Fetched reference on github.com
Last reviewed: 19 October 2026.
