We take security vulnerabilities seriously. If you discover a security issue, please report it responsibly.

DO NOT open a public GitHub issue for security vulnerabilities.

Instead, please email: [email protected] (or open a private security advisory on GitHub)

Include:

• Description of the vulnerability
• Steps to reproduce
• Potential impact
• Suggested fix (if any)

• Third-party dependencies (report to upstream)
• Demo application (packages/demo/)
• Documentation websites

This security self-review was conducted to identify potential vulnerabilities and document the security posture of PoHI before public release.

1. World ID Orb: Provides strong practical Sybil resistance through biometric-based uniqueness checks (does not claim formal biometric infallibility)
2. Cryptographic Primitives: SHA-256, Keccak-256, ZK proofs are computationally secure
3. Blockchain: World Chain provides finality and censorship resistance
4. Time: Block timestamps are reasonably accurate (within minutes)
5. GitHub Context: github.context.sha in Actions is trustworthy

• A unique human (as verified by World ID) approved a specific signal (commit SHA)
• The approval is timestamped and tamper-evident
• The same human cannot approve the same commit twice (nullifier uniqueness)

• That the human understood what they approved (semantic gap)
• That the human intended to approve that specific action (UI/social engineering)
• That the human is authorized by the organization (requires Authority Layer)
• That the code being approved is safe or correct

Attack: Attacker steals victim's phone with World App and approves malicious commit.

Attacker → Steals phone → Opens World App → Scans approval QR → Malicious code deployed

Analysis:

• PoHI correctly records that "a human approved" the commit
• The human verification is technically valid
• This is a credential theft issue, not a protocol flaw

Mitigations:

• World App biometric lock (FaceID/fingerprint)
• Device-level security (passcode)
• Organization policy: require multiple approvers for production

Residual Risk: Accepted (same as any credential-based system)

Attack: Compromised CI runner reports fake GITHUB_SHA / CI_COMMIT_SHA.

Attacker → Compromises self-hosted runner → Modifies environment → Reports wrong SHA

Analysis:

• If runner is compromised, attacker controls the environment
• PoHI would record approval for the wrong commit
• This is a supply chain attack on CI infrastructure

Mitigations:

• Use GitHub/GitLab hosted runners (trusted environment)
• Runner hardening and monitoring
• Compare attestation SHA with actual deployed code

Residual Risk: Medium (depends on runner security)

Attack: Attacker intercepts traffic to approval server and injects fake "approved" response.

CI Job → HTTPS request → Attacker MITM → Fake "approved" response → CI proceeds

Analysis:

• Requires breaking TLS (unlikely) or DNS hijacking
• Even if successful, no valid World ID proof exists
• On-chain verification would fail

Mitigations:

• HTTPS enforced for approval URLs
• Certificate pinning (future enhancement)
• On-chain attestation verification

Residual Risk: Low (requires significant infrastructure compromise)

Attack: Use approval from Repo A to authorize deploy in Repo B.

Attacker → Gets approval for repo-a:abc123 → Tries to use for repo-b:abc123

Analysis:

• Signal = SHA256("repo-a:abc123") ≠ SHA256("repo-b:abc123")
• ZK proof is bound to specific signal
• Verification would fail

Result: ✅ Attack prevented by protocol design

Attack: Two deployments try to use same approval simultaneously.

Deploy Job 1 → Checks approval → ✓
Deploy Job 2 → Checks approval → ✓ (same attestation)
Both deploy simultaneously

Analysis:

• This is not a security issue (same approval used twice is fine)
• The approval is for a specific commit, deploying it twice is valid
• If this is undesired, use on-chain nullifier check

Mitigations:

• On-chain recording marks attestation as "used"
• CI job should mark approval as consumed after use

Residual Risk: Low (depends on use case)

Attack: Same human tries to approve same commit twice (double voting).

Human A → Approves commit X → Recorded with nullifier N
Human A → Tries to approve commit X again → Same nullifier N

Analysis:

• Contract checks: nullifierUsed[commitKey][nullifierHash]
• Second attempt would fail: AlreadyApproved()

Result: ✅ Attack prevented by nullifier uniqueness

Recommendation: Callers of parseAttestation() should call validateAttestation() on the result.

Recommendation:

• Only configure trusted approval-url values
• Future: Add on-chain verification of attestation in Action

Note on Permissionless Design: The contract intentionally allows anyone to record attestations. The security comes from:

1. World ID proof verification (off-chain)
2. Attestation hash uniqueness
3. Nullifier-based duplicate prevention

Recommendations:

• Only configure trusted POHI_APPROVAL_URL values
• Use CI_JOB_TOKEN where possible (limited scope)
• For custom tokens, use minimal required permissions

Recommendations:

• Create App Password with minimal scopes (repository:write, pullrequest:write)
• Only configure trusted POHI_APPROVAL_URL values
• Store BITBUCKET_TOKEN as secured repository variable

1. Expired Merkle Root: World ID has a root expiration window. Old proofs may fail.
2. Action Scope Change: If worldIdAction changes, existing nullifiers don't apply.
3. Signal Mismatch: Commit SHA must exactly match; short SHA not accepted.

• Access Control: Owner-based administration for admin management
• Reentrancy Protection: No external calls in state-changing functions
• Integer Overflow: Solidity 0.8.x built-in checks
• Nullifier Uniqueness: Mapping prevents duplicate approvals per commit
• Custom Errors: Gas-efficient error handling

1. Non-upgradeable: Contracts cannot be upgraded (new versions = new addresses)
2. Permissionless Recording: Security relies on off-chain proof verification
3. Admin Revocation: Admins can revoke any attestation (for emergency response)

• SHA-256: Protocol standard, widely supported, interoperable
• Keccak-256: EVM native, gas efficient for on-chain operations

Both hashes are computed for each attestation to support both off-chain verification and on-chain storage.

• Security patches: Immediate update
• Minor versions: Weekly review
• Major versions: Compatibility testing required

1. Trust Your Approval Server: Only use approval-url values you control or trust
2. Require Orb Verification: Use verification-level: orb for high-security workflows
3. Complement with Code Review: PoHI proves human approval, not code correctness
4. Monitor Attestations: Watch for unexpected approvals on your repositories
5. Multi-Approver Policies: Consider requiring multiple human approvals for critical changes

1. Verify Commit Details: Always check the commit SHA and repository before approving
2. Secure Your World ID: Protect your World ID credentials
3. Report Suspicious Requests: If asked to approve something unexpected, investigate first

Coming soon. We plan to launch a bug bounty program after initial security audit.

Before submitting a PR:

• No secrets or private keys in code
• Input validation for all user inputs
• No unsafe type assertions without validation
• Error messages don't leak sensitive info
• Dependencies are up to date
• Tests cover security-critical paths
• Consider replay, Sybil, and tampering attacks

• Security issues: [email protected]
• General questions: Open a GitHub Discussion