CVE-2026-23885 is a code injection flaw (CVSS 6.4) in Alchemy CMS, a Ruby on Rails content management engine. A helper passes a module's engine name to Ruby eval, so an authenticated actor who can influence that value could run code. Versions 7.4.12 and 8.0.3 fix it. Upgrade the gem.
What's affected
Alchemy CMS before 7.4.12 on the 7.4 line, and before 8.0.3 on the 8.0 line. The vulnerable code is in the ResourcesHelper, in the resource_url_proxy method. The description says the engine name comes from module definitions that administrative configuration can influence, so the attacker needs an authenticated, privileged position.
How to check if you're exposed
From your Rails project:
bundle list | grep alchemy_cms
bundle exec gem list alchemy_cms
Check Gemfile.lock for the locked version. If you use Alchemy as an engine inside several apps, check each one.
What to do now
- Update alchemy_cms to 7.4.12 or 8.0.3 or later, then run your tests and deploy.
- Review who has administrator rights in your CMS, and whether any custom module definitions take values from user input or settings.
- Search your own code for eval calls on strings that come from configuration.
Why it matters
The weakness is CWE-95, improper neutralization of directives in dynamically evaluated code. The advisory points out that the source line even disables a security lint rule for eval. A linter warning that was silenced is a hint that a dependency or a review should have picked up.
The score is medium because exploitation needs an authenticated actor with influence over module configuration. That is a reason to avoid panic, not a reason to leave it unpatched: privileged accounts get phished and reused. The record does not list this CVE as known exploited.
Reading the severity score
The record gives a CVSS base score of 6.4, published 2026-01-19. In the vector, the attacker works with local access, needs a high privilege (administrator level) account, and the attack is high in complexity. User interaction is not needed. Impact on confidentiality is high, on integrity high and on availability high.
A base score describes the flaw in general, not your risk. Weigh it against how exposed your instance is and what it can reach. The Gold page for the CVE keeps the score, weakness and references together.
Hardening beyond the patch
Add a check for dangerous Ruby calls to your pull request pipeline. Static analysis tools for Rails can flag eval, send with user input and similar calls, and a disabled rule in dependencies is worth a review. Keep administrator accounts in your CMS to the minimum and require strong, unique passwords with two factor authentication where your setup supports it. Pin gem versions in Gemfile.lock and review dependency updates regularly so that fixes like 7.4.12 and 8.0.3 reach production quickly.
Find it across your own code
To see which of your packages are affected, the free in-browser dependency scan at gold.safeguard.sh/scan takes a manifest and lists known vulnerabilities. Reachability analysis then helps you judge whether your code calls the vulnerable path, so you can order the work.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Can an anonymous visitor exploit this?
The description says it allows an authenticated actor, and the engine name comes from administrative configuration. It is not described as anonymous.
Sources
Last reviewed: 19 October 2026.
