# Resolve kubectl plugin shadowing before invoking an extension > Duplicate PATH entries and longer matching plugin names affect which executable kubectl selects. Review discovery warnings and the intended command path before running the extension. - Canonical URL: https://update.dsesecurity.com/updates/resolve-kubectl-plugin-shadowing-before-invoking-an-extension/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T17:40:57+00:00 - Modified: 2026-10-29T17:41:39+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Duplicate PATH entries and longer matching plugin names affect which executable kubectl selects. Review discovery warnings and the intended command path before running the extension. ## Potentially affected Review scope: the documented kubectl executable-plugin discovery and naming rules; plugin trust, installation and behavior require their own approval. ## DSE recommendation Reconcile the intended extension with plugin-list warnings, executable locations and command naming before an authorized invocation. ## Article Bottom line: Identify the executable that should handle an extension command before relying on its output. Treat an unexpected plugin result as a command-discovery investigation first, with the intended executable and invocation written down together. ## Source fact: documented behavior The [Extend kubectl with plugins](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/) documentation is the primary reference. The documented kubectl plugin list command searches PATH and warns about nonexecutable files and overlapping plugin names. For duplicate plugin filenames, the executable found first in PATH is selected; for matching nested command names, the longest matching executable filename is preferred. Plugins cannot overwrite existing kubectl commands; the guide documents an exception allowing custom commands under create. ## What the source does not establish This article concerns executable selection, not acceptance of a third-party program or the correctness of its cluster operations. Resolve the extension’s provenance and permitted actions separately. A recognizable filename, discovery listing or absence of a warning is not the approval record for running it. ## Applicability questions - Which exact executable is approved for this command? - Are duplicate filenames present in different PATH locations? - Does a longer matching plugin command exist? - Does the chosen name collide with an existing built-in command? ## DSE recommendation: make the executable choice reviewable DSE recommends recording the approved extension location, file identity and intended invocation in the operating procedure. Obtain those details from the managed installation rather than from a name alone. Keep the discovery environment attributable to the same user or automation identity that will perform the work. Review plugin-list warnings before the operational invocation. For a duplicate filename, compare the competing locations and decide which installation should remain authoritative. Use the managed installation process to correct an unintended duplicate or path order. Avoid deleting a file merely because its name appears in a warning without first identifying its owner. Review nested command names as a small command tree. Write which executable should handle the intended command and which trailing words are meant to be arguments. Include longer installed names in that review. Do not troubleshoot application behavior against one binary while an operator is invoking another. Keep any path-order change bounded to its approved environment. Compare the interactive shell and scheduled task separately when both are used. Preserve the original discovery record and planned correction, then repeat discovery before the authorized extension run. Escalate a surprising built-in collision to the extension owner instead of trying progressively different operational commands. ## Verification and evidence Proposed verification, not performed: create an isolated test directory containing harmless approved fixture executables that print their own fixture identity. Exercise two duplicate filenames in separate test path locations, then two nested command names. Keep real cluster credentials outside the exercise. Predict the selected fixture for each path order and command before invoking it. Compare the result with discovery warnings and the documented selection rules. Test a built-in-name collision through discovery rather than substituting an unreviewed operational extension. Retain fixture identities, path order, invocation and actual result; use that evidence to review the real installation separately. ## Official references - [Extend kubectl with plugins](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/) — Kubernetes. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — Extend kubectl with plugins - Authority: kubernetes.io - URL: https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Resolve kubectl plugin shadowing before invoking an extension,” DSE Security, https://update.dsesecurity.com/updates/resolve-kubectl-plugin-shadowing-before-invoking-an-extension/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.