T07 · Tool Hijacking and Spoofing
- Location
auto_insight_engine.py:8- Finding
Executable Module Hijacking Through a Predictable External Import Path
- Content
View full analysis
Vulnerability Details
File Location:
auto_insight_engine.py, lines 8–19
Vulnerability Type: Untrusted external module loading and Python import-path hijacking
Risk Level: MediumVulnerable Code
python _SRC = Path(__file__).parent.parent.parent / "db" def run(query: str = "status") -> dict: """执行洞察引擎 Args: query: run | status | trends Returns: dict: 操作结果 """ sys.path.insert(0, str(_SRC)) try: from auto_insight_engine import run_cycle, get_engine_statusTechnical Analysis
The skill derives a
dbdirectory outside the audited package, inserts that directory at the beginning of the process-wide Python module search path, and imports executable code from a module namedauto_insight_engine.Given the audited project location, the expression traverses three parent directories and can resolve to a predictable shared location such as
/tmp/db. The imported implementation is not included in the audited project, so neither its integrity nor its behavior can be verified. Python executes module-level statements while importing a module, meaning a malicious file can execute code beforerun_cycleorget_engine_statusis called.Placing the external directory at index zero gives its modules precedence over most normal import locations. The global
sys.pathmodification also remains active after the function returns, potentially affecting later imports in the same Python process.The import occurs before the requested operation is validated. Consequently, requests for
status,trends, and even unsupported operations can reach the vulnerable import statement.The documentation identifies a Windows source path,
D:\coze-local\db\auto_insight_engine.py, while the implementation calculates a relative external path. This mismatch makes the actual trust boundary ambiguous and increases the chance of loading an unintended module. Depending ...[truncated 2282 chars]- Remediation
View remediation
Remediation Suggestions
-
Package the engine implementation inside the skill and use an explicit package-relative import with a distinct module name, for example:
python from .engine_impl import run_cycle, get_engine_status -
Do not modify the process-wide
sys.pathto load executable components. This prevents path-precedence attacks and unintended effects on later imports. -
Validate
querybefore loading operation-specific code. Atrendsor invalid request should not import the engine implementation when it is unnecessary. -
If an external implementation is unavoidable:
- Resolve it from an administrator-controlled, non-temporary directory.
- Reject symbolic links and verify the resolved canonical path.
- Require restrictive directory and file permissions.
- Verify the file against a pinned cryptographic hash or authenticated signature before loading it.
- Load it under a unique, fully qualified module name rather than the generic
auto_insight_enginename. - Avoid leaving external directories in the global import path.
-
Align the documented source location with the implemented location and explicitly document the ownership, deployment, and integrity requirements for the external component.
-
Run the skill under a least-privileged account or sandbox with restricted filesystem, credential, subprocess, and network access to limit the impact of any future module-loading compromise.
-
