T05 · Unauthorized Access and Privilege Escalation
- Location
openexec/engine.py:42- Finding
Approval artifacts can be replayed for repeated execution
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
OpenExec does not look malicious, but its approval, replay, and receipt guarantees are weaker than documented, so it needs review before production or high-impact use.
Treat this as suitable only for local demo or carefully isolated evaluation until the authorization and audit issues are fixed. Do not rely on it for money movement, email sending, infrastructure changes, data deletion, or other high-impact actions unless approvals are made single-use, replay retrieval is authorization-bound, receipts are signed or HMAC-protected, dependencies are reviewed, ClawShield mode and an explicit action allow-list are enforced, and the service is kept behind localhost/firewall isolation.
openexec/engine.py:42Approval artifacts can be replayed for repeated execution
openexec/engine.py:16Existing-nonce lookup bypasses approval validation and request binding
openexec/receipts.py:3Unkeyed receipt hashes allow arbitrary receipt forgery
The dependency is pinned to cryptography==46.0.5, and the supplied finding indicates multiple published advisories affecting that exact version, including issues in bundled OpenSSL and cryptographic parsing/decryption behavior. In a service whose core trust model relies on signed approval artifacts and verifiable receipts, flaws in the cryptographic library directly undermine signature verification, certificate/path validation, or confidential data handling, making the context more dangerous rather than less.
Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.
- No runtime plugin system
- No remote code execution primitives
- Static handler registry only
- No self-modifying behavior
---
Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.
## 12. Self-Modification
OpenExec does not modify its own code,
write executable files,
or alter system configuration.
This finding is essentially about unverified security claims: the file asserts absence of outbound calls, signed-approval enforcement, pinned behavior, and no runtime downloads without direct proof in the supplied content. Unsupported guarantees are risky in security tooling because they can distort threat modeling and lead users to trust controls that may exist only as documentation statements.
This finding is essentially about unverified security claims: the file asserts absence of outbound calls, signed-approval enforcement, pinned behavior, and no runtime downloads without direct proof in the supplied content. Unsupported guarantees are risky in security tooling because they can distort threat modeling and lead users to trust controls that may exist only as documentation statements.
This finding is essentially about unverified security claims: the file asserts absence of outbound calls, signed-approval enforcement, pinned behavior, and no runtime downloads without direct proof in the supplied content. Unsupported guarantees are risky in security tooling because they can distort threat modeling and lead users to trust controls that may exist only as documentation statements.
This finding is essentially about unverified security claims: the file asserts absence of outbound calls, signed-approval enforcement, pinned behavior, and no runtime downloads without direct proof in the supplied content. Unsupported guarantees are risky in security tooling because they can distort threat modeling and lead users to trust controls that may exist only as documentation statements.
This finding is essentially about unverified security claims: the file asserts absence of outbound calls, signed-approval enforcement, pinned behavior, and no runtime downloads without direct proof in the supplied content. Unsupported guarantees are risky in security tooling because they can distort threat modeling and lead users to trust controls that may exist only as documentation statements.
This finding is essentially about unverified security claims: the file asserts absence of outbound calls, signed-approval enforcement, pinned behavior, and no runtime downloads without direct proof in the supplied content. Unsupported guarantees are risky in security tooling because they can distort threat modeling and lead users to trust controls that may exist only as documentation statements.
This finding is essentially about unverified security claims: the file asserts absence of outbound calls, signed-approval enforcement, pinned behavior, and no runtime downloads without direct proof in the supplied content. Unsupported guarantees are risky in security tooling because they can distort threat modeling and lead users to trust controls that may exist only as documentation statements.
This finding is essentially about unverified security claims: the file asserts absence of outbound calls, signed-approval enforcement, pinned behavior, and no runtime downloads without direct proof in the supplied content. Unsupported guarantees are risky in security tooling because they can distort threat modeling and lead users to trust controls that may exist only as documentation statements.
This finding is essentially about unverified security claims: the file asserts absence of outbound calls, signed-approval enforcement, pinned behavior, and no runtime downloads without direct proof in the supplied content. Unsupported guarantees are risky in security tooling because they can distort threat modeling and lead users to trust controls that may exist only as documentation statements.
This finding is essentially about unverified security claims: the file asserts absence of outbound calls, signed-approval enforcement, pinned behavior, and no runtime downloads without direct proof in the supplied content. Unsupported guarantees are risky in security tooling because they can distort threat modeling and lead users to trust controls that may exist only as documentation statements.
The manifest says the service 'Runs only with a signed approval artifact (ClawShield mode),' but this endpoint explicitly supports and reports a default 'demo' mode with signature verification disabled. It also reports an 'open' restriction state and warns when no execution allow-list is configured, indicating operation outside the claimed mandatory approval-only model.
The engine explicitly bypasses approval validation in demo mode by setting approved = True without requiring or verifying a signed approval artifact. That directly contradicts the stated security model that execution is gated by signed approval, so if demo mode is enabled in any reachable environment, unauthorized actions can execute while appearing legitimately approved.
Package name closely resembles a popular package, suggesting possible typosquatting. Attackers publish malicious packages with similar names to trick developers into installing them.
The script performs pip install -r requirements.txt, which directly contradicts the skill metadata claim that no runtime package installation or dynamic downloads occur. This creates supply-chain risk because installation behavior depends on package indexes and the contents of requirements.txt, allowing unreviewed or mutable dependencies to be fetched and executed during setup.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Confirm health:
curl http://localhost:5000/health
Execute:
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
tool_call = model_output["tool_calls"][0]
response = requests.post(
"http://localhost:5000/execute",
json={
"action": tool_call["function"]["name"],
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
tool_call = model_output["tool_calls"][0]
response = requests.post(
"http://localhost:5000/execute",
json={
"action": tool_call["function"]["name"],
Code issues a request to a loopback, link-local, or private-range host. This can reach internal services not meant to be exposed and is a common SSRF pivot.
tool_call = model_output["tool_calls"][0]
response = requests.post(
"http://localhost:5000/execute",
json={
"action": tool_call["function"]["name"],
Line L182 states 'OpenExec determines whether it runs,' which contradicts repeated statements elsewhere in the same file that OpenExec does not define policy, decide approvals, or originate execution authority. The documented intent is that OpenExec verifies externally produced approval artifacts and executes only already-authorized actions, so this wording materially misstates the security boundary.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- Forged approval artifacts (ClawShield mode)
- Parameter mutation after approval
- Silent execution without receipt
- Unauthorized execution without approval
OpenExec does NOT protect against:
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- [ ] Use TLS termination
- [ ] Pin dependencies (already enforced in `requirements.txt`)
- [ ] Run inside container or VM
- [ ] Do NOT run as root
- [ ] Configure `OPENEXEC_ALLOWED_ACTIONS`
- [ ] Provide valid `CLAWSHIELD_PUBLIC_KEY`
- [ ] Protect `CLAWSHIELD_TENANT_ID` appropriately
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- [ ] Use TLS termination
- [ ] Pin dependencies (already enforced in `requirements.txt`)
- [ ] Run inside container or VM
- [ ] Do NOT run as root
- [ ] Configure `OPENEXEC_ALLOWED_ACTIONS`
- [ ] Provide valid `CLAWSHIELD_PUBLIC_KEY`
- [ ] Protect `CLAWSHIELD_TENANT_ID` appropriately
No suspicious patterns detected.