CVE-2011-10026 is a critical (CVSS 9.8) command execution flaw in the API search of Spree (spreecommerce) before 0.50.x. Input in the search[instance_eval] parameter reaches Ruby's send method without sanitizing. Upgrade past the 0.50.x line, which the vendor covered in its April 2011 security fixes post.
What's affected
Spree (spreecommerce) versions prior to 0.50.x, per the record and VulnCheck. The weak spot is the API's search functionality. The vendor's advisory is titled security fixes and was published in April 2011.
The record does not give an exact fixed patch number, only that versions before the 0.50.x line are affected. Use the vendor advisory to pick the precise release, and in practice move to a currently maintained version.
This is a sibling of CVE-2011-10019, which hits the main search form on releases before 0.60.2.
How to check if you're exposed
List your Spree version:
bundle list | grep -i spree
Anything older than 0.50.x is in scope per the record. If the app has an exposed JSON API, test whether it is reachable from outside your network and whether it needs a key.
Then search your own code for dynamic method calls fed by request parameters:
grep -rn "send\|instance_eval\|public_send" app lib | head -50
Any match where the method name can come from a request needs a review, whether or not it is in Spree itself.
What to do now
- Find all Spree installs and versions, including copies in forks.
- Upgrade to a release newer than 0.50.x, and ideally to a maintained version.
- Restrict API access to authenticated clients and to the networks that need it.
- Replace any dynamic method call that uses request data with an allowlist.
- Review logs for odd API search requests, and rotate application secrets if exposure is likely.
Why it matters
The record classes this as CWE-78 (OS Command Injection). The shape is the same as its sibling: a search parameter that is passed straight to a method that can run arbitrary code. The input is not validated, so whoever sends it chooses what the server executes.
Search forms look harmless, which is why they get less review than login pages. They also tend to be reachable without authentication. That combination of an open entry point and an unchecked dynamic call is the whole story here.
The record does not flag this CVE as CISA KEV, and makes no claim of exploitation in the wild. Public exploit material is among its references, so assume attackers know the pattern.
Quick check
How is this different from CVE-2011-10019?
Same family, different entry point. This one is the API search on versions before 0.50.x. The other affects the main search on versions before 0.60.2.
Is this still relevant in 2026?
Only for old or forked Spree copies. The lesson, never pass request data as a method name, applies to any codebase.
Sources
Last reviewed: 19 October 2026.
