[RockChinQ]

Context

execution.python.path is plugin-authored manifest data, so it is untrusted. The component loader joined it to the manifest's directory, stripped a trailing .py, converted separators to dots and imported — with sys.path.append(os.getcwd()) added on every call and never removed.

What I found when I tested it

The traversal the audit reported does not actually import outside the plugin. ../outside.py becomes <rel_dir>....outside, and the empty dotted segments raise ModuleNotFoundError; the same for ../../ and absolute paths (a leading / becomes a leading .). So there was no exploitable load-arbitrary-module path.

That means the behaviour rested on an accident of string replacement, and two real defects remained:

1. no validation at all — any future refactor of that path handling could make it exploitable;
2. the permanent sys.path.append(os.getcwd()) lets one plugin shadow modules for every plugin loaded afterwards.

Fix

_resolve_component_module resolves the target against the plugin directory and rejects:

• empty / NUL path
• absolute paths, drive letters
• any .. component
• anything whose resolved path leaves the plugin directory (commonpath check)

Import now inserts the plugin directory on sys.path only for the duration of the import and removes it in a finally, so a failure leaves sys.path untouched.

Tests

11 cases in tests/api/definition/test_manifest_component_path.py: every rejection form; a component inside the plugin still imports; a path without the .py suffix; sys.path byte-identical after both success and ModuleNotFoundError; module-cache isolation between cases.

tests/api   513 passed