The core vulnerability in CamaleonCMS 2.9.1 is a classic injection surface hiding behind what developers believed was secure code: the slug field. When building post content, the application normalizes slugs in Ruby — converting to lowercase, replacing spaces with hyphens, stripping Unicode characters, trimming length — before inserting the result into a SQL query. The critical failure is that this normalization happens in application logic, producing a string that gets interpolated directly into SQL. The developer likely added parameterization to the obvious fields (title, content, author) and the change passed review because parameterization was present in the query — yet the injection surface had already been created upstream in the string transformation pipeline.
This is the 'sanitize for format, then query' antipattern. The slug normalization was designed for URL safety, not security, but it creates the illusion of a 'clean' string that developers trust more than raw user input. That trust is the vulnerability. Any field requiring string manipulation before database insertion is now a high-risk injection surface — the transformation itself is where the injection gap opens, not at the query layer where parameterization lives.
The authenticated constraint is narrower than it sounds. Post creation privileges in CamaleonCMS default to contributor and author roles, not just administrators. Many installations enable self-registration at these privilege levels, making the attack surface substantially larger than a strict admin-only model. If your CMS accepts registered users, treat the slug field as exploitable by any authenticated account.
Exploitation against SQLite works via blind boolean and union techniques, though it's slower and noisier than MySQL or PostgreSQL due to the lack of built-in benchmarking functions. Whether this injects reliably against PostgreSQL/MySQL depends on how the slug transformation code handles dialect differences — test before assuming it's SQLite-only.
After successful injection, the blast radius extends beyond the database. CamaleonCMS stores session secrets and application credentials in configuration files readable by the web process. Extracting database contents enables lateral movement into the Rails credential store, session decryption, and potentially file system access through template rendering. Additionally, the plugin ecosystem overrides post model behavior — including slug generation callbacks — meaning plugins may silently re-introduce the same vulnerability in code paths that won't appear in core codebase diffs.
Audit your slug processing code specifically, not just parameterized queries. Check plugin dependencies for before_save or normalize_slug callback overrides. The fix requires moving slug normalization inside parameterized execution or eliminating it entirely — not just adding parameterization to the query in isolation.