The plugin.path setting is a list of directories holding Connect plugins, meaning connectors, converters and transformations. A worker loads code from those directories, so whoever can write to them controls code that runs inside the worker, with its network access and its secrets.
What the docs say
The Apache Kafka Connect user guide defines plugin.path as a list of paths that contain Connect plugins (connectors, converters, transformations). The default is empty. Separately, the worker configuration reference describes a plugin.discovery setting, which decides how plugins in the classpath and plugin path are found. Its modes range from scanning by reflection only, to service loader only, with hybrid modes that warn or fail at startup if a plugin cannot be found through the service loader.
Plugins can also declare themselves through service manifest files under META-INF, for each interface such as source connector, sink connector, converter, transformation and config provider.
Why it is a supply chain question
A connector JAR is third party code with a database driver or an API client inside. Connect workers often hold credentials for several systems at once. So the plugin directory is a trust boundary, and every JAR placed there inherits the worker's access.
| Question | Why ask it |
|---|---|
| Where did this JAR come from? | A download from an unverified page is an unreviewed dependency |
| Which version is installed? | Without a record you cannot match it to advisories |
| What libraries are bundled inside? | A connector can carry its own copies of vulnerable libraries |
| Who can write to the directory? | Write access equals code execution on the worker |
| How does a new plugin get added? | An ad hoc copy to a server is not reviewable |
A review routine
- List every plugin directory on every worker, including images that bake them in.
- For each plugin, record name, version, source and checksum.
- Generate a bill of materials for the plugin's bundled libraries and scan it.
- Lock down write access to those directories to your deployment process only.
- Build the worker image in CI so the same plugin set ships to every worker.
- Remove plugins nobody uses.
Step three is where the surprises are. A plugin is often a fat JAR with its own copies of libraries, and those copies do not show up in a scan of the worker's own dependencies unless the scanner opens the JAR.
Keep config providers separate
Confluent's guide notes that plugin path locations are for connectors and their specific dependent JARs, not for config providers, which belong on the default classpath. Mixing the two causes load failures and muddles who owns what. See Kafka Connect config providers.
Related reading
Network access to the REST API decides who can ask a worker to load a connector in the first place; see who can reach the Kafka Connect REST API on port 8083.
Safeguard's SBOM and dependency scanning can inventory bundled libraries, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Is plugin.path set by default?
The default is empty, per the Kafka docs. Workers load plugins from whichever paths you configure.
Why scan a connector JAR separately?
It can bundle its own library copies, which a scan of the worker's declared dependencies would not report.
Sources
- Kafka Connect user guide, Apache Kafka documentation, fetched 19 October 2026.
- Kafka Connect configs, Apache Kafka documentation, fetched 19 October 2026.
- Kafka Connect security, Confluent documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
