Severity: Medium
Problem
The command intent model declares destructive and requiresConfirmation fields in src/factory-core.ts:27, but the factory uses intent only as tooling metadata. It does not require confirmation before invoking a destructive command's handler.
As a result, commands capable of deleting resources, shutting down deployments, rotating credentials, or removing local extension data execute immediately after argument validation. Examples include:
- Serverless project deletion
- Hosted deployment shutdown
- Serverless credential reset
- Elasticsearch and Kibana DELETE operations
- Local extension removal
This is a safety and authorization-intent gap, not privilege escalation: the caller must already have credentials for the operation and explicitly invoke the command. A wrong resource identifier, incorrect active context, or misdirected agent can still cause destructive effects without a separate acknowledgement.
Intent coverage is incomplete. Elasticsearch and Kibana commands infer
destructive: true from the HTTP method in src/es/register.ts:86 and src/kb/register.ts:76, so generated DELETE entries already carry the flag. Cloud commands do not infer or set intent — src/cloud/register.ts:162 omits it — meaning Cloud DELETE operations and destructive POST operations such as shutdown and credential reset are not identified as destructive. elastic extension remove also receives no --dry-run and is not marked destructive at src/extension/register.ts:150.
commands.allowed and commands.blocked are local execution guardrails, not an authorization boundary. A caller possessing the underlying credential can bypass them by calling the API directly. Confirmation and command policy mitigate mistaken or agent-induced execution; they do not reduce the credential's server-side privileges.
Fix
Implement confirmation as an execution control in the common factory:
- Add a reserved
--yes option to commands marked requiresConfirmation: true. Treat destructive: true as implying requiresConfirmation: true unless the command declaration explicitly overrides it.
- Perform complete validation first; let
--dry-run exit without requiring confirmation. In dry-run mode, emit the validated, fully resolved request payload — URL, method, and body — so the caller can verify what would be sent.
- If
--yes is present, proceed without prompting.
- If stdin is a TTY and structured JSON is not being read from stdin, show the
active context and affected resource, then require explicit confirmation.
- For non-interactive,
--json, piped-stdin, and agent execution, fail closed
unless --yes is supplied.
- Return a stable structured error such as
confirmation_required in JSON mode.
- Send prompts to stderr so stdout remains machine-readable.
- For particularly consequential operations, consider requiring the user to type
the resource identifier rather than a simple y.
Intent coverage must also be corrected:
- Infer
destructive: true for Cloud DELETE operations at registration time.
- Explicitly annotate destructive POST endpoints: shutdown, credential rotation,
bulk deletion, force-delete.
- Mark
extension remove as destructive and confirmation-required.
- Add a validation test asserting
requiresConfirmation: true implies destructive: true.
For agent deployments, pair CLI command policy with server-enforced, least-privilege API keys.
Risk
Medium. Impact may be high, but this is not privilege escalation.
Copied from the security review in elastic/infosec#27626 (ECLI-005).
Severity: Medium
Problem
The command intent model declares
destructiveandrequiresConfirmationfields in src/factory-core.ts:27, but the factory uses intent only as tooling metadata. It does not require confirmation before invoking a destructive command's handler.As a result, commands capable of deleting resources, shutting down deployments, rotating credentials, or removing local extension data execute immediately after argument validation. Examples include:
This is a safety and authorization-intent gap, not privilege escalation: the caller must already have credentials for the operation and explicitly invoke the command. A wrong resource identifier, incorrect active context, or misdirected agent can still cause destructive effects without a separate acknowledgement.
Intent coverage is incomplete. Elasticsearch and Kibana commands infer
destructive: truefrom the HTTP method in src/es/register.ts:86 and src/kb/register.ts:76, so generated DELETE entries already carry the flag. Cloud commands do not infer or set intent — src/cloud/register.ts:162 omits it — meaning Cloud DELETE operations and destructive POST operations such as shutdown and credential reset are not identified as destructive.elastic extension removealso receives no--dry-runand is not marked destructive at src/extension/register.ts:150.commands.allowedandcommands.blockedare local execution guardrails, not an authorization boundary. A caller possessing the underlying credential can bypass them by calling the API directly. Confirmation and command policy mitigate mistaken or agent-induced execution; they do not reduce the credential's server-side privileges.Fix
Implement confirmation as an execution control in the common factory:
--yesoption to commands markedrequiresConfirmation: true. Treatdestructive: trueas implyingrequiresConfirmation: trueunless the command declaration explicitly overrides it.--dry-runexit without requiring confirmation. In dry-run mode, emit the validated, fully resolved request payload — URL, method, and body — so the caller can verify what would be sent.--yesis present, proceed without prompting.active context and affected resource, then require explicit confirmation.
--json, piped-stdin, and agent execution, fail closedunless
--yesis supplied.confirmation_requiredin JSON mode.the resource identifier rather than a simple
y.Intent coverage must also be corrected:
destructive: truefor Cloud DELETE operations at registration time.bulk deletion, force-delete.
extension removeas destructive and confirmation-required.requiresConfirmation: trueimpliesdestructive: true.For agent deployments, pair CLI command policy with server-enforced, least-privilege API keys.
Risk
Medium. Impact may be high, but this is not privilege escalation.
Copied from the security review in elastic/infosec#27626 (ECLI-005).