GHSA-CVPC-HCCG-WMW4 Patch Review: Missing Authorization Fix Appears Incomplete

Vulnerability

GHSA-CVPC-HCCG-WMW4 describes a missing authorization issue in Formie administrative settings. The reported impact is a classic server-side access-control failure: low-privileged Craft CMS Control Panel users are allegedly able to bypass UI restrictions and invoke Formie controller endpoints directly to change administrative settings and retrieve sensitive integration material such as API keys. This is a privilege-escalation condition because authorization is enforced inadequately at the presentation layer while sensitive state-changing endpoints remain reachable.

For this class of defect, the expected remediation is explicit server-side permission validation on every affected controller action, ideally using Craft CMS capability checks before reading secrets or mutating settings. UI-only gating, hidden controls, or client-side restrictions are not sufficient because direct HTTP requests bypass them entirely.

Patch

The supplied official patch reference is the compare view for Formie 3.1.27...3.1.28. Based on the provided snippets, the visible changes are:

• Documentation edits in docs/integrations/email-marketing.md for EmailOctopus setup wording.
• A behavioral change in src/integrations/emailmarketing/EmailOctopus.php replacing exception-driven create-then-update logic with a direct PUT request path.
• A rebuilt frontend bundle in src/web/assets/frontend/dist/js/formie.js.

No provided snippet shows changes to controller classes, permission gates, policy checks, secret redaction, or administrative settings authorization. The only concrete code delta in the supplied source material is unrelated to access control:

[VULNERABLE]
try {
    $response = $this->deliverPayload($submission, "lists/{$this->listId}/contacts", $payload);
} catch (Throwable $exception) {
    if ($exception instanceof RequestException && $response = $exception->getResponse()) {
        $message = Json::decode((string)$response->getBody());
        $errorCode = $message['error']['code'] ?? '';
    }
}

if ($errorCode === 'MEMBER_EXISTS_WITH_EMAIL_ADDRESS') {
    $response = $this->deliverPayload($submission, "lists/{$this->listId}/contacts/$emailHash", $payload, 'PUT');
}

[PATCHED]
$response = $this->deliverPayload($submission, "lists/{$this->listId}/contacts", $payload, 'PUT');

This EmailOctopus change appears to simplify contact upsert behavior and does not map to the advisory's stated root cause. Likewise, documentation and minified frontend asset updates do not demonstrate server-side authorization hardening.

Review

Pros

• The release associated with 3.1.28 does contain code changes, indicating active maintenance and a shipped update corresponding to the advisory window.
• The EmailOctopus integration change may improve robustness by avoiding exception-based duplicate-member handling, which can reduce error-path complexity in that subsystem.
• The advisory itself clearly identifies the security boundary that should be enforced server-side, which is useful for downstream validation and regression testing: direct HTTP access to administrative endpoints must be denied to low-privileged users.

Cons

• The provided patch evidence does not show any authorization checks added to affected controller endpoints, service methods, or settings accessors.
• No snippet demonstrates use of Craft CMS permission enforcement, request preconditions, or explicit denial paths for unauthorized Control Panel users.
• No visible change addresses exposure of API keys or administrative settings reads, which are central to the advisory impact statement in the GHSA.
• The frontend bundle change is not persuasive evidence for fixing a server-side authorization flaw, because direct HTTP requests bypass client code entirely.
• The compare snippets may be incomplete relative to the full patch, but on the supplied record there is insufficient source-grounded proof that the vulnerability's root cause was remediated.

Verdict

Partial fix.

On the supplied sources, the patch cannot be validated as a root-cause fix for the reported missing authorization vulnerability. The advisory describes a server-side access-control defect, but the visible diff content is concentrated in EmailOctopus integration logic, documentation, and generated frontend assets rather than controller authorization. Unless additional unshown files in the official compare add permission checks to the relevant administrative endpoints, this patch evidence does not substantiate complete remediation.

Recommended follow-up for maintainers and reviewers is to inspect all Formie controller actions that expose settings mutation or secret retrieval and verify they enforce least-privilege authorization on the server side. Regression tests should include direct authenticated HTTP requests from low-privileged Control Panel accounts to confirm denial for both read and write operations. The advisory context can be cross-checked via GitHub Security Advisory and the external report at cvereports.com.