Description

Grav CMS's scheduler-webhook plugin contains an authentication bypass in the webhook token check. When the webhook feature is enabled but no webhookToken is configured, a compound conditional short-circuits and skips token validation, so an unauthenticated remote attacker who can reach POST /scheduler/webhook can trigger the operator's already-configured scheduled jobs by sending a single request. The primitive is triggering-existing-jobs, not attacker-chosen command execution: the attacker controls when the jobs run and which one runs (via ?job=), but does not control what the jobs do. Code execution follows only when the operator has configured a job that shells out, and even then the attacker controls timing rather than payload. Not a default-install issue: reaching the endpoint requires the separate scheduler-webhook GPM plugin to be installed, scheduler.modern.webhook.enabled to be true (default false), and no webhookToken to be configured; a stock Grav or Grav-Admin install exposes nothing here.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.3",
  "pubDate": "2026-08-07T19:17:34.497Z",
  "pubdate": "2026-08-07T19:17:34.497Z",
  "executiveSummary": "The Grav CMS scheduler-webhook plugin contains an authentication bypass vulnerability within its webhook token validation mechanism. This vulnerability stems from a logical flaw in a compound conditional statement that inadvertently short-circuits and entirely skips token verification when the webhook feature is enabled but no webhookToken has been explicitly configured by the system administrator.\nThe resulting impact allows an unauthenticated, remote attacker capable of reaching the POST /scheduler/webhook endpoint to trigger pre-configured operator scheduled jobs. While the exploitation primitive is restricted to triggering existing jobs rather than arbitrary attacker-chosen command execution, an attacker retains control over execution timing and can select specific jobs using the ?job= query parameter.\nThis issue does not affect default installations of Grav or Grav-Admin. Exploitation strictly requires the separate scheduler-webhook GPM plugin to be installed, the configuration setting scheduler.modern.webhook.enabled to be set to true (default is false), and the absence of a configured webhookToken.\nRisk implications remain moderate to high depending on the nature of the pre-configured scheduled jobs present on the target system. If administrators have configured jobs that execute system shell commands, unauthenticated third parties can prematurely invoke or control the execution frequency of those operations, potentially leading to operational disruption or secondary code execution if vulnerable routines exist.",
  "technicalDetails": "The vulnerability resides in the webhook token check implementation of Grav CMS's scheduler-webhook plugin. The root cause of the flaw is an improper compound conditional check that evaluates the presence and configuration of the webhook token. When the webhook feature is enabled but the webhookToken parameter is left unconfigured or empty, the logical evaluation short-circuits, bypassing the authentication token validation entirely.\nThe vulnerable component is exposed via the HTTP POST method at the endpoint POST /scheduler/webhook. Network exposure requires the target to have the scheduler-webhook GPM plugin installed and the configuration option scheduler.modern.webhook.enabled set to true. Because token validation is skipped under the misconfiguration condition, the endpoint requires no authentication or privileges.\nThe step-by-step attack flow proceeds as follows: First, an unauthenticated remote attacker identifies a Grav CMS instance meeting the prerequisite conditions where scheduler-webhook is enabled and lacks a webhookToken. Second, the attacker crafts an HTTP POST request targeting POST /scheduler/webhook. Third, the attacker leverages the ?job= query parameter to specify a target job from the operator's pool of already-configured scheduled jobs. Fourth, upon receiving the request, the flawed conditional logic short-circuits the security check, allowing the application to process the request without verifying credentials or tokens. Finally, the server executes the requested operator job.\nRegarding payload behavior and post-exploitation impact, the primitive strictly limits the attacker to triggering existing jobs rather than executing arbitrary attacker-chosen commands or payloads. The attacker controls when the jobs run and which job is invoked via the job parameter, but does not control the internal logic of the job itself. Code execution only follows in scenarios where the operator has previously configured a scheduled job that shells out to the underlying operating system. In such cases, the attacker's capability is limited to controlling the timing and invocation of those specific system commands rather than injecting custom payloads."
}