CVE-2026-53634 Root-Cause Fix for Sharp Quick Creation Authorization Bypass

Vulnerability

CVE-2026-53634 is an authorization flaw in Code16 Sharp's Quick Creation Command controller that allowed an authenticated user without create permission to access the quick creation form endpoint and submit quick creation requests. The issue is documented in the advisory and CVE records: GHSA-VMWX-M75V-QVCH, NVD, and CVE.

The patch sources indicate the controller previously lacked an entity-level authorization gate for the quick creation flow. The provided diff summary shows create checks being introduced in the controller, and the new test demonstrates the expected behavior: when the entity prohibits the create action, both the form retrieval request and the submission request must return HTTP 403. See the patch references at PR #729 and commit aa18a85.

app(SharpEntityManager::class)
    ->entityFor('person')
    ->setProhibitedActions(['create']);

$this->getJson(route('code16.sharp.api.list.command.quick-creation-form.create', [
    'entityKey' => 'person',
    'formEntityKey' => 'person',
]))->assertForbidden();

$this->postJson(route('code16.sharp.api.list.command.quick-creation-form.create', [
    'entityKey' => 'person',
    'formEntityKey' => 'person',
]))->assertForbidden();

Patch

The fix adds explicit authorization enforcement for the quick creation controller by checking the create permission on the target entity. Although the supplied digest is abbreviated, it clearly shows the newly inserted calls:

$this->authorizationManager->check('create', $entityKey);
$this->authorizationManager->check('create', $entityKey);

Based on the accompanying regression test, the intent is to enforce authorization consistently across both controller actions involved in the quick creation workflow: the GET endpoint that returns the configuration/form payload and the POST endpoint that persists the new record. This aligns the quick creation path with the normal entity creation authorization model described by the advisory at GitHub Security Advisory.

The test coverage added in PR #729 is important because the vulnerability was not only record creation, but also unauthorized access to the form/configuration surface. The test asserts forbidden responses for both request methods after marking create as prohibited on the entity.

Review

Pros

• The patch targets the actual missing control: entity-level authorization for quick creation.
• It protects both stages of the workflow evidenced by the test: form retrieval and form submission.
• The regression test is security-relevant and directly models the reported abuse case by prohibiting create and asserting HTTP 403 on both endpoints.
• The fix is low-risk from a behavior standpoint because it reuses the existing authorization manager rather than introducing a new policy mechanism.
• The change is well-correlated with the vulnerability description in the advisory and CVE records, improving confidence that the patch addresses the reported issue.

Cons

• The provided diff excerpt is truncated, so the exact placement of each authorization check inside controller methods is not visible from the supplied material alone.
• The snippet shows the same check('create', $entityKey) line twice without surrounding method context, which makes it impossible to verify from the excerpt whether both GET and POST handlers are independently guarded or whether shared code is used.
• The test covers the denied path but does not, in the supplied snippet, demonstrate an allowed-path assertion for authorized users.
• The available sources do not show whether authorization is evaluated against entityKey only or whether formEntityKey can diverge in ways that would require additional validation.

Verdict

Root-cause.

The vulnerability is a classic missing authorization check, and the patch appears to correct that omission at the controller entry points used by the quick creation feature. The added regression test confirms the intended security property for both fetching the quick creation form and submitting it. Within the limits of the provided source excerpts, this is a direct and appropriate fix rather than a superficial mitigation. Engineers should still review the full controller in the fixing commit to confirm there are no alternate quick creation paths or mismatches between entityKey and formEntityKey, but the evidence provided supports classifying the patch as a root-cause remediation.