Security Hardening: Command Injection & Path Traversal Opportunities in PAI/Tools (Findings from PAI-OpenCode Updating Process)

[Steffen025]

Security Hardening: Command Injection & Path Traversal Opportunities in PAI/Tools (WP1 Findings from PAI-OpenCode Port)

Hi Daniel,

First of all, thank you for PAI - it's an incredible system that's fundamentally changed how I work with AI. The community around it (PAI-OpenCode) is growing, and during our v3.0 porting effort we identified several security hardening opportunities in PAI 4.0.3 that we wanted to share upstream for potential inclusion in v4.1.0.

Context

During the PAI-OpenCode v3.0 port (migrating to OpenCode platform while maintaining PAI's core philosophy), we performed a security audit of the PAI/Tools/ directory. We found 9 critical security patterns that could benefit from hardening.

Findings Summary

Category	Tool	Issue	Risk Level
Command Injection	AddBg.ts	execAsync() interpolates user-controlled inputPath and hexColor directly into shell command	Critical
Command Injection	GetTranscript.ts	execSync() interpolates URL directly into fabric command without validation	Critical
Command Injection	RelationshipReflect.ts	execSync() interpolates message and NTFY_TOPIC into curl command	Critical
Path Traversal	FeatureRegistry.ts	project parameter used directly in filename without sanitization	High
Path Traversal	SessionProgress.ts	project parameter used directly in filename without sanitization	High
Path Traversal	PipelineOrchestrator.ts	Pipeline name used directly in file path construction	High
XSS	PipelineMonitor.ts	innerHTML injects user-controlled fields without sanitization	High
XSS	PreviewMarkdown.ts	marked.parse() result assigned to innerHTML without sanitization	High
Logic	BuildCLAUDE.ts / RebuildPAI.ts	Double .md.md extension when LATEST file contains .md	Medium

Recommended Fixes

All fixes follow the same patterns we implemented in PAI-OpenCode:

1. Command Injection → Use execFile/execFileSync with array arguments
2. Path Traversal → Validate input against allowed character set
3. XSS → HTML escape or sanitize before innerHTML
4. .md.md Extension → Normalize version string

Our Implementation

We've implemented these fixes in PAI-OpenCode during the v3.0 port (see PR #33 Steffen025/pai-opencode#33) and can contribute them back as a PR to PAI if helpful.

Question for v4.1.0

Would you like us to:

1. Create a PR with these security hardening fixes for v4.1.0?
2. Wait and include these in a larger security audit for v4.1.0?
3. Document these as "user responsibility" (since PAI is personal infrastructure)?

We wanted to share these findings upstream because we believe security hardening benefits the entire PAI ecosystem. Happy to collaborate however is most helpful for your v4.1.0 roadmap.

Best regards,
Steffen Zellmer
PAI-OpenCode

PS: We'll continue monitoring for security patterns in upcoming Work Packages (WP2-WP7) and will add findings as comments to this issue if new categories emerge.

[Steffen025]

Update: WP2 (Security Hardening) - Additional Threat Vector Identified

Following up on the WP1 findings above, we've completed WP-B: Security Hardening in the PAI-OpenCode port and identified a complementary security layer that would benefit upstream PAI 4.1.0.

Context: Two Different Security Domains

The WP1 findings above address System-Level Security (protecting the host from malicious commands). During WP-B, we implemented Agent-Level Security (protecting the AI agent from malicious prompt injections and credential leaks).

WP-B Implementation: Prompt Injection Defense & Audit Hardening

Component	What We Built	Upstream Applicability
"lib/injection-patterns.ts"	37 patterns across 7 categories (instruction override, role hijacking, system prompt extraction, safety bypass, PII/credential leaks)	✅ New hook: "PromptInjectionGuard.hook.ts"
"lib/sanitizer.ts"	Input normalization pipeline (Base64 decode, Unicode lookalike normalization, obfuscated spacing collapse, HTML tag stripping)	✅ Shared utility for existing hooks
Security audit logging	Fire-and-forget logging with secrets redaction (API keys, PEM keys masked in logs)	✅ Enhancement for "SecurityValidator.hook.ts"

Key Gap in PAI 4.0.3

The current "SecurityValidator.hook.ts" (excellent for Bash/Files) doesn't inspect prompt content for:

• "Ignore all previous instructions" attacks
• API key exposure in agent outputs
• Base64/Unicode obfuscated payloads
• Role hijacking attempts

Recommended Addition for PAI 4.1.0

// New hook: PromptInjectionGuard.hook.ts
// Trigger: PreToolUse (Read, Write, Edit, Bash with args.content/text/prompt)
// Patterns: 7 categories from our implementation

Why separate hooks?

• "SecurityValidator" = System protection (Bash commands, file paths)
• "PromptInjectionGuard" = Agent protection (content scanning, PII detection)

Code Reference

Full implementation: Steffen025/pai-opencode#43

MIT licensed — feel free to adapt any patterns or logic for PAI 4.1.0.

Question

Should we:

1. Create a separate Issue for "Agent-Level Security / Prompt Injection Defense"?
2. Include this as an expansion to this Issue Security Hardening: Command Injection & Path Traversal Opportunities in PAI/Tools (Findings from PAI-OpenCode Updating Process) #904 (making it a comprehensive Security Hardening umbrella)?
3. Wait for v4.1.0 scope definition before proposing additional hooks?

The WP-B patterns are production-tested and ready to contribute whenever aligns with your roadmap.

Best regards,
Steffen