Webform REST CVE-2026-16644

Exploitation requires that the target Drupal site has the Webform REST contrib module installed and enabled at a vulnerable version (0.0.0 through 4.1.0) with its REST resources exposed. Given the CVSS vector (AV:N/AC:L/PR:N/UI:N), no authentication, user interaction, or special client-side conditions are needed once the module is present - a remote attacker sends crafted requests to the REST endpoints. The primary limiting factor is deployment: sites without the Webform REST module, or with those REST routes network-restricted, are not exposed. Because it is a specialized contrib module rather than default Drupal, real-world exposure is gated by whether an organization has deliberately deployed Webform REST.

The signals are mixed but lean toward genuine concern for exposed instances. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N) describes trivial remote unauthenticated exploitation with high confidentiality and integrity impact, and CISA's SSVC framework marks the flaw as Automatable=yes with Technical Impact=total, meaning a working technique could be scripted at scale. Counterbalancing this, EPSS is low at 0.18% (7th percentile), exploitation status is 'none' (not in CISA KEV, no public PoC identified), and the affected component is a niche contrib module rather than ubiquitous software - so this is more likely an important-but-not-yet-mass-exploited issue than an active emergency. The practical priority is real for any site actually running Webform REST, since forceful browsing to submission data is easy to attempt; organizations should patch promptly while recognizing that widespread automated exploitation has not been observed. No confirmed real-world exploitation exists in the provided data, so the urgency is driven by ease-of-exploitation and impact rather than evidence of attacks.

An attacker enumerates a Drupal site's REST endpoints and directly requests Webform REST resources - for example a submissions or form-data path - without authenticating. Because the module's authorization check is faulty, the server returns data that should have been access-restricted, exposing form submissions or allowing unauthorized modification. The low attack complexity and lack of required privileges or user interaction mean this can be attempted with simple scripted HTTP requests; no public PoC is identified at time of analysis.