Security: SpEL injection in notifier message templates leads to Remote Code Execution

[cybervuln2077]

Summary

Moss inherits Spring Boot Admin's notifier subsystem (de.codecentric.boot.admin.*). The
notifier message/description templates are bound directly from external configuration via
@ConfigurationProperties and are evaluated as Spring Expression Language (SpEL) templates
inside a full-privilege StandardEvaluationContext. An actor who can influence the application
configuration can therefore execute arbitrary code on the host (RCE).

This is the same class of issue as Spring Boot Admin's CVE-2022-46166 / GHSA-w3x5-427h-wfq6;
Moss carries the affected pattern in moss-core.

Affected version

• Moss 1.0.0.RELEASE (module moss-core)

Root cause

The notifier treats an externally-controlled configuration string as a trusted internal template
and parses it with SpelExpressionParser without any validation, then evaluates it with an
unrestricted StandardEvaluationContext (full reflection / type access, e.g. T(java.lang.Runtime)).
No sandboxing is applied to the expression's capabilities.

Vulnerability chain (verified in moss-core)

1. Source — external configuration binding
   AdminServerNotifierAutoConfiguration binds spring.boot.admin.notify.<channel>.* to the notifier
   bean via @ConfigurationProperties. The setter receives the raw config string.

2. Parse — config string parsed as a SpEL template (SlackNotifier.java)

   public void setMessage(String message) {
       // 'message' comes straight from external configuration, no validation
       this.message = parser.parseExpression(message, ParserContext.TEMPLATE_EXPRESSION);
   }

3. Sink — evaluated in a high-privilege context when a notification is sent (SlackNotifier.java)

   protected String getText(InstanceEvent event, Instance instance) {
       // ...
       StandardEvaluationContext context = new StandardEvaluationContext(root);
       // ...
       return message.getValue(context, String.class); // expression executed here
   }

The same @ConfigurationProperties-bound template pattern applies to the other notifiers
(Discord / LetsChat / Telegram / Hipchat / PagerDuty / OpsGenie / MS Teams); SlackNotifier
is the confirmed instance.

Impact

Remote Code Execution on the Moss server. An actor able to set/modify the notifier message
(application.yml, environment variables, or an external/remote config source) can run arbitrary
OS commands when a notification fires (e.g. a monitored instance changes status).

• Severity: High — CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H (7.2)
• Confidentiality/Integrity/Availability all High; requires configuration-modification privilege (PR:H).

Proof of concept (non-destructive)

Set a notifier message template to a benign SpEL payload, e.g.:

spring:
  boot:
    admin:
      notify:
        slack:
          webhook-url: http://example.invalid/hook
          message: "#{T(java.lang.Runtime).getRuntime().exec('calc')}"

When a notification is triggered, the expression is evaluated and the command runs on the host.
(calc is used as a harmless placeholder; a real attacker would substitute an arbitrary command.)

Suggested remediation

• Replace StandardEvaluationContext with a restricted SimpleEvaluationContext
  (e.g. SimpleEvaluationContext.forPropertyAccessors(DataBindingPropertyAccessor.forReadOnlyAccess(), new MapAccessor())),
  which disables type references, constructor calls and arbitrary method invocation.
• Treat notifier templates as data, not code; if expression support is required, restrict it to a
  vetted allow-list of properties.
• Mirror the upstream Spring Boot Admin fix for CVE-2022-46166.

References

• Spring Boot Admin advisory GHSA-w3x5-427h-wfq6 / CVE-2022-46166